(BTW if this gets merged feel free to squash my commits, I'm just keeping the history in case someone wants a previous version)

Changed to :ref:`groupby` Users guide explanation of how to group and bin data.

@keewis That comes out as

which is fine. I may change the description to be less repetitive with the title of the user-guide page if that is the preferred format for this.

That renders OK

However, I find it kind of hard to tell that is leading to the user docs. Trying

rst :ref:`Users guide: group and bin data <groupby>`

I can. Honestly I wasn't sure :ref: would work there? But I can try it.

Rendered docs: https://xray--7555.org.readthedocs.build/en/7555/generated/xarray.Dataset.groupby.html

See also https://github.com/pydata/xarray/issues/1435 and https://github.com/matplotlib/matplotlib/issues/22105

It could, after the units are set to dates, but all it would do is pass to datetime64, so the recommendation would be that users do that explicitly.

If the units are not set to dates (ie. this is the first call on the axis) then strings are interpreted as categories in Matplotlib, and all sorts of hilarity ensues if the strings are all dates....

The point of my original concern was the case where the automatic import should not nbe happening. I think that the new version of my test should work with the revert of #6109.

I agree that the import logic is a bit of a pain. OTOH I'm not sure how to make it better.

Sure see https://github.com/pydata/xarray/pull/6128

BTW, maybe you could/should add a test for this behaviour?

I checked the code from above, and it has the Matplotlib unit handlers rather than the pandas

As I'm away from a computer for a few days so can't double check, but I did bisect the problem to the pr that was reverted.

However you could keep this open for a more fulsome discussion of date handling and whether xarray wants to use the pandas or matplotlib converters. I would actually be pretty happy if pandas also just used matplotlibs converters - we already jump through some hoops to make data frames work.

Hi @Illviljan that is correct. However after https://github.com/pydata/xarray/pull/5794 xarray is more aggressively making the pandas choice for the user.

I'll play with it a bit to see if just removing your explicit registration fixes the problem. However changing the datetime converter would be a breaking change (to your plotting) that I'm not sure you want.

This is a tricky problem that I'm not sure matplotlib has handled properly (full disclosure, I'm on the mpl dev team and usually handle datetime issues, though I didn't design our units registry). Having a registry that users can change is very flexible. However when downstream libraries like xarray or pandas affect user plotting just by importing the package, it leads to considerable confusion as users don't necessarily know this has happened or how to get back to the Matplotlib default. Particularly if they are not using the package's plotting utilities, but just the other features and/or data types (for instance I love xarray and use it all the time in my data analysis, but I rarely use the plotting convenience functions)

Just to explain the issue a bit: pcolormesh(x, y, Z, shading='flat') was the default. If shape(Z) used to be (len(y), len(x)) matplotlib would drop, without warning, the last row and column of Z so that y and x were one larger than Z.

The new default is 'auto' where in the case above it uses shading='nearest' to create new x and y co-ordinates with the dumbest algorithm possible of placing them in the midpoints, and adding two new points on the outside. So rather than drop data from Z, we add to the x and y co-ordinates.

That is usually fine, except the midpoint between 0 and 360 is 180, and we get a weird wrap. Cartopy (xarray) accounted for this with the old shading by adding a NaN. I've not followed what they are doing now.

To get the old behaviour you simply need to do pcolormesh(x, y, Z[:-1, :-1], shading='flat') or make x and y one larger than Z in each dimension and specify the the corners of the quadrilaterals.

Sorry this is a pain, but the old behaviour of silently dropping data, while having a long lineage going back to Matlab, was deemed unacceptable. However, if this continues to be a nuisance to folks, I'm sure matplotlib would consider a new shading argument, something like 'flat-drop', or somesuch that would do the data dropping for you.

I think doing both is always appreciated: short "how to" with a common pattern or two and then a "see also".

Lock false sometimes throws hd5 error. No clear solution.

I haven't seen that yet, but I'd still far prefer an occasional error to a hung process.

I have the same behaviour with MacOS (10.15). xarray=0.16.1, dask=2.30.0, netcdf4=1.5.4. Sometimes saves, sometimes doesn't. lock=False seems to work.

As pointed out on the matplotlib gitter:

If you run

```python import numpy as np import xarray as xr import matplotlib.pyplot as plt

for i in range(200): xr.DataArray(np.array([[0, 0], [0, 0]], dtype=np.uint8)).plot.pcolormesh() at step 165 you will get: File "/Users/jklymak/matplotlib/lib/matplotlib/figure.py", line 236, in update raise ValueError('left cannot be >= right') ValueError: left cannot be >= right ``` Why? Because you have made a plot that if it displays looks like:

Are you sure your test isn't doing something similar? At some point there just isn't room for more colorbars! Adding a plt.clf() can cure the problem.

Its also is possible you are hitting floating point overflows with your test. At some point Matplotlib needs to be able to manipulate the data that comes in, and if you operate near the maximum number your data type can handle, you'll have problems. Just like you would if you just did

python a = 2*xr.DataArray(np.array([[0, 0], [0, 1e308]])) you will get: /Users/jklymak/anaconda3/envs/matplotlibdev/lib/python3.6/site-packages/xarray/core/variable.py:1165: RuntimeWarning: overflow encountered in multiply So maybe your hypothesis tester could be constrained to stay away from floating point overflows?

Matplotlib indeed has flaws and quirks, but if you are finding bugs it would be good to isolate them.

I had this error in 0.9.5. 0.10.0 definitely fixes it. Thanks!

OK, great! I figured it out. Something like the below works; @rabernat had pointed to a similar solution, but I didn't quite understand what dask.array.map_blocks was doing.

``` import xmitgcm import xarray as xr data = xmitgcm.open_mdsdataset(dirname='./',prefix={'T'},iters=12600,read_grid=True,geometry='cartesian',endian='<', chunks={'Z':1,'time':1})

def interpolateAtDepth(T,x0,y0,x,y): import scipy.interpolate if np.shape(T)[-1]>1: xout=np.zeros((1,1,ny,nx))
fit=scipy.interpolate.RectBivariateSpline(x0,y0,T[0,0,:,:].T) xout = fit(x,y).T else: xout=np.ones((1,1,1,1)) return xout

x, y, nx, ny are determined elsewhere, but set the new grid...

tm = data['T'].data.map_blocks(interpolateAtDepth,data['XC'].values,data['YC'].values,x,y,chunks=(1,1,ny,nx)) ```

Given the dask integration, being able to initialize DataArrays that are chunked would be very helpful. I want to map from an old x-y-z grid to a new one, and theoretically it could be too memory intensive to keep the new grid in memory, so it would be nice to initialize an empty one and then fill it.