h5md-user
[Top][All Lists]
Advanced

[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



reply via email to

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