id,node_id,number,title,user,state,locked,assignee,milestone,comments,created_at,updated_at,closed_at,author_association,active_lock_reason,draft,pull_request,body,reactions,performed_via_github_app,state_reason,repo,type 681864788,MDU6SXNzdWU2ODE4NjQ3ODg=,4353,IndexError when calling load() on netCDF file accessed via opendap,6200806,open,0,,,5,2020-08-19T14:00:25Z,2022-03-21T16:14:11Z,,CONTRIBUTOR,,,," **What happened**: A file that isn't obviously malformed or corrupted that I try to load using opendap generates an esoteric IndexError from dask. **What you expected to happen**: For the file to load successfully. **Minimal Complete Verifiable Example**: ```python url = ""http://iridl.ldeo.columbia.edu/SOURCES/.Models/.NMME/.NCEP-CFSv2/.HINDCAST/.MONTHLY/.tref/dods"" ds_test = xr.open_dataset(url, decode_times=False) print(ds_test) ds_test.load() ``` This yields the following: ```python Dimensions: (L: 10, M: 24, S: 348, X: 360, Y: 181) Coordinates: * M (M) float32 1.0 2.0 3.0 4.0 5.0 6.0 ... 20.0 21.0 22.0 23.0 24.0 * X (X) float32 0.0 1.0 2.0 3.0 4.0 ... 355.0 356.0 357.0 358.0 359.0 * L (L) float32 0.5 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5 * S (S) float32 264.0 265.0 266.0 267.0 ... 608.0 609.0 610.0 611.0 * Y (Y) float32 -90.0 -89.0 -88.0 -87.0 -86.0 ... 87.0 88.0 89.0 90.0 Data variables: tref (S, L, M, Y, X) float32 ... Attributes: Conventions: IRIDL --------------------------------------------------------------------------- IndexError Traceback (most recent call last) ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/xarray/backends/netCDF4_.py in _getitem(self, key) 84 original_array = self.get_array(needs_lock=False) ---> 85 array = getitem(original_array, key) 86 except IndexError: ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/xarray/backends/common.py in robust_getitem(array, key, catch, max_retries, initial_delay) 53 try: ---> 54 return array[key] 55 except catch: netCDF4/_netCDF4.pyx in netCDF4._netCDF4.Variable.__getitem__() netCDF4/_netCDF4.pyx in netCDF4._netCDF4.Variable._get() IndexError: index exceeds dimension bounds During handling of the above exception, another exception occurred: IndexError Traceback (most recent call last) in 2 ds_test = xr.open_dataset(url, decode_times=False) 3 print(ds_test) ----> 4 ds_test.load() ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/xarray/core/dataset.py in load(self, **kwargs) 664 for k, v in self.variables.items(): 665 if k not in lazy_data: --> 666 v.load() 667 668 return self ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/xarray/core/variable.py in load(self, **kwargs) 379 self._data = as_compatible_data(self._data.compute(**kwargs)) 380 elif not hasattr(self._data, ""__array_function__""): --> 381 self._data = np.asarray(self._data) 382 return self 383 ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/numpy/core/_asarray.py in asarray(a, dtype, order) 81 82 """""" ---> 83 return array(a, dtype, copy=False, order=order) 84 85 ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/xarray/core/indexing.py in __array__(self, dtype) 675 676 def __array__(self, dtype=None): --> 677 self._ensure_cached() 678 return np.asarray(self.array, dtype=dtype) 679 ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/xarray/core/indexing.py in _ensure_cached(self) 672 def _ensure_cached(self): 673 if not isinstance(self.array, NumpyIndexingAdapter): --> 674 self.array = NumpyIndexingAdapter(np.asarray(self.array)) 675 676 def __array__(self, dtype=None): ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/numpy/core/_asarray.py in asarray(a, dtype, order) 81 82 """""" ---> 83 return array(a, dtype, copy=False, order=order) 84 85 ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/xarray/core/indexing.py in __array__(self, dtype) 651 652 def __array__(self, dtype=None): --> 653 return np.asarray(self.array, dtype=dtype) 654 655 def __getitem__(self, key): ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/numpy/core/_asarray.py in asarray(a, dtype, order) 81 82 """""" ---> 83 return array(a, dtype, copy=False, order=order) 84 85 ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/xarray/core/indexing.py in __array__(self, dtype) 555 def __array__(self, dtype=None): 556 array = as_indexable(self.array) --> 557 return np.asarray(array[self.key], dtype=None) 558 559 def transpose(self, order): ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/xarray/backends/netCDF4_.py in __getitem__(self, key) 71 def __getitem__(self, key): 72 return indexing.explicit_indexing_adapter( ---> 73 key, self.shape, indexing.IndexingSupport.OUTER, self._getitem 74 ) 75 ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/xarray/core/indexing.py in explicit_indexing_adapter(key, shape, indexing_support, raw_indexing_method) 835 """""" 836 raw_key, numpy_indices = decompose_indexer(key, shape, indexing_support) --> 837 result = raw_indexing_method(raw_key.tuple) 838 if numpy_indices.tuple: 839 # index the loaded np.ndarray ~/miniconda3/envs/ensinoo/lib/python3.7/site-packages/xarray/backends/netCDF4_.py in _getitem(self, key) 93 ""your data into memory first by calling .load()."" 94 ) ---> 95 raise IndexError(msg) 96 return array 97 IndexError: The indexing operation you are attempting to perform is not valid on netCDF4.Variable object. Try loading your data into memory first by calling .load(). ``` **Anything else we need to know?**: There's something specific to this file for sure that's causing this, as I'm able to load (for expediency, a subset of) the file from the xarray [docs section on opendap](https://xarray.pydata.org/en/stable/io.html#opendap) successfully: ```python url = ""http://iridl.ldeo.columbia.edu/SOURCES/.OSU/.PRISM/.monthly/.tdmean/[X+]average/dods"" ds_test = xr.open_dataset(url, decode_times=False) print(ds_test) Dimensions: (T: 1420, Y: 621) Coordinates: * Y (Y) float32 49.916668 49.875 49.833336 ... 24.125 24.083334 * T (T) float32 -779.5 -778.5 -777.5 -776.5 ... 636.5 637.5 638.5 639.5 Data variables: tdmean (T, Y) float64 ... Attributes: Conventions: IRIDL ``` And then calling `ds_test.load()` works just fine. **Environment**:
Output of xr.show_versions() INSTALLED VERSIONS ------------------ commit: None python: 3.7.3 | packaged by conda-forge | (default, Jul 1 2019, 21:52:21) [GCC 7.3.0] python-bits: 64 OS: Linux OS-release: 3.10.0-862.14.4.el7.x86_64 machine: x86_64 processor: x86_64 byteorder: little LC_ALL: None LANG: en_US.UTF-8 LOCALE: en_US.UTF-8 libhdf5: 1.10.6 libnetcdf: 4.7.4 xarray: 0.16.0 pandas: 1.1.0 numpy: 1.19.1 scipy: 1.5.2 netCDF4: 1.5.4 pydap: installed h5netcdf: 0.8.1 h5py: 2.10.0 Nio: None zarr: 2.4.0 cftime: 1.2.1 nc_time_axis: 1.2.0 PseudoNetCDF: None rasterio: None cfgrib: 0.9.8.2 iris: None bottleneck: None dask: 2.20.0 distributed: 2.20.0 matplotlib: 3.2.1 cartopy: 0.18.0 seaborn: 0.10.1 numbagg: None pint: None setuptools: 49.6.0.post20200814 pip: 20.2.2 conda: None pytest: None IPython: 7.8.0 sphinx: None None
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4353/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,issue 589471115,MDExOlB1bGxSZXF1ZXN0Mzk1MDE3NjEz,3906,Fix for stack+groupby+apply w/ non-increasing coord,6200806,closed,0,,,4,2020-03-28T00:15:20Z,2020-03-31T18:29:35Z,2020-03-31T16:10:10Z,CONTRIBUTOR,,0,pydata/xarray/pulls/3906," - [x] Fixes #3287 - [x] Tests added - [x] Passes `isort -rc . && black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API I've added a check within `groupby.__init__` for monotonicity of the coords, which makes my test pass, but it causes three existing tests to fail. Getting the logic right that properly distinguishes among these different cases is escaping me for now, but it does seem like this call to `unique_value_groups` within `groupby.__init__` is where the re-sorting is occurring. Feedback welcome. TIA! ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/3906/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 274392275,MDU6SXNzdWUyNzQzOTIyNzU=,1721,Potential test failures with libnetcdf 4.5.0,6200806,closed,0,,,7,2017-11-16T04:36:55Z,2019-11-17T23:57:54Z,2019-11-17T23:57:54Z,CONTRIBUTOR,,,,"A heads up: @spencerkclark unearthed problems with libnetcdf 4.5.0 that will cause xarray test failures. See https://github.com/Unidata/netcdf4-python/issues/742 and link therein for more info. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1721/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 327089588,MDU6SXNzdWUzMjcwODk1ODg=,2191,Adding resample functionality to CFTimeIndex,6200806,closed,0,,,22,2018-05-28T18:01:57Z,2019-02-19T20:22:28Z,2019-02-03T12:16:21Z,CONTRIBUTOR,,,,"Now that CFTimeIndex has been implemented (#1252), one thing that remains to implement is resampling. @shoyer provided a sketch of how to implement it: https://github.com/pydata/xarray/pull/1252#issuecomment-380593243. In the interim, @spencerkclark provided a sketch of a workaround for some use-cases using groupby: https://github.com/pydata/xarray/issues/1270#issuecomment-390973986. I thought it would be useful to have a new Issue specifically on this topic from which future conversation can continue. @shoyer, does that sketch you provided still seem like a good starting point?","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/2191/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 246612712,MDU6SXNzdWUyNDY2MTI3MTI=,1497,Best way to perform DataArray.mean while retaining coords defined in the dimension being averaged,6200806,closed,0,,,2,2017-07-30T22:17:48Z,2019-01-16T03:36:16Z,2019-01-16T03:36:15Z,CONTRIBUTOR,,,,"`DataArray.mean` applied along a particular dimension causes coordinates that are defined in that dimension to be dropped: ```python In [39]: x, y = range(2), range(3) In [40]: arr = xr.DataArray(np.random.random((2,3)), dims=['x', 'y'], coords=dict(x=x, y=y)) In [41]: coord = xr.DataArray(np.random.random((2,3)), dims=['x', 'y'], coords=dict(x=x, y=y)) In [42]: arr = arr.assign_coords(z=coord) In [43]: arr Out[43]: array([[ 0.132368, 0.746242, 0.48783 ], [ 0.12747 , 0.751283, 0.033713]]) Coordinates: * y (y) int64 0 1 2 * x (x) int64 0 1 z (x, y) float64 0.993 0.1031 0.1808 0.2769 0.7237 0.2891 In [44]: arr.mean('x') Out[44]: array([ 0.129919, 0.748763, 0.260772]) Coordinates: * y (y) int64 0 1 2 ``` We have a use case where we'd like to preserve the coordinates. @spencerkclark came up with the following workaround, which entails converting to a dataset, promoting the coord to a variable, performing the mean, and demoting the original coord back from a variable to a coord: ```python def coord_preserving_mean(arr, *args, **kwargs): name = arr.name ds = arr.reset_coords() names = set(arr.coords) - set(arr.dims) ds = ds.mean(*args, **kwargs) return ds.set_coords(names)[name] ``` This works fine, but I just feel like maybe there's an easier way to do this that we're missing. Any ideas? Thanks in advance. xref https://github.com/spencerahill/aospy/issues/194","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1497/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 187591179,MDU6SXNzdWUxODc1OTExNzk=,1084,Towards a (temporary?) workaround for datetime issues at the xarray-level,6200806,closed,0,,,29,2016-11-06T21:40:36Z,2018-05-13T05:19:10Z,2018-05-13T05:19:10Z,CONTRIBUTOR,,,,"Re: #789. The consensus is that upstream fixes in Pandas are not coming anytime soon, and there is an acute need amongst many xarray users for a workaround in the meantime. There are two separate issues: (1) date-range limitations due to nanosecond precision, and (2) support for non-standard calendars. @shoyer, @jhamman , @spencerkclark, @darothen, and I briefly discussed offline a potential workaround that I am (poorly) summarizing here, with hope that others will correct/extend my snippet. The idea is to extend either PeriodIndex or (more involved but potentially more robust) Int64Index, either through subclassing or composition, to implement all of the desired functionality: slicing, resampling, groupby, and serialization. For reference, @spencerkclark nicely summarized the limitations of PeriodIndex and the netCDF4.datetime objects, which are often used as workarounds currently: https://github.com/spencerahill/aospy/issues/98#issuecomment-256043833","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1084/reactions"", ""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 205248365,MDU6SXNzdWUyMDUyNDgzNjU=,1248,Clarifying sel/drop behavior for dims with vs. without coords,6200806,closed,0,,,2,2017-02-03T19:31:51Z,2017-02-05T23:09:39Z,2017-02-05T23:09:39Z,CONTRIBUTOR,,,,"Just want to clarify if below is the intended behavior re: selecting on dims w/ vs. w/out coords. I'm on v0.9.1: In short, selecting a single value of a dimension causes the dimension to be dropped only if it doesn't have a coordinate. Is that intentional? It's counter-intuitive to me but not a huge deal. Simple example: ```python In [156]: ds=xr.DataArray([1,2], name='test').to_dataset().assign_coords(bounds=[0,1]) In [161]: ds Out[161]: Dimensions: (bounds: 2, dim_0: 2) Coordinates: * bounds (bounds) int64 0 1 Dimensions without coordinates: dim_0 Data variables: test (dim_0) int64 1 2 In [163]: ds.isel(bounds=0).drop('bounds') Out[163]: Dimensions: (dim_0: 2) Dimensions without coordinates: dim_0 Data variables: test (dim_0) int64 1 2 In [164]: ds.isel(dim_0=0).drop('dim_0') --------------------------------------------------------------------------- ValueError Traceback (most recent call last) in () ----> 1 ds.isel(dim_0=0).drop('dim_0') /Users/shill/Dropbox/miniconda3/lib/python3.5/site-packages/xarray/core/dataset.py in drop(self, labels, dim) 1888 labels = [labels] 1889 if dim is None: -> 1890 return self._drop_vars(labels) 1891 else: 1892 try: /Users/shill/Dropbox/miniconda3/lib/python3.5/site-packages/xarray/core/dataset.py in _drop_vars(self, names) 1899 1900 def _drop_vars(self, names): -> 1901 self._assert_all_in_dataset(names) 1902 drop = set(names) 1903 variables = OrderedDict((k, v) for k, v in iteritems(self._variables) /Users/shill/Dropbox/miniconda3/lib/python3.5/site-packages/xarray/core/dataset.py in _assert_all_in_dataset(self, names, virtual_okay) 1867 bad_names -= self.virtual_variables 1868 if bad_names: -> 1869 raise ValueError('One or more of the specified variables ' 1870 'cannot be found in this dataset') 1871 ValueError: One or more of the specified variables cannot be found in this dataset ``` cc @spencerkclark xref https://github.com/spencerahill/aospy/issues/137#issuecomment-277326319","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1248/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 201441553,MDU6SXNzdWUyMDE0NDE1NTM=,1216,Why ufuncs module not included in top-level namespace,6200806,closed,0,,,2,2017-01-18T00:00:08Z,2017-01-19T05:59:26Z,2017-01-19T05:59:26Z,CONTRIBUTOR,,,,"I.e. there is no `from . import ufuncs` in `__init__.py`. Is this deliberate? If it was included, one could access them after `import xarray as xr` via e.g. `xr.ufuncs.sin` rather than having to do separately e.g. `from xarray.ufuncs import sin`. Sorry if I'm missing something obvious here.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1216/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 201770526,MDExOlB1bGxSZXF1ZXN0MTAyMjA1NDM3,1219,ENH import ufuncs module in toplevel namespace,6200806,closed,0,,,1,2017-01-19T05:51:02Z,2017-01-19T05:59:26Z,2017-01-19T05:59:26Z,CONTRIBUTOR,,0,pydata/xarray/pulls/1219," - [x] closes #1216 - [ ] tests added / passed - [ ] passes ``git diff upstream/master | flake8 --diff`` - [ ] whatsnew entry Let me know if you want tests and/or what's new; wasn't sure since this is so small.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1219/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 132536288,MDU6SXNzdWUxMzI1MzYyODg=,754,Expose testing methods,6200806,closed,0,,,6,2016-02-09T21:16:25Z,2016-12-23T18:48:12Z,2016-12-23T18:48:12Z,CONTRIBUTOR,,,,"Similar to numpy's [numpy.testing](http://docs.scipy.org/doc/numpy/reference/routines.testing.html) module, I would find it useful for xarray to expose some of its testing methods, particularly those in its base [TestCase](https://github.com/pydata/xarray/blob/master/xarray/test/__init__.py#L129). I imagine other folks whose packages and/or modules derive heavily from xarray would find this useful too. For now I am just copy-pasting xarray's code for these methods into my testing modules. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/754/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 128735308,MDU6SXNzdWUxMjg3MzUzMDg=,725,Replacing coord with coord of same name results in NaNs,6200806,closed,0,,,2,2016-01-26T06:12:42Z,2016-02-16T05:19:07Z,2016-02-16T05:19:07Z,CONTRIBUTOR,,,,"I think this is another unintended consequence of #648. Consider the following case: ``` python In [20]: arr = xr.DataArray(range(3), dims=['abc']) In [21]: new_coord = xr.DataArray([1,2,3], dims=['abc'], coords=[[1,2,3]]) In [22]: arr['abc'] = new_coord In [23]: arr Out[24]: array([0, 1, 2]) Coordinates: * abc (abc) float64 nan 1.0 2.0 ``` Note the `nan`. Before #648, this worked, in that `arr`'s coordinates would consist of `new_coord`. The use case: we have some data defined on the edges of pressure levels in an atmospheric model, and other data defined at the center of the pressure levels. In order to perform calculations involving both kinds of data, we average the edge-defined data (i.e. 0.5*(value at top edge + value at bottom edge)) to get the value at the level centers. But the resulting DataArray still has as its coord (from xarray's perspective, that is) the level edges, and so we replace that coord with the DataArray of the level centers. A workaround would be `arr['abc'].values = new_coord.values`, but then any other metadata associated with the original coord is retained, which is not good. Somewhat involved and not sure I described clearly, so let me know if clarification needed. Also I vaguely suspect there's a cleaner way of doing this in the first place. Thanks! ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/725/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 130064443,MDExOlB1bGxSZXF1ZXN0NTc3NTczMzg=,736,Accept rename to same name,6200806,closed,0,,,4,2016-01-31T02:17:01Z,2016-02-02T03:44:33Z,2016-02-02T01:33:03Z,CONTRIBUTOR,,0,pydata/xarray/pulls/736,"Closes #724 ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/736/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 128718628,MDU6SXNzdWUxMjg3MTg2Mjg=,724,Behavior of ds.rename when old and new name are the same,6200806,closed,0,,,2,2016-01-26T04:12:24Z,2016-02-02T01:33:03Z,2016-02-02T01:33:03Z,CONTRIBUTOR,,,,"Before #648, passing `Dataset.rename` a `name_dict` whose keys and values were identical did not raise an exception. Now, however, it raises a ValueError: ``` python arr = xr.DataArray(range(2), name='arrname') ds = arr.to_dataset() ds.rename({'dim_0':'dim_0'}) --------------------------------------------------------------------------- ValueError Traceback (most recent call last) in () ----> 1 ds.rename({'dim_0':'dim_0'}) /Users/spencerahill/anaconda/lib/python2.7/site-packages/xarray/core/dataset.pyc in rename(self, name_dict, inplace) 1245 ""variable in this dataset"" % k) 1246 if v in self: -> 1247 raise ValueError('the new name %r already exists' % v) 1248 1249 variables = OrderedDict() ValueError: the new name 'dim_0' already exists ``` This is easy enough to handle with a try/except clause in my own code, but it would be nice (for me at least) for `rename` to not raise anything for these cases. Since the result is simply the original Dataset unchanged, this could be implemented by replacing line 1246 with `if v in self and k != v:` The use case is that we have data coming from multiple sources, often with differing internal names for coordinates and variables, and we're programmatically forcing them to have consistent names via `rename`. Sometimes, a piece of data already has the name that we are after, hence the non-rename `rename`. Thanks! ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/724/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 112430028,MDU6SXNzdWUxMTI0MzAwMjg=,634,Unexpected behavior by diff when applied to coordinate DataArray,6200806,closed,0,,,3,2015-10-20T18:26:58Z,2015-12-04T20:40:31Z,2015-12-04T20:40:31Z,CONTRIBUTOR,,,,"`DataArray.diff`, when applied to a coordinate, just returns the coordinate itself with one index truncated. Consider the following: ``` In [5]: arr = xray.DataArray(range(0, 20, 2), dims=['lon'], coords=[range(10)]) In [6]: arr.diff('lon') array([2, 2, 2, 2, 2, 2, 2, 2, 2]) Coordinates: * lon (lon) int64 1 2 3 4 5 6 7 8 9 In [7]: arr['lon'].diff('lon') array([1, 2, 3, 4, 5, 6, 7, 8, 9]) Coordinates: * lon (lon) int64 1 2 3 4 5 6 7 8 9 ``` Is this the intended behavior? The documentation doesn't mention anything about this, and its counter-intuitive, so I'm wondering if its a bug instead. Even if it is intended, I personally would like to be able to use a coordinate array's diff on itself to get its spacing, e.g. for use as the denominator in finite differencing approximations to derivatives. Thanks! ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/634/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 118910006,MDU6SXNzdWUxMTg5MTAwMDY=,667,Problems when array of coordinate bounds is 2D,6200806,closed,0,,,4,2015-11-25T19:46:12Z,2015-11-25T20:46:14Z,2015-11-25T20:45:42Z,CONTRIBUTOR,,,,"Most of the netCDF data I work with stores, in addition to the coordinates themselves, the bounds of each coordinate value. Often these bounds are stored as arrays with shape Nx2, where N is the number of points for that coordinate. For example: ``` $ ncdump -c /archive/Spencer.Hill/am3/am3clim_hurrell/gfdl.ncrc2-intel-prod-openmp/pp/atmos/ts/monthly/1yr/atmos.201001-201012.t_surf.nc netcdf atmos.201001-201012.t_surf { dimensions: time = UNLIMITED ; // (12 currently) lat = 90 ; bnds = 2 ; lon = 144 ; variables: double average_DT(time) ; average_DT:long_name = ""Length of average period"" ; average_DT:units = ""days"" ; average_DT:missing_value = 1.e+20 ; average_DT:_FillValue = 1.e+20 ; double average_T1(time) ; average_T1:long_name = ""Start time for average period"" ; average_T1:units = ""days since 1980-01-01 00:00:00"" ; average_T1:missing_value = 1.e+20 ; average_T1:_FillValue = 1.e+20 ; double average_T2(time) ; average_T2:long_name = ""End time for average period"" ; average_T2:units = ""days since 1980-01-01 00:00:00"" ; average_T2:missing_value = 1.e+20 ; average_T2:_FillValue = 1.e+20 ; double lat(lat) ; lat:long_name = ""latitude"" ; lat:units = ""degrees_N"" ; lat:cartesian_axis = ""Y"" ; lat:bounds = ""lat_bnds"" ; double lat_bnds(lat, bnds) ; lat_bnds:long_name = ""latitude bounds"" ; lat_bnds:units = ""degrees_N"" ; lat_bnds:cartesian_axis = ""Y"" ; double lon(lon) ; lon:long_name = ""longitude"" ; lon:units = ""degrees_E"" ; lon:cartesian_axis = ""X"" ; lon:bounds = ""lon_bnds"" ; double lon_bnds(lon, bnds) ; lon_bnds:long_name = ""longitude bounds"" ; lon_bnds:units = ""degrees_E"" ; lon_bnds:cartesian_axis = ""X"" ; float t_surf(time, lat, lon) ; t_surf:long_name = ""surface temperature"" ; t_surf:units = ""deg_k"" ; t_surf:valid_range = 100.f, 400.f ; t_surf:missing_value = 1.e+20f ; t_surf:_FillValue = 1.e+20f ; t_surf:cell_methods = ""time: mean"" ; t_surf:time_avg_info = ""average_T1,average_T2,average_DT"" ; t_surf:interp_method = ""conserve_order2"" ; double time(time) ; time:long_name = ""time"" ; time:units = ""days since 1980-01-01 00:00:00"" ; time:cartesian_axis = ""T"" ; time:calendar_type = ""JULIAN"" ; time:calendar = ""JULIAN"" ; time:bounds = ""time_bounds"" ; double time_bounds(time, bnds) ; time_bounds:long_name = ""time axis boundaries"" ; time_bounds:units = ""days"" ; time_bounds:missing_value = 1.e+20 ; time_bounds:_FillValue = 1.e+20 ; // global attributes: :filename = ""atmos.201001-201012.t_surf.nc"" ; :title = ""am3clim_hurrell"" ; :grid_type = ""mosaic"" ; :grid_tile = ""1"" ; :comment = ""pressure level interpolator, version 3.0, precision=double"" ; :history = ""fregrid --input_mosaic atmos_mosaic.nc --input_file 20100101.atmos_month --interp_method conserve_order2 --remap_file .fregrid_remap_file_144_by_90 --nlon 144 --nlat 90 --scalar_field (**please see the field list in this file**)"" ; :code_version = ""$Name: fre-nctools-bronx-7 $"" ; data: lat = -89, -87, -85, -83, -81, -79, -77, -75, -73, -71, -69, -67, -65, -63, -61, -59, -57, -55, -53, -51, -49, -47, -45, -43, -41, -39, -37, -35, -33, -31, -29, -27, -25, -23, -21, -19, -17, -15, -13, -11, -9, -7, -5, -3, -1, 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31, 33, 35, 37, 39, 41, 43, 45, 47, 49, 51, 53, 55, 57, 59, 61, 63, 65, 67, 69, 71, 73, 75, 77, 79, 81, 83, 85, 87, 89 ; lon = 1.25, 3.75, 6.25, 8.75, 11.25, 13.75, 16.25, 18.75, 21.25, 23.75, 26.25, 28.75, 31.25, 33.75, 36.25, 38.75, 41.25, 43.75, 46.25, 48.75, 51.25, 53.75, 56.25, 58.75, 61.25, 63.75, 66.25, 68.75, 71.25, 73.75, 76.25, 78.75, 81.25, 83.75, 86.25, 88.75, 91.25, 93.75, 96.25, 98.75, 101.25, 103.75, 106.25, 108.75, 111.25, 113.75, 116.25, 118.75, 121.25, 123.75, 126.25, 128.75, 131.25, 133.75, 136.25, 138.75, 141.25, 143.75, 146.25, 148.75, 151.25, 153.75, 156.25, 158.75, 161.25, 163.75, 166.25, 168.75, 171.25, 173.75, 176.25, 178.75, 181.25, 183.75, 186.25, 188.75, 191.25, 193.75, 196.25, 198.75, 201.25, 203.75, 206.25, 208.75, 211.25, 213.75, 216.25, 218.75, 221.25, 223.75, 226.25, 228.75, 231.25, 233.75, 236.25, 238.75, 241.25, 243.75, 246.25, 248.75, 251.25, 253.75, 256.25, 258.75, 261.25, 263.75, 266.25, 268.75, 271.25, 273.75, 276.25, 278.75, 281.25, 283.75, 286.25, 288.75, 291.25, 293.75, 296.25, 298.75, 301.25, 303.75, 306.25, 308.75, 311.25, 313.75, 316.25, 318.75, 321.25, 323.75, 326.25, 328.75, 331.25, 333.75, 336.25, 338.75, 341.25, 343.75, 346.25, 348.75, 351.25, 353.75, 356.25, 358.75 ; time = 10973.5, 11003, 11032.5, 11063, 11093.5, 11124, 11154.5, 11185.5, 11216, 11246.5, 11277, 11307.5 ; } ``` These 2-D bounding arrays lead to the ""Buffer has wrong number of dimensions"" error in #665. In the case of #665, only the time coordinate has this 2-D bounds array; here other coordinates (namely lat and lon) have it as well. Conceptually, these bound arrays represent coordinates, but when read in as a `Dataset`, they become variables, not coordinates. Perhaps this is part of the problem? ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/667/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue