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

Re: udunits

Hi Jonathan,

>Date: Tue, 29 Mar 2005 09:14:52 +0100
>From: Jonathan Gregory <address@hidden>
>To: address@hidden,
>To: address@hidden,
>To: address@hidden
>Subject: udunits

The above message contained the following:

> A question about the use of dB as a unit for a CF standard name has just come
> up on the CF email list, not for the first time. dB is a dimensionless unit
> not included in udunits.dat.

This isn't the first time the need for logarithmic units in the UDUNITS
package has arisen.  I haven't done significant work on the UDUNITS
package for quite a while -- so I suppose it's about time to take it
up again.  Unfortunately, adding logarithmic units will necessitate a
change to the API that will be incompatible with the current API because
the assumption of a Gaussian transformation will no longer be valid.

> There are other units for which CF seems to have a fairly strong need,
> including PSU (practical salinity unit), also dimensionless (=1e-3),

Dimensionless units are, indeed, problematical.  For example, values
expressed in "psu" and "ppt" are both dimensionless -- but they
shouldn't be added or subtracted if one is concerned about accuracy.

The current UDUNITS package can handle the "psu" unit if the following
entry is added to the udunits.dat file:

    # Practical Salinity Unit
    psu         S       0.001           # exact

> and sverdrup (Sv = 1e6 m3 s-1), which conflicts with sievert for its
> abbreviation.

Sievert and Sverdrup are tough.  Much as it offends my oceanographic
schooling, I think most of the world associates "Sv" with Sieverts
rather than Sverdrups (I could be wrong, but I think the medical and
radiation communities dwarf the oceanographic).

My advice is to always use full names for units rather than
abbreviations -- just to avoid this kind of ambiguity.

> How should we deal with this? Could these and perhaps other units be added to
> udunits.dat? Or should we provide our own CF version of udunits.dat? In the
> latter case we would somehow have to keep it in step with the standard one,
> which is an obstacle.
> This isn't a new problem but I don't think we've really addressed it.
> Thanks for your help. Best wishes
> Jonathan

The UDUNITS package is going to become a subpackage of the netCDF
package.  As such, it will probably receive more attention than it has
in the recent past.

Steve Emmerson
UDUNITS Developer