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

From: Ross Walker <ross.rosswalker.co.uk>
Date: Wed, 18 Mar 2009 23:07:07 +0000

Hi Bob,

> After trying to follow this thread and reading the Cerutti, Duke, et.
> al. paper, my lack of experience with Amber still leaves me with some
> questions about my restart runs. Here's the problem: if I restart
> after a minimization (or if NTX .lt. 3 .and. TEMPI .ne. 0.0), it is
> clear that the pseudo-random number generator (PRNG)comes into play and
> I would want to use a new IG each time. On the other hand, I assume it
> is *not* involved with restarting a sander run from a .rst file which
> contains the velocity information. So, if this is not the case, then
> I'd really like to know that.
>
> What is bothering me is that I'm (no doubt, naively) having difficulty
> imagining the situation when one would do a long series of linked
> calculations while resetting the initial velocities at each restart. In
> this case, the consequences of not specifically changing the IG value at
> each restart in order to find an initial, 'non-repetitive' set of
> velocities seem apparent. Alternatively, (and the crux of my concern) it
> may be that the PRNG is used elsewhere (embedded in the Amber code) and
> the reason for changing the IG value is not explicitly apparent.

What you are describing is correct if you do not use a thermostat or you use
a Berendsen thermostat. In this case the random number generator is not used
unless you are randomly assigning velocities which you do not do on a
restart. However, the paper and the discussion is refering to the case where
the Langevin thermostat is used (ntt=3) here the random number generator is
used to drive the Langevin thermostat and it is this situation that causes
the problems. Since if you keep reusing the same random number stream you
essentially impart a series of correlated forces on your system which can
cause all sorts of weird things to happen. Thus if you have ntt=3 you MUST
change the value of IG for every run including restarts. With AMBER 10 and
later you can set this to -1 and it will use the wallclock time in
microseconds and save you needing to script the change yourself.

I hope this answers your concerns.

All the best
Ross


/\
\/
|\oss Walker

| Assistant Research Professor |
| San Diego Supercomputer Center |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
| http://www.rosswalker.co.uk | PGP Key available on request |

Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.






_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Mar 20 2009 - 01:11:54 PDT
Custom Search