langevin dynamics and random seeds

From: Peter Freddolino (
Date: Thu May 01 2008 - 11:44:40 CDT

Dear all,
it's public service announcement time:

Dave Cerutti at Vanderbilt recently discovered an artifact that can
occur with Langevin dynamics under some conditions: If the same random
number seed is used in multiple subsequent restarts of a simulation, and
Langevin random forces are applied in a deterministic order, then for
finite length runs there will be an accumulating drift in the force
applied to each atom over time (proportional to 1/sqrt(n), where n is
the length of each individual run). This can cause artifacts ranging
from unrealistically fast dynamics (for ~100,000 steps per run) to rapid
unphysical system denaturation (for 1000 steps per run). Dave is in the
process of further investigating this and writing up a full description
of the problem. This was originally discovered in AMBER, although it
sounds like some other packages may also be vulnerable.

To the best of our knowledge (both theoretical and due to tests
attempting to reproduce the artifact) NAMD is *not* affected by this
problem, for three reasons:
-namd langevin forces are applied patchwise, so if any atom migration
occurs during a run the order of atoms will be different in subsequent
runs (so any multi-patch system is safe)
-When namd is run in parallel, the order in which random numbers are
consumed is nondeterministic, so the repeated application of the same
set of random forces cannot occur (so any parallel run is safe)
-By default, namd uses a random number seed based on the current system
clock time, so the same random number seed will not be used for restart
runs (so any run not explicitly specifying a random number seed is safe)

I still want to bring this to the community's attention, both because
edge cases probably exist in namd where one could cause this drift to
occur (very small systems, run in serial, with an explicitly specified
constant seed in the config file) and because it generally affects
anyone using MD programs or writing their own MD code. It should not be
surprising that the best way to be safe from problems like this in *any*
application (not just MD) is to use a good PRNG, and make sure that you
use a seed value that doesn't repeat.

I'm sure more detail about when this does and does not occur, and how to
look for it, will be included in Dave's forthcoming paper.


This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:49:26 CST