[gmx-developers] Inconsistent force calculating result between generic kernel and interaction-specific kernel?

Berk Hess hess at kth.se
Wed Jun 12 14:17:54 CEST 2013


Hi,

You haven't said at what step this happens.
At step zero the forces should match, except for the last decimal(s).
But since MD is chaotic, trajectories diverge exponentially, which is 
very fast.
This usually means forces are significantly decorrelated after 100 to 
1000 steps.

Cheers,

Berk

On 06/12/2013 01:50 PM, Mark Abraham wrote:
>
>
>
> On Wed, Jun 12, 2013 at 3:28 AM, Mark Tianwu Zang <zangtw at gmail.com 
> <mailto:zangtw at gmail.com>> wrote:
>
>     Hi Francesco and Mark,
>     Thanks for your precious advice. Now this time I didn't insert any
>     code but use the .mdp options instead. I used the following steps:
>     first set the environment variable GMX_NB_GENERIC=1, run the
>     GROMACS, and run again with the same input but GMX_NB_GENERIC
>     unset. Next, compare two force.xvg generated from two traj.trr
>     using g_traj. However, I still found the results different from
>     each other.. My gcc version is 4.6.3(almost the newest), my fftw
>     version is 3.3.3(double precision, and GROMACS is also build in
>     double-precision) and I use the argument --reprod to make sure the
>     calculation of PME is reproducible.
>     My running command for GROMACS is
>     mpirun -np 2 mdrun_mpi -s test.tpr -v -reprod
>
>
> That's better, but the advice here is worth following: 
> http://www.gromacs.org/Documentation/How-tos/Single-Point_Energy
>
>     I tried to attach my test tpr and mdp file in this email but my
>     attempt was not approved by administrator because the email would
>     be oversized..
>
>
> Describing in words what your system is doing would be a good start ;-)
>
> Mark
>
>
>     -Mark
>
>
>     On Sat, Jun 8, 2013 at 7:25 AM, francesco oteri
>     <francesco.oteri at gmail.com <mailto:francesco.oteri at gmail.com>> wrote:
>
>         In my case the excuse was that the system administrator never
>         updated the compiler.
>         So I after a couple of days I installed the new compiler.
>         In any case, I noticed that the problem disappeared using the
>         "Debug" version so  I guess
>         it is something related either to the optimized kernel or the
>         optimization strategy used by the compiler.
>
>
>         Francesco
>
>
>         2013/6/8 Mark Abraham <mark.j.abraham at gmail.com
>         <mailto:mark.j.abraham at gmail.com>>
>
>
>
>
>             On Sat, Jun 8, 2013 at 12:59 PM, francesco oteri
>             <francesco.oteri at gmail.com
>             <mailto:francesco.oteri at gmail.com>> wrote:
>
>                 H Mark,
>                 I had a similar problem recently and, eventually, I
>                 figured out the cause was the compiler version.
>                 I was using gcc4.1 and my problem got solved using a
>                 more recent version. Actually, this issue
>                 in the website is clearly stated. So, which compiler
>                 are you using?
>                 Could you report an example of inconsistency?
>
>
>             That warning has been there many years, but AFAIK nobody
>             ever identified the real problem (if it exists).
>             Nevertheless, there is no excuse for using both GROMACS
>             and such an old compiler! :-)
>
>             Mark
>
>
>                 Francesco
>
>
>                 2013/6/8 Mark Abraham <mark.j.abraham at gmail.com
>                 <mailto:mark.j.abraham at gmail.com>>
>
>
>
>
>                     On Sat, Jun 8, 2013 at 1:44 AM, Mark Tianwu Zang
>                     <zangtw at gmail.com <mailto:zangtw at gmail.com>> wrote:
>
>                         Dear all,
>                         I have inserted only a few lines after
>                         update() in md.c to monitor how forces change
>                         after every step. My codes are very simple,
>                         just like:
>                         for i=0 to md->nalloc
>                          fprintf f[i][0], f[i][1], f[i][2]
>
>
>                     That seems like the hard way to do it, with
>                     nstfout available in the .mdp file.
>
>                         However, I found the results of my output
>                         become quite different after exporting
>                         GMX_NB_GENERIC=1, which means the forces
>                         calculated by generic kernel and
>                         interaction-specific kernel are not the same.
>                         I am a little confused now.. It this phenomena
>                         quite normal or I ignored something important?
>
>
>                     AFAIK the generic kernel should serve as a
>                     reference for the interaction-specific kernels. If
>                     not, there might a problem to fix. Hard to say
>                     without context.
>
>                     Mark
>
>                         Thanks a lot!
>                         -Mark
>
>
>
>                         --
>                         gmx-developers mailing list
>                         gmx-developers at gromacs.org
>                         <mailto:gmx-developers at gromacs.org>
>                         http://lists.gromacs.org/mailman/listinfo/gmx-developers
>                         Please don't post (un)subscribe requests to
>                         the list. Use the
>                         www interface or send it to
>                         gmx-developers-request at gromacs.org
>                         <mailto:gmx-developers-request at gromacs.org>.
>
>
>
>                     --
>                     gmx-developers mailing list
>                     gmx-developers at gromacs.org
>                     <mailto:gmx-developers at gromacs.org>
>                     http://lists.gromacs.org/mailman/listinfo/gmx-developers
>                     Please don't post (un)subscribe requests to the
>                     list. Use the
>                     www interface or send it to
>                     gmx-developers-request at gromacs.org
>                     <mailto:gmx-developers-request at gromacs.org>.
>
>
>
>
>                 -- 
>                 Cordiali saluti, Dr.Oteri Francesco
>
>                 --
>                 gmx-developers mailing list
>                 gmx-developers at gromacs.org
>                 <mailto:gmx-developers at gromacs.org>
>                 http://lists.gromacs.org/mailman/listinfo/gmx-developers
>                 Please don't post (un)subscribe requests to the list.
>                 Use the
>                 www interface or send it to
>                 gmx-developers-request at gromacs.org
>                 <mailto:gmx-developers-request at gromacs.org>.
>
>
>
>             --
>             gmx-developers mailing list
>             gmx-developers at gromacs.org <mailto:gmx-developers at gromacs.org>
>             http://lists.gromacs.org/mailman/listinfo/gmx-developers
>             Please don't post (un)subscribe requests to the list. Use the
>             www interface or send it to
>             gmx-developers-request at gromacs.org
>             <mailto:gmx-developers-request at gromacs.org>.
>
>
>
>
>         -- 
>         Cordiali saluti, Dr.Oteri Francesco
>
>         --
>         gmx-developers mailing list
>         gmx-developers at gromacs.org <mailto:gmx-developers at gromacs.org>
>         http://lists.gromacs.org/mailman/listinfo/gmx-developers
>         Please don't post (un)subscribe requests to the list. Use the
>         www interface or send it to gmx-developers-request at gromacs.org
>         <mailto:gmx-developers-request at gromacs.org>.
>
>
>
>     --
>     gmx-developers mailing list
>     gmx-developers at gromacs.org <mailto:gmx-developers at gromacs.org>
>     http://lists.gromacs.org/mailman/listinfo/gmx-developers
>     Please don't post (un)subscribe requests to the list. Use the
>     www interface or send it to gmx-developers-request at gromacs.org
>     <mailto:gmx-developers-request at gromacs.org>.
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130612/b4648ab3/attachment.html>


More information about the gromacs.org_gmx-developers mailing list