[Paraview] Parallel Load/Rendering of Polygon Data

[Phillip Ezolt]

Hi All,

	I have a large polygon model (2.5 gig) that I want to view within
paraview.  Individually, each of the nodes do not have enough memory (2
gig) to load the model, however, in parallel, they should have enough.
I've tried several different ways to load and render my model in
parallel without success....

Questions:
	1) Does paraview provide way to load and render this polygon
	   data in parallel, with each node loading and rendering a
	   subset of the data? 

	If I:
		A) load another relatively large model, 
		B) split it across many nodes, 
		C) use "map process id to color"

	The image appears on the screen with a series of horizontal
	bands. This is as if each of the nodes had all of the polygons,
	but only drew a band of it. (Sort-last)

	I would prefer that each node loaded and drew a different subset
        of the geometry and then depth-composited it together.
	
	(At first, round robin selection of polygons would be just
         fine..)

	Does paraview support this?  If not, where would I look to add
	the round-round loading/rendering of polygon data?

	2) What file format should I save the polygon data in? 
		
	I've used a single 4-gig x86_64 node to convert it from VRML 2.0
	to a 'pvd' file.  However, the 'pvd' file only has one
        piece, "lucy_0.vtp".  When I try to load it on many (8) 2-gig
	nodes in parallel, they each run out of memory.  

	When I load the model on the single 4-gig node, the RSS of 
	paraview is ~2.5 gig.  As a result, I would expect an 8 way run
        of paraview to each be 300M... That isn't the case.  (Yes, I
        know that things don't scale like that, but each node should
        not require more than 1 gig...)

	What is the right file format to use for parallel loading?  How
	should I generate this file from VRML data? 

NOTE: I'd had success loading/parallizing raw data across many nodes,
but polygon data doesn't seem to work.  However, I may not have reached
the single-node memory threshold....


Thanks in advance,
-- 
Phillip Ezolt <Phillip.Ezolt at hp.com>