<div dir="ltr">he Rene,<div><br></div><div>how did you pin your mpi processes on the node?</div><div>for the implicit solver this makes a big difference.</div><div>these routines are memory bandwidth limited. you will saturate your bandwidth usually when running on half the number of cores per socket.</div>

<div>so for a dual socket node you want to use half the number of cores per socket but use both sockets.</div><div>depending on the configuration of the system usually the default strategy is to fill the first socket completely before using cores from the second socket.</div>

<div><br></div><div>cheers</div><div>Thomas</div><div>ps i assume you run on intel Xeon cpu's? for amd its a little more complex since there you also have to make sure you pin your processes on a single socket in the right way.</div>

<div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 11:22 AM, Rene Gassmoeller <span dir="ltr"><<a href="mailto:rengas@gfz-potsdam.de" target="_blank">rengas@gfz-potsdam.de</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok so finally here is the promised update on the scaling results. I<br>
attached the new calc spreadsheet, in which I subtracted the<br>
initialization and I/O timing and averaged the runtimes over 3<br>
subsequent runs (not much change there, except from the very small models).<br>
In fact removing the initialization and I/O times from the runtime<br>
resolved the issue with the apparent slowdown for a high number of<br>
DoFs/core, apparently the I/O speed is somewhat limiting, but this will<br>
not be a problem for the final models.<br>
<br>
Using half the available cores per node did not change much in terms of<br>
efficiency (at least on a single node).<br>
<div><br>
>> - weak scaling is normally number of cores vs runtime with a fixed<br>
>> number of DoFs/core. Optimal scaling are horizontal lines (or you plot<br>
>> it as cores vs. efficiency)<br>
<br>
</div>Done in the new spreadsheet. The lines are not horizontal but see<br>
next point for this.<br>
<div><br>
>> - assembly might not scale perfectly due to communication to the ghost<br>
>> neighbors. I have not seen that much in the past, but it depends on<br>
>> the speed of the interconnect (and if you are bandwidth-limited it<br>
>> will get slower with number of DoFs/core). You can try to add another<br>
>> timing section for the matrix.compress() call.<br>
<br>
</div>Thanks for the hint. In the new setup (maximal cores per node)<br>
the assembly scales quite perfectly for 50 kDoFs/core at the moment . At<br>
400 kDoF/node at least the Stokes Assembly increase its computing time<br>
by 10 % over an increase in #DoFs by factor 8 (increasing global<br>
resolution by 1). This does support your point. However the increase is<br>
so small that it does not bother me at the moment.<br>
<br>
The increase in computing time for stokes solve however is by far the<br>
stronger effect. On the other hand I think this might be model specific<br>
for this setup. Since we wanted to use a setup that is not too far from<br>
the models we will run productively, we decided to include a spherical<br>
temperature/composition anomaly in the setup, which of course is<br>
resolved differently by the different resolutions. This may be the<br>
reason for the increased number of stokes iterations for increased<br>
resolution. For an actual assessment of the code scaling (instead of the<br>
scaling for our model setup) one would need<br>
to repeat the models with a resolution independent setup (i.e. harmonic<br>
perturbation of low degree), I guess. I finished a model setup for this,<br>
and if I find some free time I will update the results for resolution<br>
independence.<br>
<br>
Cheers and thanks for the help,<br>
Rene<br>
<br>
<br>
<br>_______________________________________________<br>
Aspect-devel mailing list<br>
<a href="mailto:Aspect-devel@geodynamics.org" target="_blank">Aspect-devel@geodynamics.org</a><br>
<a href="http://geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel" target="_blank">http://geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel</a><br></blockquote></div><br></div></div>