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

hooks to "prepare" xarray objects for plotting #5562

Open
keewis opened this issue Jul 2, 2021 · 6 comments
Open

hooks to "prepare" xarray objects for plotting #5562

keewis opened this issue Jul 2, 2021 · 6 comments
Labels
topic-arrays related to flexible array support

Comments

@keewis
Copy link
Collaborator

keewis commented Jul 2, 2021

From xarray-contrib/pint-xarray#61 (comment)

matplotlib has a module called matplotlib.units which manages a mapping of types to hooks. This is then used to convert custom types to something matplotlib can work with, and to optionally add axis labels. For example, with pint:

In [9]: ureg = pint.UnitRegistry()
   ...: ureg.setup_matplotlib()
   ...:
   ...: t = ureg.Quantity(np.arange(10), "s")
   ...: v = ureg.Quantity(5, "m / s")
   ...: x = v * t
   ...: 
   ...: fig, ax = plt.subplots(1, 1)
   ...: ax.plot(t, x)
   ...: 
   ...: plt.show()

this will plot the data without UnitStrippedWarnings and even attach the units as labels to the axis (the format is hard-coded in pint right now).

While this is pretty neat there are some issues:

  • xarray's plotting code converts to masked_array, dropping metadata on the duck array (which means matplotlib won't see the duck arrays)
  • we will end up overwriting the axis labels once the variable names are added (not sure if there's a way to specify a label format?)
  • it is matplotlib specific, which means we have to reimplement once we go through with the plotting entrypoints discussed in ENH: Plotting backend options #3553 and Add entrypoint for plotting backends #3640

All of this makes me wonder: should we try to maintain our own mapping of hooks which "prepare" the object based on the data's type? My initial idea would be that the hook function receives a Dataset or DataArray object and modifies it to convert the data to numpy arrays and optionally modifies the attrs.

For example for pint the hook would return the result of .pint.dequantify() but it could also be used to explicitly call .get on cupy arrays or .todense on sparse arrays.

xref #5561

@dcherian
Copy link
Contributor

dcherian commented Jul 2, 2021

For example for pint the hook would return the result of .pint.dequantify() but it could also be used to explicitly call .get on cupy arrays or .todense on sparse arrays.

We discussed as_numpy or to_numpy_data here: #3245

@keewis
Copy link
Collaborator Author

keewis commented Jul 3, 2021

that will work if we want to remove the units, but .pint.dequantify() also adds the units as string-valued attributes. In other words, I'd like the new hook to work on xarray objects instead of the wrapped duck array.

@dcherian
Copy link
Contributor

dcherian commented Jul 3, 2021

wouldn't as_numpy on a pint-backed DataArray return a DataArray with numpy data and units in the attribute?

@dcherian
Copy link
Contributor

dcherian commented Jul 3, 2021

Oh I see. as_numpy is using data.magnitude and dropping the units. I think we should special-case pint and add the units attribute on the DataArray like .pint.dequantify

@dcherian dcherian added the topic-arrays related to flexible array support label Jul 4, 2021
@dcherian
Copy link
Contributor

dcherian commented Jul 4, 2021

I think we should special-case pint and add the units attribute on the DataArray like .pint.dequantify

We would also want this to write pint-backed xarray datasets to netCDF.

@keewis
Copy link
Collaborator Author

keewis commented Jul 4, 2021

that makes sense, but I think long term it might be better to find a way to delegate this to duck array extension libraries (it really should call .pint.dequantify()).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-arrays related to flexible array support
Projects
None yet
Development

No branches or pull requests

2 participants