Fast Path For Temporal Data: Difference between revisions
No edit summary |
No edit summary |
||
| Line 11: | Line 11: | ||
==Exodus Example== | ==Exodus Example== | ||
An example of this optimized path can be seen in the exodus API. It contains ex_get_xxx_time() functions that read the values of a node/element variable for a single node/element through a specified number of time steps. When a filter wants a node's/element's variable value over time (e.g. the vtkExtractDataOverTime filter), instead of re-executing for each timestep, it would send one request upstream to the reader which, in the case of the exodus reader, would then call the appropriate ex_get_xxx_time() method. The problem then becomes how to propagate the data back to the filter. | An example of this optimized path can be seen in the exodus API. It contains ex_get_xxx_time() functions that read the values of a node/element variable for a single node/element through a specified number of time steps. When a filter wants a node's/element's variable value over time (e.g. the vtkExtractDataOverTime filter), instead of re-executing for each timestep, it would send one request upstream to the reader which, in the case of the exodus reader, would then call the appropriate ex_get_xxx_time() method. The problem then becomes how to propagate the data back to the filter. Should it create a new output dataset or send it back in a vtkInformation key-to-value map? | ||
==Discussion Board== | ==Discussion Board== | ||
| Line 17: | Line 17: | ||
Are there any other ideas for solutions besides the two mentioned above (a separate pipeline or returning the data as meta-information)? | Are there any other ideas for solutions besides the two mentioned above (a separate pipeline or returning the data as meta-information)? | ||
What pros and cons | What pros and cons does each approach have? | ||
Revision as of 12:20, 18 May 2007
Problem Defintion
The new time support in VTK is described here. It contains the following excerpt:
...requesting the data for one cell across many timesteps would still be very slow compared to what it could be for a more optimized path. To address this need in the future we plan on creating a fast-path for such requests. This fast path will be implemented for key readers and the array calculator initially. It is still unclear exactly how this will be implemented. But it will effectively be a separate pipeline possibly connecting to a different output port. Another option is to have a special information request that returns the data as meta-information as opposed to first class data.
The purpose of this page is to begin a discussion on how to implement such a "fast-path".
Exodus Example
An example of this optimized path can be seen in the exodus API. It contains ex_get_xxx_time() functions that read the values of a node/element variable for a single node/element through a specified number of time steps. When a filter wants a node's/element's variable value over time (e.g. the vtkExtractDataOverTime filter), instead of re-executing for each timestep, it would send one request upstream to the reader which, in the case of the exodus reader, would then call the appropriate ex_get_xxx_time() method. The problem then becomes how to propagate the data back to the filter. Should it create a new output dataset or send it back in a vtkInformation key-to-value map?
Discussion Board
Are there any other ideas for solutions besides the two mentioned above (a separate pipeline or returning the data as meta-information)?
What pros and cons does each approach have?
