[gmx-users] micelle disaggregated in serial, but not parallel, runs using sd integrator

Chris Neale chris.neale at utoronto.ca
Thu Feb 5 01:30:47 CET 2009

It appears as if you were correct Berk. I will report on the results of my 24h test tomorrow, but I also set up another system 
that used ld_seed=1993 and ran in 20 ps segments instead of the 200 ps segments that I was previously using. This system shows 
signs of disaggregation on the 200 ps time-scale as opposed to the 2 ns time-scale that I observed for 200 ps segments.

I don't know how you figured that one out, but I am very grateful.

Now that I see the trajectories, it does make sense that any net movement applied to an individual molecule by the noise will 
lead to directed movement over many separate segments.

I think this is probably worth a note in the grompp output for sd runs when a user sets ld_seed to something other than -1 and 
utilizes the -t option (or some other indication that this is intended as a continuation).


-- original message --
Thank you Berk,

I will repeat my runs using the checkpoint file and report my findings back to this list. Thank you for this advice.


-- original message --


In this manner you use the same random seed and thus noise for all parts.
In most cases this will not lead to serious artifacts with SD,
but you can never be sure.
When checkpoints are used, you do not repeat random numbers.
This also gives a difference between serial and parallel in 4.0.
With serial you get exactly the same noise per atom, in parallel not,
since atoms migrate from one node to another (with domain decompostion).

If you do not use checkpoints, use ld_seed=-1 and do not use tpbconv.


More information about the gromacs.org_gmx-users mailing list