[Top][All Lists]

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

Re: [h5md-user] units module

From: Felix Höfling
Subject: Re: [h5md-user] units module
Date: Wed, 16 Oct 2013 17:21:42 +0200
User-agent: Opera Mail/12.15 (Linux)

Am 16.10.2013, 15:11 Uhr, schrieb Pierre de Buyl <address@hidden>:

Hi Konrad,

Thanks for your replies.

On Wed, Oct 16, 2013 at 08:35:54AM +0200, Konrad Hinsen wrote:
Pierre de Buyl writes:

> I just toyed a bit with udunits2 and it seems very nice. The fact that we can
 > rely on this software if need is good.

Indeed. On the other hand, if we allow units to be as general as
allowed by udunits, this means that every program wanting to read H5MD
must either use udunits or re-implement a large subset of it.

Indeed, your restriction is fine.

I find udunits' grouping into SI-base units, SI-derived units etc. very reasonable. Let's keep it for H5MD rather than introducing a different subset. Then a simple reader may want to implement the base units only, and an advanced one relies on udunits. The modules/units section would make a promise which unit set is used, and the reader can immediately tell whether it can cope with it or not.

Actually, whether a reader can "understand" a small or large set of units is mainly a matter of the database defining the units. Do I overlook something here? Why not copying the full list from udunits?

BTW, a more advanced functionality that discriminates between "simple" and "advanced" readers is automatic conversion between units ...

> Is there some kind of "ultimate ASCII SI units definition" available? The xml
 > files from udunits2 seem close to that :-)

It's the best collection I know of.

So, to get back to Peter's message:

I propose that we follow udunits grammar by restricting it similarly to Mosaic.
For reference, Mosaic's definition is
The value of the units field is a text string in ASCII encoding. It contains a sequence of unit factors separated by a space. A unit factor is a unit symbol optionally followed by a non-zero integer which indicates the power to which
this factor is taken.

I would remove the constants defined ("c" and "Nav"), however. We may want to
add "a unit string must be parseable by udunits"?

This should follow automatically if the grammar is specified correctly as a subset of udunits grammar. I would not like to make the spec depend on an external piece of software (with the exception of HDF5 of course). The reference to udunits should go to the implementation section.


reply via email to

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