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

Wed Jun 12 22:58:40 CEST 2013

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?
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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130612/56ef21dd/attachment.html>