Time Support

Overview

For some time now (groaaan, a pun), we've known that we need 'time support' in ParaView/ParaQ, 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.

Timesteps

Timesteps are point-samples of continuous time that are defined for a specific data set. They need not be contiguous or uniformly spaced, and in fact often aren't, since many simulations adjust their sample rate dynamically based on the simulation content. When more-than-one data set is present in a visualization, the timesteps in the data sets may represent completely different ranges and rates of time. Thus, it is important to have a single time "reference" that is uniform across all data sets. This document assumes that "time" is an absolute, continuous real number, and that a "timestep" is an individual sample at a particular point in time.

Use Cases

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.

1. Plot the values of one-to-many elements over a specified range of time (client side graphing).
2. Take time series data for a known element (point or cell), run that through a filter (such as calculator), and then plot that (client side graphing).
3. Provide time series data to a filter that requires multiple time-steps as input (e.g: for time step N, average the data for N-1, N, and N+1). (DSP).
4. Support alternatives to streamlines - streamline: plot the path through a field at an instant in time. Streak-/path-lines: plot the position of a particle for every instant in time.
5. Calculate the integral of a cut plane over time, i.e the integral of a plane (or something) at each time step.
6. Ghosting (e.g. see the path of a bouncing ball).
7. Min/max, and other statistical operations. The operation can be for a single element over time or over all elements over time.
8. Per time step field data. That is data that could be a field of a data set that changes over time. We should also be able to represent field data that does not change over time.
9. AMR?
10. Calculate envelopes (convex hull) over time. Calculate unions and intersections over time, i.e. "what volume was ever occupied by an object", and "what volume was always occupied by an object".
11. Get a window of data (all elements between times T1 and T2).
12. Select non-contiguous time steps.
13. Time sampling.
14. Hierarchical (weeks, months, years).
15. Handle when <math>\Delta t</math> is not constant.
16. Multiple timelines (> 1 data set, etc).
    • They can be overlapping or non-overlapping.
17. Readers report temporal bounds. Time is part of the extents.

ID	Need	Importance
1	Plot the values of one-to-many nodes(cells) over a specified range of time (client side graphing).	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.

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?