[Paraview] Problem with parallel module

[Wylie, Brian]

Greg,
 
Observation: I wouldn't rely on IceT to precisely show you the piece
being renderer on each server. Meaning that's not one of the use cases
we care about... it may not be flipping the back buffer, node 0 may show
an image of  the model already 'composited', etc... you can ask Ken
Moreland for elaboration on the exact characteristics. But in any case
the images that you see on the server side may be misleading...
 
The first thing I would suggest is trying any of the existing 'sources'
or readers that already work in parallel, and then either looking at the
server windows or (the better option given the comment above) running
the 'ProcessIdScalars' filter to color the data by the processor id
thats working on that piece.
 
First Option
1) Source....Sphere...
2) Filter... ProcessIdScalars 
 
Second option is to use any of the existing readers on data that you can
find in VTKData or ParaViewData repositories. pvtp, pvtu, pvtr, etc....
all of these readers/datatypes will 'do the right thing' when run on
multiple processors. After reading in the data you can do the
'ProcessIds' filter.
 
Please let me know if any of these suggestions are helpful.... :)

  Brian Wylie - Org 1424
  Sandia National Laboratories
  MS 0822 - Building 880/A1-J
  (505)844-2238 FAX(505)845-0833                      
       ____                  _    __
      / __ \____  _________ | |  / (_)__ _      __
     / /_/ / __ `/ ___/ __ `/ | / / / _ \ | /| / /
    / ____/ /_/ / /  / /_/ /| |/ / /  __/ |/ |/ /
   /_/    \__,_/_/   \__,_/ |___/_/\___/|__/|__/

                                    Unleash the Beast


 


________________________________

	From: paraview-bounces+bnwylie=sandia.gov at paraview.org
[mailto:paraview-bounces+bnwylie=sandia.gov at paraview.org] On Behalf Of
Gregory D Abram
	Sent: Tuesday, October 03, 2006 4:21 PM
	To: paraview at paraview.org
	Subject: [Paraview] Problem with parallel module
	
	

	I'm trying to create a parallel reader and I guess I'm not
understanding something.  Before going so far as to actually read data,
I have a little attempt that, on each of 2 parallel servers, creates two
orthogonal meshes in the output vtkUnstructuredMesh thats passed into
its ExecuteData method.   It seems to run on both servers; I can put in
a gdb breakpoint at the ExecuteData entry point, and it gets hit in both
cases.   I can watch it create the two grids on each node.  I had
guessed that the reader, on each of the servers, would pass the local
data down through similar pipelines, which would join when truly
parallel filters are encountered, and finally join in a IceT sort-last
rendering process.   
	
	Unfortunately, it seems that the output of the reader in the
MyId = 1 server is disappearing.  IceT is doing the rendering, I think -
rendering windows pop up on the two server node's X servers.  But the
one on the MyId = 1 server remains empty, while the other shows the mesh
thats created on that server. 
	
	So I guess I'm wondering if I have to explicitly gather the data
back onto the MyId = 0 server and let PV handle redistribution?   Can
somebody point me at an illuminating document (I have the PV book on
order). 
	
	Thanks, 
	Greg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/paraview/attachments/20061003/c24e1992/attachment.htm