[gmx-developers] Writing TNG with libtng_io

Magnus Lundborg magnus.lundborg at scilifelab.se
Tue Aug 1 11:05:52 CEST 2017


Dear Jonathan,

Sorry about the delay, but I've started looking into this now. Regarding 
1 it is probably that zlib was not found when compiling TNG and was thus 
disabled. Later versions (GROMACS master or TNG library 1.8) compile 
zlib if it was not found. Earlier versions should have had a fallback 
when zlib is not available, but with later versions I hope it should 
just work.

2. Frame sets assume that the time between frames are constant within 
the frame set. So, I'm afraid that your solution with one frame per 
frame set is the only solution right now. It could be worth looking into 
how this can be improved and I'm happy to hear suggestions.

Using picoseconds as time unit was an early mistake and using seconds in 
the utility functions was a way to try to hide that from most users. 
However, it probably made it worse this way since it's not consistent. 
It would have been better to stick to seconds everywhere. However, I'm 
reluctant to change the API at this moment. That could be discussed for 
a later major version, but it could cause problems.

Cheers,

Magnus

On 2017-07-08 17:18, Jonathan Barnoud wrote:
> Dear all,
>
> With other developers of MDAnalysis, we are working on a python 
> wrapper for the TNG library. While it is aimed at being used in 
> MDAnalysis, this wrapper is written to be used standalone. More 
> details can be found at <http://www.mdanalysis.org/pytng/>.
>
> I am working on the writing of a basic TNG file. I want to be able to 
> write particle positions  and a box shape for each frame. Each frame 
> can have an arbitrary time attached to it. I did manage to do this in 
> this pull request: <https://github.com/MDAnalysis/pytng/pull/18>, and 
> in this minimal example jupyter notebook: 
> <https://gist.github.com/jbarnoud/b8f750f116b76aba1b205babc001b569>. 
> Both cases are written in cython rather than C, but they call the same 
> functions from the tng_io library that a C program would.
>
> There are a few things I am not completely sure about, though.
>
> 1. When I write the box shape with `tng_util_box_shape_write` or 
> `tng_util_box_shape_with_time_write`, I do not manage to read it back 
> with gromacs. Both 'gmx check' and 'gmx dump' fail to read the box 
> with the following message:
>
>     TNG library: Cannot uncompress data block. 
> /home/jon/src/gromacs-2016.3/src/external/tng_io/src/lib/tng_io.c:5298
>
> I did solve the problem by using `tng_util_generic_write` (or its 
> `with_time` equivalent) and by setting the compression to 
> `TNG_UNCOMPRESSED`.
>
> Does gromacs support the TNG_GZIP_COMPRESSION that is the default for 
> the high level `tng_util_box_shape_write` function? If so, what should 
> I do to have it working?
>
> 2. I write an arbitrary time with each frame. The time is arbitrary in 
> the sense that I do not know before hand what is the time that the 
> user of the library will provide for the frame, and that the time 
> difference between two consecutive frames do not have to be constant 
> (nor even positive). I managed this by setting the number of frames 
> per frame set to 1, and to set the time per frame to 0.
>
> Is it possible to have the arbitrary time with more than one frame per 
> frame set? I did get some results by setting the time per frame for 
> each frame using the time difference with the previous frame, but I 
> got some strange behaviors when the difference was 0; and 
> `tng_time_per_frame_set` refuses negative values.
>
> Also, I noticed that all the `tng_util_*_with_time_write` functions 
> expect the time to be expressed in seconds, while 
> `tng_time_per_frame_set` expects picoseconds. Is there a reason for 
> this discrepancy?
>
> Thank you for any insight you may provide,
> Jonathan Barnoud
> ||
> |
> |
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20170801/5beb917d/attachment.html>


More information about the gromacs.org_gmx-developers mailing list