[vtk-developers] [ParaView3-Developer] Temporal Pipeline Fixes update

[Berk Geveci]

> I'm not quite sure I'm doing everything completely correct - so I want to
> know what is the minimal set of keys that have to be set/unset and checked
> on each iteration. This question is just too nasty to answer over email, so
> I'm wondering if I can maybe do a messenger/skype call with someone (who is
> the current pipeline master?) and ask a few questions 'in real time'
> sometime next week maybe to help me be sure I'm not going to break 500 tests
> or key functionality.

As sad as I am to admit it, I am the current "owner" of the pipeline.
Yes, I would be happy to chat -we can even do video over skype-. You
changes sound exciting. I will take a closer look at them tomorrow.

-berk

On Fri, Jun 19, 2009 at 5:29 AM, John Biddiscombe<biddisco at cscs.ch> wrote:
> I have been looking at the way temporal looping/requests are handled and
> made a number of changes, but in order to ensure I'm doing things right, I
> have some questions.
>
> Before asking, I shall summarize the new pipeline as follows
>
> Before : A filter that required N time steps, placed them in the
> UPDATE_TIME_STEPS during RUE
> After : No change
>
> Before : The filter requiring N time steps would specify vtkTemporalDataSet
> as the input type (regardless of what real underlying type was really
> wanted).
> After : The filter can request PolyData/UnstructuredGrid etc as usual, but
> adds an additional key to FillInputPortInformation which states
> INPUT_TEMPORAL_DATA. Ken : I tried to make it work using only the N>1 in
> UPDATE_TIME_STEPS, but found that when the filter only needed 1 step for
> particular update (eg interpolator when Tin = Tout), then the pipeline
> reverted to normal, and the filters had to be modified to know when to
> expect temporal or simple. Much easier to add an Input key which says, give
> me temporal polydata/UG/etc, and regardless of how many steps are actually
> requested, that's what it gets. A collection of T steps, where T=1,2,3,4....
>
> Before : The executive of the filter immediately upstream of the time
> request, would initiate looping and replace its output with a
> temporaldataset.
> After : The filter immediately upstream does nothing different from simple
> operation.
>
> Before : Every filter upstream of the TemporalRequest received the
> REQUIRES_TIME_DOWNSTREAM and internally looped and replaced its own output
> with a temporalDataSet..
> After : The only filter which does any input changing is the one that
> actually requested the N steps. Other filters are completely unaffected,
> except that they are triggered N times. REQUIRES_TIME_DOWNSTREAM is now
> unnecessary and will be removed.
>
> Before : The executive of the filter which requested N steps, receives a
> TemporalDataSet and executes basically as normal.
> After : The executive of the filter which requested N steps, triggers the
> upstream pipeline to execute N times, it collects the N datasets and places
> them into a TemporalDataSet, then replaces its own input (from the flat
> polydata/UG/etc) with the temporal collection and triggers its own update so
> that the temporal algorithm operates as before. It receives A temporal
> dataset, but can output a normal polydata/grid etc as usual (the filter
> subclasses vtkPolyDataAlgorithm etc and not vtkTemporalDataSetAlgorithm).
> After the algorithm has executed on the Temporal data, it replaces the input
> with the Nth dataset so that any other filter which is connected to the same
> input does not see any change in input type.
>
> Before : vtkTemporalDataSetAlgorithm was used liberally
> After : vtkTemporalDataSetAlgorithm is gone. A filter which needs time
> simply states, give me time./ A filter which exports time will flag it.
> Currently, only vtkTemporalInterpolator actually had the ability to generate
> multiple output steps AFAIK.
>
> Before : Filter outputs in ParaView changed type - which broke stuff.
> After : Filter outputs in ParaView do not change.
>
> Before : It was not possible to write a filter which expected temporal
> polydata/other type, it always received a generic temporal dataset which
> could have contained some other type (image etc)
> After : Filters specify type, and temporal on input and output. Type checks
> now work correctly.
>
> Before : Temporal filters which required composite temporal data, had to be
> implemented specially to handle composit inputs.
> After : A filter such as TemporalInterpolator can now take vtkDataSet as
> input, vtkDataSet as output and allow composite inputs which are temporal
> with no extra work. The executive loops the upstream pipeline over Time,
> collect ing N composite datasets, it then extracts each leaf node from each
> time step and makes a new simple temporal dataset, updates the Interpolator
> Once per block, with the N steps per block, then collects the M blocks and
> puts them back into a composite filter of the same structure as the original
> input. It's complex, but now vtkTemporlaIntepolator inherits from
> vtkDataSetAlgotithm and specifies input/output types as vtkDataSet. It is
> executen once per block with a temporal input per block. It is lovely and
> simple now. No special cases for composite data.
>
> Before : If datatypes change between time steps, most filters using temporal
> inputs will break Multiblock structures changing over time introduce
> problems we have not dealt with yet.
> After : Still true. No change there, though we now at least have better type
> check on simple (non composite) temporal pipelines.
>
> Before : Filters that exported N time steps worked.
> After : I've got filters importing N steps working (99% use case), but am
> not finished with filters exporting N steps. To be continued .....
>
> Before : There were bugs
> After : There are still bugs (but different!). My testing is still at an
> early stage and I may discover that actually, everything I've written is
> crap because one use case buggers it all up.
>
> My main question is this. Inside vtkCompositeDataPipeline, there are methods
> such as ExecuteSimpleAlgorithmForBlock, etc etc, which do a number of
> piece/extent/other information checks/sets/etc on info keys before and after
> initiating looping and suchlike.
>
> I'm not quite sure I'm doing everything completely correct - so I want to
> know what is the minimal set of keys that have to be set/unset and checked
> on each iteration. This question is just too nasty to answer over email, so
> I'm wondering if I can maybe do a messenger/skype call with someone (who is
> the current pipeline master?) and ask a few questions 'in real time'
> sometime next week maybe to help me be sure I'm not going to break 500 tests
> or key functionality.
>
> As always, your comments are welcome, but might be ignored if you tell me
> I'm doing it all wrong :)
>
> Regards
>
> JB
>
> --
> John Biddiscombe,                            email:biddisco @ cscs.ch
> http://www.cscs.ch/
> CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
> Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82
>
> _______________________________________________
> ParaQ-Developer mailing list
> ParaQ-Developer at paraview.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/paraq-developer
>