h5md-user
[Top][All Lists]
Advanced

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

Re: [h5md-user] tentative of synthesis: parameters, box size, particle n


From: Felix Höfling
Subject: Re: [h5md-user] tentative of synthesis: parameters, box size, particle number
Date: Fri, 07 Oct 2011 10:02:33 +0200
User-agent: Opera Mail/11.51 (Linux)

Am 06.10.2011, 11:13 Uhr, schrieb Pierre de Buyl
<address@hidden>:

Le 5 oct. 2011 à 10:16, Felix Höfling a écrit :
Am 04.10.2011, 22:10 Uhr, schrieb Pierre de Buyl
Does anyone see a limitation to use the scheme proposed by Felix ?
box
 \-- offset
(...)
The more elaborate scheme seems overkill.
We could think of setting an attribute to the "box" group that would indicate the type of box information.
box
 +-- kind = [ cubic | triclinic ]
 +-- time_dependent = [ 0 | 1 ]

Then, future revision could easily adapt it by adding box types.

I think the above scheme naturally includes triclinic boxes. What is then
the benefit of the attribute "kind"? If it is set to "cubic", one could
use scalars instead of matrices for the edge value. But such an approach
could easily result in an endless distinction of cases for H5MD readers.
On the other hand, knowing that the box is cuboid/orthorhombic would
simplify the computation of, e.g., the box volume. (In the present scheme, one needs to compute the determinant of the edges matrix—which is not hard
if an algorithm like numpy.linalg.det is available.)

If we find it really necessary to provide additional meta information as
box kind or time dependence, I would prefer a Boolean scheme that allows
to combines these features independently (time_dependence: true/false,
orthogonal: true/false, internal_symmetries: true/false). But I think that
all the information can be retrieved as well from the dataset extents
(time_dependence), their contents (orthogonality), or presence of
attributes (transformation, see below).

As discussed earlier ("fields of observable group", 06/09/2011), the box
shall allow for internal symmetries. The suggestion was to implement them
as an optional set of isometric transformations ξ' = A ξ + b with a
transformation matrix A and a shift vector b. The transformation acts on
fractional coordinates ξ. If the matrix of edge vectors is denoted by M,
dimensionful coordinates should be obtained as x = M ξ (or with the
transposed of M? what about the non-orthogonal case?). Then, the
transformation becomes something like
x' = M ξ' = M A M⁻¹ x + M b.
Thus, the transformation of fractional coordinates is easily transformed
in one for dimensionful coordinates.

parameters
    \-- box
         +-- [transformation]  [#copies][d][d]
         +-- [shift]  [#copies][d]
         \-- edges
| \-- value [var][d][d] e.g., ((L_x, 0, 0), (0, L_y, 0), (0, 0, L_z))
         |    \-- time [var]
         |    \-- step [var]
         \-- offset
              \-- value [var][d] e.g., (-L_x/2, -L_y/2, -L_z/2)
              \-- time [var]
              \-- step [var]

Shall we put this in the draft? Since this generic box description might
appear a bit complicated for people used to cubic boxes, we should give a
detailed guide how to use the scheme (e.g., transformations and volume
computations).

Ok, I realized only recently (this week) that the set of symmetry
transformations is not to be applied to the coordinates but that
it is used to specify that one can take replicas of the box.

I fear that including it right now would be premature. Is there
experience by anyone of using that kind of box information? It
seems to be a very powerful feature that many would appreciate
but it is my opinion that we should consider it for a later
release, after feedback from users. Placing it in
the "discussion" section makes much more sense to me.

Pierre

If I remember correctly, Konrad asked to cover more complex box cells like
a truncated octahedral, which he uses in protein simulations. This started
the whole discussion on symmetry transformations, and I think the outcome
of the discussion should become an optional feature in H5MD.

Anyway before a first final release, I suggest a testing phase of the H5MD
specifications which covers various use cases  including all optional
features.

Felix



reply via email to

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