[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [h5md-user] fields of observable group

From: Felix Höfling
Subject: Re: [h5md-user] fields of observable group
Date: Fri, 02 Sep 2011 14:07:51 +0200
User-agent: Opera Mail/11.50 (Linux)

Am 01.09.2011, 20:12 Uhr, schrieb Konrad Hinsen

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.


Dear Konrad,

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]