[gmx-users] Cleaning up trajectory files after crash

[Justin Lemkul]

On 8/11/13 9:16 AM, Joshua Adelman wrote:
> I recently had a simulation crash where my .trr and .xtc files extend beyond
> the last checkpoint time (I'm using 4.6.3). Explicitly something like
> run_002.trr was written after state.cpt. I was wondering if there was a
> recommended protocol for truncating run_002.trr such that when I restart
> from the checkpoint, starting the next trajectory file in the series,
> run_003.trr will be continuous with the previous one? This is important in
> terms of going back and treating the series of trajectory files as
> continuous for analysis purposes.
>
> My preliminary thought is to get the timestamp, T,  of the state.cpt file
> using gmxcheck, and then do `trjconv -f run_002.trr -trunc T`. This seems to
> work (although I need to check if the coordinates in the truncated file
> match with the state.cpt file). When I try the same thing with my .xtc file,
> I get an error message:
>
> Fatal error:
> run_002.xtc is not a trajectory file, exiting
>
> This seems strange since running gmxcheck on the xtc file doesn't report any
> issues.
>
> Any suggestions on the proper way to clean up the files or the error message
> would be appreciated.
>

There is no need to truncate anything.  If you're concatenating later with 
trjcat, they will be stitched together properly with frames from the second 
trajectory overwriting the frames in the first (i.e. the stretch in run_002.trr 
that is "past" the checkpoint will be re-calculated in run_003.trr and 
incorporated seamlessly).  The trjcat documentation alludes to this behavior.

-Justin

-- 
==================================================

Justin A. Lemkul, Ph.D.
Postdoctoral Fellow

Department of Pharmaceutical Sciences
School of Pharmacy
Health Sciences Facility II, Room 601
University of Maryland, Baltimore
20 Penn St.
Baltimore, MD 21201

jalemkul at outerbanks.umaryland.edu | (410) 706-7441

==================================================