[Paraview] Temporal shift with Python Programmable Filter
Eric Monson
emonson at cs.duke.edu
Wed Feb 6 14:33:34 EST 2008
Hey Ken,
Sorry, I was wrong. Under some fluke situation (that has happened
twice during my testing, but that I can't figure out how to reproduce)
it all works, but not usually.
Instead of me trying to describe details again, is there any chance
you can just load my (small toy) data set and see how it works on your
end? I'm attaching a zip file with a pvsm state file, plus the pvd and
folder of vtu files for the data. (You'll have to edit the state file
so that the pvd file path is correct for wherever you unpack
everything on your system.)
If this isn't convenient for you, tomorrow morning I can get back to
this and figure out how to describe the current state of affairs.
Thanks,
-Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CircleTimeShift.zip
Type: application/zip
Size: 40666 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/paraview/attachments/20080206/8d7ba6d6/CircleTimeShift-0001.zip
-------------- next part --------------
On Feb 6, 2008, at 11:49 AM, Eric Monson wrote:
> Great job -- that seems to have fixed most of it. Thanks!
>
> There's still a little odd behavior at t = 0 and t = end. At t = 0
> the Shift 0 UG still says t = 1.0, and at t = end the Shift 1 UG
> still says t = end-1...
>
> Thanks again,
> -Eric
>
>
> On Feb 6, 2008, at 10:57 AM, Moreland, Kenneth wrote:
>
>> So I think I know what is happening here. When
>> vtkTemporalShiftScale copies data from input to output, it just
>> copies pointers of all the data sets it contains. Thus, when
>> vtkTemporalShiftScale changes the time step of the unstructured
>> grid, it is also changing the time step for the same object earlier
>> in the pipeline. This is probably causing problems with the time
>> checking upstream in the pipeline and timesteps elsewhere that also
>> share this data object.
>>
>> I have attached some more changes to vtkTemporalShiftScale that
>> might fix this problem. This version iterates over all the
>> multiblock data sets and creates a new copy of the data sets (but
>> still keeping shallow copies of field and connectivity data). Note
>> that I made these changes against the latest CVS version of
>> ParaView. I think things might have changed a bit since the 3.2.1
>> release.
>>
>> -Ken
>>
>>> -----Original Message-----
>>> From: Eric Monson [mailto:emonson at cs.duke.edu]
>>> Sent: Wednesday, February 06, 2008 8:00 AM
>>> To: Moreland, Kenneth
>>> Cc: ParaView List
>>> Subject: Re: [Paraview] Temporal shift with Python Programmable
>>> Filter
>>>
>>> Hey Ken,
>>>
>>> Well, I applied the patch, and things are a little different (and
>>> maybe on the right track) but everything doesn't seem quite solved
>>> yet.
>>>
>>> As you suggested, after the patch the Shift 1 UG shows t = 4.0 in
>>> the
>>> situation below. Can you explain to me why that is desirable?
>>> Shouldn't the Shift 1 data all have t = 3.0, not 4.0 (because of the
>>> time shift)? Or, are you trying to tell the system that as far as
>>> updates are concerned, all data sets are at t = 4.0, even though the
>>> data in the Shift 1 set is really from one step behind the Shift 0
>>> data set?
>>>
>>> There are still a couple of strange results from probing the
>>> DATA_TIME_STEPS: First, if we take the example I was showing below,
>>> when I increment time forwards until everyone has t=4.0, then if I
>>> go
>>> backwards one step in time I get:
>>>
>>> Shift 0 TDS: t = 3.0
>>> Shift 0 UG: t = 4.0 <----
>>> Shift 1 TDS: t = 3.0
>>> Shift 1 UG: t = 3.0
>>> Output UG (copy of shift 1 UG): t = 3.0
>>>
>>> So, when stepping backwards the Shift 0 UG doesn't get decremented
>>> properly for some reason. (If I stepped back again, everyone would
>>> be
>>> at t = 2.0, except the Shift 0 UG would show t = 3.0) In this case,
>>> though, when the Output is a (deep) copy of the Shift 1 UG, the
>>> points
>>> seem to move properly as time is incremented forward and backwards.
>>>
>>> If the Output is a copy of the Shift 0 UG, though, the problem with
>>> that lack of decrement can lead to improper point movement. e.g.
>>> If I
>>> set up the same situation as above, incrementing up until everyone
>>> is
>>> at t = 4.0, then step backwards one click, I get:
>>>
>>> Shift 0 TDS: t = 3.0
>>> Shift 0 UG: t = 4.0 <----
>>> Shift 1 TDS: t = 3.0
>>> Shift 1 UG: t = 3.0
>>> Output UG (copy of shift 0 UG): t = 4.0 <----
>>>
>>> Then, if I try to click forwards one time step from there, the
>>> Programmable Filter doesn't execute, and the Output point doesn't
>>> move
>>> properly on the screen -- presumably because the system thinks t = 4
>>> already and so it doesn't have to update?
>>>
>>> Please let me know if you have any more ideas about what's going on.
>>>
>>> Thanks for the help,
>>> -Eric
>>>
>>>
>>> On Feb 5, 2008, at 2:35 PM, Moreland, Kenneth wrote:
>>>
>>>> If you look in the code for vtkTemporalShiftScale, you will see
>>>> that
>>>> there is a place in request data where it shifts the time values
>>>> for
>>>> the root temporal data set object (starting at about line 110).
>>>> The
>>>> patch I gave you should change the Shift 1 UnstructuredGrid to t =
>>>> 4.0.
>>>>
>>>> -Ken
>>>>
>>>>> -----Original Message-----
>>>>> From: paraview-bounces+kmorel=sandia.gov at paraview.org [mailto:paraview-
>>>>> bounces+kmorel=sandia.gov at paraview.org] On Behalf Of Eric Monson
>>>>> Sent: Tuesday, February 05, 2008 12:00 PM
>>>>> To: ParaView List
>>>>> Subject: Re: [Paraview] Temporal shift with Python Programmable
>>>>> Filter
>>>>>
>>>>> I'll try the patch later this afternoon when I have more time
>>>>> and see
>>>>> if that helps.
>>>>>
>>>>> With your tip I was able to probe the DATA_TIME_STEPS for all the
>>>>> data
>>>>> sets, and the result seems a little strange to me -- see if this
>>>>> helps:
>>>>>
>>>>> e.g.
>>>>> Shift 0 TemporalDataSet: t = 4.0
>>>>> Shift 0 UnstructuredGrid: t = 4.0
>>>>> Shift 1 TemporalDataSet: t = 4.0 <---
>>>>> Shift 1 UnstructuredGrid: t = 3.0
>>>>> Output UnstructuredGrid (copy of shift 1 UG): t = 3.0
>>>>>
>>>>> Should that Shift 1 TemporalDataSet really have t = 4.0 --
>>>>> shouldn't
>>>>> it be t = 3.0 in that case?
>>>>>
>>>>> Thanks,
>>>>> -Eric
>>>>>
>>>>>
>>>>> On Feb 5, 2008, at 1:09 PM, Moreland, Kenneth wrote:
>>>>>
>>>>>> The data object's time is stored in an information object
>>>>>> maintained
>>>>>> by the data object with the key vtkDataObject::DATA_TIME_STEPS().
>>>>>> In C++, you can get this with something like
>>>>>>
>>>>>> data->GetInformation()->Get(vtkDataObject::DATA_TIME_STEPS()).
>>>>>>
>>>>>> You might try applying the following patch to
>>>>>> vtkTemporalShiftScale.cxx. It adjusts the time stamp on the
>>>>>> internal data objects so that they match the time requested. I
>>>>>> never checked this in because I do not know if it will adversely
>>>>>> affect anything else. If it fixes your problem, we should
>>>>>> consider
>>>>>> it.
>>>>>>
>>>>>> -Ken
>>>>>>
>>>>>>
>>>>>> kmorel1 1> cvs diff -u vtkTemporalShiftScale.cxx
>>>>>> Index: vtkTemporalShiftScale.cxx
>>>>>> =
>>>>>> =
>>>>>> =================================================================
>>>>>> RCS file: /cvsroot/ParaView3/ParaView3/VTK/Hybrid/
>>>>>> vtkTemporalShiftScale.cxx,v
>>>>>> retrieving revision 1.4
>>>>>> diff -u -r1.4 vtkTemporalShiftScale.cxx
>>>>>> --- vtkTemporalShiftScale.cxx 7 Sep 2006 18:01:31 -0000
>>>>>> 1.4
>>>>>> +++ vtkTemporalShiftScale.cxx 5 Feb 2008 18:07:06 -0000
>>>>>> @@ -121,7 +121,18 @@
>>>>>> outData->GetInformation()->Set(vtkDataObject::DATA_TIME_STEPS(),
>>>>>> outTimes, inLength);
>>>>>> delete [] outTimes;
>>>>>> -
>>>>>> +
>>>>>> + // adjust the time steps of the internal data
>>>>>> + for (i = 0; i < (int)outData->GetNumberOfTimeSteps(); i++)
>>>>>> + {
>>>>>> + vtkInformation *dataInfo = outData->GetDataSet(i, 0)-
>>>>>>> GetInformation();
>>>>>> + int numtimes = dataInfo-
>>>>>>> Length(vtkDataObject::DATA_TIME_STEPS());
>>>>>> + double *times = dataInfo-
>>>>>>> Get(vtkDataObject::DATA_TIME_STEPS());
>>>>>> + for (int j = 0; j < numtimes; j++)
>>>>>> + {
>>>>>> + times[j] = times[j]*this->Scale + this->Shift;
>>>>>> + }
>>>>>> + }
>>>>>> return 1;
>>>>>> }
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Eric Monson [mailto:emonson at cs.duke.edu]
>>>>>>> Sent: Tuesday, February 05, 2008 10:39 AM
>>>>>>> To: Moreland, Kenneth
>>>>>>> Cc: ParaView List
>>>>>>> Subject: Re: [Paraview] Temporal shift with Python Programmable
>>>>>>> Filter
>>>>>>>
>>>>>>> Hey Ken,
>>>>>>>
>>>>>>> That sounds like a reasonable guess. If that's the problem, do
>>>>>>> you
>>>>>>> know if there's a way to force the update to the correct time? I
>>>>>>> also
>>>>>>> can't seem to find any way of getting at the data object's time
>>>>>>> value...
>>>>>>>
>>>>>>> It's just tough for me to figure out how to debug this one,
>>>>>>> unless
>>>>>>> someone can see something I've obviously left out.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Eric
>>>>>>>
>>>>>>>
>>>>>>> On Feb 5, 2008, at 12:03 PM, Moreland, Kenneth wrote:
>>>>>>>
>>>>>>>> This is a total guess, but maybe it has something to do with
>>>>>>>> the
>>>>>>>> time value placed in the data set. Data objects often hold the
>>>>>>>> time
>>>>>>>> value on which they are supposed to be defined. Maybe when you
>>>>>>>> copy
>>>>>>>> the shifted data, its time value is also shifted. When you
>>>>>>>> then
>>>>>>>> step the time, the new time now matches the shifted time from
>>>>>>>> the
>>>>>>>> last time update. Perhaps the pipeline sees the time match and
>>>>>>>> does
>>>>>>>> not update the pipeline.
>>>>>>>>
>>>>>>>> -Ken
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: paraview-bounces+kmorel=sandia.gov at paraview.org
>>>>> [mailto:paraview-
>>>>>>>>> bounces+kmorel=sandia.gov at paraview.org] On Behalf Of Eric
>>>>>>>>> Monson
>>>>>>>>> Sent: Monday, February 04, 2008 10:11 AM
>>>>>>>>> To: ParaView List
>>>>>>>>> Subject: [Paraview] Temporal shift with Python Programmable
>>>>>>>>> Filter
>>>>>>>>>
>>>>>>>>> Hey All,
>>>>>>>>>
>>>>>>>>> This may seem like an odd question, but I think the answer may
>>>>>>>>> help
>>>>>>>>> clarify a larger problem I'm having...
>>>>>>>>>
>>>>>>>>> I'm trying to calculate the velocity vectors for diffusing
>>>>>>>>> particles,
>>>>>>>>> and the way I'm doing it right now is to feed two copies of my
>>>>>>>>> Unstructured Grid data into the Python Programmable Filter
>>>>>>>>> (PPF).
>>>>>>>>> The
>>>>>>>>> first copy has a time shift of 0, and the second one has Shift
>>>>>>>>> = 1.
>>>>>>>>> These are both Temporal Data Sets, and so I've been
>>>>>>>>> accessing the
>>>>>>>>> underlying Unstructured Grids by doing this:
>>>>>>>>>
>>>>>>>>> in0 = self.GetInputDataObject(0,0).GetDataSet(0,0)
>>>>>>>>> in1 = self.GetInputDataObject(0,1).GetDataSet(0,0)
>>>>>>>>>
>>>>>>>>> I force the PPF output to vtkUnstructuredGrid, and I have been
>>>>>>>>> making
>>>>>>>>> the output equivalent to one of the input points like so:
>>>>>>>>>
>>>>>>>>> out1 = self.GetOutput()
>>>>>>>>> out1.DeepCopy(in1)
>>>>>>>>>
>>>>>>>>> (In the complete calculation I later add a vtkFloatArray to
>>>>>>>>> "out1"
>>>>>>>>> containing the calculated velocity vectors.)
>>>>>>>>>
>>>>>>>>> The odd thing I see is that if the output is a copy of the
>>>>>>>>> Shift
>>>>>>>>> = 0
>>>>>>>>> point, I can increment time forward and backwards (arrow
>>>>>>>>> click on
>>>>>>>>> Time
>>>>>>>>> control) and everything looks fine. If the output is a copy of
>>>>>>>>> the
>>>>>>>>> Shift = 1 point, then on every other click it increments,
>>>>>>>>> and on
>>>>>>>>> the
>>>>>>>>> other clicks it doesn't move or change its scalar values. (If
>>>>>>>>> Shift =
>>>>>>>>> -1, then it increments properly backwards, but not forwards.)
>>>>>>>>>
>>>>>>>>> Is there some sort of update forcing I should be doing that
>>>>>>>>> I'm
>>>>>>>>> not?
>>>>>>>>> Is this an unreliable way of accessing the data from within
>>>>>>>>> the
>>>>>>>>> Temporal Data Sets?
>>>>>>>>>
>>>>>>>>> (I seemingly randomly get cases where my calculated velocity
>>>>>>>>> vector
>>>>>>>>> goes to zero and won't snap out of it unless I rebuild the
>>>>>>>>> whole
>>>>>>>>> pipeline from scratch, so I'm hoping I'm just doing something
>>>>>>>>> wrong
>>>>>>>>> here...)
>>>>>>>>>
>>>>>>>>> Thanks for the help,
>>>>>>>>> -Eric
>>>>>>>>>
>>>>>>>>> -----------------------------------------------------
>>>>>>>>> Eric E. Monson
>>>>>>>>> Duke Visualization Technology Group
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ParaView mailing list
>>>>>>>>> ParaView at paraview.org
>>>>>>>>> http://www.paraview.org/mailman/listinfo/paraview
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ParaView mailing list
>>>>> ParaView at paraview.org
>>>>> http://www.paraview.org/mailman/listinfo/paraview
>>>>
>>>
>>
>> <vtkTemporalShiftScale.cxx><vtkTemporalShiftScale.h>
>
> _______________________________________________
> ParaView mailing list
> ParaView at paraview.org
> http://www.paraview.org/mailman/listinfo/paraview
More information about the ParaView
mailing list