[gmx-developers] Inconsistent force calculating result between generic kernel and interaction-specific kernel?
Berk Hess
hess at kth.se
Thu Jun 13 10:52:48 CEST 2013
Hi,
Are you running all these runs with domain decomposition?
If you are running in parallel, the local order of atoms (in md.c) can
be different, depending on the kernel. So that could explain your
different forces.
The forces in the trr, however, will always be ordered as in the
topology, and thus they should match with -rerun.
Cheers,
Berk
On 06/13/2013 10:46 AM, francesco oteri wrote:
> Hi Tianwu,
> just to be sure, can you try to compile with CMAKE_BUILD_TYPE=Debug
> and repeating again the runs?
>
> Francesco
>
>
> 2013/6/13 Mark Abraham <mark.j.abraham at gmail.com
> <mailto:mark.j.abraham at gmail.com>>
>
>
>
>
> On Wed, Jun 12, 2013 at 10:58 PM, Tianwu Zang <tz4 at rice.edu
> <mailto:tz4 at rice.edu>> wrote:
>
> Hi all,
> I am using a very common system for testing, with only one
> protein (~1000+ atoms) and ~7000+ water atoms with box size = 4.5
> When I tried rerun the simulation, results kept the same with
> the last run for the same kernel, but became quite different
> (even at step=0) for different kernel, like using generic
> kernel in the first run and specific kernel in the second run..
> In my case, for specific kernel, f[0]~884 and for generic
> kernel f[0]~337, which is a huge difference..
> I have already set the variable gen_seed in my .mdp file so
> there shouldn't be any problem of random seed.
> Now I am wondering if these force results should not differ
> from each other, where I am doing wrong?
>
>
> OK. What's your .mdp file?
>
> Mark
>
> Thanks again,
> -Mark
>
>
> On Wed, Jun 12, 2013 at 8:05 AM, francesco oteri
> <francesco.oteri at gmail.com <mailto:francesco.oteri at gmail.com>>
> wrote:
>
> Hi,
> Marc said it is using -rerun and, as far as I know and
> basing on my experience,
> it gives exactly the same reults. Of course, also the seed
> has to be the same :D
>
> Francesco
>
>
> 2013/6/12 Berk Hess <hess at kth.se <mailto:hess at kth.se>>
>
> 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>.
>>
>>
>>
>>
>
>
> --
> 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>.
>
>
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130613/4bd70315/attachment.html>
More information about the gromacs.org_gmx-developers
mailing list