Hi,<br><br>Thank you for taking the time to fix the issue. I would be very interested in testing out the modified code, but unfortunately I have had some difficulties compiling the Gromacs code obtained straight from GIT. In particular, I encounter the following error: <br>
<br>~/gromacs/src/tools/gmx_membed.c:1095: error: expected declaration specifiers or ‘...’ before ‘gmx_global_stat_t’<br><br>If you are curious to see the log and CMake cache files from the build, I have attached them to this email. I could also just patch the relevant parts of version 4.5.1 and test that out. If this would be feasible, then what specific lines should I modify?<br>
<br>-Kevin<br><br><br><br><br><br><br><br>
Date: Thu, 9 Sep 2010 17:19:36 +0200<br>
From: Berk Hess &lt;<a href="mailto:gmx3@hotmail.com">gmx3@hotmail.com</a>&gt;<br>
Subject: RE: [gmx-users] Overflow problem with test-particle insertion<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;COL113-<div id=":nr">W1513821AC701A1763B351B8E730@phx.gbl&gt;<br>
Content-Type: text/plain; charset=&quot;iso-8859-1&quot;<br>
<br>
<br>
Hi,<br>
<br>
I realized now that this is an SSE issue.<br>
Normally you would get NAN (or is it INF?). That is treated correctly in the GROMACS TPI code.<br>
But in SSE a float &quot;wraps around&quot; when it overflows, which could, in very few cases, lead to a reasonably<br>
looking energy value (I check for very high and very low values).<br>
I found that you can check for overflows in SSE and committed a fix for 4.5.2.<br>
I also filled the first 10 points (up to r=0.02 nm) of the potential/force tables, these used to be zero.<br>
These values are only relevant for energy minimization or TPI with extreme atomic overlap.<br>
<br>
Berk<br>
<br>
From: <a href="mailto:gmx3@hotmail.com">gmx3@hotmail.com</a><br>
To: <a href="mailto:gmx-users@gromacs.org">gmx-users@gromacs.org</a><br>
Subject: RE: [gmx-users] Overflow problem with test-particle insertion<br>
Date: Thu, 9 Sep 2010 09:39:42 +0200<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Hi,<br>
<br>
This is an interesting issue.<br>
The chance is quite small that this happens, but maybe not negligible.<br>
In single precision the maximum a float can store is 2^127.<br>
This gives a minimum distance of (2^127)^-1/12 = 6.5e-4 nm.<br>
The chance of inserting a particle within this radius is dens*3e-10,<br>
where dens is the number of particles per nm^3.<br>
A typical density of LJ particles is 30 per nm^3, which leads to a chance of 1e-8.<br>
Such insertion numbers can be reached, so we probably have to worry about this.<br>
<br>
However, in your example the distance seems to be around 4e-3, which would<br>
give r^-12 = 6e28. This still fits in a float and should not cause problems.<br>
So we should make sure we understand what&#39;s going on here.<br>
Could you file a bugzilla with the files to reproduce this and which insertion<br>
is the problematic one?<br>
<br>
I so two possible solutions:<br>
Force tabulated potentials with TPI, this can currently be achieved by setting<br>
the environment variable GMX_FORCE_TABLES<br>
Or require double precision.<br>
But I think both solutions would lead to about 40% lower performance.<br>
<br>
Berk<br>
<br>
<br>
Date: Wed, 8 Sep 2010 21:16:46 -0400<br>
From: <a href="mailto:kdaly@princeton.edu">kdaly@princeton.edu</a><br>
To: <a href="mailto:gmx-users@gromacs.org">gmx-users@gromacs.org</a><br>
Subject: [gmx-users] Overflow problem with test-particle insertion<br>
<br>
Hello Gromacs users,<br>
<br>
I sent a message to the list in June describing what appeared to be a 
float overflow issue with the energy calculation for test-particle 
insertions: <a href="http://lists.gromacs.org/pipermail/gmx-users/2010-June/052213.html" target="_blank">http://lists.gromacs.org/pipermail/gmx-users/2010-June/052213.html</a>.<br>
<br>
<br>
I have recently tried the test-particle insertion mode in Gromacs-4.5.1,
 and it seems the problem is still there. Does anyone know how to work 
around or fix this problem without using tabulated potentials?<br>
<br>
-Kevin<br>
</div>