[gmx-users] Possible trjconv malfunction?

[Justin Lemkul]

On 6/26/14, 10:02 AM, Nathan Scott wrote:
> Hi all,
>
> I am trying to use trjconv to extract .g96 files iteratively, then use my
> own software for analysis, then delete the .g96 file, but I am running into
> perplexing behavior. I did a bit of searching in the list archive but can
> find no mention of this, so it could well be I am just doing something
> wrong.
>
> I have a continuation (the original simulation was run for 20 ns) of a
> simulation that was run for 50,000 steps, dt=0.002 ps, with the xtc file
> written every 1000 steps (2 ps). When I issue the following command
> everything works fine and I get a .g96 file ad the header shows a time of
> 20000.
>
> echo 0|trjconv_mpi -f stn_wt_a_fit_1.xtc -s stn_wt_a_1.tpr -b 20000 -e
> 20000 -o g96/stn_wt_a_1_0.g96 -novel
>
> But when I try to extract the next file, which should be 2 ps later in the
> simulation by using this command, I get an error:
>
> echo 0|trjconv_mpi -f stn_wt_a_fit_1.xtc -s stn_wt_a_1.tpr -b 20002 -e
> 20000 -o g96/stn_wt_a_1_0.g96 -novel
>
> WARNING no output, last frame read at t=20004
>
> When I run with -b and -e set to 20004 I get a .g96 file with a time of
> 20004. I tried 20001, 20002, and 20003 just to see what happens, and I get
> the same error referencing 20004 as the "last frame read."
>
> trjconv seems to think that there are 4 ps between frames. Just to check
> myself, I did a gmxdump of the .xtc file and the .edr file, and they both
> show a frame at 20002 ps and a final frame of the trajectory at 20100,
> exactly as I expected, .Also, when I use trjconv -sep to output all of the
> individual frames of the trajectory in one shot, I get 51 files with
> correct timings in the headers, 20000, 20002, 20004, etc up to 20100.
>
> If anyone could shed light on this problem I would very much appreciate it.
> This is Gromacs 4.6.5, by the way, being run on Trestles at the SDSC
> through an XSEDE account. I am running into problems trying to extract all
> of the structure files at once to the per-node scratch space so I thought
> I'd give iterative extraction a try, since my analysis code runs in serial
> anyway.
>

Your trjconv command is simply wrong.  You've specified -b 20002 -e 20000, so 
you're telling trjconv to start at a time that is after it has ended, so it 
chokes on the next frame (20004) because it can't satisfy the conditions you've 
set.  Using -b 20000 -e 20002 should be fine.  Note that -dump is much more 
efficient and circumvents similar problems.

-Justin

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

Justin A. Lemkul, Ph.D.
Ruth L. Kirschstein NRSA 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
http://mackerell.umaryland.edu/~jalemkul

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