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

Thu Jun 13 15:15:37 CEST 2013

That may very well be it. In his second mail Mark provided a command
line which included "mpirun -np 2", hence he was using DD.
--
Szilárd


On Thu, Jun 13, 2013 at 10:52 AM, Berk Hess <hess at kth.se> wrote:
> 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>
>>
>>
>>
>>
>> On Wed, Jun 12, 2013 at 10:58 PM, Tianwu Zang <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> 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>
>>>>>
>>>>> 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>
>>>>> 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> 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>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Jun 8, 2013 at 12:59 PM, francesco oteri
>>>>>>>> <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>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Jun 8, 2013 at 1:44 AM, Mark Tianwu Zang
>>>>>>>>>> <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
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> gmx-developers mailing list
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Cordiali saluti, Dr.Oteri Francesco
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> gmx-developers mailing list
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> gmx-developers mailing list
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cordiali saluti, Dr.Oteri Francesco
>>>>>>>
>>>>>>> --
>>>>>>> gmx-developers mailing list
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> gmx-developers mailing list
>>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> gmx-developers mailing list
>>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cordiali saluti, Dr.Oteri Francesco
>>>>
>>>> --
>>>> gmx-developers mailing list
>>>> 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.
>>>
>>>
>>>
>>> --
>>> gmx-developers mailing list
>>> 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.
>>
>>
>>
>> --
>> gmx-developers mailing list
>> 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.
>
>
>
>
> --
> Cordiali saluti, Dr.Oteri Francesco
>
>
>
>
> --
> gmx-developers mailing list
> 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.