VMD-L Mailing List

From: Giacomo Fiorin (giacomo.fiorin_at_gmail.com)
Date: Fri Nov 22 2019 - 11:05:51 CST

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