Minor issues with libxdrf
I was unsuccessful in using xtc_get_last_frame_time and xtc_get_last_frame_number from libxdrf.c on different XTC files (GMX version 3.3.3). This is a minor bug - these two functions are not used in GMX per se, but they affect the writing of external programs that deal with the trajectories.
After digging into it (see the discussion in the developers forum)1 Mark Abraham found the following solution:
A closer inspection of xtc_at_header_start reveals that it tries to read three ints before testing the first for being the magic number. So the "-4" in line 1666 is wrong logically (since the second scan for an int will give I/O failure), as well as for hard-coding the number. I think line 1666 should read
Line 1634 should have the same modification too.
xtc_get_current_frame_time and xtc_get_current_frame_number should have the same algorithm with different return variables, but they don't. The latter doesn't test for the case ret==0, and to remedy this, needs the four-line fragment at line 1294 added to it, with 2*sizeof(int) replacing the 8.
I tested it and this seems to work, without harming xtc_seek_time, so I guggest to apply these fixes.
I guess that 2*sizeof(int) should replace the 8 in line 1294 as well.
#1 Updated by Erik Lindahl over 11 years ago
Fixed, I think it least :-)
However, we should never use sizeof(int) for XDR files when moving file pointers, since the XDR standard specifies that XDR_INT is always 4 bytes. I've added a define for that to make it clearer.
(brr... this code is quite ugly, but it's a hack since we didn't think of random access for xtc originally)