Hi,
On Fri, May 03, 2013 at 06:15:23PM +0200, Felix Höfling wrote:
Am 03.05.2013, 16:27 Uhr, schrieb Peter Colberg
<address@hidden>:
>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
>><address@hidden>:
>>>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
>trouble.)
>
>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.
>
>Peter
>
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.
Felix
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:
\observables
+-- 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
datasets.
Pierre