Re: [AMBER] IG not change at each restart of NPT simulation

From: Adrian Roitberg <roitberg.qtp.ufl.edu>
Date: Wed, 18 Feb 2009 09:46:36 -0500

Just to add my own two cents to this.

The vulnerability that Bob describes is indeed real. In practical terms
however, it will tend to show up as a problem if you run VERY short
simulations and then restart. If you were doing segments of 5-10 ps
(trust me, there are people doing this, I am not completely sure why !),
then I would be VERY worried. The signature of not changing the ig after
each re-run, as described in the paper he cites, would be seeing your
system blow up. I mean this literally, if you hit this problem, you WILL
know.

One can show that the problem rears its ugly head when you restart on
time scales of the order of the langevin thermostat's relaxation time.
You should be 'safe' with 1.6 ns.

We are undergoing the last revision of a paper showing a different
problem with langevin dynamics and restarts without changing IG. I do
not believe it will hit you at 1.6 ns anyways.

Cheers
Adrian


Carlos Simmerling wrote:
> I'm not sure sure that I would be that worried- people have done this
> for a while and gotten pretty reasonable agreement with expts. I think
> in theory there is a problem, but it's not really that clear that it
> causes severe problems in large, complex systems. I'm not saying that
> I disagree with Bob, or the paper cited, just that one needs to be
> careful in looking at the past and saying that since we found a
> potential problem that we should throw out our old work. Clearly much
> good work was done with older force fields that we not optimal, and so
> on. We make lots of approximations in our work, and we often improve
> them but if you understand the limitations of certain methods it
> doesn't mean work done with them should be discounted. It's not as
> simple as saying that simulations with highly complex systems that
> used the same ig value and Langevin thermostat are not acceptable.
> nothing we do is perfect- the challenge in being successful in this
> field is in understanding and managing the limitations.
>
> On Wed, Feb 18, 2009 at 8:57 AM, Robert Duke <rduke.email.unc.edu> wrote:
>> Jeffrey,
>> Sorry, but I would be worried if I were you. Please see the following
>> paper:
>> Cerutti, Duke, et al., "A Vulnerability in Popular Molecular Dynamics
>> Packages Concerning Langevin and Anderson Dynamics", J Chem Theory and
>> Computation 4, 1669 (2008).
>> Best Regards - Bob Duke
>>
>> ----- Original Message ----- From: "Jeffrey" <jeffry20072008.yahoo.cn>
>> To: "AMBER Mailing List" <amber.ambermd.org>
>> Sent: Wednesday, February 18, 2009 7:49 AM
>> Subject: [AMBER] IG not change at each restart of NPT simulation
>>
>>
>>> Dear all,
>>>
>>> I read previous posts discussing ntt=3 or 1 for NPT simulation. I
>>> performed a 30-ns npt trajectory using ntt=3 and ig=default at each restart
>>> (1.6 ns per segment) to monitor the conformational dynamics of a protein
>>> system. But some posts have mentioned that IG should change its value at
>>> each restart otherwise artiactual behavior can be observed. I'd like to know
>>> more in detail about how ig=default at each restart will effect my
>>> observation when I only concern on the conformational dynamics? Should I
>>> rerun the simulation from just the starting model?
>>>
>>> Many thanks.
>>>
>>>
>>> ----
>>> Jeffrey
>>>
>>>
>>> I pasted here one of the relating posts by Bob.
>>> ---------
>>> Germain -
>>> ig is used for computing random velocities during a restart that does NOT
>>> have velocity information (eg., from a minimization), and for the andersen
>>> and langevin thermostats (ntt 2, 3 respectively). You can get artifactual
>>> behaviour in the thermostats if you use the same seed in restarts, as you
>>> need to be effectively sampling from a gaussian distribution over the
>>> entire
>>> run, not resampling from the same sequence of pseudorandom numbers
>>> repeatedly. So in using these thermostats it is important to be careful
>>> about changing the value of ig through your restarts, or strange things
>>> can
>>> happen. There is a facility in sander to use the system clock to get the
>>> random seed, probably only in amber 10 (sorry, I don't have amber 10 doc
>>> available at the moment), and don't see it described in 9). I don't have
>>> this capability in pmemd yet. The best way to do this stuff is to carry
>>> the
>>> state of the rng forward between restarts; I plan to do that in pmemd in
>>> the
>>> future.
>>> Regards - Bob Duke
>>>
>>>
>>> __________________________________________________
>>> ¸Ï¿ì×¢²áÑÅ»¢³¬´óÈÝÁ¿Ãâ·ÑÓÊÏä?
>>> http://cn.mail.yahoo.com
>>>
>>>
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>

-- 
                           Dr. Adrian E. Roitberg
                             Associate Professor
                            Quantum Theory Project
                           Department of Chemistry
                 Senior Editor. Journal of Physical Chemistry
                          American Chemical Society
University of Florida                         PHONE 352 392-6972
P.O. Box 118435                               FAX   352 392-8722
Gainesville, FL 32611-8435                    Email adrian.qtp.ufl.edu
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Feb 20 2009 - 01:09:10 PST
Custom Search