From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Wed May 20 2015 - 11:07:56 CDT
On Wed, May 20, 2015 at 5:59 PM, Michael Feig <feig_at_msu.edu> wrote:
> Hence my statement about running on a single core ... and the Berendsen thermostat does not use random seeds.
in NAMD/charm++ you *always* run in parallel (the basic idea of
charm++ is to apply "overparallelization" with the load balancer then
distributing the resulting work units across the available pool of
compute units), so your system will be always be divided into patches
which will be executed in unspecified order.
it does not use random seeds, but it cannot dissipate a drift either.
> Otherwise there are possibly two related options in NAMD:
> COMmotion
> zeroMomentum
>
> Only the latter should be relevant but it is turned off in our simulations.
i disagree. i quick google search gives:
COMmotion $ <$ allow initial center of mass motion? $ >$
Acceptable Values: yes or no
Default Value: no
Description: Specifies whether or not motion of the center of mass of
the entire system is allowed. *** If this option is set to no, the
initial velocities of the system will be adjusted to remove center of
mass motion of the system. *** Note that this does not preclude later
center-of-mass motion due to external forces such as random noise in
Langevin dynamics, boundary potentials, and harmonic restraints.
so there you have your explanation for the COM drift quench on
restart. if you want to keep that COM drift, you have to set COMmotion
to yes.
axel.
>
> If NAMD does remove drift upon restart (which it seems it does) and there is a way to turn it off, we would be happy to learn how to accomplish that.
>
> The question of why there is drift (or not) is a good one and exactly the reason why this issue is coming up. If we need to run long simulations to see a drift but cannot do so without NAMD removing the drift at every restart it is difficult to diagnose ... we do understand the issues otherwise.
>
> Michael.
>
> -----Original Message-----
> From: Axel Kohlmeyer [mailto:akohlmey_at_gmail.com]
> Sent: Wednesday, May 20, 2015 11:49 AM
> To: NAMD list; Michael Feig
> Subject: Re: namd-l: Restarting trajectories
>
> On Wed, May 20, 2015 at 9:47 AM, Michael Feig <feig_at_msu.edu> wrote:
>> To come back to the different trajectory topic raised by Grzegorz and
>> maybe clarify things:
>>
>>
>>
>> We do understand issues about the chaotic nature of MD simulations but
>> it seems that a ‘short’ simulation, let’s say for 10 ps running on a
>> single core should be identical
>
> please note that the parallelization and load balancing methodology used in NAMD will likely change the order in which forces are summed even when running on a single processor. like it stated before, unless you use fixed point math and no thermostat, you cannot expect trajectories to be perfectly reproducible and reversible.
>
>> whether it is run as a single run or restarted in between. If that is
>> not the case with NAMD, it means that the frequency of restarts
>> affects the trajectory one obtains.
>>
>> Moreover, we seem to see that every restart leads to some kind of
>> reset in system drift which means that the results are actually
>> different depending on how often
>>
>> simulations are restarted. We seem to see this with the Berendsen
>> thermostat where (Langevin) random seeds should not play a role.
>>
>>
>>
>> The next step for us would be to dig into the NAMD code to see what is
>> going on, but I think there may be a problem here.
>
> have you checked the NAMD documentation whether there is an option to remove the COM motion upon (re)start?
> i wouldn't be surprised if this may be active by default and would need to be disabled if you want to preserve the center of mass motion.
> but in any case, i don't think removing the COM drift on restart should be a big issue, but rather what part of your simulation setup is *causing* it, since that should not happen under normal circumstances.
> please also note that unlike langevin, a berendsen thermostat will not dissipate a drift but is more likely to enhance it (since *all* velocities are scaled by the same factor thus having the largest error on the fastest atoms).
>
> axel.
>
>>
>>
>>
>> Michael.
>
>
>
> --
> Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0 College of Science & Technology, Temple University, Philadelphia PA, USA International Centre for Theoretical Physics, Trieste. Italy.
>
-- Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0 College of Science & Technology, Temple University, Philadelphia PA, USA International Centre for Theoretical Physics, Trieste. Italy.
This archive was generated by hypermail 2.1.6 : Thu Dec 31 2015 - 23:21:53 CST