From: Emad Tajkhorshid (emad_at_life.illinois.edu)
Date: Wed May 20 2015 - 12:32:12 CDT
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]
> 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]
>> 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 : Tue Dec 27 2016 - 23:21:09 CST