Re: [Paraview] Multiple temporal shifts still not working right
Hey John, Unfortunately, this didn't do it either. When you get around to looking at it more closely, load up the simple data set I sent at the beginning of the thread (or that Ken posted to the bug report), put two temporal shift scales branching off of it, one with zero post-shift and one with a post-shift of 1. Group those two temporal shift scales and look at the output. Step forward and backward in time -- the behavior is different each direction. Go to the Information tab of the grouped data set -- it shows a Multi-block Dataset of two Unstructured Grids, and the Current Time Step for each looks right, but the data itself (the scalar "Step", and the X range) is clearly not different between the two UGs. Also, in one direction, the Current Time only increments every other click of the time increment button. Hope you're able to track it down. Thanks again, -Eric On Dec 2, 2008, at 12:39 PM, John Biddiscombe wrote: Eric OK I was waiting for some files to copy, so I had a quick edit of vtkTemporalSnapToTimeStep and vtkTemporalShiftScale. Both these classes derived from vtkTemporalDataSetAlgorithm, but this was wrong, when we reimplemented the Temporal stuff, it was possible for these classes to derive from vtkDataObject. All they do is change information. You can now connect them to normal filters willy nilly, without vtkTemporalDataSets being created all over the shop. Tyr updating from CVS the 4 files in Hybrid vtkTemporalSnap* vtkTemporalShift* then have another go. Get rid of any TemporalCache filters that you don't need too. I've been meaning to do this for ages. I hope it makes a difference. I still haven't actually read all your emails, but I'm sure there was some dodgy temporal caching/dataset swapping going on, this ought to make it easier to track down when I do look into it properly at least JB Hey John, I really appreciate the suggestion, but it doesn't seem to do anything to solve this problem. If you can take a look at this after Christmas that would be great! Thanks, -Eric On Dec 2, 2008, at 4:00 AM, John Biddiscombe wrote: Eric, I had a temporal problem and made a small change to vtkCompositeDataPipeline which fixed my trouble. It occurred to me (and I confess that due to other deadlines, I have not followed this thread carefully, but I will fix the problem after Christmas) - that perhaps your problem was related. Try this open vtkCompositeDataPipeline search for two lines with hasRTD = true and comment them out - like so! // hasRTD = true; Now tell me if your pipeline does what you expect. I don't know why REQUIRES_TIME_DOWNSTREAM is actually being forwarded up the pipeline, the executive should replace the output of the filter it is working with now, and others can do as they please. I was getting all sorts of nonsense with multiple temporal filters causing outputs to be replaced all over the place, this solved it. It may not be applicable to your case, but if it works...please let me know. JB I added this information to the bug report. -Ken On 11/25/08 11:33 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote: Hey Ken, Thanks a lot for looking into this -- I'm sure it was a pleasure to see it pop up again! :) Your workaround using the temporal cache filter seems to work as long as I do the grouping in the "correct" order. If I first click on the shift(0) filter, and then command-click to also select the shift(1) filter and then group the data sets, stepping forward in time only shows one point, but then backwards in time shows the correct thing: two points trailing each other. If I select the shift(1) first and then the shift(0), stepping forwards in time works, but not backwards. (Although, I still get a "stutter" sometimes where on the second click forwards after applying the group filter the points collapse for one step...) If I select in the "wrong" order, but increase the size of the caches (up from the original 2), I can get the points to look right for one or two steps forwards sometimes. They always look right going forward if I've just stepped backwards through that time range so the data is in the caches. So, temporal caching fixes it if the filters are selected in the "right" order for the order in which the time is going to be stepped... Thanks, -Eric On Nov 24, 2008, at 6:58 PM, Moreland, Kenneth wrote: Nuts. I guess it wasn’t fixed after all. I submitted a new bug report with your new description. http://www.paraview.org/Bug/view.php?id=8156 Note that I think I found a workaround using the temporal cache filter. (Details in the bug report.) -Ken On 11/21/08 8:15 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote: Hey, Sorry for the long email, but I find this problem difficult to describe succinctly... In Febr
Re: [Paraview] Multiple temporal shifts still not working right
erratum... it was possible for these classes to derive from vtkDataObjectAlgorithm Note to self : re-Read before clicking send. JB ___ ParaView mailing list ParaView@paraview.org http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Multiple temporal shifts still not working right
Eric OK I was waiting for some files to copy, so I had a quick edit of vtkTemporalSnapToTimeStep and vtkTemporalShiftScale. Both these classes derived from vtkTemporalDataSetAlgorithm, but this was wrong, when we reimplemented the Temporal stuff, it was possible for these classes to derive from vtkDataObject. All they do is change information. You can now connect them to normal filters willy nilly, without vtkTemporalDataSets being created all over the shop. Tyr updating from CVS the 4 files in Hybrid vtkTemporalSnap* vtkTemporalShift* then have another go. Get rid of any TemporalCache filters that you don't need too. I've been meaning to do this for ages. I hope it makes a difference. I still haven't actually read all your emails, but I'm sure there was some dodgy temporal caching/dataset swapping going on, this ought to make it easier to track down when I do look into it properly at least JB Hey John, I really appreciate the suggestion, but it doesn't seem to do anything to solve this problem. If you can take a look at this after Christmas that would be great! Thanks, -Eric On Dec 2, 2008, at 4:00 AM, John Biddiscombe wrote: Eric, I had a temporal problem and made a small change to vtkCompositeDataPipeline which fixed my trouble. It occurred to me (and I confess that due to other deadlines, I have not followed this thread carefully, but I will fix the problem after Christmas) - that perhaps your problem was related. Try this open vtkCompositeDataPipeline search for two lines with hasRTD = true and comment them out - like so! // hasRTD = true; Now tell me if your pipeline does what you expect. I don't know why REQUIRES_TIME_DOWNSTREAM is actually being forwarded up the pipeline, the executive should replace the output of the filter it is working with now, and others can do as they please. I was getting all sorts of nonsense with multiple temporal filters causing outputs to be replaced all over the place, this solved it. It may not be applicable to your case, but if it works...please let me know. JB I added this information to the bug report. -Ken On 11/25/08 11:33 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote: Hey Ken, Thanks a lot for looking into this -- I'm sure it was a pleasure to see it pop up again! :) Your workaround using the temporal cache filter seems to work as long as I do the grouping in the "correct" order. If I first click on the shift(0) filter, and then command-click to also select the shift(1) filter and then group the data sets, stepping forward in time only shows one point, but then backwards in time shows the correct thing: two points trailing each other. If I select the shift(1) first and then the shift(0), stepping forwards in time works, but not backwards. (Although, I still get a "stutter" sometimes where on the second click forwards after applying the group filter the points collapse for one step...) If I select in the "wrong" order, but increase the size of the caches (up from the original 2), I can get the points to look right for one or two steps forwards sometimes. They always look right going forward if I've just stepped backwards through that time range so the data is in the caches. So, temporal caching fixes it if the filters are selected in the "right" order for the order in which the time is going to be stepped... Thanks, -Eric On Nov 24, 2008, at 6:58 PM, Moreland, Kenneth wrote: Nuts. I guess it wasn’t fixed after all. I submitted a new bug report with your new description. http://www.paraview.org/Bug/view.php?id=8156 Note that I think I found a workaround using the temporal cache filter. (Details in the bug report.) -Ken On 11/21/08 8:15 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote: Hey, Sorry for the long email, but I find this problem difficult to describe succinctly... In February I was trying to use multiple Temporal Shift Scale filters as input to a Python Programmable Filter to do on-the-fly point velocity calculations (for diffusing particles in my simulation output). There were troubles with the pipeline updating properly, and Ken Moreland came up with a nice self-contained test case and filed the bug 6307: http://www.paraview.org/Bug/view.php?id=6307 which was listed in August as "fixed" because the test case seemed to work now. But, I don't think this is really resolved yet. If you load in the TimeShiftTest2.pvsm state file, the animation seems to play correctly, but I think that's a red herring. If you turn off the visibility of the TemporalShiftScale filters, you can see that no box
Re: [Paraview] Multiple temporal shifts still not working right
Hey John, I really appreciate the suggestion, but it doesn't seem to do anything to solve this problem. If you can take a look at this after Christmas that would be great! Thanks, -Eric On Dec 2, 2008, at 4:00 AM, John Biddiscombe wrote: Eric, I had a temporal problem and made a small change to vtkCompositeDataPipeline which fixed my trouble. It occurred to me (and I confess that due to other deadlines, I have not followed this thread carefully, but I will fix the problem after Christmas) - that perhaps your problem was related. Try this open vtkCompositeDataPipeline search for two lines with hasRTD = true and comment them out - like so! // hasRTD = true; Now tell me if your pipeline does what you expect. I don't know why REQUIRES_TIME_DOWNSTREAM is actually being forwarded up the pipeline, the executive should replace the output of the filter it is working with now, and others can do as they please. I was getting all sorts of nonsense with multiple temporal filters causing outputs to be replaced all over the place, this solved it. It may not be applicable to your case, but if it works...please let me know. JB I added this information to the bug report. -Ken On 11/25/08 11:33 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote: Hey Ken, Thanks a lot for looking into this -- I'm sure it was a pleasure to see it pop up again! :) Your workaround using the temporal cache filter seems to work as long as I do the grouping in the "correct" order. If I first click on the shift(0) filter, and then command-click to also select the shift(1) filter and then group the data sets, stepping forward in time only shows one point, but then backwards in time shows the correct thing: two points trailing each other. If I select the shift(1) first and then the shift(0), stepping forwards in time works, but not backwards. (Although, I still get a "stutter" sometimes where on the second click forwards after applying the group filter the points collapse for one step...) If I select in the "wrong" order, but increase the size of the caches (up from the original 2), I can get the points to look right for one or two steps forwards sometimes. They always look right going forward if I've just stepped backwards through that time range so the data is in the caches. So, temporal caching fixes it if the filters are selected in the "right" order for the order in which the time is going to be stepped... Thanks, -Eric On Nov 24, 2008, at 6:58 PM, Moreland, Kenneth wrote: Nuts. I guess it wasn’t fixed after all. I submitted a new bug report with your new description. http://www.paraview.org/Bug/view.php?id=8156 Note that I think I found a workaround using the temporal cache filter. (Details in the bug report.) -Ken On 11/21/08 8:15 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote: Hey, Sorry for the long email, but I find this problem difficult to describe succinctly... In February I was trying to use multiple Temporal Shift Scale filters as input to a Python Programmable Filter to do on-the-fly point velocity calculations (for diffusing particles in my simulation output). There were troubles with the pipeline updating properly, and Ken Moreland came up with a nice self-contained test case and filed the bug 6307: http://www.paraview.org/Bug/view.php?id=6307 which was listed in August as "fixed" because the test case seemed to work now. But, I don't think this is really resolved yet. If you load in the TimeShiftTest2.pvsm state file, the animation seems to play correctly, but I think that's a red herring. If you turn off the visibility of the TemporalShiftScale filters, you can see that no boxes move until after t=1.0, whereas if the temporal filters are turned on, and the group filter is turned off, one box moves and then the other. I don't know if this helps, but if you look at the Output printed by the Python filter in TimeShiftTest1.pvsm, you can see that the temporal data sets have the correct time, but the ImageData within them doesn't match. .. All of this is much more clear to me when I load in a simple data set with one point moving in time (attached Xdmf data set -- I'll also attach a link to a state file which sets this pipeline up, but you'll have to change the path for the data file in the state file manually if you want to use it). The pip
Re: [Paraview] Multiple temporal shifts still not working right
Eric, I had a temporal problem and made a small change to vtkCompositeDataPipeline which fixed my trouble. It occurred to me (and I confess that due to other deadlines, I have not followed this thread carefully, but I will fix the problem after Christmas) - that perhaps your problem was related. Try this open vtkCompositeDataPipeline search for two lines with hasRTD = true and comment them out - like so! // hasRTD = true; Now tell me if your pipeline does what you expect. I don't know why REQUIRES_TIME_DOWNSTREAM is actually being forwarded up the pipeline, the executive should replace the output of the filter it is working with now, and others can do as they please. I was getting all sorts of nonsense with multiple temporal filters causing outputs to be replaced all over the place, this solved it. It may not be applicable to your case, but if it works...please let me know. JB I added this information to the bug report. -Ken On 11/25/08 11:33 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote: Hey Ken, Thanks a lot for looking into this -- I'm sure it was a pleasure to see it pop up again! :) Your workaround using the temporal cache filter seems to work as long as I do the grouping in the "correct" order. If I first click on the shift(0) filter, and then command-click to also select the shift(1) filter and then group the data sets, stepping forward in time only shows one point, but then backwards in time shows the correct thing: two points trailing each other. If I select the shift(1) first and then the shift(0), stepping forwards in time works, but not backwards. (Although, I still get a "stutter" sometimes where on the second click forwards after applying the group filter the points collapse for one step...) If I select in the "wrong" order, but increase the size of the caches (up from the original 2), I can get the points to look right for one or two steps forwards sometimes. They always look right going forward if I've just stepped backwards through that time range so the data is in the caches. So, temporal caching fixes it if the filters are selected in the "right" order for the order in which the time is going to be stepped... Thanks, -Eric On Nov 24, 2008, at 6:58 PM, Moreland, Kenneth wrote: Nuts. I guess it wasn’t fixed after all. I submitted a new bug report with your new description. http://www.paraview.org/Bug/view.php?id=8156 Note that I think I found a workaround using the temporal cache filter. (Details in the bug report.) -Ken On 11/21/08 8:15 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote: Hey, Sorry for the long email, but I find this problem difficult to describe succinctly... In February I was trying to use multiple Temporal Shift Scale filters as input to a Python Programmable Filter to do on-the-fly point velocity calculations (for diffusing particles in my simulation output). There were troubles with the pipeline updating properly, and Ken Moreland came up with a nice self-contained test case and filed the bug 6307: http://www.paraview.org/Bug/view.php?id=6307 which was listed in August as "fixed" because the test case seemed to work now. But, I don't think this is really resolved yet. If you load in the TimeShiftTest2.pvsm state file, the animation seems to play correctly, but I think that's a red herring. If you turn off the visibility of the TemporalShiftScale filters, you can see that no boxes move until after t=1.0, whereas if the temporal filters are turned on, and the group filter is turned off, one box moves and then the other. I don't know if this helps, but if you look at the Output printed by the Python filter in TimeShiftTest1.pvsm, you can see that the temporal data sets have the correct time, but the ImageData within them doesn't match. .. All of this is much more clear to me when I load in a simple data set with one point moving in time (attached Xdmf data set -- I'll also attach a link to a state file which sets this pipeline up, but you'll have to change the path for the data file in the state file manually if you want to use it). The pipeline is: Load data. Add a Temporal Shift Scale with (post) shift=0. Add another TSS off the original data set with (post) shift = 1. Highlight both
Re: [Paraview] Multiple temporal shifts still not working right
I added this information to the bug report.
-Ken
On 11/25/08 11:33 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote:
Hey Ken,
Thanks a lot for looking into this -- I'm sure it was a pleasure to see it pop
up again! :)
Your workaround using the temporal cache filter seems to work as long as I do
the grouping in the "correct" order. If I first click on the shift(0) filter,
and then command-click to also select the shift(1) filter and then group the
data sets, stepping forward in time only shows one point, but then backwards in
time shows the correct thing: two points trailing each other. If I select the
shift(1) first and then the shift(0), stepping forwards in time works, but not
backwards. (Although, I still get a "stutter" sometimes where on the second
click forwards after applying the group filter the points collapse for one
step...)
If I select in the "wrong" order, but increase the size of the caches (up from
the original 2), I can get the points to look right for one or two steps
forwards sometimes. They always look right going forward if I've just stepped
backwards through that time range so the data is in the caches.
So, temporal caching fixes it if the filters are selected in the "right" order
for the order in which the time is going to be stepped...
Thanks,
-Eric
On Nov 24, 2008, at 6:58 PM, Moreland, Kenneth wrote:
Nuts. I guess it wasn't fixed after all. I submitted a new bug report with
your new description.
http://www.paraview.org/Bug/view.php?id=8156
Note that I think I found a workaround using the temporal cache filter.
(Details in the bug report.)
-Ken
On 11/21/08 8:15 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote:
Hey,
Sorry for the long email, but I find this problem difficult to
describe succinctly...
In February I was trying to use multiple Temporal Shift Scale filters
as input to a Python Programmable Filter to do on-the-fly point
velocity calculations (for diffusing particles in my simulation
output). There were troubles with the pipeline updating properly, and
Ken Moreland came up with a nice self-contained test case and filed
the bug 6307:
http://www.paraview.org/Bug/view.php?id=6307
which was listed in August as "fixed" because the test case seemed to
work now. But, I don't think this is really resolved yet.
If you load in the TimeShiftTest2.pvsm state file, the animation seems
to play correctly, but I think that's a red herring. If you turn off
the visibility of the TemporalShiftScale filters, you can see that no
boxes move until after t=1.0, whereas if the temporal filters are
turned on, and the group filter is turned off, one box moves and then
the other.
I don't know if this helps, but if you look at the Output printed by
the Python filter in TimeShiftTest1.pvsm, you can see that the
temporal data sets have the correct time, but the ImageData within
them doesn't match.
..
All of this is much more clear to me when I load in a simple data set
with one point moving in time (attached Xdmf data set -- I'll also
attach a link to a state file which sets this pipeline up, but you'll
have to change the path for the data file in the state file manually
if you want to use it).
The pipeline is: Load data. Add a Temporal Shift Scale with (post)
shift=0. Add another TSS off the original data set with (post) shift =
1. Highlight both TSSs and route into a Python Programmable Filter
with Unstructured Grid output and this script:
in0 = self.GetInputDataObject(0,0)
ds0 = in0.GetTimeStep(0)
in1 = self.GetInputDataObject(0,1)
ds1 = in1.GetTimeStep(0)
print 'in1 t = %.1f' % in1.GetInformation().Get(in1.DATA_TIME_STEPS(),0)
print 'ds1 t = %.1f' % ds1.GetInformation().Get(ds1.DATA_TIME_STEPS(),0)
print 'in0 t = %.1f' % in0.GetInformation().Get(in0.DATA_TIME_STEPS(),0)
print 'ds0 t = %.1f' % ds0.GetInformation().Get(ds0.DATA_TIME_STEPS(),0)
out1 = self.GetOutputDataObject(0)
out1.ShallowCopy(ds0)
print 'out1 t = %.1f' %
out1.GetInformation().Get(out1.DATA_TIME_STEPS(),0)
When I animate this (PV CVS or 3.4, OS X 10.5.5), with the TSSs on and
the PPF off, I see the expected: two points, one following the other.
When the TSSs are off and the PPF is on, only one point shows up.
Also, the behavior is different if the animation is stepped backwards
rather than forwards. And, the printed Output times from the PPF show
one of the ImageData sets time doesn't match its temporal host.
As in Ken's example, this works very similarly with a Group filter in
place of the PPF.
This still seems very confusing, and I hope someone will have some clue!
Thanks,
-Eric
--
Eric E Monson
Duke Visualization Technology Group
Test data set:
Kenneth Moreland
*** Sandia National Laboratories
***
*** *** *** email: [EMAIL PROTECTED]
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel
Re: [Paraview] Multiple temporal shifts still not working right
Hey Ken,
Thanks a lot for looking into this -- I'm sure it was a pleasure to
see it pop up again! :)
Your workaround using the temporal cache filter seems to work as long
as I do the grouping in the "correct" order. If I first click on the
shift(0) filter, and then command-click to also select the shift(1)
filter and then group the data sets, stepping forward in time only
shows one point, but then backwards in time shows the correct thing:
two points trailing each other. If I select the shift(1) first and
then the shift(0), stepping forwards in time works, but not backwards.
(Although, I still get a "stutter" sometimes where on the second click
forwards after applying the group filter the points collapse for one
step...)
If I select in the "wrong" order, but increase the size of the caches
(up from the original 2), I can get the points to look right for one
or two steps forwards sometimes. They always look right going forward
if I've just stepped backwards through that time range so the data is
in the caches.
So, temporal caching fixes it if the filters are selected in the
"right" order for the order in which the time is going to be stepped...
Thanks,
-Eric
On Nov 24, 2008, at 6:58 PM, Moreland, Kenneth wrote:
Nuts. I guess it wasn’t fixed after all. I submitted a new bug
report with your new description.
http://www.paraview.org/Bug/view.php?id=8156
Note that I think I found a workaround using the temporal cache
filter. (Details in the bug report.)
-Ken
On 11/21/08 8:15 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote:
Hey,
Sorry for the long email, but I find this problem difficult to
describe succinctly...
In February I was trying to use multiple Temporal Shift Scale filters
as input to a Python Programmable Filter to do on-the-fly point
velocity calculations (for diffusing particles in my simulation
output). There were troubles with the pipeline updating properly, and
Ken Moreland came up with a nice self-contained test case and filed
the bug 6307:
http://www.paraview.org/Bug/view.php?id=6307
which was listed in August as "fixed" because the test case seemed to
work now. But, I don't think this is really resolved yet.
If you load in the TimeShiftTest2.pvsm state file, the animation seems
to play correctly, but I think that's a red herring. If you turn off
the visibility of the TemporalShiftScale filters, you can see that no
boxes move until after t=1.0, whereas if the temporal filters are
turned on, and the group filter is turned off, one box moves and then
the other.
I don't know if this helps, but if you look at the Output printed by
the Python filter in TimeShiftTest1.pvsm, you can see that the
temporal data sets have the correct time, but the ImageData within
them doesn't match.
..
All of this is much more clear to me when I load in a simple data set
with one point moving in time (attached Xdmf data set -- I'll also
attach a link to a state file which sets this pipeline up, but you'll
have to change the path for the data file in the state file manually
if you want to use it).
The pipeline is: Load data. Add a Temporal Shift Scale with (post)
shift=0. Add another TSS off the original data set with (post) shift =
1. Highlight both TSSs and route into a Python Programmable Filter
with Unstructured Grid output and this script:
in0 = self.GetInputDataObject(0,0)
ds0 = in0.GetTimeStep(0)
in1 = self.GetInputDataObject(0,1)
ds1 = in1.GetTimeStep(0)
print 'in1 t = %.1f' %
in1.GetInformation().Get(in1.DATA_TIME_STEPS(),0)
print 'ds1 t = %.1f' %
ds1.GetInformation().Get(ds1.DATA_TIME_STEPS(),0)
print 'in0 t = %.1f' %
in0.GetInformation().Get(in0.DATA_TIME_STEPS(),0)
print 'ds0 t = %.1f' %
ds0.GetInformation().Get(ds0.DATA_TIME_STEPS(),0)
out1 = self.GetOutputDataObject(0)
out1.ShallowCopy(ds0)
print 'out1 t = %.1f' %
out1.GetInformation().Get(out1.DATA_TIME_STEPS(),0)
When I animate this (PV CVS or 3.4, OS X 10.5.5), with the TSSs on and
the PPF off, I see the expected: two points, one following the other.
When the TSSs are off and the PPF is on, only one point shows up.
Also, the behavior is different if the animation is stepped backwards
rather than forwards. And, the printed Output times from the PPF show
one of the ImageData sets time doesn't match its temporal host.
As in Ken's example, this works very similarly with a Group filter in
place of the PPF.
This still seems very confusing, and I hope someone will have some
clue!
Thanks,
-Eric
--
Eric E Monson
Duke Visualization Technology Group
Test data set:
Kenneth Moreland
*** Sandia National Laboratories
***
*** *** *** email: [EMAIL PROTECTED]
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel
___
ParaView mailing list
ParaView@paraview.org
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Multiple temporal shifts still not working right
Nuts. I guess it wasn't fixed after all. I submitted a new bug report with
your new description.
http://www.paraview.org/Bug/view.php?id=8156
Note that I think I found a workaround using the temporal cache filter.
(Details in the bug report.)
-Ken
On 11/21/08 8:15 AM, "Eric E. Monson" <[EMAIL PROTECTED]> wrote:
Hey,
Sorry for the long email, but I find this problem difficult to
describe succinctly...
In February I was trying to use multiple Temporal Shift Scale filters
as input to a Python Programmable Filter to do on-the-fly point
velocity calculations (for diffusing particles in my simulation
output). There were troubles with the pipeline updating properly, and
Ken Moreland came up with a nice self-contained test case and filed
the bug 6307:
http://www.paraview.org/Bug/view.php?id=6307
which was listed in August as "fixed" because the test case seemed to
work now. But, I don't think this is really resolved yet.
If you load in the TimeShiftTest2.pvsm state file, the animation seems
to play correctly, but I think that's a red herring. If you turn off
the visibility of the TemporalShiftScale filters, you can see that no
boxes move until after t=1.0, whereas if the temporal filters are
turned on, and the group filter is turned off, one box moves and then
the other.
I don't know if this helps, but if you look at the Output printed by
the Python filter in TimeShiftTest1.pvsm, you can see that the
temporal data sets have the correct time, but the ImageData within
them doesn't match.
..
All of this is much more clear to me when I load in a simple data set
with one point moving in time (attached Xdmf data set -- I'll also
attach a link to a state file which sets this pipeline up, but you'll
have to change the path for the data file in the state file manually
if you want to use it).
The pipeline is: Load data. Add a Temporal Shift Scale with (post)
shift=0. Add another TSS off the original data set with (post) shift =
1. Highlight both TSSs and route into a Python Programmable Filter
with Unstructured Grid output and this script:
in0 = self.GetInputDataObject(0,0)
ds0 = in0.GetTimeStep(0)
in1 = self.GetInputDataObject(0,1)
ds1 = in1.GetTimeStep(0)
print 'in1 t = %.1f' % in1.GetInformation().Get(in1.DATA_TIME_STEPS(),0)
print 'ds1 t = %.1f' % ds1.GetInformation().Get(ds1.DATA_TIME_STEPS(),0)
print 'in0 t = %.1f' % in0.GetInformation().Get(in0.DATA_TIME_STEPS(),0)
print 'ds0 t = %.1f' % ds0.GetInformation().Get(ds0.DATA_TIME_STEPS(),0)
out1 = self.GetOutputDataObject(0)
out1.ShallowCopy(ds0)
print 'out1 t = %.1f' %
out1.GetInformation().Get(out1.DATA_TIME_STEPS(),0)
When I animate this (PV CVS or 3.4, OS X 10.5.5), with the TSSs on and
the PPF off, I see the expected: two points, one following the other.
When the TSSs are off and the PPF is on, only one point shows up.
Also, the behavior is different if the animation is stepped backwards
rather than forwards. And, the printed Output times from the PPF show
one of the ImageData sets time doesn't match its temporal host.
As in Ken's example, this works very similarly with a Group filter in
place of the PPF.
This still seems very confusing, and I hope someone will have some clue!
Thanks,
-Eric
--
Eric E Monson
Duke Visualization Technology Group
Test data set:
Kenneth Moreland
*** Sandia National Laboratories
***
*** *** *** email: [EMAIL PROTECTED]
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel
___
ParaView mailing list
ParaView@paraview.org
http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Multiple temporal shifts still not working right
Hey, Sorry for the long email, but I find this problem difficult to describe succinctly... In February I was trying to use multiple Temporal Shift Scale filters as input to a Python Programmable Filter to do on-the-fly point velocity calculations (for diffusing particles in my simulation output). There were troubles with the pipeline updating properly, and Ken Moreland came up with a nice self-contained test case and filed the bug 6307: http://www.paraview.org/Bug/view.php?id=6307 which was listed in August as "fixed" because the test case seemed to work now. But, I don't think this is really resolved yet. If you load in the TimeShiftTest2.pvsm state file, the animation seems to play correctly, but I think that's a red herring. If you turn off the visibility of the TemporalShiftScale filters, you can see that no boxes move until after t=1.0, whereas if the temporal filters are turned on, and the group filter is turned off, one box moves and then the other. I don't know if this helps, but if you look at the Output printed by the Python filter in TimeShiftTest1.pvsm, you can see that the temporal data sets have the correct time, but the ImageData within them doesn't match. .. All of this is much more clear to me when I load in a simple data set with one point moving in time (attached Xdmf data set -- I'll also attach a link to a state file which sets this pipeline up, but you'll have to change the path for the data file in the state file manually if you want to use it). The pipeline is: Load data. Add a Temporal Shift Scale with (post) shift=0. Add another TSS off the original data set with (post) shift = 1. Highlight both TSSs and route into a Python Programmable Filter with Unstructured Grid output and this script: in0 = self.GetInputDataObject(0,0) ds0 = in0.GetTimeStep(0) in1 = self.GetInputDataObject(0,1) ds1 = in1.GetTimeStep(0) print 'in1 t = %.1f' % in1.GetInformation().Get(in1.DATA_TIME_STEPS(),0) print 'ds1 t = %.1f' % ds1.GetInformation().Get(ds1.DATA_TIME_STEPS(),0) print 'in0 t = %.1f' % in0.GetInformation().Get(in0.DATA_TIME_STEPS(),0) print 'ds0 t = %.1f' % ds0.GetInformation().Get(ds0.DATA_TIME_STEPS(),0) out1 = self.GetOutputDataObject(0) out1.ShallowCopy(ds0) print 'out1 t = %.1f' % out1.GetInformation().Get(out1.DATA_TIME_STEPS(),0) When I animate this (PV CVS or 3.4, OS X 10.5.5), with the TSSs on and the PPF off, I see the expected: two points, one following the other. When the TSSs are off and the PPF is on, only one point shows up. Also, the behavior is different if the animation is stepped backwards rather than forwards. And, the printed Output times from the PPF show one of the ImageData sets time doesn't match its temporal host. As in Ken's example, this works very similarly with a Group filter in place of the PPF. This still seems very confusing, and I hope someone will have some clue! Thanks, -Eric -- Eric E Monson Duke Visualization Technology Group Test data set: singlePointTest1.xmf Description: Binary data State file to set up pipeline automatically: http://www.cs.duke.edu/~emonson/TimeShiftData3.pvsm ___ ParaView mailing list ParaView@paraview.org http://www.paraview.org/mailman/listinfo/paraview
