[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [h5md-user] tentative of synthesis: parameters, box size, particle n
From: |
Pierre de Buyl |
Subject: |
Re: [h5md-user] tentative of synthesis: parameters, box size, particle number |
Date: |
Thu, 6 Oct 2011 11:13:27 +0200 |
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