[Paraview] Parallel XDMF Reader and Distributed Parallel Render issues

[David E DeMarle]

>The first question is: Should I use ¡°Data Collection¡± or other structures
like ¡°Tree¡±, >¡°Subset¡± to organize the Grids?

I recommend a collection for this. In Parallel, it _should_ work such that
each processor reads a different stripe of the contents of the collection
out of the HDF5 data. I think that a top level collection is required to
make the striping work and an implicit one like you have will not work (that
was the case last time I touched the reader a couple of years ago). I say
should because I think as of a few weeks ago there was a bug in the
vtkXDMFReader that made this not work properly.

If the filesystem has bandwidth to support the independent reads then
striping within a collection will be the fastest configuration possible.

 I run paraview on an cluster with 8 nodes, and I type the command ¡°mpirun
> ¨Cnp 8 ./pvserver¡± on the first node to start the server, which allocate each
> node one server process. Then I also start paraview on the first node using
> ¡°./paraview¡±, and connect to the server.
>
> I have read << The ParaView Guide>>, and it says that when paraview run in
> the Client/Server mode, render server and data server will all run on the
> server end. But when running the Client/Server mode on my cluster, it seems
> that only the data server is distributed working on the 8 nodes and the
> render server does not work(only Collection but not sort last render). Here
> are some time logs recording the whole process.
>
> Local Process
>
> Still Render,  0.022987 seconds
>
>     Execute vtkMPIMoveData id: 1563,  0.019109 seconds
>
> Still Render,  82.7161 seconds
>
>     Execute vtkMPIMoveData id: 1563,  0.014251 seconds
>
>     Execute vtkMPIMoveData id: 1843,  76.0409 seconds
>
> Still Render,  2.77689 seconds
>
> Still Render,  2.77948 seconds
>
>
>
> Server, Process 0
>
> Execute vtkXdmfReader id: 1303,  0.893424 seconds
>
> Execute vtkPVGeometryFilter id: 1394,  0.024707 seconds
>
> Execute vtkMPIMoveData id: 1563,  0.011097 seconds
>
> Execute vtkContourFilter id: 1711,  5.41831 seconds
>
> ¡­¡­¡­¡­¡­¡­# also the vtkContourFilter time
>
> Execute vtkContourFilter id: 1711,  0.189248 seconds
>
> Execute vtkPVGeometryFilter id: 1729,  2.45381 seconds
>
> Execute vtkMPIMoveData id: 1843,  61.2669 seconds
>
>     Dataserver gathering to 0,  39.0038 seconds
>
>     Dataserver sending to client,  22.2626 seconds
>
>
>
> Server, Process 1
>
> Execute vtkXdmfReader id: 1303,  0.884488 seconds
>
> Execute vtkPVGeometryFilter id: 1394,  0.026233 seconds
>
> Execute vtkContourFilter id: 1711,  5.40355 seconds
>
> ¡­¡­¡­¡­¡­¡­# also the vtkContourFilter time
>
> Execute vtkContourFilter id: 1711,  0.173221 seconds
>
> Execute vtkPVGeometryFilter id: 1729,  2.41831 seconds
>
> Execute vtkMPIMoveData id: 1843,  3.25894 seconds
>
>     Dataserver gathering to 0,  3.25879 seconds
>
>
>
> Server, Process 2
>
> ¡­¡­¡­¡­¡­¡­¡­¡­¡­
>
> ¡­¡­¡­¡­¡­¡­¡­¡­¡­
>
> Server, Process 7
>
> ¡­¡­¡­¡­¡­¡­
>
> #the other Server process are same as process 1
>
>
Whether the render server gets involved is configuration and data size
dependent. See the remote render threshold control under preferences. When
you are doing remote rendering make sure that the server has access to GL
(either GPU based or CPU based with OSMesa) and that X is not being
forwarded back to the client. mpirun -np N glxgears should pop up windows on
each server node for instance, and not multiple windows back on the client.


>
>
> From the time log, I only see the time record related to data server, but
> there are not render server. It seems that all render works are just done on
> the Local Process, and the other processes only take responsibility for raw
> data processing, producing geometry and transferring geometry to Local
> Process.
>
>        In additional, I tried to run paraview in Client/Server mode
> respectively on 1 node, 4 nodes and 8 nodes. I found that the more I use
> the nodes, the longer the render time is. It depressed me seriously.
>

ParaView scales in terms of data size (Gustafsons law), not in terms of
speed (Ahmdahls law). That is, if the data is small enough to process on one
processor, adding more processors will probably slow it down. If the data is
too large for one processor, say because it requires swapping (or exceeds
memory entirely), then adding more processors makes it faster (or possible
at all).


> Do I run the Client/Server mode correctly? Why the performance continued to
> decline when more nodes joined to the server? Is it related to the
> ¡°Setting->Render View->Server->Remote Render Threshold¡±? But my data is
> large(about 4GB), and even I cancel this Threshold, there are no improvement
> for the render time. Could you tell me how to make paraview render in
> distributed parallel?
>
> Thank you for your helpJ
>
>
> ------------------------------
> ûÓйã¸æµÄÖÕÉíÃâ·ÑÓÊÏä,www.yeah.net <http://www.yeah.net/?from=footer>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20090827/10d46da6/attachment-0001.htm>