[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [h5md-user] Minor revisions before H5MD v1.0

From: Felix Höfling
Subject: Re: [h5md-user] Minor revisions before H5MD v1.0
Date: Mon, 06 May 2013 16:12:57 +0200
User-agent: Opera Mail/12.15 (Linux)

Am 05.05.2013, 21:12 Uhr, schrieb Pierre de Buyl <address@hidden>:


On Fri, May 03, 2013 at 06:15:23PM +0200, Felix Höfling wrote:
Am 03.05.2013, 16:27 Uhr, schrieb Peter Colberg

>Hi Felix,
>On Fri, May 03, 2013 at 04:03:26PM +0200, Felix Höfling wrote:
>>Am 02.05.2013, 22:57 Uhr, schrieb Peter Colberg

>>>The "parameters" group is intended as a program-dependent group.
>>>I suggest to remove the "parameters/dimension" attribute, as it
>>>is in contrast to the purpose of this group. The dimension can
>>>be derived from, e.g., the "edges" attributes or "edges/value"
>>>dataset, similar to the number of particles being derived from
>>>"position/value" dataset(s).
>>I think we should not turn the clock back. There were good reasons
>>to include the dimension parameter explicitly, mainly it cannot be
>>inferred from scalar datasets in /observables. Recall that the box
>>group is not mandatory.
>(It was a recent proposal, so it can be reverted without causing
>I am definitely opposed to defining anything within the “parameters”
>group. That group has been, as said, intended as program-specific.
>As for the spatial dimension attribute: The idea of self-describing
>datasets is one of the main benefits of using a structural format for
>storing molecular data. I would rather not violate that principle.
>If you need to split up your files, you could store the box group as
>well, or add a custom attribute "dimension" to your observables. The
>tool h5copy is quite useful for such splitting operations.

I do not adhere to the /parameters group, but one needs a definite
place were an H5MD reader can get the space dimension from in a
simple and reliable way. In particular, it must not depend on the
presence of any group, be it /trajectory or /observables or
/observables/box. The point is that the scalar observable data sets
are incomplete without the dimension thus breaking the
self-descriptiveness of the data format.


I'd like to propose another solution. I think that it is better and that it
satisfies the legimate concerns that were expressed by both of you:
1. Avoid polluting the yet free /parameters group.
2. Take into account the possibility that several parts of the file may be
related to different dimensional constraints.
3. Allow to determine without ambiguity the dimensionality of the system related
to a given observable. This should have been number 1 indeed :-)

Here is the idea:

  +-- dimension OPTIONAL
  \-- obs1
       +-- dimension OPTIONAL
       \-- step
       \-- time
       \-- value

If you want to know the dimensionality of the system related to obs1, you use the innermost dimension attribute available. I put everything optional so that
the user may DNRY (do not repeat yourself) as he/she sees fit.

Data from the trajectory group keeps its dimensionality inferred from the


Hi Pierre,

Looking up an attribute in different possible places might be a bit impractical for the H5MD reader. I have a different suggestion just posted to the original thread. Let me repeat it:

Interpretation of the data in /observables may depend on information about the spatial dimension or the system geometry. Such interpretation is only possible, if the optional group /observables/box is present and if its step/time datasets coincide with the those of the observable under consideration. Otherwise, an H5MD reader considers the file incomplete for the desired purpose and fails.

Apart from that we might add the attribute "dimension" to the box group itself. It costs basically no storage and is less cumbersome than checking whether the box has an attribute "offset" or a dataset "offset", opening it and retrieving its shape.

What do you think?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]