[gmx-users] How to rescue trr trajectory when two or more corrupted frames exist

Christopher Neale chris.neale at mail.utoronto.ca
Sun Apr 28 00:08:57 CEST 2013

This is great advice from Mark. If you don't get around to doing analysis frequently,
then you can at least set up your run script to execute gmxcheck on all relevant files prior to each time 
you restart a run in which you load in a .cpt file and to error out if there is some corruption found.


-- original message --

AFAIK there is no magic number header. However, .trr files have frames of
constant size, so you can make a .tpr that will write a .trr file that will
include the longest period of your nst[xfv]out. Some Unix tool like dd (or
maybe hexdump) can probably tell you the size of that repeating unit. Then
you can use dd to write increasingly larger multiples of that size to get a
subset that includes all the trajectory before the *second* corruption.
Back up your files first! I suggest you write two periods to check my
assertion that the frames ought to be of constant size. Practice on a small
trajectory you don't care about.

Then you'll be in a position to judge the start point of the first complete
frame after the first corruption, which will allow you to construct a
fancier dd solution to get the remainder of the trajectory from the
post-first-corruption fragment. Then trjcat -h to learn how to stitch the
parts together.

Everybody learn: do (parts of) your analysis while your simulation is
running, not after it finishes! :-)


More information about the gromacs.org_gmx-users mailing list