[Paraview] Parallel Scalability
Berk Geveci
berk.geveci at kitware.com
Tue Apr 2 13:41:22 EDT 2013
Hi Olaf,
I am having some difficulty reproducing this issue. It seems to scale fine
for me. I have some suggestions for improving workflow andperformance:
1. You can simply use pvbatch for this if you remove the Connect() command
from the script. I was running it as:
mpiexec -n 2 ~/Work/ParaView/git-3.14/build-osmesa/bin/pvbatch visualize.py
conc_4996800.vtr
This removes the need to setup a pvserver and a pvpython. It might also
improve performance in situations where ParaView delivers geometry to the
client (pvpython). This is unnecessary for batch use and pvbatch should
avoid it.
2. If you add the following to the end of your script (when running with
pvbatch), you can see a more detailed breakdown of timing information. This
will tell you how long each filter is taking on each process.
from paraview import servermanager as sm
session = sm.ActiveConnection.Session
timerInfo = sm.vtkPVTimerInformation()
timerInfo.SetLogThreshold(0)
session.GatherInformation(0x04, timerInfo, 0)
for i in range(timerInfo.GetNumberOfLogs()):
print timerInfo.GetLog(i)
3. The way you are using the transform filter is significantly increasing
your compute time and memory usage by converting your rectilinear grid to a
structured grid (because rectilinear grids are always axis aligned). If you
really must transform your data, I suggest transforming the output of the
contour filter. This was a huge time server when I was running this script.
Best,
-berk
On Tue, Mar 26, 2013 at 11:40 AM, Dr. Olaf Ippisch <
olaf.ippisch at iwr.uni-heidelberg.de> wrote:
> Dear Berk,
>
> I tried your suggestion and coloured the result with the
> ProcessIdScalars Filter. I can see the partitioning and it also makes
> sense, so there should not be any major load imbalance. I did add some
> timing information in the code. I add the changed program. It is evident
> that the data input is not the bottleneck. There is also some speedup in
> the application of the filters (should be the contour filter mostly),
> but this is more than compensated by the much longer time needed by the
> WriteImage command which does the rendering. You can see the times
> below. As I use a fast raid for the I/O this is not due to disk speed.
> Do you have any ideas if I could do something to speed up this last part?
>
> Best regards,
> Olaf
>
> 1 Process:
> Reading data from conc_4996800.vtr
> Setup and Transformation took 1.52222299576
> Writing contour_00380.png
> [Array: conc, Array: ProcessId]
> (0.0, 0.0)
> Filters took 83.8577969074
> Rendering took 13.8007481098
> Total runtime: 99.1809921265
>
> 2 Processes:
> Reading data from conc_4996800.vtr
> Setup and Transformation took 1.02662491798
> Writing contour_00380.png
> [Array: conc, Array: ProcessId]
> (0.0, 1.0)
> Filters took 54.6261291504
> Rendering took 46.8519799709
> Total runtime: 102.504925966
>
> 4 Processes:
> Reading data from conc_4996800.vtr
> Setup and Transformation took 0.90910410881
> Writing contour_00380.png
> [Array: conc, Array: ProcessId]
> (0.0, 3.0)
> Filters took 56.8009800911
> Rendering took 42.3190040588
> Total runtime: 100.029356956
>
>
>
> Am 26.03.13 13:43, schrieb Berk Geveci:
> > Hi Olaf,
> >
> > From your previous message, I am assuming that you are using vtr files.
> > In this case, the processing should scale. If you can make an example
> > files available, I can verify this. Feel free to e-mail them to me
> > directly or I can download them somewhere if they are too big. The two
> > potential problems are:
> >
> > - IO. You still have one disk if you are not running this on a cluster.
> > If the processing that ParaView is doing is negligible compared to the
> > time it takes to read the data, you will not see good scaling of the
> > whole script as you add more processes.
> >
> > - Load balancing. ParaView uses static load balancing when running in
> > parallel. So if that partitioning is not load balanced wrt iso-surfacing
> > (e.g. most of the iso-surface is generated by one process only), you
> > will not see good scaling. You can check if this is the case by applying
> > Process Id Scalars to the contour output. It will color polygons based
> > on which processor generates them.
> >
> > Best,
> > -berk
> >
> >
> >
> > On Mon, Mar 25, 2013 at 10:46 AM, Dr. Olaf Ippisch
> > <olaf.ippisch at iwr.uni-heidelberg.de
> > <mailto:olaf.ippisch at iwr.uni-heidelberg.de>> wrote:
> >
> > Dear Paraview developers and users,
> >
> > I tried to run paraview in parallel using a python script. I
> compiled a
> > server including OpenMPI support and support for MESA off-screen
> > rendering and started the server using mpirun. The I connected from a
> > python script (see attachment). I could see that there are two
> threads
> > both taking 100% CPU time. However, there was absolutely no speed-up.
> > The runtime using two processors was completely the some. The data
> sets
> > were rather large (about 100 million unknowns in 3D, 512 x 512 x
> 405).
> > The result looked like the result with one process, but the time
> needed
> > was also the same. I am sure that I am making some error either in
> the
> > setup or I am missing something in the python program. Do you have
> any
> > suggestions?
> >
> > Best regards,
> > Olaf Ippisch
> >
> > --
> > Dr. Olaf Ippisch
> > Universität Heidelberg
> > Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
> > Im Neuenheimer Feld 368, Raum 4.24
> > Tel: 06221/548252 Fax: 06221/548884
> > Mail: Im Neuenheimer Feld 368, 69120 Heidelberg
> > e-mail: <olaf.ippisch at iwr.uni-heidelberg.de
> > <mailto:olaf.ippisch at iwr.uni-heidelberg.de>>
> >
> > _______________________________________________
> > Powered by www.kitware.com <http://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
> >
> >
>
> --
> Dr. Olaf Ippisch
> Universität Heidelberg
> Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
> Im Neuenheimer Feld 368, Raum 4.24
> Tel: 06221/548252 Fax: 06221/548884
> Mail: Im Neuenheimer Feld 368, 69120 Heidelberg
> e-mail: <olaf.ippisch at iwr.uni-heidelberg.de>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20130402/0f3a653b/attachment.htm>
More information about the ParaView
mailing list