ClientSideData: Difference between revisions
From ParaQ Wiki
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| Line 12: | Line 12: | ||
* Execute the visualization network at regular intervals, sampling the data-of-interest at each time step, then plot the accumulated results. This is the approach used by the ParaView "Probe" and "Pick" filters for plotting. Pros: works today, capable of "recording" any data that varies over time - regardless of network complexity. Cons: extremely poor performance. | * Execute the visualization network at regular intervals, sampling the data-of-interest at each time step, then plot the accumulated results. This is the approach used by the ParaView "Probe" and "Pick" filters for plotting. Pros: works today, capable of "recording" any data that varies over time - regardless of network complexity. Cons: extremely poor performance. | ||
* Use "out-of-band" APIs to collect time-varying data from network nodes that support doing so. The (only known?) example of this is vtkExodusReader / vtkPExodusReader, for which the GetTimeSeriesData() method will return an array of values for a given variable and element ID. Pros: works today (on the client), good performance. Cons: usable only with those nodes that implement an API for reading time-varying data. Cannot collect time-varying data that has been modified by filters, without adding the out-of-band API to each filter. | * Use "out-of-band" APIs to collect time-varying data from network nodes that support doing so. The (only known?) example of this is vtkExodusReader / vtkPExodusReader, for which the GetTimeSeriesData() method will return an array of values for a given variable and element ID. Pros: works today (on the client), good performance. Cons: usable only with those nodes that implement an API for reading time-varying data. Cannot collect time-varying data that has been modified by filters, without adding the out-of-band API to each filter. | ||
* Expand the visualization pipeline to include time-varying data. Pros: good performance, capable of returning any data that varies, regardless of network complexity. Cons: major changes to VTK pipeline. Passing time-varying data down the pipeline continuously would be a major performance problem, implying that some way of "querying" for data up the pipeline would be necessary. | * Expand the visualization pipeline to include time-varying data. Pros: good performance, capable of returning any data that varies, regardless of network complexity. Cons: major changes to VTK pipeline. Passing time-varying data down the pipeline continuously would be a major performance problem, implying that some way of "querying" for data up the pipeline would be necessary, e.g. growing "extents" to support temporal extents. | ||
==Implementation== | ==Implementation== | ||
Revision as of 14:05, 23 December 2005
Requirements
- Support general-purpose collection of complete data sets from one-to-many parallel servers to the client.
- Support collection of time-varying data from one-to-many parallel servers to the client, e.g: retrieve the value at a specific point/cell over time.
- For scalability, support special-purpose collection of data subsets from one-to-many parallel servers to the client.
Design
For transferring an entire vtkDataSet from servers to client, a single new proxy type can be created, based on the existing vtkMPIMoveData.
Collecting time-varying data is more challenging - alternative approaches include:
- Execute the visualization network at regular intervals, sampling the data-of-interest at each time step, then plot the accumulated results. This is the approach used by the ParaView "Probe" and "Pick" filters for plotting. Pros: works today, capable of "recording" any data that varies over time - regardless of network complexity. Cons: extremely poor performance.
- Use "out-of-band" APIs to collect time-varying data from network nodes that support doing so. The (only known?) example of this is vtkExodusReader / vtkPExodusReader, for which the GetTimeSeriesData() method will return an array of values for a given variable and element ID. Pros: works today (on the client), good performance. Cons: usable only with those nodes that implement an API for reading time-varying data. Cannot collect time-varying data that has been modified by filters, without adding the out-of-band API to each filter.
- Expand the visualization pipeline to include time-varying data. Pros: good performance, capable of returning any data that varies, regardless of network complexity. Cons: major changes to VTK pipeline. Passing time-varying data down the pipeline continuously would be a major performance problem, implying that some way of "querying" for data up the pipeline would be necessary, e.g. growing "extents" to support temporal extents.
Implementation
- A new class, vtkSMClientSideDataProxy, has been created for general-purpose work: it collects a complete vtkDataSet from the servers. To use it, use the AddInput() method to connect it to a source proxy, then call GetCollectedData() to return a vtkDataSet. Internally, it uses vtkMPIMoveData to handle the transfer of data from server(s) to client.
Examples
An example of client side data in action: the histogram in this screenshot was generated directly from the vtkDataSet transmitted to the client:
Sample plot of cell data varying over time, for a specified cell:
