[gmx-developers] Errors in tng_io reading box vectors

[Magnus Lundborg]

Hi again Peter,

I'm sorry about the problems you ran into. One of them is, as you say, a 
bug, whereas I hope the other one is not. The bug (in 
tng_util_box_shape_read()) is fixed now, in the sense that it checks the 
data type and returns TNG_FAILURE if it was not a float. I should also 
add convenience functions for reading doubles. There is currently no 
conversion between data types in these util_ functions.

There were also mistakes in the documentation, which I have now pushed 
to the master branch of TNG (availaible at git clone 
https://gerrit.gromacs.org/tng) (it will take another while before it 
trickles into the actual GROMACS master branch). The size of the 
returned array from tng_data_vector_interval_get is depending on the 
stride_length of the written data. So e.g. if you read 100 frames of 
data with a stride_length 100 the length of the returned array will only 
be 1*n_values_per_frame.

So, I hope these things are fixed with these latest changes.

However, in your case there is actually another function that could be 
convenient to use instead of the two above, i.e., 
tng_util_non_particle_data_next_frame_read(). That will read the next 
available frame of data of the requested type. A convenient way to 
handle it can be like in 
https://github.com/gromacs/gromacs/blob/master/src/gromacs/fileio/tngio_for_tools.cpp#L479-L525 
.

Please contact me if you run into further problems or have more 
questions. I'm happy that you are adding TNG support to MDTraj. I've 
been considering it myself for a long time, but have not had time to 
start looking into it.

Kind Regards,

Magnus

On 2016-06-01 09:31, Magnus Lundborg wrote:
> Hi Peter,
>
> I'll look into this and report back. Thanks for the report.
>
> Kind Regards,
>
> Magnus
>
> On 05/31/2016 07:01 PM, Peter Kenneth Eastman wrote:
>> Hi,
>>
>> I'm using the Gromacs tng_io library to add support for TNG files to 
>> MDTraj.  I've run into two different problems when trying to read the 
>> box shape.  One of them is clearly a bug. The other one I'm not sure 
>> whether it's a bug, or just a misunderstanding on my part about how 
>> it's supposed to work.
>>
>> The first problem is that tng_util_box_shape_read() returns the box 
>> shape via an argument that's declared as "float **box_shape".  But it 
>> doesn't check that the box shape is actually stored as floats, or 
>> convert it if it's something else.  You can see this at 
>> https://github.com/gromacs/gromacs/blob/master/src/external/tng_io/src/lib/tng_io.c#L15613-L15618. 
>> It calls tng_data_vector_interval_get(), but then completely ignores 
>> what value gets returned in the type argument.  So if the box shape 
>> happened to be stored in double precision, you end up with corrupt 
>> data (a float* that actually points to doubles, not floats).
>>
>> I worked around this by instead calling 
>> tng_data_vector_interval_get() directly, but now I've run into a 
>> different problem.  According to the documentation, the returned 
>> array should be of length n_frames*n_values_per_frame and contain the 
>> box shape for every frame.  But instead it only contains data for the 
>> very first frame (the first 9 doubles). All elements beyond that look 
>> like they just contain garbage (perhaps uninitialized memory).
>>
>> Thanks for any help on this.
>>
>> Peter
>