Hi everyone,
a few comments on the first messages I have been reading...
On 30 Aug, 2011, at 16:39 , Peter Colberg wrote:
Good thing you mention the parameters group:
I propose to drop this common name, and let a program use its
program name instead (e.g. “halmd”). A common name such as
“parameters” suggests that the group's structure is somewhat
standardized, which is not the case. More importantly, this avoids
the confusion of trying to resume with *parameters* written by a
different, incompatible program.
I'd use a common name such as "parameters", with an attribute specifying
the program that created the file, and program-specific subgroups for
program-specific parameters. There are bound to be common parameters,
which should be recognizable as such. Having just a program name as a
group name provides no hint to human readers about the contents of the
group, in particular for readers not aware of the existence of a
specific program.
On 30 Aug, 2011, at 17:34 , Felix Höfling wrote:
I have one objection: it might be of advantage to have some parameters
standardised, e.g., the box size. Otherwise, an H5MD reader could not
retrieve the box size from an H5MD file without the trajectory group.
(And the box volume is certainly an interesting quantity independent of
the trajectory.)
How do you plan to handle variable box sizes, as used in
constant-pressure simulations? Box parameters should in general be
time-dependent, like particle positions. Of course one would want a
compact version for constant box size, a very common special case.
On 17 Jun, 2011, at 10:33 , Felix Höfling wrote:
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).
In my experience, the most convenient numerical representation of
orientation is a normalized quaternion, i.e. four numbers. Quaternions
have none of the singularity problems that plague Euler angles.
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.)
They are. You just apply the usual rules using the box parameters for
the given time step.
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:
Right. There is one popular box shape that doesn't fit this scheme, the
truncated octahedral. It also has a box described as above, but has two
copies of each atoms in the unit cell, related by a translation along
the diagonal.
I wonder if the offset is really useful. I have never needed one so far.
Konrad.