[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[h5md-user] Unit attribute versus non-dimensionless quantities
From: |
Peter Colberg |
Subject: |
[h5md-user] Unit attribute versus non-dimensionless quantities |
Date: |
Tue, 30 Jul 2013 22:39:50 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi all,
Upon reading the section on Time-independent data, I realized that the
specification is inconsistent with regard to the unit attribute versus
time-independent box attributes, or more generally, the unit attribute
versus time-independent non-dimensionless data stored in an attribute.
The issue is that HDF5 attributes cannot have additional metadata,
i.e., attributes cannot be attached to an attribute. If the length is
chosen as a non-dimensionless quantity, then the box edges and offset
require a unit attribute. However, if the box is fixed in time, the
box edges and offset are stored as attributes, and thus cannot have
a unit attribute.
A solution would be to store the box edges or offset as either a data
group (time-dependent), a dataset (time-independent with unit), or an
attribute (time-independent without unit). Further, the specification
could state that a dimensionless time-independent quantity is stored
as either an attribute or a dataset (depending on the size of the
data), while a non-dimensionless time-independent quantity is stored
as a dataset with a unit attribute.
An alternative would be to store the box edges and offset as either
a data group or a dataset, and generally forbid attributes for storing
quantities which could potentially carry a unit. However, I would
rather avoid this restriction, since it causes a mess of attribute
and dataset quantities in my output files, despite all of them being
dimensionless time-independent quantities.
Another approach would be to dispose of the unit attribute, and store
a non-dimensionless quantity as a compound of a number (the value) and
a string (the unit). This would allow storing quantities with a unit
in both datasets and attributes, the latter being especially useful
for any kind of parameter. Since I have no experience with compound
data types, e.g., how they would affect the size and compression of a
time series, or how usable they are across programming environments,
this solution would have to be postponed until after H5MD v1.0.
How would you resolve the issue?
I feel that the safest, future-proof solution is to move the unit
attribute from the specification to the discussion section, and find
a solution later, that has proven itself in practice. I have yet to
hear from someone who is consistently using H5MD data with units in
their simulations, never mind experiments.
Peter
- [h5md-user] Unit attribute versus non-dimensionless quantities,
Peter Colberg <=