<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Ken<br>
<br>
Yes. I expect the type to be reported in FillInput/Output Information.
And yes, there is already a byzantine sequence of temporal
creation/swapping that goes on. I hope to simplify it.<br>
<br>
You're on the right track.<br>
<br>
A filter tries to create it's output in RDO, so it looks at it's input
and makes a choice.<br>
Currently, as soon as you create a temporal filter, every filter
downstream of it has its output changed to be of type temporal. All
real type information is lost after this - and the 'normal' (ideal)
connection of filter taking Grid as input to filter outputing temporal
collection of grid is broken. The reason is because the executive does
not correctly look inside the temporal collection and use the actual
data object inside it.<br>
to fix this, I want to Ban the direct export of TemporalDataset and
only allow the executive to create the temporal datasets and to control
the looping or select the dataobject inside the temporal collection
when necesary. A filter capable of delivering multiple steps at once
will delcare the type as usual, and add the extra temporal suport key
in filloutputinformation (as you correctly suggest).<br>
<br>
I see how it all works very clearly in my mind, but I can't find the
words to write it down at the moment as I'm trying to do something else
at the same time .....<br>
<br>
To be continued.<br>
<br>
JB<br>
<blockquote cite="mid:C56BD8B6.5C7A%25kmorel@sandia.gov" type="cite">
<title>Re: [vtk-developers] Temporal Redesign</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">John,<br>
<br>
I’m still trying to catch up on my email, so I may not have read this
completely correctly. One thing I did not quite catch is how a filter
could “declare” it work with data of a particular type but then work
with temporal data. An algorithm “declares” its output type in
REQUEST_DATA_OBJECT where it looks at the type of the object created
for its input (if applicable) and creates a data object of its own for
its output. If a temporally-enabled filter creates an output of type,
say, unstructured grid, and then needs to output a temporal data set,
then who makes the temporal data set and who creates the objects to
populate it? I fear the answer includes a byzantine sequence of data
object creations and deletions with perhaps odd requests sent to the
algorithm.<br>
<br>
It might work better if REQUEST_DATA_OBJECT was not used to determine
data type but rather the information reported in
FillInput/OutputPortInformation. It could also be handy to say “I
don’t know the type yet.” That kind of change might have a profound
impact on the existing pipeline classes and algorithms, though.
Especially for the imaging pipeline.<br>
<br>
-Ken<br>
<br>
<br>
On 12/8/08 12:28 PM, "John Biddiscombe" <<a moz-do-not-send="true"
href="biddisco@cscs.ch">biddisco@cscs.ch</a>> wrote:<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">I made a few changes to TemporalShiftScale
and SnapToTimeStep last week which had unfortunate repercussions for
the TemporalFractal test.<br>
<br>
I've spent some time going over the executives and various classes
which make use of TemporalData and I would like to make some changes to
the whole temporal framework...<br>
<br>
Problems : The main problem with the temporal design as it stands is
that it is very difficult to know when a filter has got the right input
or output when temporal looping is involved. The problem is largely
caused by the TemporalDataSetAlgorithm Family. These classes export a
TemporalDataSet directly, and it isn't possible to know what kind of
datatype they have inside the collection. <br>
<br>
Consider the case of the failing TemporalFractal Test.<br>
A TemporalFractal class exports TemporalDataSet. Currently, this can
only be connected to another class which takes TemporalData as input.
Even if it only exports a single timestep, which may be uniform grid,
or rectilinear, or even a hierarchy of either (Multiblock etc)<br>
<br>
We would like the Executive to take temporal data and loop it for non
temporal filters, but we can't connect a non temporal filter to it and
get it right- because when the filters are connected together and first
executed, the RequestDataObject pass for the filter accepting the
TemporalDataSet doesn't know what type of output to create - we fudged
around this by simply exporting a temporal dataset too (which is why
snap and shift scale were TemporalAlgorithms (and they should not be,
they do not change the type of data passing through them). There are
several bugs existing (<a moz-do-not-send="true"
href="http://public.kitware.com/mantis/view.php?id=6662">http://public.kitware.com/mantis/view.php?id=6662</a>)
which all stem from the problem that the executive needs to take a
single dataset from a temporal collection and pass it into a non
temporal filter - currently it just doesn't do it and we see the output
of a filter change to temporal within the paraview gui and various
other side effects once temporal stuff is initiated. <br>
<br>
I'd am going to remove the whole TemporalDataSetAlgorithm family and
instead have filters which declare themselves as (say)
UniformGrid/Image/PolyData algorithms (or even multiblock), but export
a new information key which says "I support temporal" if they are
capable of delivering multiple time steps. Filters which require
temporal collectios of type X, will add a key requesting time.<br>
<br>
The advantages of this are<br>
a) Filters will export a defined 'type', which other filters and the
gui will be aware of, so temporal filters exporting polydata will be
distinct from temporal filters exporting imagedata and so on. The user
can then also write a filter which requires N Polydata and not any
other type, currently the pipeline connects all temporal classes
without checks.<br>
b) The checks in the executive will be simpler. A filter needs temporal
data, but the upstream pipeline exports simple, so loop. When a filter
needs simple, but upstream has declared time support, we take the i'th
dataset on iteration i (or more correctly, the dataset with
timestamp=t).<br>
c) Filters which support temporal activity (exporting more than one
dataset) as in b) above can have their output dataobjects replaced by
the executive and fill the N steps as before. We replace the code in
the existing CheckDataObject() method which currently is incorrect
(temporal IsA(composite) always returns true and causes untold trouble)
and solve most of the outstanding temporal problems in one place
(almost). Effectively we have, if filter supports temporal output and
more than one steps were requested. change it - . If filter requires
temporal and only one step exists, create temporal - the rest of the
time, stop messing about. The current dataset swapping logic is a mess.<br>
d) existing filters(readers mainly) can be updated to support temporal
natively with a pretty simple strategy. Add the temporal support flag,
and in request data, generate N steps if required, and place them in
the output. Much easier than the current option of creating a new class
derived from TemporalDataSetAlgorithm and instantiating a reader inside
it. (I'm talking here about generating multiple time steps from an
existing reader - the executive can loop for you, but if you have a
sophisticated file format, reading N at once can be desirable...)<br>
<br>
The changes the users will notice are<br>
vtkTemporalDataSetAlgorithm is removed, instead, filters which can <i>supply
</i>multiple steps place an extra key TEMPORAL_OUTPUT_SUPPORTED in
FillOutputInformation<br>
Filters which <i>require </i>multiple timesteps will place
TEMPORAL_INPUT_REQUIRED during the FillInputInformation call. (Here' I
think we might enhance the paraview GUI to allow a temporal input
domain so that you can only instantiate temporal filters when connected
to filters which are capable of supplying it). Filters such as temporal
interpolator, become dataobject algorithms, likewise temporalcache. <br>
<br>
I believe this will solve a great many problems, though I have not
considered the effect on TEMPORAL_FAST_PATH so please get back to me if
this is going to be a problem.<br>
<br>
I will be working on this on the back burner until the new year no
doubt, when I hope I have everything in order. The changes I have
outlined above are of course subject to change as I encounter problems
I've not considered. Please get in touch if you have strong feelings
about this.<br>
<br>
JB<br>
<br>
<br>
<br>
<br>
</span></font></blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
</span></font><font size="1"><font face="Monaco, Courier New"><span
style="font-size: 7.5pt;"><br>
**** Kenneth Moreland<br>
*** Sandia National Laboratories<br>
*********** <br>
*** *** *** email: <a moz-do-not-send="true" href="kmorel@sandia.gov">kmorel@sandia.gov</a><br>
** *** ** phone: (505) 844-8919<br>
*** web: <a moz-do-not-send="true"
href="http://www.cs.unm.edu/%7Ekmorel">http://www.cs.unm.edu/~kmorel</a><br>
</span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
</span></font></blockquote>
<br>
<br>
<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>