concat automagically outer-joins coordinates

I would like to concatenate two netCDF files that have float64 coordinate variables. I thought the coordinate values were the same, but in fact they differ by something in the order of 1e-14.

Using open_mfdataset or concat to merge the datasets, I get a completely different output shape than the two input files have.

This is because concat is somewhere performing an outer join on the coordinates. Now I am wondering where else in my workflows this might happen without my notice…

It would be awesome if there was an option to change this behaviour on concat, open_mfdataset, and auto_combine. I would actually rather make these functions fail if any dimension other than the concatenation dimension differs.

Note: This could also be a special case, because

>>> (ds1.lon == ds2.lon).all()
<xarray.DataArray 'lon' ()>
array(True, dtype=bool)

while

>>> (ds1.lon.values == ds2.lon.values).all()
False

Maybe an interface change could be considered together with that discussed in #1340?

[shoyer]

I think the right solution here is to relabel the coordinates on each of the datasets that you are concatenating. The alternative behavior here is xarray raising an error in the case of conflicting coordinate labels.

[darothen]

@wqshen, a workaround until a more complete modification to align is available would be to explicitly copy/set the coordinate values on your arrays before using xr.concat(). Alternatively, if it’s as simple as stacking along a new tailing axis, you could stack via dask/numpy and then construct a new DataArray passing the coordinates explicitly.