Re: [h5md-user] Suggestion

[Felix Höfling]

Please apologise for being silent in the last weeks.

I'm not sure whether the discussion via proposed patches is practical, but
let's give it a try.

Thank you, Pierre, for condensing the previous mails into a draft patch.

--- a/draft.rst
+++ b/draft.rst
@@ -42,6 +42,15 @@ trajectory via dataset slicing.
   The file is allowed to possess non-conforming groups that contain other
   information such as simulation parameters.

+The groups that are part of the H5MD specifications are
+
+* h5md: Group containing, as attributes, information on the file itself.
+* parameters: Group containing the parameters for a simulation/dataset,
such as
+  the spatial dimension of the system or simulation parameters.
+* trajectory: Group containing the trajectory of the system (positions,
...).
+* observables: Group containing all time-dependent variables in the
system,
+  except the ones found in the "trajectory group".
+
   Global attributes
   -----------------

The origin and the purpose of a H5MD file are not determined. It may serve
as mere simulation input containing only minimal information about
particle positions (not even their interactions). On the other hand, it
may reflect a full simulation run including derived observables or
correlation functions as output.

As Konrad pointed out, the H5MD format shall be as versatile as possible.
Modularity and flexibility shall be essential design goals of the format.
So a H5MD file shall not require the presence of neither the trajectory
nor the observables group. This strengthens my point that the box should
be stored in /parameters.

I prefer to have only two mandatory groups and modify Pierre's suggestion
as follows:

+* h5md: contains attributes with information on the file itself
+* parameters: contains essential and global parameters of the stored
datasets,
+  such as the spatial dimension and the simulation box. The group may
contain
+  subgroups named after the authoring software with program-specific
simulation
+  parameters.
+
+ Further, a series of optional root groups is standardised:
+* trajectory: contains the trajectory of the simulated system or of a
subsystem in form of a series of microscopic states (e.g., particle
positions, velocities, forces[?]).
+* observables: contains physical observables in form of a time series
(e.g., temperature, pressure, box volume, particle number)

Concerning the box types, Konrads argumentation (from 12th October) has
convinced me. A reader can benefit from the knowledge that the box is,
e.g., strictly cubic. Eventually, we will have different types of boxes,
and a fully compatible reader has to support all of them.

I find Peter's proposal to use different dataset names for the different
kinds of boxes appealing because it avoids potential misinterpretations of
the box data. So far, we have only the distinction between lengths
(cuboid) and edges (triclinic). But for a cubic box, we would need another
name ("length", singular?). Alternatively, we could always use "edges"
with different dataset extents: scalar (cubic), d-dimensional vector
(cuboid), and d×d-matrix (triclinic).

In the patch proposed by Pierre, "cubic" needs to be replaced by "cuboid".
At least I understand a cubic box to have all edges the same length.

For static and fluctuating boxes, I tend to use the same format. In case
of a static box, the dataset would contain only one entry at step and time
0. I think this is easier to implement in both readers and writers.

Concerning the symmetry transformations discussed in length, I suggest a
proposals section in the draft. Communication of the proposed features
could help to avoid multiple or contradicting parallel developments. These
features are not yet part of the specification, but have successfully been
implemented by at least one party and are actively used. Before somebody
else independently adds a new feature, the adaption of one of these
proposals can be considered.

Best regards,
Felix



Am 21.10.2011, 15:51 Uhr, schrieb Pierre de Buyl
<address@hidden>:

> Attachment forgotten...
>
> Le 21 oct. 2011 à 15:36, Pierre de Buyl a écrit :
>
> > So, Peter, is this the form of discussion you'd like ?
> > (Patch attached)
> >
> > I suggest to solve the following issues before 0.1:
> >    - cubic / triclinic boxes
> >    - fate of the "parameters" group. I suggest: not time-dependent  
> > data. Subgroups for program-specific parameters and a few common  
> > parameters (such as "dimension").
> >    - other ?
> >
> > Best,
> >
> > Pierre


--
Dr. Felix Höfling
Max Planck Institute for Intelligent Systems
(formerly Max Planck Institute for Metals Research)
Heisenbergstr. 3
70569 Stuttgart
Germany

Phone:  +49 711 689 1938
Fax:    +49 711 689 1922