NCAR
Determine supported units
Description
DISCUSSION SOLICITED What units/unit conversions do we want to support long term?
Options (probably not a complete list)
- Just SI units and variations thereof (kg v g, etc)
- Any unit conversion that a user requests (within reason)
- Also equivalent units? (Joules v Newton-meters)
- Bring in a 3rd party library and just support whatever they do
On the subject of third-party libraries for unit conversion, I did a bit of research and found a few potential logical choices:
- unitpy. I believe this is the suggestion @mwaxmonsky proposed initially. Seems like a very simple but effective Python package with an extensive list of unit conversions.
- pint. This seems like it may be the best option for us if we want to go in this direction: not only does it have an extensive list of default unit conversions, but it contains the capability to define your own unit conversions, which would allow the framework to add its own custom conversions without needing a separate routine.
- Unidata (who support NetCDF libraries) have a library for unit conversion: UDUNITS. It is unclear how convenient this would be in the context of the framework, since presumably we would be doing conversion at the framework level in Python, but I thought I would mention it since it's specifically in the geoscience software ecosystem. (Edit: although the more I think about it, this might be the best option from a performance perspective)
My preference would be to just add anything reasonable that is requested. It is pretty easy to add a new conversion to @climbfuji's unit_conversion.py module.
Just wanted to add two more to the list:
- https://github.com/astropy/astropy - Haven't used it directly but it has a very active governance and contributor history (over 30k commits!) and great documentation (https://docs.astropy.org/en/stable/units/index.html). It is definitely overkill for our use case but I think we should consider it.
- https://github.com/Unidata/MetPy - I used this a while ago and it was pretty solid for units. Not sure how it compares in terms of capability to astropy but might be something worth considering as well. Given it's a UNIDATA product as well, we might be able to get more support if needed?
Both have a pretty consistent release cadence as well and are past their 1.0 release.
I agree with @gold2718 that there needs to be a very good reason to implement something else than what we have now. It works fine, it is super easy to maintain and extend, and I think over the last 3 years since I left NOAA at most one or two conversions were added (which takes literally 3 minutes to do).
