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

Yang Ye leafyoung81-group at yahoo.com
Thu Nov 17 04:44:39 CET 2005

Hi, eric

Not clear about your exact situation. My experience with shuffle was 
also painful but has been smooth once I have been clear about the 
concept behind.

I met such situations before that a shuffled simulation was crashed that 
I have to continue it; or changing number of nodes by creating new tpr file.

For both situations, I never make the second shuffle. But to supply a 
shuffled topology to grompp. Here is my awk script to convert the output 
of grompp (you need to use grompp ...2>pp.log to save it.) to a table, 
which I can insert in the [ molecules ] section of topology.


  if ($1=="Moltype") {
     for (i=0;i<NF-2;i++) {
        moltype[i] = $(i+2)
     if (begin==1) {
        if($1=="CPU") {
           for (i=0;i<molnum;i++) {
              if ($(3+i)==0) continue
              printf("%s\t%d\n", moltype[i], $(3+i))

Yang Ye

Eric Carpenter wrote:

>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
>gmx-users mailing list
>gmx-users at gromacs.org
>Please don't post (un)subscribe requests to the list. Use the 
>www interface or send it to gmx-users-request at gromacs.org.

Yang Ye
/Computational Biology Lab
School of Biological Sciences
Nanyang Technological University
Tel: 6316-2884

More information about the gromacs.org_gmx-users mailing list