Re: Is there solution to numerical inaccuracy

From: Peter Freddolino (
Date: Mon Dec 03 2007 - 17:02:51 CST

Hi Alok,

> This is what I can make out from this comment. I explain with an
> example. Suppose we take 'x1' as the seed for the A run (same seed for
> B1 run) and random number
> at the half of run A or at the end of B1 run is 'y1'. But since, we
> donot know the internal state of random number generator we are not
> aware of 'y1'. The second half
> of run A is proceding with 'y1' whereas to start the run B2 though we
> are using the restart files that we get at the end of B1 but we are
> providing 'x1' as the seed. Which I
> believe is the root cause. Peter, am I right in quoting this example?
> Please correct if I did a mistake.
> Is there no way in NAMD which is also keeping track of the random
> numbers generated so that at the time of crash we can open some kind
> of log file and see what was the random number at the time of crash
> and further use that random number for the restart file. I know all
> this holds
> true if we are running constant temperature on single processor.
> However, this random number generator is no more deterministic when it
> comes to
> doing simulation in parallel.
Your example and understanding appear correct. The reason that this is
not currently tracked in namd is that it really isn't important (because
of the sampling principles I outlined in that email). I'm sure if
someone wanted to contribute a patch to add this to the restart files it
would be welcome, but it isn't a high priority at this point...
>> If you run NVE simulations, you should always get the same results
>> (limited by floating point imprecision, if you're running in parallel)
>> from the same input coordinates and velocities.
> Is this imprecision is because of nodeterminism in different processes
> talking to master node and
> non-associativity of floating point addition?


This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:45:39 CST