⇐ ⇒

[CF-metadata] Decibel units in CF standard names

From: Martin Juckes - UKRI STFC <martin.juckes>
Date: Tue, 6 Nov 2018 09:55:08 +0000

Dear Jonathan,


Interesting that your version of udunits has bel & decibel ... mine (udunits2 which I installed on Oct. 17th) does not have these (*"udunits2: Don't recognize "bel"* it tells me), but does had dBz, dBW, dBV, dBv and a few others. There is a different udunits unit for every reference level. Do you know which version of udunits you are using?


cfunits, on the other hand, which uses the udunits2 library, does have bel and decibel added, and has them equivalent to '1'. The list of changes that cfunits makes relative to udunits is copied below (from the cfunits.Units help text), with changes that are not mentioned in the convention highlighted:


 | ======================= ====== ============ ==============
 | Unit name Symbol Definition Status
 | ======================= ====== ============ ==============
 | practical_salinity_unit psu 1e-3 New unit
 | level 1 New unit
 | sigma_level 1 New unit
 | layer 1 New unit
 | decibel dB 1 New unit
 | bel 10 dB New unit
 | sverdrup Sv 1e6 m3 s-1 Added symbol
 | sievert J kg-1 Removed symbol
 | ======================= ====== ============ ==============


There appear to be two options: to diverge from UDUNITS in the approach taken for decibels, or not.

If we diverge, and use "dB" for multiple reference levels, this needs to be expressed more clearly in the convention. This should include specifying whether "dB" is conformant with "1". Both us have some objections to this idea, but it may be that we need to accept that conformance of units is a fuzzy idea.

If we follow UDUNITS, I'm afraid "dB" as a unit has to go.

regards,
Martin

________________________________
From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of Jonathan Gregory <j.m.gregory at reading.ac.uk>
Sent: 05 November 2018 21:00
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Decibel units in CF standard names

Dear Martin

> The discussion of a machine-readable document with details of rules related to specific standard names is here: https://cf-trac.llnl.gov/trac/ticket/153 . It has been quiet for some time. The dB issues could be covered there, as you say. There is a difference in that the rules discussed in ticket 153 are about specifying what needs to be in the data file, so that it is possible to check that file meta-data is as complete as intended by the convention. Your suggestion would entail adding information that would not be in the data file.

Yes, I agree, that's a bit different. The rules file would provide the info.
It's a convenient place to put it.

> You also suggest that alternative reference levels could be specified in an attribute, but that does not appear to be allowed by current standard name definitions,

I admit that I didn't check the definitions of these standard names! But there
are standard names which refer to a value with a default that can be overridden
by a coordinate variable or scalar coordinate variable (not an attribute). If
there is a use-case for different reference values for any of the dB instances
you mention, we should provide for it using that mechanism by amending the
definitions of the standard names, I suggest.

> It is true that dB is dimensionless, like "1", but we would create huge confusion if dB data values were multiplied by 100 and presented as "%" ... a sound_intensity_level_in_water with a value of 25% might be technically equivalent to 0.25dB, but not very useful to users. I'm not sure how to deal with this, but I'm not comfortable with the idea that dB is fully equivalent to "1" as a unit.

I find that in my version of udunits, bel and decibel are units, and they are
not convertible to dimensionless numbers. I think that's consistent with what
you say and I agree it makes sense like that.

Best wishes

Jonathan
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Tue Nov 06 2018 - 02:55:08 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:43 BST

⇐ ⇒