[vtk-developers] [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR

[Berk Geveci]

Hi John,

Good news. It is now much easier to propagate meta-data and requests in VTK
now. (Don't give me a hard time about not communicating this. I am working
on my issues). All you need is a subclass of a vtkInformationKey that
overrides CopyDefaultInformation(), probably to copy itself. Look at
vtkEnsembleSource and vtkInformationDataObjectMetaDataKey to see an
example. In fact, if your kd tree is a vtkDataObject subclass, you can use
that key class to define a custom key like vtkEnsembleSource. No more need
for keys to copy silliness.

There is also support for adding arbitrary request objects without changing
executives. Look at vtkInformationIntegerRequestKey to see an example. You
need a key subclass that overrides
CopyDefaultInformation(), NeedToExecute(), StoreMetaData() for that.

I will write a blog with details in the near future.

Best,
-berk




On Wed, Aug 27, 2014 at 7:46 AM, Biddiscombe, John A. <biddisco at cscs.ch>
wrote:

>  Berk,
>
>
>
> OK. I see how the piece requests change, but I was using the extent
> translator to pass bounds information and (more importantly) a PKdTree
> (from Zoltan) downstream to the compositing engine to stop it from
> instantiating the D3 filter and performing a redundant and slow repartition
> when I enable transparency. My Zoltan partitioner used to add an extent
> translator (also containgin the KdTree) to the information in the pipeline,
> which the compositing code could detect and act appropriately (with some
> minor tweaks).
>
>
>
> Has the compositing code been enhanced in any way to make use of
> partitioning information that I can piggy-back for my needs?
>
>
>
> JB
>
>
>
> *From:* Berk Geveci [mailto:berk.geveci at kitware.com]
> *Sent:* 27 August 2014 13:36
> *To:* Biddiscombe, John A.
> *Cc:* vtk-developers at vtk.org; paraview-developers at paraview.org
> *Subject:* Re: [Paraview-developers]
> vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR
>
>
>
> Hi John,
>
>
>
> Check out:
>
>
>
> http://www.vtk.org/Wiki/VTK/Parallel_Pipeline
>
>
>
> Overall, load balancing should be much easier now. The reader can make
> arbitrary partitioning decisions but can still get requests from downstream
> about partitioning. Two main strategies:
>
>
>
> - Downstream send extent + piece requests, reader does its own
> partitioning based on these two
>
> - Downstream send specific extent requests to each rank (and no piece)
>
>
>
> The first one is appropriate to ParaView.
>
>
>
> This is much more robust and works through extract vois with subsampling
> etc. Something that never worked well in parallel.
>
>
>
> -berk
>
>
>
> On Wed, Aug 27, 2014 at 3:16 AM, Biddiscombe, John A. <biddisco at cscs.ch>
> wrote:
>
> Recompiling my Paraview plugins against the latest version, I find that
> many of the vtk::Keys I use frequently are gone.
>
>
>
> In order to handle my dynamic load balancing, I use the extent translators
> (particularly my own custom ones) continuously.
>
>
>
> Is there a replacement for this?
>
>
>
> thanks
>
>
>
> JB
>
>
>
> --
>
> John Biddiscombe,                        email:biddisco @.at.@ cscs.ch
>
> http://www.cscs.ch/
>
> CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
>
> Via Trevano 131, 6900 Lugano, Switzerland   | Fax:  +41 (91) 610.82.82
>
>
>
>
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140827/d1a53d67/attachment-0002.html>