[Paraview] Temporal shift with Python Programmable Filter
Eric Monson
emonson at cs.duke.edu
Wed Feb 6 09:59:37 EST 2008
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
>
More information about the ParaView
mailing list