[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [h5md-user] fields of observable group
Re: [h5md-user] fields of observable group
Fri, 02 Sep 2011 14:07:51 +0200
Opera Mail/11.50 (Linux)
Am 01.09.2011, 20:12 Uhr, schrieb Konrad Hinsen
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
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
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
I wonder if the offset is really useful. I have never needed one so far.
Welcome on this list and thank you for your valuable comments.
It think storing the box size as a time-dependent quantity in the
/parameters group would be useful, I will make a suggestion in the other
thread "parameters group" which I've opened the day before yesterday.
Further, I agree that the top-level structure should not get cluttered by
program-specific groups. So moving such information in a subgroup of
/parameters makes sense to me.
How should the edges/offset scheme be extended to account for such things
as a truncated octahedral?
The offset can be useful if, e. g., different simulation snapshots shall
be glued together (for creating layered structures of pre-equilibrated
phases). And it is necessary for the complete description of an
arbitrarily positioned box in space. Of course, it is redundant for
particle positions reduced to the periodic box.