<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

</head>

<body bgcolor="#ffffff" text="#000000">

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 class="moz-txt-link-freetext" 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>

</body>

</html>