VMD-L Mailing List

From: Anthony Ruth (Anthony.J.Ruth.12_at_nd.edu)
Date: Mon Nov 25 2019 - 08:19:44 CST

Thank you for the suggestion. I will try out the .xtc format. Between being
fixed precision and binary encoded there should be a substantial reduction
in file size.

regards,
Anthony Ruth
Condensed Matter Theory
University of Notre Dame

On Fri, Nov 22, 2019 at 11:06 AM Giacomo Fiorin <giacomo.fiorin_at_gmail.com>
wrote:

> This is a very interesting question, and I just saw Axel's reply while
> typing my own :-)
>
> Rather than repeating I would only add this: VMD has a reader for XTC, but
> not a writer, for which you will need GROMACS. You could just install the
> GROMACS build distributed by the package manager (if on Linux), since you
> won't need an optimized or double-precision build. Sadly, GROMACS does not
> read .xyz files natively (to my knowledge).
>
> As intermediate step you could probably use catdcd to convert from .xyz to
> the ".trr" uncompressed GROMACS format, and use gmx trjconv or trjcat to
> generate the compressed .xtc file. Unlike VMD, catdcd will not need to
> load the whole trajectory in memory before beginning to write. (See Axel's
> comment about memory usage in VMD).
>
> Giacomo
>
> On Fri, Nov 22, 2019 at 11:54 AM Axel Kohlmeyer <akohlmey_at_gmail.com>
> wrote:
>
>>
>>
>> On Fri, Nov 22, 2019 at 10:34 AM Anthony Ruth <Anthony.J.Ruth.12_at_nd.edu>
>> wrote:
>>
>>>
>>> The biggest waste in my current setup is that few atoms move each frame
>>> but all of the atoms are repeated in the file for every frame. For example,
>>> the first frame is given by an .xyz file. The next frame has only the
>>> changes relative to the first frame, e.g. atom1 moved to (5,3,0)
>>> atom5 moved to (4,4,0). Is there a filetype or a combination of
>>> filetypes that VMD could interpret this kind of information from and would
>>> obtain the same set of frames as printing a full structure for each frame?
>>>
>>
>> I am not aware of a file format currently that supports this kind of
>> setup (but I don't know all of them well enough; as you noticed there are
>> just too many of them), but it should be possible to implement a custom
>> file type reader, that would be based on an existing file type and then
>> keeps a copy of the coordinates around and updates them with the delta
>> information you have. please note, that this file will still expand to
>> having the coordinates for every atom at every step stored in RAM, as that
>> is a requirement of how VMD stores information. When writing a custom file
>> format, you could also make it compress text with gzip, bzip2 or similar
>> and then decompress on-the-fly when reading those files. that might provide
>> additional storage savings while maintaining a simple file format
>> underneath.
>>
>> The other option I as looking at is a simple binary encoded format. Do
>>> you have a recommendation on a commonly used binary format?
>>>
>>
>> An option to perhaps look into would be the .xtc format, that gromacs
>> supports. This is a fixed precision (not floating point) binary format,
>> that can compress data by storing only the delta of the coordinates between
>> frames. That may help reducing size without writing a "deltaxyz" kind of
>> custom file reader.
>>
>> axel.
>>
>>
>>
>>>
>>> regards,
>>> Anthony Ruth
>>> Condensed Matter Theory
>>> University of Notre Damee
>>>
>>
>>
>> --
>> Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0
>> College of Science & Technology, Temple University, Philadelphia PA, USA
>> International Centre for Theoretical Physics, Trieste. Italy.
>>
>
>
> --
> Giacomo Fiorin
> Associate Professor of Research, Temple University, Philadelphia, PA
> Research collaborator, National Institutes of Health, Bethesda, MD
> http://goo.gl/Q3TBQU
> https://github.com/giacomofiorin
>