Blog post to show off pint-xarray integration?

[TomNicholas]

@rabernat suggested to me that as a cool new feature the pint-xarray integration deserves it's own blog post to advertise it!

We could put it on the pangeo blog. It doesn't need to be a major undertaking, it would just be good to have an overview to refer to when mentioning this feature, and I think we're at the point where we want people to be trying this code out.

I'm happy to write this, but was wondering if

1. Anyone else was interested in helping (@keewis @jthielen ?) (you would be credited with all this excellent work regardless of course)
2. Are there any features/bugfixes we should wait for before writing it? True unit-aware indexes would be cool but that also will take a while...
3. Any particular ideas for cool unit problems to use as an example?

[jthielen]

Sounds like a great idea! If this is something in the near-term (e.g. 1-3 weeks), I will unfortunately be unable to help as I am currently finalizing my thesis. But, if it is something more on the next couple months timeline, I'd be glad to help, as I really want to get back into more open source contributions after my defense.

While it is not strictly a feature/bugfix to wait for on pint-xarray's end, I think it would be great to make sure that pint-xarray and cf-xarray can work well together (especially with cf-xarray's UDUNITS-emulating pint registry that follows from MetPy's approach). Being able to showcase seamless unit-aware analysis of CF-compliant earth science datasets would be a great selling point. I think the most work that remains is seeing if one library's accessors could utilize the other's when it is available (so that things like ds.temperature.cf.sel(Z=850 * units.hPa) work). But, if this is too much of a lift in the timeline for the blog post, then it can probably just be referenced as a roadmap item.

[dcherian]

pint-xarray and cf-xarray can work well together (especially with cf-xarray's UDUNITS-emulating pint registry that follows from MetPy's approach).

I got started on this here: NCAR/pop-tools#88; but then paused for the unit registry work in cf-xarray. We could adapt it to a few cloud datasets instead of NCAR-local datasets

[rabernat]

I support this 💯 . @jhamman is an editor on the Pangeo medium blog and can make sure you have permissions to submit a story.

[keewis]

I agree, that would be great, and since I currently have lots of time I would be able to help. Unfortunately, I don't have any ideas for examples (if I had we would have more tutorials) so thanks for the suggestion, @dcherian.

I don't think we have to wait for any bug fixes or new features right now: there were no bug reports involving pint-xarray since the last release (could be because the package is not that widely used) but there are a few things we need to figure out, e.g. the best way to interact with registries provided by a separate package or getting xarray to pass the duck arrays to matplotlib so the matplotlib.units feature works. I don't think we have to wait on those, though: for now, we can tell people to make sure to import packages like cf-xarray before pint-xarray and recommend dequantifying before plotting.

[keewis]

@TomNicholas, can we compile a list of features we want to demonstrate in the blog post? I think that would make it much easier to get started.

[TomNicholas]

Thanks for the reminder @keewis - here's a list I had already made:

Things we want to show off:

• Actual benefits of using Pint vs bare numpy (e.g. raising an error on some invalid operation that you might not have noticed otherwise)
• Automatic decoding of units in attributes (being able to just read a netCDF file and quantify automatically is super helpful)
• cf_xarray integration?
• Dask integration (this is a must-have for man users so we want to at least mention it, but requires Rely on NEP-18 to dispatch to dask in duck_array_ops pydata/xarray#5571)
• Automatically plotting the correct units (small but a nice quality-of-life feature to point out)
• Point to the wrapped functions like sel else that will likely trip people up.

Ideas for format of blog post

Some random ideas - these might also be useful for examples in the pint-xarray docs.

1. Velocity over time graphs

• Show division (m/s)
• Show wrapped functions (integrate to get displacement?)
• Not geoscience specific
• Everyone will understand it
• Unexciting

2. Story of NASA orbiter lost due to metric-imperial mix up

3. CMIP6 use case

• Real research use case
• Geoscience specific

[TomNicholas]

I've drafted a blog post in #142. It's like 90% written, but I do think we should fix #141 before releasing it, and I could do with help to make a cool example that uses cf_xarray.units. We will also need another release of xarray first, because we need to inlcude pydata/xarray#5571 in order for dask to work with pint.

This can either go on the pangeo Medium blog, or we can make a new xarray blog for xarray-related announcements. Ryan suggested that if we go with the latter we could use dev.to instead of Medium, as it is apparently better for technical content. For now the blog posts just exists in markdown form in #142 - feel free to make comments or suggest changes.

[keewis]

I think we decided to open a new xarray blog in a meeting a few weeks ago, which could then also include other posts about xarray (like the user survey). I don't know medium or dev.to, so I guess it would be good to bring that up in the meeting next week. I'm not quite sure if we need to wait on the release, though: it could also be written as a preview (but there definitely is value in being able to reproduce with a released version of xarray – and pint, too, for that matter).

[dcherian]

I'm not quite sure if we need to wait on the release

we could just release now and then let the indexes refactor marinate for a while after merging. Everyone's in favour of more frequent releases anyway...

[keewis]

I agree. If we release more frequently maybe we should switch to date-based versions (i.e. like dask and fsspec)?

[TomNicholas]

it could also be written as a preview

I would rather not publish the blog post telling people they can't actually use the code in it - I want them to try it out before they forget that it exists.

we could just release now and then let the indexes refactor marinate for a while after merging

I'm happy to co-ordinate the next xarray release, I'll just ping Benoit to check that we can safely do that with the indexes refactor first.

[keewis]

with the release of pint=0.19 the last big blocker of the blog post is finally going to disappear (as far as I can tell the only task left is to actually make the release), so I'm wondering whether we should try to schedule a dedicated meeting to finish that, and to maybe also discuss the general direction of the package.

What do you think, @TomNicholas, @jthielen?

[TomNicholas]

wondering whether we should try to schedule a dedicated meeting to finish that, and to maybe also discuss the general direction of the package.

I'm down, and sorry for having let this slide!