From: Grzegorz Nawrocki (aksonik_at_gmail.com)
Date: Thu May 21 2015 - 09:10:28 CDT
You are right. Turning off the thermostat (i.e. running NVE) only is not
sufficient.
This time the difference is not visible immediately after restart, but
after some time after it,
that indeed, looks like the butterfly effect.
Thanks a lot,
Grzegorz
2015-05-20 15:38 GMT-04:00 Bennion, Brian <bennion1_at_llnl.gov>:
> 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>:
>
> 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> 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 <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> 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 <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.
>
>
>
>
>
>
> --
>
> Grzegorz Nawrocki
>
-- Grzegorz Nawrocki
This archive was generated by hypermail 2.1.6 : Tue Dec 27 2016 - 23:21:09 CST