issue_comments

@shoyer OK, I see that keeping the core dims does make sense in some cases. I am fine with doing something like

xr.apply_ufunc(apply_A, dr, input_core_dims=[['x']], output_core_dims=[['x_new']]).rename({'x_new': 'x'})

Xarray should certainly be raising an informative error message earlier rather than only when writing these files to disk. It should not be possible to create coordinates with inconsistent dimension sizes.

I would hesitate to drop coordinates associated with core dimensions that appear in both the input and output, because there are definitely functions that do preserve dimension identity, e.g., for a ufunc that normalizes across a dimension, e.g., centered_in_time = xr.apply_ufunc(lambda x: x - x.mean(axis=-1), ds, input_core_dims=[['time']], output_core_dims=[['time']]).

I think your "Case 2: Specifying a new output dimension name" should be the recommended pattern here. This already removes all coordinates associated with the input core dimensions (since they are not specified on outputs), so you can simply rename the output dimensions to achieve your desired result, e.g., dr_out2.rename({'x_new': 'x'}).

@jhamman @rabernat Thanks for the help!

Raising an error when encountering this issue and adding keep_core_coords=False to optionally drop the coordinate would be a good solution for me.

But is there any case that we do want to keep the core coordinate? Since input_core_dims means "dimensions that should not be broadcast", I suppose that the output DataArray has no way to inherit these non-broadcasting dimensions? Should the core coordinate just be dropped by default?

Another more basic issue: Users are allowed the mess-up the coordinate dimension of an existing DataArray. Is this an expected behavior?

``` In [1]: import xarray as xr

In [2]: xr.DataArray([0, 1, 2, 3], dims='x', coords={'x':[0, 1]}) # this is not allowed (...) ValueError: conflicting sizes for dimension 'x': length 4 on the data but length 2 on coordinate 'x'

In [3]: dr = xr.DataArray([0, 1, 2, 3], dims='x', coords={'x':[0, 1, 2, 3]})

In [4]: dr['x'] = [0, 1] # but you can mess-up the coordinate dimension afterwards

In [5]: dr Out[5]: <xarray.DataArray (x: 4)> array([0, 1, 2, 3]) Coordinates: * x (x) int64 0 1

In [6]: dr.to_netcdf('wrong_coordinate.nc') (...) ValueError: conflicting sizes for dimension 'x': length 4 on 'xarray_dataarray_variable' and length 2 on 'x' ```

👍 I agree we should try to fix these issues upstream (in xarray) rather than compelling @JiaweiZhuang to work around them in xESMF. Thanks for the bug report.

@JiaweiZhuang - thanks for the report. Based on your example, I think we should be raising an error when constructing the output object. That won't help your use case which we do want to support so I think another option to drop the coordinate may also be in order.