Re: [h5md-user] boundary conditions (again)

[Pierre de Buyl]

On Thu, Aug 01, 2013 at 10:50:25AM +0200, Felix Höfling wrote:
> Am 31.07.2013, 18:43 Uhr, schrieb Peter Colberg
> <address@hidden>:
> 
> >On Wed, Jul 31, 2013 at 11:08:12AM +0200, Felix Höfling wrote:
> >>Hence, I suggest that the boundary type "nonperiodic" is replaced
> >>either by the empty string or by "none" (synonym for "unspecified").
> >>In this case, the edge specification along this axis is not
> >>relevant. Even more, if all axes have "none", "edges" could be
> >>dropped at all ...
> >
> >The choices "periodic" and "none" would be fine with me, too.
> >
> >But what about the geometry attribute? So far, the choices "cuboid"
> >and "triclinic" mandate three dimensions, and a box with finite edges
> >lengths for all dimensions. We did not consider two-dimensional
> >systems, or infinite boundaries, where the latter is hard to classify
> >using a string.
> >
> 
> "cuboid" is to be understood as "hypercuboid" with a straightforward
> generalisation to dimensions lower and higher than 3. I think the
> main purpose of these attributes is to discriminate between the
> various shapes of edges: a vector for cuboid, and a set of vectors
> for triclinic.
> 
> What about dropping the "geometry" attribute and interpreting
> "edges" according to its shape? See the attached patch for details.
> I have also included a scalar shape for a natural support of the
> simplest and very common case: cubic boxes.
> 

cuboid and triclinic are 3D but the specifications then refers to D-dimensional
data so that there is no confusion.

Interpreting "edges" to infer "geometry" is an opposite way of working than what
you suggested in the past :-)
I can live with both situations but keeping "geometry" seems more simple to me.

What seems unanimous, though, is to have "periodic" and "none" for the values in
"boundary".

Regards,

Pierre

> >From a079d335c3cb2a15bb05ca36ba5db291cebfb098 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Felix=20H=C3=B6fling?= <address@hidden>
> Date: Thu, 1 Aug 2013 10:38:17 +0200
> Subject: [PATCH] box: drop geometry attribute, change "nonperiodic" to "none"
> 
> The geometry attribute is not needed since it can be inferred from the
> shape of "edges".
> 
> Extend the spec for a simple support of cubic boxes with a scalar edge
> value.
> 
> Shorten the specification of time-dependent vs. -independent and drop
> the subsection headlines. The issue has been specified in the general
> part already, and the two examples should clarify this again.
> 
> http://article.gmane.org/gmane.science.simulation.h5md.user/218
> ---
>  draft.rst | 56 +++++++++++++++++++++-----------------------------------
>  1 file changed, 21 insertions(+), 35 deletions(-)
> 
> diff --git a/draft.rst b/draft.rst
> index 46a068e..5bb7956 100644
> --- a/draft.rst
> +++ b/draft.rst
> @@ -310,20 +310,23 @@ The specification of the simulation box is stored in 
> the group ``box``, which
>  must be contained within each of the subgroups of the ``particles`` group.
>  The group ``box`` must further be stored in (or hard-linked to) the
>  ``observables`` group, if present.
> +A specific requirement for ``box`` groups inside ``particles`` is that the
> +``step`` and ``time`` datasets exactly match those of the corresponding
> +``position`` groups, which may be accomplished by hard-linking the datasets.
> +
>  Storing the box information at several places reflects the fact that all root
>  groups are optional (except for ``h5md``), and further that different 
> subgroups
>  may be sampled at different time grids. This way, the box information remains
>  associated to a group of particles or the collection of observables.
>  
> -The spatial dimension, the type of geometry, and the boundary conditions of 
> the
> -box are stored as attributes to the ``box`` group, e.g., ::
> +The spatial dimension and the boundary conditions of the box are stored as
> +attributes to the ``box`` group, e.g., ::
>  
>      particles
>       \-- <group1>
>            \-- box
>                 +-- dimension
>                 +-- boundary [D]
> -               +-- geometry
>                 \-- ...
>  
>  ``dimension``
> @@ -333,52 +336,36 @@ box are stored as attributes to the ``box`` group, 
> e.g., ::
>  ``boundary``
>      An attribute that is a string-valued array of size ``D`` that
>      specifies the boundary condition of the box along each dimension. The
> -    elements of ``boundary`` are either ``periodic`` or ``nonperiodic``.
> +    elements of ``boundary`` are either ``periodic`` or ``none``.
>  
> -``geometry``
> -    An attribute that is string-valued and is either ``cuboid`` or
> -    ``triclinic``.
> -
> -For a cuboid box, the following additional data is stored:
> +Information on the geometry of the box edges and on the coordinate offset is
> +stored as attributes or as H5MD data groups, depending on whether the box is
> +fixed in time or not.
>  
>  ``edges``
> -    A ``D``-dimensional vector specifying the space diagonal of the
> -    box. The box is not restricted to having the same edge lengths in the
> -    different dimensions.
> +    A scalar, a ``D``-dimensional vector, or a ``D`` ?? ``D`` matrix, 
> depending
> +    on the geometry of the box. The box is neither restricted to having the
> +    same edge lengths in all directions nor to having orthogonal edges.
>  
> -``offset``
> -    A ``D``-dimensional vector specifying the lower coordinate
> -    for all directions.
> +    If ``edges`` is a scalar, the box is a (hyper-)cube with the given edge
> +    length.
>  
> -For a triclinic box, the following additional data is stored:
> +    If ``edges`` is a vector, it specifies the space diagonal of a
> +    cuboid-shaped box.
>  
> -``edges``
> -    A ``D`` ?? ``D`` matrix with the rows specifying the edge vectors
> -    of the box.
> +    If ``edges`` is a matrix, the box is of general triclinic shape with the
> +    edge vectors given by the rows of the matrix.
>  
>  ``offset``
>      A ``D``-dimensional vector specifying the lower coordinate
>      for all directions.
>  
> -Time dependence
> -^^^^^^^^^^^^^^^
> -
> -If the simulation box is fixed in time, ``edges`` and ``offset`` are stored 
> as
> -attributes of the ``box`` group for all box kinds. Else, ``edges`` and
> -``offset`` are stored as datasets following the ``value``, ``step``, ``time``
> -organization.
> -
> -A specific requirement for ``box`` groups inside ``particles`` is that the
> -``step`` and ``time`` datasets exactly match those of the corresponding
> -``position`` groups, which may be accomplished by hard-linking the datasets.
> -
>  For instance, a cuboid box that changes in time would appear as::
>  
>      particles
>       \-- <group1>
>            \-- box
>                 +-- dimension
> -               +-- geometry
>                 +-- boundary
>                 \-- edges
>                      \-- value [variable][D]
> @@ -389,19 +376,18 @@ For instance, a cuboid box that changes in time would 
> appear as::
>                      \-- step [variable]
>                      \-- time [variable]
>  
> -where ``dimension`` is equal to ``D`` and ``geometry`` is set to ``cuboid``.
> +where ``dimension`` is equal to ``D``.
>  A fixed-in-time triclinic box would appear as::
>  
>      particles
>       \-- <group1>
>            \-- box
>                 +-- dimension
> -               +-- geometry
>                 +-- boundary
>                 +-- edges [D][D]
>                 +-- offset [D]
>  
> -where ``dimension`` is equal to ``D`` and ``geometry`` is set to 
> ``triclinic``.
> +where ``dimension`` is equal to ``D``.
>  
>  
>  Observables group
> -- 
> 1.7.11.4
>