Re: [h5md-user] H5MD discussions

[Pierre de Buyl]

Hi all,

Thanks for the input, Felix, I go on in the text.

> Salut Pierre, Hallo Peter,
>
> So let me start the dicussion on this provisional "list".
>
> I have still some issues with the trajectory group of H5MD:
>
> 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 ?

> 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".
    - 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.

> 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 ?

> Please let me know what you think about these ideas.
>
> Cheers,
> Felix

The box part should be taken into account. For the rest, it depends  
on how general it is.
I also send another mail for the general setup of the project.

Pierre


> Am 16.06.2011, 20:26 Uhr, schrieb Peter Colberg  
> <address@hidden>:
>
> > Hello Felix, hello Pierre,
> >
> > by this mail, I shall officially establish contact between both of  
> > you
> > to discuss the first specification of H5MD, while the public H5MD
> > mailing list is still pending. Be sure to include me in CC:.
> >
> > Peter
>
>
> --
> 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