'[vtk-developers] Temporal Pipeline Fixes update'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: vtk-developers
Subject: [vtk-developers] Temporal Pipeline Fixes update
From: John Biddiscombe <biddisco () cscs ! ch>
Date: 2009-06-19 9:29:21
Message-ID: 4A3B5A71.6050204 () cscs ! ch
[Download RAW message or body]

[Attachment #2 (text/html)]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
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&gt;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,&nbsp; 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 
 
<pre class="moz-signature" cols="78">-- 
John Biddiscombe, email:biddisco @ cscs.ch
<a class="moz-txt-link-freetext" href="http://www.cscs.ch/">http://www.cscs.ch/</a>
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82</pre>
</body>
</html>

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtk-developers

[prev in list] [next in list] [prev in thread] [next in thread] 