Time Implementation: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
No edit summary
Line 13: Line 13:


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.
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.
:<font color="green">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.</font>
:--[[User:Kmorel|Ken]] 17:39, 8 Jan 2007 (EST)


===Time Values and Range===
===Time Values and Range===

Revision as of 17:39, 8 January 2007

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.

Paraviewtoolbar.png

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)

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