[gmx-developers] Does GROMACS pass random numbers through checkpoint/restart files?

[David Cerutti]

Just another comment here, this issue I mentioned pertains to a protein 
solvated with explicit water, particle-mesh Ewald, a conservative 1.5fs 
time step with SHAKE on all bonds to hydrogen, SETTLE on the water, 9.0A 
real-space cutoff, Lennard-Jone tails.  By all measures, this is a very 
safe MD simulation protocol, and in another case I have it running with a 
stable tetramer for 250ns.

I'm testing Andersen thermostat as well, and it appears that in the 
extreme case of 1000 steps per restart (and with random velocity 
reassignmet every 1000 steps), the Andersen thermostat does produce 
something akin to this artifact but not as quickly as the Langevin; it may 
also improve more rapidly over longer segments, even with the bad random 
numbers.  Time (i.e. a week) will tell.

Good to know that Gromacs4 is going to deal with this issue.

Dave

> The issue brought up by Dave can be very problematic, but only when the state 
> is heavily influenced
> by the random numbers. This will be the case for Monte Carlo and Brownian 
> dynamics simulations.
> During my PhD work, I experienced a nasty case of recurring dynamics with BD.
> With stochastic dynamics (Langevin dynamics with momenta), the velocities 
> will often contribute more
> to the state than the random numbers. But for a protein in vacuum, or with 
> implicit solvent (currently
> not implemented in Gromacs), the velocity space could possibly be so small 
> that the random state
> can have a significant influence on the results.
>
> In Gromacs 3 the random state is not stored, and even worse, with ld_seed=-1 
> grompp generates
> a random seed, but tpbconv reuses the same seed. But as I said, I think that 
> for SD is solvent
> the velocity state of the solvent will swamp the memory effect of the SD 
> random state.
>
> Just a week ago I implemented checkpoint files for Gromacs 4, including 
> storage of the complete ring state
> for BD and SD.
>
> Berk.