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

[Peter Colberg]

Dear all,

After catching up with 20(!) mails on box geometry and symmetry
transformations for periodic images, I am ready to comment. But
before that, a belated welcome to the discussion group, Konrad!


On Wed, Oct 12, 2011 at 03:31:52PM +0200, Konrad Hinsen wrote:
> On 5 Oct, 2011, at 10:16 , Felix Höfling wrote:
> 
> > 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.)
> 
> For me the important difference between a cubic and a triclinic box
> is that a cubic box is guaranteed to be cubic at all times, whereas
> a general triclinic box may happen to be cubic at some instant and
> then change. That's why it is not sufficient to say "store the
> general lattice vectors for a triclinic box, and let the reader
> check the geometry to see if it is cubic". The reader would have to
> do that check for all time steps. So yes, I consider it important to
> store information about "cubicity" somehow, even if the box size and
> shape is then always stored fully (three lattice vectors).

I agree that it is impractical to store lattice vectors and demand
from a reader to detect a cubic box by checking for zero components,
especially if the box size fluctuates.

However, following the principle of modularity suggested by Konrad,
why don't we let the (box) data speak for itself and choose different
dataset names to express different geometry groups?

For the different box types discussed so far, that would be:

 * “lengths” dataset containing scalar lengths of box edges, for a cuboid box

 * “edges” dataset for a triclinic box

 * “transformation”, “shift”, … datasets for more complex space groups


> It would be perfectly fine with me to leave stuff like symmetry
> transforms out of the first release, but make sure that programs who
> need it can put it somewhere in a safe way. Successful extensions
> can then after a while be adopted as standard.

The lengthy discussion between you and Felix deserves to be included
in some form in the first H5MD version ;-). However, if none of you
require non-triclinic (meaning more complex than tricilinic) box
geometries right now, we might as well postpone that feature.


Would Felix' proposal [1] fulfill everyone's needs so far?

[1] <address@hidden>


Please, it would be nice to see the follow-up discussion of details in
the form of git commits against h5md HEAD, in the spirit of “show me
the code” ;-).

Regards,
Peter