Hi Justin and Mark,<br><br>Thanks once again for getting back.<br><br>I&#39;ve found the problem - it&#39;s actually a known bug already: <br><br><a href="http://redmine.gromacs.org/issues/901">http://redmine.gromacs.org/issues/901</a><br>
<br>The dispersion correction is multiplied my the number of processes (I found this after taking a closer look at my md.log files to see where the energy was changing)! I guess this means I should use the serial version for meaningful binding energies. It also looks like it will be fixed for version 4.5.6<br>
<br>Thank you again, I really appreciate your help.<br><br>Steve<br><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 30/05/2012 9:42 PM, Stephen Cox wrote:<br>
&gt; Hi Justin,<br>
&gt;<br>
&gt; Thanks for getting back and posting the links.<br>
&gt;<br>
&gt;<br>
&gt;     On 5/29/12 6:22 AM, Stephen Cox wrote:<br>
&gt;     &gt; Hi,<br>
&gt;     &gt;<br>
&gt;     &gt; I&#39;m running a number of energy minimizations on a clathrate<br>
&gt;     supercell and I get<br>
&gt;     &gt; quite significantly different values for the total energy<br>
&gt;     depending on the<br>
&gt;     &gt; number of mpi processes / number of threads I use. More<br>
&gt;     specifically, some<br>
&gt;     &gt; numbers I get are:<br>
&gt;     &gt;<br>
&gt;     &gt; #cores      energy<br>
&gt;     &gt; 1        -2.41936409202696e+04<br>
&gt;     &gt; 2        -2.43726425776809e+04<br>
&gt;     &gt; 3        -2.45516442350804e+04<br>
&gt;     &gt; 4        -2.47003944216983e+04<br>
&gt;     &gt;<br>
&gt;     &gt; #threads    energy<br>
&gt;     &gt; 1        -2.41936409202696e+04<br>
&gt;     &gt; 2        -2.43726425776792e+04<br>
&gt;     &gt; 3        -2.45516442350804e+04<br>
&gt;     &gt; 4        -2.47306458924815e+04<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; I&#39;d expect some numerical noise, but these differences seem to0<br>
&gt;     large for that.<br>
&gt;<br>
&gt;     The difference is only 2%, which by MD standards, is quite good,<br>
&gt;     I&#39;d say ;)<br>
&gt;     Consider the discussion here:<br>
&gt;<br>
&gt;<br>
&gt; I agree for MD this wouldn&#39;t be too bad, but I&#39;d expect energy<br>
&gt; minimization to get very close to the same local minimum from a given<br>
&gt; starting configuration. The thing is I want to compute a binding curve<br>
&gt; for my clathrate and compare to DFT values for the binding energy<br>
&gt; (amongst other things), and the difference in energy between different<br>
&gt; number of cores is rather significant for this purpose.<br>
<br>
Given the usual roughness of the PE surface to which you are minimizing,<br>
some variation in end point is expected.<br></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt;<br>
&gt; Furthermore, if I only calculate the energy for nsteps = 0 (i.e. a<br>
&gt; single point energy for identical structures) I get the same trend as<br>
&gt; above (both mpi/openmp with domain/particle decomposition). Surely<br>
&gt; there shouldn&#39;t be such a large difference in energy for a single<br>
&gt; point calculation?<br>
<br>
nsteps = 0 is not strictly a single-point energy, since the constraints<br>
act before EM step 0. mdrun -s -rerun will give a single point. This<br>
probably won&#39;t change your observations. You should also be sure you&#39;re<br>
making observations with the latest release (4.5.5).<br></blockquote><div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If you can continue to observe this trend for more processors<br>
(overallocating?), then you may have evidence of a problem - but a full<br>
system description and an .mdp file will be in order also.<br>
<br>
Mark</blockquote><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt;<br>
&gt;<br>
&gt;     <a href="http://www.gromacs.org/Documentation/Terminology/Reproducibility" target="_blank">http://www.gromacs.org/Documentation/Terminology/Reproducibility</a><br>
&gt;<br>
&gt;     To an extent, the information here may also be relevant:<br>
&gt;<br>
&gt;     <a href="http://www.gromacs.org/Documentation/How-tos/Extending_Simulations#Exact_vs_binary_identical_continuation" target="_blank">http://www.gromacs.org/Documentation/How-tos/Extending_Simulations#Exact_vs_binary_identical_continuation</a><br>

&gt;<br>
&gt;     &gt; Before submitting a bug report, I&#39;d like to check:<br>
&gt;     &gt; a) if someone has seen something similar;<br>
&gt;<br>
&gt;     Sure.  Energies can be different due to a whole host of factors<br>
&gt;     (discussed<br>
&gt;     above), and MPI only complicates matters.<br>
&gt;<br>
&gt;     &gt; b) should I just trust the serial version?<br>
&gt;<br>
&gt;     Maybe, but I don&#39;t know that there&#39;s evidence to say that any of<br>
&gt;     the above tests<br>
&gt;     are more or less accurate than the others.  What happens if you<br>
&gt;     run with mdrun<br>
&gt;     -reprod on all your tests?<br>
&gt;<br>
&gt;<br>
&gt; Running with -reprod produces the same trend as above. If it was<br>
&gt; numerical noise, I would have thought that the numbers would fluctuate<br>
&gt; around some average value, not follow a definite trend where the<br>
&gt; energy decreases with the number of cores/threads...<br>
&gt;<br>
&gt;<br>
&gt;     &gt; c) have I simply done something stupid (grompp.mdp appended below);<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     Nope, looks fine.<br>
&gt;<br>
&gt;     -Justin<br>
&gt;<br>
&gt; Thanks again for getting back to me.<br>
&gt;<br>
&gt;<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.gromacs.org/pipermail/gmx-users/attachments/20120530/a4ed4a18/attachment-0001.html" target="_blank">http://lists.gromacs.org/pipermail/gmx-users/attachments/20120530/a4ed4a18/attachment-0001.html</a><br>

<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 30 May 2012 07:51:02 -0400<br>
From: &quot;Justin A. Lemkul&quot; &lt;<a href="mailto:jalemkul@vt.edu">jalemkul@vt.edu</a>&gt;<br>
Subject: Re: [gmx-users] Re: Possible bug: energy changes with the<br>
        number  of      nodes for energy minimization<br>
To: Discussion list for GROMACS users &lt;<a href="mailto:gmx-users@gromacs.org">gmx-users@gromacs.org</a>&gt;<br>
Message-ID: &lt;<a href="mailto:4FC609A6.4090702@vt.edu">4FC609A6.4090702@vt.edu</a>&gt;<br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
<br>
<br>
On 5/30/12 7:42 AM, Stephen Cox wrote:<br>
&gt; Hi Justin,<br>
&gt;<br>
&gt; Thanks for getting back and posting the links.<br>
&gt;<br>
&gt;<br>
&gt;     On 5/29/12 6:22 AM, Stephen Cox wrote:<br>
&gt;      &gt; Hi,<br>
&gt;      &gt;<br>
&gt;      &gt; I&#39;m running a number of energy minimizations on a clathrate supercell and<br>
&gt;     I get<br>
&gt;      &gt; quite significantly different values for the total energy depending on the<br>
&gt;      &gt; number of mpi processes / number of threads I use. More specifically, some<br>
&gt;      &gt; numbers I get are:<br>
&gt;      &gt;<br>
&gt;      &gt; #cores      energy<br>
&gt;      &gt; 1        -2.41936409202696e+04<br>
&gt;      &gt; 2        -2.43726425776809e+04<br>
&gt;      &gt; 3        -2.45516442350804e+04<br>
&gt;      &gt; 4        -2.47003944216983e+04<br>
&gt;      &gt;<br>
&gt;      &gt; #threads    energy<br>
&gt;      &gt; 1        -2.41936409202696e+04<br>
&gt;      &gt; 2        -2.43726425776792e+04<br>
&gt;      &gt; 3        -2.45516442350804e+04<br>
&gt;      &gt; 4        -2.47306458924815e+04<br>
&gt;      &gt;<br>
&gt;      &gt;<br>
&gt;      &gt; I&#39;d expect some numerical noise, but these differences seem to0 large for<br>
&gt;     that.<br>
&gt;<br>
&gt;     The difference is only 2%, which by MD standards, is quite good, I&#39;d say ;)<br>
&gt;     Consider the discussion here:<br>
&gt;<br>
&gt;<br>
&gt; I agree for MD this wouldn&#39;t be too bad, but I&#39;d expect energy minimization to<br>
&gt; get very close to the same local minimum from a given starting configuration.<br>
&gt; The thing is I want to compute a binding curve for my clathrate and compare to<br>
&gt; DFT values for the binding energy (amongst other things), and the difference in<br>
&gt; energy between different number of cores is rather significant for this purpose.<br>
&gt;<br>
<br>
I think the real issue comes down to how you&#39;re going to calculate binding<br>
energy.  I would still expect that with sufficient MD sampling, the differences<br>
should be small or statistically insignificant given the nature of MD<br>
calculations.  EM will likely be very sensitive to the nature of how it is run<br>
(MPI vs. serial, etc) since even the tiny rounding errors and other factors<br>
described below will cause changes in how the EM algorithm proceeds.  For most<br>
purposes, such differences are irrelevant as EM is only a preparatory step for<br>
more intense calculations.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; Furthermore, if I only calculate the energy for nsteps = 0 (i.e. a single point<br>
&gt; energy for identical structures) I get the same trend as above (both mpi/openmp<br>
&gt; with domain/particle decomposition). Surely there shouldn&#39;t be such a large<br>
&gt; difference in energy for a single point calculation?<br>
&gt;<br>
<br>
That depends.  Are you using the same .mdp file, just setting &quot;nsteps = 0&quot;?  If<br>
so, that&#39;s not a good test.  EM algorithms will make a change at step 0, the<br>
magnitude of which will again reflect the differences you&#39;re seeing.  If you use<br>
the md integrator with a zero-step evaluation, that&#39;s a better test.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
-Justin<br>
<br>
<br></blockquote><div><br></div></div>