[gmx-users] Re: Frame/conformation in trajectory is ignored

[Mark Abraham]

On 16/07/2011 8:33 PM, Martin Kamp Jensen wrote:
> On Fri, Jul 15, 2011 at 1:41 PM, Mark Abraham <Mark.Abraham at anu.edu.au 
> <mailto:Mark.Abraham at anu.edu.au>> wrote:
>
>     On 15/07/2011 7:31 PM, Martin Kamp Jensen wrote:
>>     Hello,
>>
>>     I am trying to evaluate energy values of several conformations
>>     using a (pseudo)trajectory. Currently, I am concatenating
>>     GROMOS-96 files (.g96) and using that as a trajectory. For some
>>     reason the second conformation in a trajectory is ignored. So
>>     e.g. if I have three conformations (1.g96, 2.g96, and 3.g96),
>>     then concatenate them into 1+2+3.g96, and then use the latter
>>     file as a trajectory, the conformation of 2.g96 is ignored when
>>     using mdrun -rerun with a suitable binary run file.
>>
>>     I have created an archive [1] with files demonstrating the
>>     problem. Use the "run" script for a stepwise demonstration of the
>>     problem: The output of mdrun shows that the last frame processed
>>     is one less then expected for concatenated files. Further, it is
>>     the second frame that is missing which can be determined by
>>     looking at the energy values in the energy file generated by mdrun.
>>
>>     I have no clue what is going on here. I hope someone can provide
>>     some insights. (The same approach seems to work fine with PDB
>>     files instead of GROMOS-96 files, but there is less precision in
>>     PDB files and because of some irrelevant details it is easier for
>>     me to work with GROMOS-96 files at the moment.)
>>
>>     [1] http://dl.dropbox.com/u/2666968/GROMACS/missingframe.tar
>>
>>     Thanks,
>>     Martin.
>
>     That's a bug. Reading the .g96 file format as a trajectory uses
>     some dirty dirty non-thread-safe code, and the cleanup a few years
>     ago to make things thread-safe did that without preserving correct
>     functionality. I suggest you concatenate separate .g96 files using
>     trjcat into .trr format, and use rerun on that.
>
>
> Too bad, but thank you for explaining. Is your suggestion based on the 
> fact that the functionality is completely unreliable?

Yes. The behaviour of the code is (in principle) unpredictable, but you 
might get lucky and observe regularities, and here you did.

> I mean, if the bugs are known (e.g. 2nd frame is always ignored), it 
> would maybe be better to just work around them.

If anything, the bug will lead to skipping alternate frames. You could 
try constructing the input to have empty frames, or duplicate frames, 
and check the output very carefully to see patterns in what happens.

> (It would be a bit sad to write out 100 or 1000 g96 files and then use 
> trjcat since I will need to do that millions of times during a run of 
> my application.)

You could write .gro files if they have enough precision, or .xtc files 
(there's a C library for doing the latter on the GROMACS webpage).

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20110716/49dfc1d5/attachment.html>