[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [h5md-user] H5MD discussions
Pierre de Buyl
Re: [h5md-user] H5MD discussions
Tue, 30 Aug 2011 20:59:51 -0000
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.)
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
- 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.
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.
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))
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.
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.
Am 16.06.2011, 20:26 Uhr, schrieb Peter Colberg
Hello Felix, hello Pierre,
by this mail, I shall officially establish contact between both of
to discuss the first specification of H5MD, while the public H5MD
mailing list is still pending. Be sure to include me in CC:.
Dr. Felix Höfling
Max Planck Institute for Intelligent Systems
(formerly Max Planck Institute for Metals Research)
Phone: +49 711 689 1938
Fax: +49 711 689 1922