Time Support: Difference between revisions
From ParaQ Wiki
Jump to navigationJump to search
| Line 43: | Line 43: | ||
* All filters can request that downstream filters provide certain timesteps. | * All filters can request that downstream filters provide certain timesteps. | ||
* All filters must respond to upstream requests for timestep ranges. | * 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 | **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. | ||
==Expectations for Downstream Data== | ==Expectations for Downstream Data== | ||
Revision as of 15:54, 4 January 2006
Thoughts on Time Support in ParaQ (and ParaView)
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. | Any filter operation that needs previous or future timesteps to calculate its results. Example: a filter that calculates a time-based gradient (acceleration). |
| 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.
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?
