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 <ndfa...@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" <kmo...@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." <biddi...@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: kmo...@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