[Paraview] CoProcessing question

[Biddiscombe, John A.]

David

Thanks. I think the vtkTableExtentTranslator is the right one for the job. I can instantiate one in the adaptor - or the pythoin script, and use the mpi_rank from the simulation to setup the extents table. What will be the hard part is forcing the pipeline to use it in the glue between the coprocessing and simulation.

I'll play with this approach and also the multi-block, and post back to the list if I discover anything useful.

JB

> -----Original Message-----
> From: David E DeMarle [mailto:dave.demarle at kitware.com]
> Sent: 29 July 2010 06:00
> To: Fabian, Nathan
> Cc: Moreland, Kenneth; Biddiscombe, John A.; Andy Bauer;
> paraview at paraview.org
> Subject: Re: [Paraview] CoProcessing question
> 
> In parallel structured data reader can only provide fixed structured
> extents on each processor (ie each gets a slab file and can't read
> other files), it can make up a table saying what processor provides
> what extents, assign that to a vtkTableExtentTranslator, and then
> replace the default extent translator it gets with the new one.
> Afterward the pipeline won't ask it to produce data outside of what it
> announced.
> 
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 28 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-371-3971 x109
> 
> 
> 
> On Wed, Jul 28, 2010 at 6:59 PM, Fabian, Nathan <ndfabia at sandia.gov> wrote:
> > Hi,
> >
> > I originally tried the following on each piece:
> >
> > SetOrigin(0,0,0)
> > SetSpacing(.1,.1,0)
> > SetExtent(0,xmax,ystart(myproc),ystop(myproc),0,0)
> >
> > And when I output it to XMLPImageDataWriter, paraview couldn't read it
> > complaining about the extents.  It actually correctly showed the first
> > piece.
> >
> > I could have sworn I talked to Utkarsh about it, but I can't find the
> > conversation... So it's quite possible there's a serious operator error on
> > my part.
> >
> > The current solution is in Paraview under
> > CoProcessing/Adaptors/FortranAdaptors/NPICAdaptor  That solution creates a
> > MultiBlockDataSet with one block (on each processor) which contains the
> > image.
> >
> > Nathan.
> >
> > On 7/28/10 4:44 PM, "Moreland, Kenneth" <kmorel at sandia.gov> wrote:
> >
> > John,
> >
> > I don't have any experience with that, but I think Nathan Fabian telling
> me
> > he tried that and it didn't work.  I don't remember why.
> >
> > -Ken
> >
> >
> > On 7/28/10 3:25 PM, "Biddiscombe, John A." <biddisco at cscs.ch> wrote:
> >
> > 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).
> >
> >
> >    ****      Kenneth Moreland
> >     ***      Sandia National Laboratories
> > ***********
> > *** *** ***  email: kmorel at sandia.gov
> > **  ***  **  phone: (505) 844-8919
> >     ***      web:   http://www.cs.unm.edu/~kmorel
> >
> >
> >