[Paraview] Temporal shift with Python Programmable Filter
Eric Monson
emonson at cs.duke.edu
Wed Feb 6 11:13:53 EST 2008
Hey Ken,
This sounds very likely to me as the culprit. It has seemed sometimes
(but I can't always reproduce it) that some time shift problems appear
and then lock in (as if the upstream data has changed) and from then
on things don't work until I rebuild the pipeline from scratch.
I'm working from CVS so I'll try the fixes and let you know how it goes.
-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>
More information about the ParaView
mailing list