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

Re: udunits

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: udunits
  • Date: Wed, 30 Mar 2005 10:53:11 -0700
Jonathan,

>Date: Wed, 30 Mar 2005 18:26:50 +0100
>From: Jonathan Gregory <address@hidden>
>Organization: Reading University
>To: Steve Emmerson <address@hidden>
>Subject: Re: udunits

The above message contained the following:

> Thanks for your reply. Since a logarithm is dimensionless, I suppose one can
> just deal with it like any other dimensionless number to some extent (e.g.
> packing, conversion between decibel and bel) and not worry how it is derived.
> In that case isn't the API all right?

The current API might be OK if one never wanted to convert values
between logarithmic and non-logarithmic units.  I can imagine numerous
scenarios, however, in which one would like to do just that (comparing
power levels given in dB and Watts, for example).  If I'm going to
modify the package to support logarithmic units, then I might as well
add support for such conversions.

> Should we then for the moment produce a CF version of udunits.dat which
> contains the dimensionless dB

The problem with adding "B" or "Bel" to the UDUNITS database is that
logarithmic units always need a reference level and the grammar for
specifying units (which is used in the database) doesn't support it.
For example, the grammar needs to support something like

    dB (1 mW)

for a decibel unit with a 1 milliwatt reference level.

> and PSU and sverdrup (or perhaps Sv if we can do without sievert in
> our field)?

One can always have one's own units database, but then God help someone 
trying to do interdisciplinary work, or to have one's work immediately
understood years later.

As I recommended before, the safest, least ambiguous strategy is to
write-out all unit names and avoid symbols.

Regards,
Steve Emmerson