[gmx-developers] Getting the last frame in an xtc file

[Mark Abraham]

Ran Friedman wrote:
> Mark Abraham wrote:
>> Ran Friedman wrote:
>>> One more piece of information:
>>> I replaced xtc_get_current_frame_time of GMX 3.3.3 with that of GMX
>>> 3.3.1 and recompiled.
>>>
>>> Now xtc_get_last_frame_time does work.
>> Well that's something.
>>
>>> Ran Friedman wrote:
>>>> Dear Mark, GMX developers,
>>>>
>>>> Unfortunately this doesn't work. In any case, this part of the code
>>>> returns -1 in any case:
>>>>  }else if(ret == -1){
>>>>     if(gmx_fseek(xdrfiles[fp+1],off,SEEK_SET)) {
>>>>       return -1;
>>>>     }
>>>>     return -1;
>>>>  }
>>>>
>>>> and even if I try to move backwards 2*sizeoff(int) at a time  it
>>>> doesn't
>>>> get me anywhere.
>> What value does ret have?
> -1
> Ran.

Well ret==-1 means that there was an I/O failure in xtc_at_header_start. 
   ret==0 means failure to recognise a valid frame header, and should 
trigger the backward scan.

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

     if(gmx_fseek(xdrfiles[fp+1],-3*sizeof(int),SEEK_END)){

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. My earlier suggestion for line 1328 was wrong, so leave 
it unchanged.

Mark