Time Support
Thoughts on Time Support in ParaQ (and ParaView)
Overview
For some time now (groaaan, a pun), 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 ParaView supports animations that show time sequences. However, there are many improvements, large and small, that need to be made. Below is a list of use cases, in the voice of the customer, without suggesting an implementation. Each need is assigned an importance from the list: (Must have, Very desirable, Desirable, Not needed, Undesirable). A "Must have" feature is required by users in order for them to use ParaView.
| ID | Need | Importance |
|---|---|---|
| 1 | Plot the values of multiple nodes(cells) over a specified range of time | Must have |
| 2 | Animations of time-series data that handle simulations with nonuniform time steps. This includes optional interpolation of node(cell) variables to intermediate times to avoid choppy playback or nonuniform playback (i.e., varying playback speed as integration step size is varied). | Must have |
| 3 | Plot the values of nodal (or cell-centered) variables taken on over a space curve and over a specified range of time. The space curve may be a line or a circle. | Very desirable |
| 4 | Having an optional "snap to nodes" feature for the spacetime plots above (Need 3) would be very useful. | Very desirable |
| 5 | Having an optional "geometry inference" feature for defining circular curves for the spacetime plots above (Need 3) would be very useful. | Very desirable |
| 6 | Want to know the time at which a variable meets or exceeds a given value (either at specified node(s), or for any node in the entire mesh). An example is thermal situations where we need to know whether or when a particular temperature-sensitive component fails. | Very desirable |
| 7 | Would like time interpolation (as required for animations in Need 1) to be nonlinear (i.e., parabolic) so that it matches the interpolation assumed by the integration technique used by the solver. Note that different solvers have different integration schemes. Predictor-corrector methods do not necessarily specify a unique interpolant, but other methods do. | Desirable |
| 8 | Take time-derivatives. (Since the simulation package can be made to output these values directly when required, this is not needed). | Not needed |
Mapping the needs to ParaView's infrastructure
Because the needs don't specify an implementation, we need to identify and evaluate ways in which ParaView can be extended to meet them (where they are not already met).
Currently, ParaView supports a single data set in a pipeline. There is a way for filters to request multiple timesteps but this may cause cache problems upstream. Also, there is no way for a filter to request "pieces" of unstructured grids that contain a specified node or cell. This is required for efficient plotting at points or along curves. The Exodus reader has functionality that allows single node or cell values to be requested, but the XY plot filter can only take advantage of this if the Exodus reader is its direct upstream filter (without any intervening filters). If extents are generalized in a way that lets filters specify pieces containing cells or nodes, this limitation would go away.
Memory efficiency. 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. Another thing that would help with memory efficiency is for multiple timesteps to refer to the same connectivity (and point?) arrays. This is more of an implementation issue for readers than for the pipeline, though.
ParaView currently assumes that a given mesh will have attributes for a single time step and that that time step will be one selected from a list of available time steps provided by a source, such as a reader. There is no way for a mesh to indicate that its attributes are interpolated to some time between time steps provided by a source.
Timesteps
The timesteps present in a pipeline:
- Need not be contiguous or uniformly spaced
- 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?
