On 16/07/2011 8:33 PM, Martin Kamp Jensen wrote:
On Fri, Jul 15, 2011 at 1:41 PM, Mark Abraham <[email protected] <mailto:[email protected]>> 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
-- gmx-users mailing list [email protected] http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/Search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [email protected]. Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
