<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Just a quick follow-up to my run
performance problem.<br>
<br>
The culprit was the issue with LoopControl. Setting the parameter
"LoopControl::settle_after_iteration = 0" reproduced the previous
run performance with a performance boost of ~2% over the
ET_2013_05 version. I also tried using MVAPICH2 instead of Intel
MPI and saw the same type of behavior when using/not using the
above parameter.<br>
<br>
Thanks for your help,<br>
Jim Healy<br>
<br>
On 01/20/2014 01:07 AM, Roland Haas wrote:<br>
</div>
<blockquote cite="mid:52DCBD31.7050708@mail.gatech.edu" type="cite">
<pre wrap="">Hello Jim,
</pre>
<blockquote type="cite">
<pre wrap="">So, I tried using the previous stampede.cfg included in the ET_2013_05
branch of simfactory, the same one I used to compile my ET_2013_05
build. This cfgfile uses the same version of IMPI but different Intel
compilers (version 13.0.2.146). The run speed shows the same trends as
when using the newer config file.
</pre>
</blockquote>
<pre wrap="">Have you tried on a different machine as well?
</pre>
<blockquote type="cite">
<pre wrap="">The parameter file I am using is EXACTLY the same, not a single change.
The run is fairly lightweight, not requiring many nodes to run (I used
2). It is purely vacuum GR, an R1 configuration (equal-mass,
non-spinning BBH system with a small initial separation). Memory usage
in all three cases is the same, and is stable throughout the run.
Are there new parameters that I should be setting to get similar
performance as before? New thorns that I should have active? If not,
has anyone else used stampede recently and experienced similar problems?
</pre>
</blockquote>
<pre wrap="">In particular, please have a look at ticket #1512
<a class="moz-txt-link-freetext" href="https://trac.einsteintoolkit.org/ticket/1512">https://trac.einsteintoolkit.org/ticket/1512</a> which contains a small
parfile which you can use to test for particular issue in loopcontrol.
The test runs in ~2 minutes or so and you should be able to verify if
you see the slowdown you experienced. A workaround is to set
LoopControl::settle_after_iteration = 0 . The slowdown after recovery
however does not fit this picture.
Yours,
Roland
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@einsteintoolkit.org">Users@einsteintoolkit.org</a>
<a class="moz-txt-link-freetext" href="http://lists.einsteintoolkit.org/mailman/listinfo/users">http://lists.einsteintoolkit.org/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</body>
</html>