<div dir="ltr">Hi Olaf,<div><br></div><div>I am having some difficulty reproducing this issue. It seems to scale fine for me. I have some suggestions for improving workflow andperformance:</div><div><br></div><div style>1. You can simply use pvbatch for this if you remove the Connect() command from the script. I was running it as:</div>
<div style><br></div><div style>mpiexec -n 2 ~/Work/ParaView/git-3.14/build-osmesa/bin/pvbatch visualize.py conc_4996800.vtr<br></div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style><div>from paraview import servermanager as sm</div><div><br></div><div>session = sm.ActiveConnection.Session</div><div>timerInfo = sm.vtkPVTimerInformation()</div><div>timerInfo.SetLogThreshold(0)</div>
<div>session.GatherInformation(0x04, timerInfo, 0)</div><div><br></div><div>for i in range(timerInfo.GetNumberOfLogs()):</div><div> print timerInfo.GetLog(i)</div><div><br></div><div style>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.</div>
<div style><br></div><div style>Best,</div><div style>-berk</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 26, 2013 at 11:40 AM, Dr. Olaf Ippisch <span dir="ltr"><<a href="mailto:olaf.ippisch@iwr.uni-heidelberg.de" target="_blank">olaf.ippisch@iwr.uni-heidelberg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Berk,<br>
<br>
I tried your suggestion and coloured the result with the<br>
ProcessIdScalars Filter. I can see the partitioning and it also makes<br>
sense, so there should not be any major load imbalance. I did add some<br>
timing information in the code. I add the changed program. It is evident<br>
that the data input is not the bottleneck. There is also some speedup in<br>
the application of the filters (should be the contour filter mostly),<br>
but this is more than compensated by the much longer time needed by the<br>
WriteImage command which does the rendering. You can see the times<br>
below. As I use a fast raid for the I/O this is not due to disk speed.<br>
Do you have any ideas if I could do something to speed up this last part?<br>
<br>
Best regards,<br>
Olaf<br>
<br>
1 Process:<br>
Reading data from conc_4996800.vtr<br>
Setup and Transformation took 1.52222299576<br>
Writing contour_00380.png<br>
[Array: conc, Array: ProcessId]<br>
(0.0, 0.0)<br>
Filters took 83.8577969074<br>
Rendering took 13.8007481098<br>
Total runtime: 99.1809921265<br>
<br>
2 Processes:<br>
Reading data from conc_4996800.vtr<br>
Setup and Transformation took 1.02662491798<br>
Writing contour_00380.png<br>
[Array: conc, Array: ProcessId]<br>
(0.0, 1.0)<br>
Filters took 54.6261291504<br>
Rendering took 46.8519799709<br>
Total runtime: 102.504925966<br>
<br>
4 Processes:<br>
Reading data from conc_4996800.vtr<br>
Setup and Transformation took 0.90910410881<br>
Writing contour_00380.png<br>
[Array: conc, Array: ProcessId]<br>
(0.0, 3.0)<br>
Filters took 56.8009800911<br>
Rendering took 42.3190040588<br>
Total runtime: 100.029356956<br>
<br>
<br>
<br>
Am 26.03.13 13:43, schrieb Berk Geveci:<br>
<div class="im">> Hi Olaf,<br>
><br>
> From your previous message, I am assuming that you are using vtr files.<br>
> In this case, the processing should scale. If you can make an example<br>
> files available, I can verify this. Feel free to e-mail them to me<br>
> directly or I can download them somewhere if they are too big. The two<br>
> potential problems are:<br>
><br>
> - IO. You still have one disk if you are not running this on a cluster.<br>
> If the processing that ParaView is doing is negligible compared to the<br>
> time it takes to read the data, you will not see good scaling of the<br>
> whole script as you add more processes.<br>
><br>
> - Load balancing. ParaView uses static load balancing when running in<br>
> parallel. So if that partitioning is not load balanced wrt iso-surfacing<br>
> (e.g. most of the iso-surface is generated by one process only), you<br>
> will not see good scaling. You can check if this is the case by applying<br>
> Process Id Scalars to the contour output. It will color polygons based<br>
> on which processor generates them.<br>
><br>
> Best,<br>
> -berk<br>
><br>
><br>
><br>
> On Mon, Mar 25, 2013 at 10:46 AM, Dr. Olaf Ippisch<br>
> <<a href="mailto:olaf.ippisch@iwr.uni-heidelberg.de">olaf.ippisch@iwr.uni-heidelberg.de</a><br>
</div><div class="im">> <mailto:<a href="mailto:olaf.ippisch@iwr.uni-heidelberg.de">olaf.ippisch@iwr.uni-heidelberg.de</a>>> wrote:<br>
><br>
> Dear Paraview developers and users,<br>
><br>
> I tried to run paraview in parallel using a python script. I compiled a<br>
> server including OpenMPI support and support for MESA off-screen<br>
> rendering and started the server using mpirun. The I connected from a<br>
> python script (see attachment). I could see that there are two threads<br>
> both taking 100% CPU time. However, there was absolutely no speed-up.<br>
> The runtime using two processors was completely the some. The data sets<br>
> were rather large (about 100 million unknowns in 3D, 512 x 512 x 405).<br>
> The result looked like the result with one process, but the time needed<br>
> was also the same. I am sure that I am making some error either in the<br>
> setup or I am missing something in the python program. Do you have any<br>
> suggestions?<br>
><br>
> Best regards,<br>
> Olaf Ippisch<br>
><br>
> --<br>
> Dr. Olaf Ippisch<br>
> Universität Heidelberg<br>
> Interdisziplinäres Zentrum für Wissenschaftliches Rechnen<br>
> Im Neuenheimer Feld 368, Raum 4.24<br>
> Tel: 06221/548252 Fax: 06221/548884<br>
> Mail: Im Neuenheimer Feld 368, 69120 Heidelberg<br>
> e-mail: <<a href="mailto:olaf.ippisch@iwr.uni-heidelberg.de">olaf.ippisch@iwr.uni-heidelberg.de</a><br>
</div>> <mailto:<a href="mailto:olaf.ippisch@iwr.uni-heidelberg.de">olaf.ippisch@iwr.uni-heidelberg.de</a>>><br>
><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a> <<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>><br>
<div class="im HOEnZb">><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Please keep messages on-topic and check the ParaView Wiki at:<br>
> <a href="http://paraview.org/Wiki/ParaView" target="_blank">http://paraview.org/Wiki/ParaView</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br>
><br>
><br>
<br>
</div><div class="HOEnZb"><div class="h5">--<br>
Dr. Olaf Ippisch<br>
Universität Heidelberg<br>
Interdisziplinäres Zentrum für Wissenschaftliches Rechnen<br>
Im Neuenheimer Feld 368, Raum 4.24<br>
Tel: 06221/548252 Fax: 06221/548884<br>
Mail: Im Neuenheimer Feld 368, 69120 Heidelberg<br>
e-mail: <<a href="mailto:olaf.ippisch@iwr.uni-heidelberg.de">olaf.ippisch@iwr.uni-heidelberg.de</a>><br>
</div></div></blockquote></div><br></div>