[Paraview] CoProcessing question

[David E DeMarle]

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
>
>
>