Yes, I was a bit too fast with that RNG idea, but it could still be viable
if the decomposition is right and a suitable RNG is used. I've been using
ran2 in mdgx, which takes 36 integers, and as I said my decomposition
scheme is such that I would need one RNG per cell, which is about 1 per
50-100 atoms. One RNG per atom would be far too much; when the atoms
migrate between processes the RNGs would have to go with them!
Regarding reproducibility, there are still a lot of ways that trajectories
can diverge beyond the RNGs, and this has been another argument for not
worrying about them in pmemd. In mdgx, there are a couple of things that
will cause the trajectories to diverge based on non-associativity in the
arithmetic, but the ones I can identify are amenable to inexpensive
changes that would lead to reproducible results. I don't intend to do
this, but I also like to keep avenues open unless there's clear reason to
close them off.
As for including the state in the restart, I was thinking something like
NATOM Timestamp
X1 Y1 Z1 X2 Y2 Z2
X3 Y3 Z3 ...
...
Xn Yn Zn
Vx1 Vy1 Vz1 Vx2 Vy2 Vz2
Vx3 Vy3 Vz3 ...
...
Vxn Vyn Vzn
Gx Gy Gz Ga Gb Gc
%
% RNG STATE
% S1 S2 S3 S4 S5 S6
% S7 S8 ...
% ...
I'd hope that AMBER programs can tolerate reading to up through the box
dimensions and then stopping, even if there's some extra data beyond that
marked off with special characters. Even if it's a double, you can just
codify it somehow, print it in ascii format and splice it back together.
Cumbersome, but for only 100 doubles it's trivial. I just don't know
enough about how the various other programs that work with restarts do it;
it might also break non-AMBER programs, though, so maybe the ascii format
is stuck. Perhaps the best thing would be a supplementary checkpoint file
(.chk?) to contain this new data, which the program looks for but doesn't
flinch if it's unavailable.
Dave
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Oct 17 2011 - 00:30:02 PDT
