[Paraview] CoProcessing question

[Biddiscombe, John A.]

Dave, Ken, Andy

> Is this a job for TableExtentTranslator in the reader or adapter?

I wish I knew the answer to this question. Who does?


> > Actually, I think there is an issue with structured extents.  The problem
> > with structured extents is that ParaView/VTK will ask for a particular
> > extent on each process, and these extents are not likely to match up with
> > what is actually available on that process.  It situation is stupid
> because
> > the extents are picked arbitrarily, and everyone would be happy with the
> > extents available from the FORTRAN code, but there is no way for the
> > CoProcessing library to force the pipeline to accept certain extents.

Hold on a minute. Everything you said is quite right and I'm with you 100% - Except. Suppose the pipeline places piece numbers in each update request - which are converted to structured extents (can't remember exactly where in the executive this will happen, but it will somewhere) - then the reader (or in this case coprocessing library) produces pieces of data which in our case, will not be the right pieces. We set the extents accordingly on out imagedata and just past the results out. When the pipeline downstream receives all these pieces, it will probably ignore the updateextent that was requested and use the real extent on the actual dataobjects. No? yes?

It might work. Anyway. I'll try out some pieces and see what gives. Ideally the coprocessing library will need a way of modifying the extents. I'll see if there's a way of managing it. (I'll also see what the TableExtentTranslator thingy does, though it may be the reverse of what we want).

We had a vague plan at some point to allow filters to set some kind of piece manipulator on the executive for load balancing on transient data where the topology features are in one place and skip loading other bits. I'll think about this some more.

> > The only way around the problem right now that I know of is to place the
> > data in a multiblock structure like AMR.

Would like to avoid this. Did vtkMultiPieceDataSet ever get worked on?

thanks for thought provoking feedback

JB

> >
> > -Ken
> >
> >
> > On 7/28/10 9:59 AM, "Andy Bauer" <andy.bauer at kitware.com> wrote:
> >
> > Hi John,
> >
> > I'd like to think it works but as I haven't tested it to do that I'm not
> > going to promise that it works :)  It uses a TrivialProducer to insert the
> > data set/composite data set into the pipeline with the idea that
> > coprocessing should essentially execute almost exactly the same as any
> > corresponding paraview python script for pvbatch.
> >
> > Since you're asking about it though I'll try to look at it this week and
> get
> > back to you.  If you get to it sooner than I do and find a bug then I'd
> also
> > be more than happy to try and fix it.
> >
> > Andy
> >
> > On Wed, Jul 28, 2010 at 11:02 AM, Biddiscombe, John A. <biddisco at cscs.ch>
> > wrote:
> >
> > I'm experimenting with the coProcessing library. It's very nice. Well done
> > you guys.
> >
> > Question : I have a Fortran code generating a slab of data (volume,
> actually
> > a rectilinear grid, but for now I'll be happy with a volume).
> >
> > I can send the data into the adaptor and generate datasets, all is well.
> On
> > a single process all seems to be normal, but before I start on lots of
> cores
> > .....
> >
> > The data is divided among processes such that I need to worry about whole
> > extents, and piece extents.
> >
> > Can I export individual image data (rectilinear grid) pieces from each
> > process, set the extent locally and let the usual paraview pipeline handle
> > it. Normally (in a reader) I'd be getting piece numbers and all that and
> I'm
> > not sure if this will be transparent or not.
> >
> > The Phasta (I think) example, uses a multiblcok structure, which I'd
> prefer
> > to avoid. a Multipiece dataset is fine...is there a volume example
> anywhere?
> >
> > Thanks
> >
> > JB
> >
> >
> >
> >    ****      Kenneth Moreland
> >     ***      Sandia National Laboratories
> > ***********
> > *** *** ***  email: kmorel at sandia.gov
> > **  ***  **  phone: (505) 844-8919
> >     ***      web:   http://www.cs.unm.edu/~kmorel
> >
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the ParaView Wiki at:
> > http://paraview.org/Wiki/ParaView
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.paraview.org/mailman/listinfo/paraview
> >
> >