ClientSideData: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
No edit summary
mNo edit summary
Line 20: Line 20:
==Examples==
==Examples==


An example of client side data in action: the histogram in this screenshot was generated directly from the vtkDataSet transmitted to the client:
<table>
 
<tr>
[[Image:Histogram.png]]
<td>[[Image:Histogram.png|thumb|left]]</td>
 
<td>An example of client side data in action: the histogram in this screenshot was generated directly from the vtkDataSet transmitted to the client.</td>
 
</tr>
 
<tr>
 
<td>[[Image:Line_plot.png|thumb|left]]</td>
Sample plot of cell data varying over time, for a specified cell (note that in this example the client is querying the client-side Exodus reader directly, so this isn't a true example of transferring data from server(s) to client):
<td>Sample plot of cell data varying over time, for a specified cell (note that in this example the client is querying the client-side Exodus reader directly, so this isn't a true example of transferring data from server(s) to client).</td>
 
</tr>
[[Image:Line_plot.png]]
</table>

Revision as of 15:03, 3 January 2006

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

Histogram.png
An example of client side data in action: the histogram in this screenshot was generated directly from the vtkDataSet transmitted to the client.
Line plot.png
Sample plot of cell data varying over time, for a specified cell (note that in this example the client is querying the client-side Exodus reader directly, so this isn't a true example of transferring data from server(s) to client).