[gmx-users] Cleaning up trajectory files after crash

[Joshua Adelman]

On Aug 11, 2013, at 2:12 PM, Justin Lemkul wrote:

> 
> 
> 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
> 
> 

Hi Justin,

Thanks for your reply. Unfortunately, I was not intending to concatenate the files, especially in light of the total continuous trajectory taking up a large amount of disk space. I guess I could just use trjcat on any xtc file where there was a crash with the subsequent one in the series and use the output instead, but I'd rather just remove the frames past the checkpoint so that I can process all of the files without any special checking for this case. 

Also, I was looking at the source for gmx_trjconv.c and it looks like the truncation routine doesn't accept xtc files (although I could be wrong since I haven't spent much time looking at Gromac's internals):
https://github.com/gromacs/gromacs/blob/d67173b36b78840466e691a4a6657d2b8fdb1c84/src/gromacs/gmxana/gmx_trjconv.c#L463
This does not appear to be documented outside of looking at the source. This seems particularly confusing because trjconv does take xtc files and the error message is a little misleading since xtc is a trajectory file, but just not one of the formats that is allowed with trunc. 
Alternatively, I think I could use the `-e` flag to specify the last frame that I want corresponding to the checkpoint and write to a new file rather than truncating in-place. Does that sound reasonable?
Thanks again for your help.
Josh