Time Support

Thoughts on Time Support in ParaQ (and ParaView)

DANGER - THIS PAGE IS UNDER CONSTRUCTION, and SHOULD NOT BE STUDIED YET.

Overview

For some time now, we've known that we need 'time support' in ParaView, but there's been little written down about what this really means. Time support is a broad topic, and this wiki entry is an attempt to lay the groundwork for future debate on the topic.

What is time support?

This is our first question to address. Certainly, ParaView supports 'time', in that it reads data files that have a notion of time (in particular, timesteps), and the appliciation supports animation (stepping through time). However, there are several specific cases which are not supported by the current ParaView architecture.

ID	Requirement	Description	What the heck do we need it for?
1	Multiple timesteps in a single pipeline.	Currently, ParaView supports a single data set in a pipeline, and there is no support for iterating over several 'timesteps' of data at a filter.	1. Any filter operation that needs previous or future timesteps to calculate its results. Example: a filter that calculates a time-based gradient (acceleration).
			2. Memory efficiency (perhaps). If we want to visualize multiple timesteps of data (think of looking at a multiple-exposure photograph of a ball bouncing), it might be more efficient to have a single pipeline with several timesteps worth of data, rather than having either a) several inputs, which are ganged together or b) several copies of the same pipeline, with inputs set to the appropriate timestep.
2	Query of 'time series' data for particular nodes or elements.	The Exodus reader supports time-based query, but there is no standard method for transporting this data along the pipeline. There is no standard for discovering or dealing with this data.	Graphing data for a particular element over time (the extent of time in the source file).

Timesteps

The timesteps present in a pipeline:

• Need not be contiguous
• Need not be valid timesteps present in the source data. For example, there may be an interpolated timestep present.

Responsibilities of a Filter

• All filters operate on all input timesteps, unless otherwise restricted.
• All filters can request that downstream filters provide certain timesteps.
• All filters must respond to upstream requests for timestep ranges.
• A filters need not 'care' about time.
  • A filter that does not care about time in its calculation is responsible for applying its operation to appropriate input timesteps, and create data appropriate to satisfy upstream requests for data. If we implement the 'dataset per timestep' approach, in the simplest case, this is simply a matter of applying the filter's operation to each input timestep in turn.
• Filter must guarantee that its output data is consistent, across timesteps.

Expectations for Downstream Data

• Data for t[0] and t[1] for the same element can be usefully compared. This item, if it is a requirement, imposes restrictions on what kinds of data can be passed in the pipeline. In particular, if we have a filter that performs some interpolation on element A, can that operation be performed correctly on all timesteps in the data? Are all the elements available at t[0] and t[1], so that we can compare the results of the output filters?