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.
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. Regards, Steve Emmerson UDUNITS Developer