[gmx-users] -t and -shuffle problem in grompp

[Eric Carpenter]

Was:  "Problems with PBC and constraints while doing parallel runs"  and
      "Re: gmx-users Digest, Vol 19, Issue 26"

I hope my further change of the thread title does not cause more problems,
but the problem seems to be passing -t and -shuffle to grompp together.  
I had a problem with this in the past and concluded the trajectory had to
have been from a run shuffled for the same number of nodes (and not a
deshuffled version either).  I don't know if this correct; I'm loath
to trust that this is safe.  I simply don't use the two options together.

As David van der Spoel has pointed grompp shuffles the topology and then
reads the coordinates from the trajectory.  You can verify this by looking
at the stderr messages from grompp, the shuffling occurs before the
trajectory read.  I've always found this a bit annoying when continuing
runs on different numbers of processors and wanting to reshuffle.  
Personally, I think grompp should produce an error/warning when both
options are given, and a note in the documentation would be nice.  
(Perhaps there is, but I missed it.)  There is some mention of using 3.2.1
as a workaround, but I believe this version has the same problems.

The consequences of this mistake/bug are sometimes quite subtle, In mdrun
I've seen runs that crashed almost immediately, warnings of inconsistent
shifts (check all logs), and "Initial temperature: 1238.73 K" instead of
310.119 K. I may have seen one error in grompp caused by this, but I think
it usually shows in the run.

On Mon, 2005-11-07 at 20:48 +0100, David wrote:
> > coordinates. Try it without shuffle first. If that work make an inverse
> > deshuf.ndx file from the original deshuf.ndx and apply that to your
> > original trr (last frame only will suffice):
> > trjconv -f popc-serial.trr -b XXX -n reshuf.ndx -o reshuffled.trr

I don't know how to produce the inverse file you describe.  Could you
explain how?  I'm sure I'm being stupid, but haven't found any
documentation for doing this.

My solution is something like:
trjconv -f traj.trr -s topol.tpr -b 15000 -e 15000 -n deshuf.ndx -vel -ndec 8 -o conf.gro

The idea is to create a high precision input from grompp and then avoid
passing the trajectory.  I think the -ndec 8 should create a .gro file as
accurate as the single-precision *.trr file and the times for -b and -e
are for the frame grompp would have used.

Because of this multiple shuffling, I believe that if grompp were to be 
changed to accept both options at once, it should also accept an input 
deshuf.ndx so that it could read a shuffled trajectory from a prior run.

					Eric Carpenter