[Top][All Lists]

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

Re: [h5md-user] fields of observable group

From: Konrad Hinsen
Subject: Re: [h5md-user] fields of observable group
Date: Thu, 1 Sep 2011 20:12:15 +0200

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 Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expériences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mail: research AT khinsen DOT fastmail DOT net

reply via email to

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