[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.
--
---------------------------------------------------------------------
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
---------------------------------------------------------------------
- Re: [h5md-user] fields of observable group,
Konrad Hinsen <=