Re: [h5md-user] [EXTERNAL] Re: Units Module Question

[Pierre de Buyl]

On Tue, May 13, 2014 at 10:09:58AM +0200, Konrad Hinsen wrote:
> Hart, David Blaine writes:
> 
>  > I actually think you are right, and that the string "1.602 10-19 C"
>  > is not valid.  I would take this reading because it is a "unit" and
>  > not a conversion factor, which means I was misusing the "unit"
>  > metadata when I was trying to give a conversion factor in my units.
> 
> Indeed.
> 
>  > But it would still make sense to have a single numeric unit
>  > factor, especially a power of ten, as it is descriptive of the
>  > units. It would then make sense not to allow scientific notation,
>  > since that should probably apply to the data itself, while the
>  > units module only defines the unit, not a conversion factor which
> 
> Speaking for my original unit definition in MOSAIC, on which the one
> in H5MD is based, my original intention was indeed not to allow
> scientific notation, in order to avoid the problems associated with
> floating-point notation and precision. That's why the specification
> allows only one numerical factor, and requires it to be an integer or
> a decimal fraction. It makes it possible to compare units for identity
> without doing floating-point operations.
> 
> A straightforward generalization that maintains this advantage is to
> allow integers and decimal fractions written in an exponential
> notation. A very simple specification would actually be "an integer
> plus optionally an integer power of ten", thus banning the decimal
> point which could be seen as an invitation to do floating-point
> computations.
> 
>  > I realized this as I was reading the SI Brochure, and it seems the
>  > units module has already accounted for this by defining the
>  > "system" metadata within the /h5md/modules/units/ group. If I
>  > wanted to propose a, for example, "CGS-ESU" system, that would be
>  > easily defined as a different "system". And if I want to convert my
>  > energy from Kcal to J, I should multiply through the 4.184 J / Kcal
>  > conversion factor on my data first, then set the unit to "J",
>  > rather than set the unit to "4.184 J", since that isn't a unit,
>  > it's an equation. :-)
> 
> Right.
> 
> Again referring to MOSAIC, my intention was to explicitly limit the
> number of allowed units, both for clarity and ease of processing.  If
> you allow kcal, then sooner or later the multiple definitions of the
> calorie will cause trouble. Even if you specify which calorie you want
> to allow, someone will get it wrong one day. In the spirit of the SI,
> the best solution in the long run is to ban all those messy units and
> hope that they will finally disappear from science. Of course this
> philosophy is in direct conflict with any approach trying to
> accommodate a maximum of conventions in a single file format.

Ok, I had not "an integer or a decimal fraction" when writing my last email.
Fortunately, this part was designed with precision and it becomes thus quite
clear. 

And yes, it is possible to design alternative unit systems although the use of
"SI" is, in my opinion, recommended as much as possible (that is when there are
physical units and not only "simulation units" such as Lennard-Jones). As Felix
mentions, the numeric unit factor is part of the unit string and as such allows
you to works in units of "4.184 J" :-)

Cheers,

Pierre