Re: [h5md-user] Unit attribute versus non-dimensionless quantities

[Pierre de Buyl]

On Fri, Aug 02, 2013 at 02:25:58PM +0200, Felix Höfling wrote:
> Am 01.08.2013, 18:28 Uhr, schrieb Peter Colberg
> <address@hidden>:
> 
> >On Thu, Aug 01, 2013 at 06:13:55PM +0200, Felix Höfling wrote:
> >>I think we would miss an important feature of HDF5 if we do not
> >>mention (and support) the possibility of annotating data in general,
> >>the physical unit is just one important example.
> >>
> >>Many people in MD, in particular in the context of force fields and
> >>protein simulations, use absolute physical quantities and need
> >>units. I have seen many situations where even LJ units were
> >>translated to nm and fs. Just guessing or assuming physical units is
> >>not in the spirit of a self-describing file format.
> >>
> >>The current specification is not as worse as it seems. The
> >>specification of units is possible for all proper datasets, only
> >>data stored as attributes can not carry a unit. We could just leave
> >>it as it is.
> >
> >The specification as is cannot be implemented, since an attribute
> >cannot have an attribute. Since we seem to disagree on how to
> >implement units, this should be postponed.
> >
> >Note that I would not consider a unit as an annotation. A
> >non-dimensionless quantity consists of a number and a unit.
> >
> >For an example of how units could be implemented on a computer,
> >have a look at Boost.Units [1]. The idea is the same: the data
> >type is the type of the quantity, not the number.
> >
> >[1] www.boost.org/libs/units
> >
> >>I have also asked myself the question whether insisting on storing
> >>dimensionful data as HDF5 attributes might be a design flaw of H5MD,
> >>but I don't want to re-open this discussion.
> >
> >That would be the natural consequence of using a "unit" attribute
> >attached to the data: the use of attributes would be forbidden for
> >most data. I doubt whether that is a good solution. I certainly
> >wish to annotate my datasets with non-dimensionless attributes.
> >
> >Peter
> 
> I think we're trying to solve two issues in one step:
> 
> 1) It should be possible to annotate data in a flexible way, allowing also
> for custom annotations. This goes beyond the issue of units, but reflects
> an important feature of HDF5.

This has not to be part of the spec. You may annotate arbitrily your data
without breaking H5MD.

> 2) Dimensionful data need to carry a unit. In the case of datasets and
> data groups, this could simply be an attribute. For data stored as
> attributes, this is not possible and a more involved solution is needed
> (and Peter has pointed at such a solution)
> 
> I think H5MD would miss something important if neither 1) nor 2) are
> addressed in the first release. My suggestion is
> 
> - mention that datasets and data groups can be annotated at will in a
> user-defined way
> 
> - provide two alternatives for specifying units in case of datasets and
> data groups (as attribute "unit" or as attribute to a special type)
> 
> - attributes can carry a unit only via an annotated, special type
> 
> - add a unit attribute to the box, letting edge and offset share the same
> unit
> 
> The right place to put these things would be a subsection in the general
> section following the specification of time-(in)dependent data.
> 
> Would that be a reasonable compromise between versatility and usability (a
> flexible number of simple attributes) on the one hand side and efficiency
> (attributes instead of datasets) on the other?

I think that v1.0 should not specify anything unit-related [1]. This will be 
missed
but as I see it, the only "good" solution is to use named types. Using the unit
attribute is, in light of the recent discussions too limited. And we don't want
to have a dual solution as a basis for the future.


Regards,

Pierre

[1] Unless a compromise on named datatypes is found.

> 
> I'll be on vacation from now on ... sorry that we didn't manage to close
> this issue before.