Re: Is there solution to numerical inaccuracy

From: Peter Freddolino (petefred_at_ks.uiuc.edu)
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?
Yes.

Peter

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