SciTools
cfunits package confusion
The cfunits package is extremely similarly named to this one, and apparently has a purpose in common.
In particular, one major difference is cfunits' changes to the standard udunits definitions:
find *.nonCF -exec sh -c 'echo $0; diff -u "$0" "${0:0:${#0}-6}"' {} \;
udunits2-accepted.xml.nonCF
--- udunits2-accepted.xml.nonCF 2018-04-30 17:22:48.171105000 +0100
+++ udunits2-accepted.xml 2018-04-30 17:22:48.168105000 +0100
@@ -188,9 +188,11 @@
<def>cGy</def>
<aliases> <name><singular>rad</singular></name> </aliases>
</unit>
- -->
+ -->
+ <!-- 'rem' is changed from 'cSv' since 'Sv' has been reassigned to sverdrup for CF
+ -->
<unit>
- <def>cSv</def>
+ <def>0.01 sievert</def>
<aliases>
<name><singular>rem</singular></name>
</aliases>
udunits2-common.xml.nonCF
--- udunits2-common.xml.nonCF 2018-04-30 17:22:48.177098000 +0100
+++ udunits2-common.xml 2018-04-30 17:22:48.175099000 +0100
@@ -877,10 +877,10 @@
<def>1e6 m^3/s</def> <!-- exact -->
<aliases>
<name> <singular>sverdrup</singular> </name>
- <!-- The following is commented-out because "Sv" means
- "sievert" in the SI unit-system.
- <symbol>Sv</symbol>
+ <!-- The following is not commented-out, thereby overriding "Sv" meaning
+ "sievert" in the SI unit-system, more useful to CF.
-->
+ <symbol>Sv</symbol>
</aliases>
</unit>
@@ -1637,4 +1637,71 @@
<symbol>DU</symbol>
</aliases>
</unit>
+ <!-- Units useful to CF -->
+ <unit>
+ <def>1e-3</def> <!-- exact -->
+ <aliases>
+ <name>
+ <singular>practical_salinity_unit</singular>
+ <plural>practical_salinity_units</plural>
+ </name>
+ <symbol>psu</symbol>
+ </aliases>
+ </unit>
+ <unit>
+ <def>calendar_year/12</def> <!-- exact -->
+ <aliases>
+ <name>
+ <singular>calendar_month</singular>
+ </name>
+ <symbol>cM</symbol>
+ </aliases>
+ </unit>
+ <unit>
+ <def>1</def> <!-- exact -->
+ <aliases>
+ <name>
+ <singular>level</singular>
+ <plural>levels</plural>
+ </name>
+ </aliases>
+ </unit>
+ <unit>
+ <def>1</def> <!-- exact -->
+ <aliases>
+ <name>
+ <singular>layer</singular>
+ <plural>layers</plural>
+ </name>
+ </aliases>
+ </unit>
+ <unit>
+ <def>1</def> <!-- exact -->
+ <aliases>
+ <name>
+ <singular>sigma_level</singular>
+ <plural>sigma_levels</plural>
+ </name>
+ </aliases>
+ </unit>
+ <unit>
+ <def>1</def> <!-- exact -->
+ <aliases>
+ <name>
+ <singular>decibel</singular>
+ <plural>decibels</plural>
+ </name>
+ <symbol>dB</symbol>
+ </aliases>
+ </unit>
+ <unit>
+ <def>10 dB</def> <!-- exact -->
+ <aliases>
+ <name>
+ <singular>bel</singular>
+ <plural>bels</plural>
+ </name>
+ </aliases>
+ </unit>
+
</unit-system>
udunits2-derived.xml.nonCF
--- udunits2-derived.xml.nonCF 2018-04-30 17:22:48.181097000 +0100
+++ udunits2-derived.xml 2018-04-30 17:22:48.179100000 +0100
@@ -137,7 +137,10 @@
<def>J/kg</def>
<aliases>
<name><singular>sievert</singular></name>
+ <!-- The following is commented-out, allowing "Sv" to mean
+ "sverdrup", more useful to CF.
<symbol>Sv</symbol>
+ -->
</aliases>
</unit>
</unit-system>
See also: https://github.com/SciTools/cf_units/issues/30#issuecomment-118768645
@pelson What do you propose we do about this confusion? Or are you just highlighting that the cfunits package is similar, but different.
Or are you hinting that we should allow a way for users to add their own custom units? :thinking:
I'm proposing that we try to bridge the gap - there is no good reason for two CF units type packages IMHO.
At the very least, we should recognise the other in our README, and highlight some of the pros/cons of each (I don't know what they are at this point, hence my probably naive "no good reason" statement 😉).
cc @davidhassell
@rcomer This link seems to reject the difference as not worthy of talking about. In fact, just the fact that this project thinks it is worth a few sentences was encouraging to me.
Does anyone know both well enough to say whether there a difference in how configurable/changeable the list of units is, or is this an xml edit in either library? One issue I have is that I am in a community that uses particular conventions for going between mhos or Siemans and practical salinity units. At low salinities it includes adjustments for things like agricultural salts. So, to replace tools we have I would need this to be possible and I need to be able to specify my own custom function to do it. Do the above changes get me closer to where I want to go or is hard because I want to interject a nonstandard unit plus a new conversion? I'm understand there are several larger questions at play and I will caveat my projects accordingly.
Note : this does deserve some consideration, at least to answer the above question about defining custom units ( see also #155 ) I don't think this is in scope for the current work sprint though (16-27 Sep 2024, working towards release v3.3) So, I'm going to assign this to myself, but I shall not put it on the board for that effort.
