[Paraview] caching output pipelines

Kent Eschenberg eschenbe at psc.edu
Mon May 5 13:47:21 EDT 2008


You seem to be on the right track except maybe for one detail: your reader cannot reuse the output data structure. Actually, there is little value to trying to reuse it since you are already keeping the non-varying part (the geometry) elsewhere. In RequestData a new output data structure must be built.

I made a custom, local change to the PVD reader so it does what you are trying to accomplish: it creates multi-block output from an input data set where the geometry does not change over time. I think this will be included in a future release.

But I did one thing different: I stored the geometry in a VTK data structure instead of the non-VTK structure you used. The main output from the reader is given a pointer to the saved geometry. I incremented the usage count for the geometry by one so that it was not deleted when the main data structure was deleted.

Kent
Pittsburgh Supercomputing Center

Olesen, Mark wrote:
> I'm working on bits of an add-on reader and would like to figure out how
> the pipeline caching is supposed to work. Unfortunately I only have
> immediate access to a somewhat older "VTK Visualization Toolkit" book
> and not the "VTK User's Guide", where the required information might
> presumably be found.
> 
> I have a time-invariant geometry (organized as a vtkMultiBlockDataSet
> with several blocks) and a number of time-steps. To avoid pulling the
> geometry data from disk at each time step, the geometry is cached in an
> internal (non-vtk) format. I've tried various means of updating field
> values only without needing to update the underlying geometry, but have
> had thus far no luck.
> 
> I was inspired by the Biddiscombe et al. IEEE 2007 publication and
> started digging through the VTK/IO directory for suitable examples.
> I can't, however, see that any of them have implemented the combination
> of an invariant geometry and transient fields.
> 
> At the moment I have a RequestInformation() method with
>     outInfo->Set
>     (
>         vtkStreamingDemandDrivenPipeline::TIME_STEPS(),
>         timeSteps,
>         nTimeSteps
>     );
> 
>     outInfo->Set
>     (
>         vtkStreamingDemandDrivenPipeline::TIME_RANGE(),
>         timeRange,
>         2
>     );
> 
> and a RequestData() method that responds to
> 
>     vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEPS()
> 
> 
> I suspect that UPDATE_TIME_STEPS could be combined with
> PREVIOUS_UPDATE_TIME_STEPS to a time change, but at each evaluation of
> RequestData(), the output DATA_OBJECT is always reset to having zero
> blocks anyhow. Since I haven't fiddled with the ReleaseData settings,
> (ie., the output block has "Global Release Data: Off" and "Release Data:
> Off") I assume this is a feature.
> 
> Are there other Request...() methods that I should be using here?
> 
> Is there an example somewhere in the VTK source that approaches what I
> am attempting or a pseudo-code snippet somewhere?
> What is the canonical method for tackling this problem?
> I could save my own private vtkMultiBlockDataSet within the class and
> then copy it to the output as required, but I somehow suspect that that
> isn't quite how it supposed to be done. It also feels funny (and slow)
> updating geometry that hasn't changed at all.
> 
> I would be very appreciative of any tips or hints for solving this
> problem.
> 
> /mark
> This e-mail message and any attachments may contain 
> legally privileged, confidential or proprietary Information, 
> or information otherwise protected by law of EMCON 
> Technologies, its affiliates, or third parties. This notice 
> serves as marking of its “Confidential” status as defined 
> in any confidentiality agreements concerning the sender 
> and recipient. If you are not the intended recipient(s), 
> or the employee or agent responsible for delivery of this 
> message to the intended recipient(s), you are hereby 
> notified that any dissemination, distribution or copying 
> of this e-mail message is strictly prohibited. 
> If you have received this message in error, please 
> immediately notify the sender and delete this e-mail 
> message from your computer.


More information about the ParaView mailing list