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.

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 contiguously 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 contiguous. 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