Time Implementation

The new time support in VTK is described here. The important things to note:

• Discrete as well as contiguous time values are supported
• Update time has to be requested by the final consumer (usually mapper, i.e. display in paraview)
• Some algorithms may request more than 1 time step.

In ParaView 2, the time is controlled by a widget that belongs to the readers object inspector. This does not work well with the new time support as the time is no longer a parameter of the reader but rather something that needs to be set at the end of the pipeline. Here is how I am thinking of implementing time in ParaView 3.

Latest design

The source/reader time will be tied to the animation time. This means that by default all readers/sources/filters will be synced to the animation time. We will create animation tracks for each view that will control time. This is a little different than ParaView 2. In ParaView 2, we create a track per reader. Also, by default, these tracks will linearly interpolate time with a slope of 1. This means that the time value sent to the reader will be the same as animation time. Note that unlike ParaView 2 that sends time index to the reader, the current architecture sends time values to the reader. This is based on the assumptions that:

1. All readers/sources provide time values for all time steps. If a reader provides only index based time, we will assign time values (probably uniform spacing of 1 time unit, starting from 0)
2. All readers/sources provide time values of the same unit. We will probably have to provide shift/scale functionality to the sources to allow the user to work with different time units.

We will also provide a way of turning of individual animation tracks so that the user can, for example, animate a cut plane on the same time step.

The animation time will be assigned to a time property that is on the view manager (vtkSMMultiViewRenderModuleProxy). All views will have time properties that are by default linked to this time property. All displays will have time properties that are by default linked to the view that contains them. In the first pass, the only way to set a different time on a view will be using the python interface. This will be accomplished by breaking the link between the view manager and a view and setting the time property. In the future, we can provide this functionality through the animation interface (by allowing different current time for different views, this may become complicated fast).

Time Values and Range

The animation interface will have 3 modes:

1. snap to time steps - where each animation frame corresponds to a time step of a source/reader (user specified begin time and end time)
2. uniform spacing - where each animation frame will be t0 + n * dt (user specifies beginning time (t0), number of frames (n) and time spacing (dt))
3. real time (user specified a time scaling, a begin time and an end time)

In either of the last 2 modes, if the time value does not exactly match If the user selects a time value that is not available on the reader, the reader will read the closest time step unless the user explicitly inserts a vtkTemporalInterpolator (will not work if geometry changes).

If the user loads two readers/sources that provide different time values, the time values will be merged into one list.

Time-aware filters

• Accumulate over time: This filter will loop over a given time range and accumulate the results. This can be used to
  • Plot the value at a point (picked by position or id) over time
  • Generate a carpet plot from a line probe (where one of the dimensions is time)
  • Find the maximum value over time
  • ...
• Particle paths and streaklines: John Biddiscombe already implemented this. I will ask him to incorporate it when I am done.
• Interpolate in time
• Shift/scale

List of readers to be updated

• vtkPVDReader
• Ensight reader
• SPCTH reader
• Phasta reader
• Exodus reader (mostly done)
• OpenFOAM reader
• MFIX reader
• FLUENT reader
• LSDyna reader

First design

Time as a property of displays/views

Each display will have a time property. By default, these will be linked to a time property of the view that contains them. Furthermore, the time property of all views will be linked to a global time property. The time of the active display will be displayed on the toolbar.

Whether a time index or a time value is shown on the toolbar widget will depend on the time selection mode (should this be part of the toolbar or a menu?). It will be possible to break the time property link between the active view and the global time to property (how is this related to the general property link editor property?). This will allow users to display different timesteps in different views. To have 2 different readers with different time steps in the same view, the user will have to apply the vtkTemporalShiftScale filter.

I am very uncomfortable with the idea of having a time value in the toolbar that is different than the "time" associated with animation (which has its own toolbar). I don't think most users will understand, or care to understand, the difference between animation time and pipeline time (the latter being something that the former controls). In fact, I was unclear on the distinction of the two until about a month ago when Brian bluntly fixed my perception. Since the animation controls will control the pipeline time anyway (unless a more experienced user changes it with a clunky animation control panel), I suggest that we hide the control of the pipeline time in some deep, dark recesses of the GUI.

--Ken 17:39, 8 Jan 2007 (EST)

We need to be careful here. First of all, we have to define what the animation controls on the toolbar do. Do they control all animation tracks or do they simply control time? If they control all animation tracks (let's say we are varying the radius of a sphere and moving the camera as part of the animation as well as controlling time) and if there is no separate time control, the users will not be able to control the time independently of the other tracks without digging into some hidden panel. If the animation controls drive only time, we have to give users another set of animation buttons somewhere else (which will also be confusing). Also, if there is a analytic source that allows time to vary continuously in the pipeline, the only way to control the time for that would be from a time control.

I see the animation control something that controls a collection of parameters (time, radius, cut plane location etc.). I think everything that is controlled by the animation should have their own widgets. As the animation is run, those widgets should reflect the values that the animation control sets on them. If we hide some of these parameters, I think we would confuse the users even more. Does make sense?

If the user loads a dataset with time steps, we will still automatically create an animation track that controls time (maybe, unless the user already has other tracks, not sure about that). This way, unless they change the animation, the animation controls will control the time as expected (i.e. next will go to the next time step, play will move over time etc.). However, changing time step on the time toolbar would not effect the animation step.

Berk 09:49, 9 Jan 2007 (EST)

I just thought of an alternative to the approach above. As Ken suggested, we could unify the time that is coming from sources and the time that the animation uses. As in ParaView 2, we could have 2 animation modes: discrete (each frame corresponds to 1 time step) and continuous. The animation tracks would use the time coming from readers/source and the animation time would adjust itself based on the time ranges and steps coming from all sources/readers. The time value label could become part of the animation toolbar. One thing we would need is to be able to enable/disable animation tracks individually so that the animation controls can drive only some readers. We would have to think of a way of allowing separate animation tracks for separate views (linked by default).

Berk 09:54, 9 Jan 2007 (EST)

Time Values and Range

The time range and the time step values (if available) will be displayed in the information tab of individual readers. One thing that is not clear is which time step values to use on the time property if there are more that one readers with different time values on the same view. I can think of two solutions:

1. Merge the two different lists into one (also uniquify of course)
2. Provide multiple lists the user can select from (similar to Ensight)

If the user selects a time value that is not available on the reader, the reader will read the closest time step unless the user explicitly inserts a vtkTemporalInterpolator (will not work if geometry changes).

Animation

The users will be able to select between time step animation (discrete) and time value animation (contiguous).

Time-aware filters

• Accumulate over time: This filter will loop over a given time range and accumulate the results. This can be used to
  • Plot the value at a point (picked by position or id) over time
  • Generate a carpet plot from a line probe (where one of the dimensions is time)
  • Find the maximum value over time
  • ...
• Particle paths and streaklines: John Biddiscombe already implemented this. I will ask him to incorporate it when I am done.
• Interpolate in time
• Shift/scale

List of readers to be updated

• vtkPVDReader
• Ensight reader
• SPCTH reader
• Phasta reader
• Exodus reader (mostly done)
• SAF reader (is this even used by anyone?)
• OpenFOAM reader
• MFIX reader
• FLUENT reader
• LSDyna reader