From: Bennion, Brian (bennion1_at_llnl.gov)
Date: Wed May 20 2015 - 14:38:43 CDT
Hello
You still need to apply Axel’s other two criteria.
1. You need to only have one patch
2. Turn off tcouple
Brian
From: owner-namd-l_at_ks.uiuc.edu [mailto:owner-namd-l_at_ks.uiuc.edu] On Behalf Of Grzegorz Nawrocki
Sent: Wednesday, May 20, 2015 12:24 PM
To: NAMD list; Emad Tajkhorshid
Cc: Michael Feig; Axel Kohlmeyer
Subject: Re: namd-l: Restarting trajectories
You are right, by default center of mass motion is removed, i.e. comMotion = no. I repeated the simulation allowing for the montion, i.e. comMotion = yes. The trajectories, with and without restart, are still different. This time the directions of movement of individual atoms seem to be preserved, but the velocities are higher after the restart. They shouldn't, since I provide binary velocities, as well as coordinates. I don't use "temperature" or "seed" parameters at all. "tCouple" is on and "tCoupleTemp" is the same as before the restart. Is there something else that can be wrong?
Best wishes,
Grzegorz
2015-05-20 13:32 GMT-04:00 Emad Tajkhorshid <emad_at_life.illinois.edu<mailto:emad_at_life.illinois.edu>>:
I tend to agree with Michael, in that, when we “restart” a run, it should be as if the job did not stop at all (e.g., because of the job time limit). Otherwise, depending on how many times a job gets restarted one would get different results.
- Emad
On May 20, 2015, at 11:18 AM, Michael Feig <feig_at_msu.edu<mailto:feig_at_msu.edu>> wrote:
Thank you for the explanation! We will try that.
I think the confusion comes from what exactly a restart is supposed to be and what the meaning of 'initial velocities' is in the context of simulations that are being restarted. I would have expected that the phase space (coordinates and velocities) is preserved through a restart and that 'initial' truly means t=0. But it's ok, maybe we figured it out.
Thanks again!
-----Original Message-----
From: Axel Kohlmeyer [mailto:akohlmey_at_gmail.com]
Sent: Wednesday, May 20, 2015 12:08 PM
To: Michael Feig
Cc: NAMD list
Subject: Re: namd-l: Restarting trajectories
On Wed, May 20, 2015 at 5:59 PM, Michael Feig <feig_at_msu.edu<mailto: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<mailto: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<mailto: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<mailto:akohlmey_at_gmail.com> http://goo.gl/1wk0 College of Science & Technology, Temple University, Philadelphia PA, USA International Centre for Theoretical Physics, Trieste. Italy.
--
Grzegorz Nawrocki
This archive was generated by hypermail 2.1.6 : Tue Dec 27 2016 - 23:21:09 CST