[gmx-users] content of trr / xtc files + -b/-e flag question + tpr question

[Mark Abraham]

On Sun, Dec 14, 2014 at 7:08 AM, Eric Smoll <ericsmoll at gmail.com> wrote:
>
> Hello Gromacs users.
>
> I have a few questions.
>
> I ran two small trajectories:
>
> trajectory 1:
> dt = 0.0008
> nsteps=10
> nstxout=2
> nstxtcout=3
>
> trajectory 2:
> dt = 0.0008
> nsteps=10
> nstxout=3
> nstxtcout=2
>
> We can examine the content of each trajectory using "trajconv -sep -nzeros
> 1". The initial frame is always the initial coordinates.
>
> In trajectory 1, the trr file contains frames at times
> 0.    ,  0.0016,  0.0032,  0.0048,  0.0064,  0.008
> and the xtc file contains frames at times
> 0.    ,  0.0024,  0.0048,  0.0072
>
> In trajectory 2, the trr file contains frames at times
> 0.    ,  0.0024,  0.0048,  0.0072
> and the xtc file contains frames at times
> 0.    ,  0.0016,  0.0032,  0.0048,  0.0064,  0.008
>
> In section 7.3.8 of the manual, under "nstxout" it reads: "*frequency to
> write coordinates to output trajectory file, the last coordinates are
> always written." **My tests seem to suggest that the last frame of the
> simulation is not always written. Am I reading this incorrectly?


Those docs are probably left over from the pre-checkpointing era (pre 4.0,
IIRC). Back then, you'd have to do a restart from the trajectory+energy
file, so the last frame got written always. Since those days, the last
frame will get written (to the checkpoint file) if mdrun gets a chance to
do an orderly shutdown. We should fix those docs.


> Is the
> final frame always written to the mdrun -c flag as a .gro file? If this was
> the intended meaning it is a bit misleading.*
>

mdrun -c writes a .gro file in response to mdrun -confout/-noconfout. This
behaviour is not intended to relate to the above.

*Many GROMACS tools make use of -b/-e flags. What is the precise rule these
> flags apply?* For instance, how would -b  0.0020 -e 0.0068 filter the
> results above? What about -b  0.0021 -e 0.0067?
>

The look at the time stamp on the input frame, compare it, and act
accordingly. The comparison is done using floating-point representations,
so if you really want to ensure a first frame whose time is 0.0016 is
included, using -b 0.00159 is advisable. Sometimes this won't matter. Your
suggested ranges will extract the frames 0.0032, 0.0048, 0.0064 or 0.0024,
0.0048 respectively on input and flag combination. I would have thought
this part was pretty clear already... :-) was there something unclear?

Many GROMACS tools make use of a run input file when processing coordinate
> or trajectory files. The run input file contains an initial coordinate set
> and mdrun uses the initial coordinates to start a simulation. However, *it
> is not clear to me what other tools make use of these "tpr" initial
> coordinates.


That depends on the tool. Some tools use the .tpr (or other input file)
simply to get atom names or connectivity. Other tools use that frame as
some kind of reference comparison state (e.g. gmx rms). But it would not be
logical to assume the .tpr file was somehow an extra starting frame...


> If I am manipulating coordinate and trajectory files, when is
> it necessary to update the initial coordinates in a "tpr" file?*
>

... so generally no; the coordinates in the .tpr need to make sense only
for the operation that the tool implements. You ca

Mark


>
> Best,
> Eric
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-request at gromacs.org.
>