Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine supported units #535

Open
peverwhee opened this issue Feb 27, 2024 · 4 comments
Open

Determine supported units #535

peverwhee opened this issue Feb 27, 2024 · 4 comments

Comments

@peverwhee
Copy link
Collaborator

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
@mkavulich
Copy link
Collaborator

mkavulich commented Mar 13, 2024

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)

@gold2718
Copy link
Collaborator

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.

@mwaxmonsky
Copy link
Collaborator

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.

@climbfuji
Copy link
Collaborator

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants