Re: [h5md-user] H5MD discussions

[Felix Höfling]

Hi Pierre,

Am 17.06.2011, 17:39 Uhr, schrieb Pierre de Buyl <address@hidden>:

> > 1) Rigid particles (like true colloids, not composed of many particles)  
> > have additional degrees of freedom. I suggest to optionally extend the  
> > trajectory group by groups "orientation" (a unit vector,  or angles?  
> > The vector appears less ambiguous than definitions of Euler angles) and  
> > "angular_velocity" (this is an axial vector, so actually a traceless,  
> > symmetric tensor of rank 2, but can be stored as a vector).
> Are you thinking of internal coordinates here ?
> Is there an obvious coordinate system for these ?
No, I mean rigid bodies in the sense of classical mechanics. The particles  
are specified by their position and orientation in space. This is already  
necessary for spherical colloidal particles suspended in a fluid, but it  
might be clearer to think of ellipsoidal or more general particles  
(without internal degrees of freedom). This issue is not very urgent,  
since the file format may be extended at will. Common extensions, however,  
should be specified and unified in an upcoming version of the  
specification.

> > 2) In NTP simulations, for example, the volume of the simulation box  
> > fluctuates. This shall be supported by a generic MD file format. (I'm  
> > not sure whether and how periodic boundaries are applied in this case,  
> > maybe they are not used in all directions.)
> >
> > My suggestion is a separate data group "box" in trajectory along with  
> > its own timestamp, which may contain a single entry only if the box  
> > remains fixed. The relevant value of box at a given point in time is  
> > determined from the latest stored value before or at that point in time.
> Indeed, in any case for NPT simulations the box size as a function of  
> time is of interest.
> Then, how should it be stored. A desirable idea is that the parsing of  
> the file remains simple in the two situations. As I see it, the  
> solutions are:
>      - A full time-dependent time-series, similar to an observable, with  
> step, time and data. In any case, any temporal information should be "at  
> the time given by step/time".
For a fixed box, writing always the same numbers would flood the output  
files unnecessarily. Even if this would be compressed heavily, it adds  
load to the HDF5 library. I would avoid that.

If the velocity and position  data are written at different intervals,  
there shall be a box information at each of these tics. (Is the box size  
relevant for the velocities?) Addressing the matching box data will always  
require searching for the matching simulation step, which is a bit  
unpleasent for the user scripts (for analysis) - but it appears to be  
unavoidable.

>      - An option is to specify the fixed box size as an attribute and  
> fall back on the dataset if absent. Else, the problem is that the "box"  
> group has a weird structure.
"weird structure" means a different time grid than in the position and  
velocity groups? Choosing between an attribute with fixed box and a full  
dataset could be a good solution. Then a user script might choose not to  
support the more complicated data set version (while not fully supporting  
the H5MD standard.)

> > 3) Specification of a box with non-orthogonal edges requires more than  
> > giving just two corners, it also requires some information about the  
> > angles. To me, it appears more direct if the edge vectors of the box  
> > would be stored for this general case. This would imply two datasets:  
> > "offset" and "edges", where the latter is a d×d matrix with the edge  
> > vectors as rows. For a cuboid box of lengths L_x, L_y, L_z centered  
> > around the origin, one would have:
> >
> > offset (-L_x/2, -L_y/2, -L_z/2)
> > edges ((L_x, 0, 0), (0, L_y, 0), (0, 0, L_z))
> > time (0)
> > step (0)
> >
> > This suggestion contains some redundancy (e.g., the zeros), but appears  
> > the most general and manageable to me.
> This is nice.
> How is it redundant ?
I thought one could save some numbers by specifying relative angles  
between the edges. But this is cumbersome, and maybe it requires the same  
amount of data.

Felix


--
Dr. Felix Höfling
Max Planck Institute for Intelligent Systems
(formerly Max Planck Institute for Metals Research)
Heisenbergstr. 3
70569 Stuttgart
Germany

Phone:  +49 711 689 1938
Fax:    +49 711 689 1922