[gmx-developers] From .tpr to .gro+.top+.mdp

[Mark Abraham]

Nayden Markatchev wrote:
> Hello,
> 
> My group started experimenting with the idea of mutable and migratable
> jobs across clusters and gromacs is the first application we tried.
> Moving the job is made easy because of the portable format of the .tpr
> file, but we run into a problem when we want to reconfigure a job.  I
> did a bit of searching around, but I couldn't find information on how
> to do that, so I resorted in posting in the gromacs-users mailing
> list.  My question was, provided I have a .tpr file, and I lack .gro,
> .top, and .mdp files, is is possible to reconfigure that file to be
> run on a different number of nodes that it was originally configured
> for.  I was told that the this is not possible but I wonder why this
> is the case.  Because of the nature of my second question, I thought
> that this mailing list is the more appropriate place for it.

The reason will include the decomposition of the grid search algorithm 
to multiple processors (see section 3.4.2 in manual) and presumably more 
(and uglier!) such stuff if PME is being used.

Regenerating an equivalent .mdp file is fairly straightforward, since 
the input record is in the .tpr file (see gmxdump output). You don't 
want to regenerate just a .gro file because you will lose precision. You 
want to regenerate a .trr and .edr file for the data, and a .gro file 
just for atom names. This is fiddly but doable. Regenerating an 
equivalent .top file would be possible, but far too much work to be 
worth doing for the gain cases of 1) rescuing a user who deleted their 
own topology and 2) trying to do a transparent migration of cpu size.

If you want mutability, write a wrapper job submission script that takes 
the original {trr,edr,gro,top,mdp} grompp input set as its input and 
decides at runtime how many cpus to use and generate the .tpr file then.

Mark