Re: [h5md-user] Suggestion

[Pierre de Buyl]

Hi Felix,

> 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.
I wanted to try, but it's not very practical!

> --- 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:
We may even not require "parameters". See more below :-)


> 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.
This is OK then.

> 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).
As long as we specify explicitly the box type, any way will do :-)
"edges" is nice. We also need "offset".

> 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.
Orthogonal ? Is there a "more accepted" term that we should choose ?
Cubic is indeed too restrictive.

> 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.
As we agree to specify explicitly the kind of box, we can choose either. I'd
prefer to use a single dataset instead of a group structure (in which case it
would go to "parameters", see below).

Opinions ?


> 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.

Who is using those symmetries in a HDF5 file ? I agree anyway that they
should be postponed to a next release.

OK, now, the actual purpose of my message.

When I suggested to use "parameters" for time independent data and
"observables" for time dependent data, this was for several reasons:
    1. Clarity of the programmatic interface. Indeed, one can have routines
      operating on "parameters" that just fetch data from the parameters group,
      without needing to check whether the data is time-dependent or not.
      None of the choice is impossible to make but it really is, for me, a time-
      saving feature to have a set of "observables" routines and a set of
      "parameters" routine. I am sure that many scientists will appreciate that.
    2. Avoiding the choice may save time to many people in the future. A simple
      criterion like the one I suggest leaves no choice on the position of the 
data
      in the H5MD file. The very very lengthy discussion that we are having is 
in
      itself a strong argument towards that choice.
    3. Regarding the box size, I have another point. A box size information for
      the /initial/ size of the box, for instance, would go in parameters as 
well as
      the information on its fate: fixed or not. That would depend on the 
different
      programs. The subsequent box size time series would go to observables.

Finally, I don't think that the issue of mandatory group is that relevant to 
this
discussion. We might ask that only "h5md" is mandatory, even if such a file
would be useless.

Besides this endless discussion about the groups, I think the discussions
have made our ideas quite mature on H5MD and that once this issue is
solved, the rest of the discussions should go well.

As there was no argument other than matters of principles supporting the
location of data in observables/parameters, I am sure everyone will agree
that we have to settle for a solution shortly.

I hope I have not been too abrupt in presenting my point of view and that
we will agree soon :-)

Best wishes,

Pierre