issue_comments

Sorry, @spencerkclark is right, the ValueError issue we had was also due to the 2D time bounds array only. For example: (the netCDF file used below is also at ftp://ftp.gfdl.noaa.gov/pub/s1h/atmos.201001-201012.t_surf.nc)

``` python In [1]: ds = xray.open_dataset('/archive/Spencer.Hill/am3/am3clim_hurrell/gfdl.ncrc2-intel-prod-openmp/pp/atmos/ts/monthly/1yr/atmos.201001-201012.t_surf.nc')

In [2]: print(ds)

ValueError Traceback (most recent call last) <ipython-input-2-4d24098ddece> in <module>() ----> 1 print(ds)

/home/s1h/anaconda/lib/python2.7/site-packages/xray/core/dataset.pyc in repr(self) 885 886 def repr(self): --> 887 return formatting.dataset_repr(self) 888 889 @property

...

/home/s1h/anaconda/lib/python2.7/site-packages/pandas/tseries/timedeltas.pyc in _convert_listlike(arg, box, unit, name) 47 value = arg.astype('timedelta64[{0}]'.format(unit)).astype('timedelta64[ns]', copy=False) 48 else: ---> 49 value = tslib.array_to_timedelta64(_ensure_object(arg), unit=unit, errors=errors) 50 value = value.astype('timedelta64[ns]', copy=False) 51

pandas/tslib.pyx in pandas.tslib.array_to_timedelta64 (pandas/tslib.c:47046)()

ValueError: Buffer has wrong number of dimensions (expected 1, got 2)

In [3]: ds2 = ds.drop('time_bounds')

In [4]: print(ds2) <xray.Dataset> Dimensions: (bnds: 2, lat: 90, lon: 144, time: 12) Coordinates: * lat (lat) float64 -89.0 -87.0 -85.0 -83.0 -81.0 -79.0 -77.0 ... * lon (lon) float64 1.25 3.75 6.25 8.75 11.25 13.75 16.25 18.75 ... * time (time) datetime64[ns] 2010-01-16T12:00:00 2010-02-15 ... * bnds (bnds) int64 0 1 Data variables: average_DT (time) timedelta64[ns] 31 days 28 days 31 days 30 days ... average_T1 (time) datetime64[ns] 2010-01-01 2010-02-01 2010-03-01 ... average_T2 (time) datetime64[ns] 2010-02-01 2010-03-01 2010-04-01 ... lat_bnds (lat, bnds) float64 -90.0 -88.0 -88.0 -86.0 -86.0 -84.0 ... lon_bnds (lon, bnds) float64 0.0 2.5 2.5 5.0 5.0 7.5 7.5 10.0 10.0 ... t_surf (time, lat, lon) float64 245.9 245.9 245.8 245.7 245.7 245.6 ... ... ```

The errors I was thinking of relating to these lat- and lon-bounds were ultimately due to errors in my own code...my mistakes appear to be the unifying theme here! Sorry for the confusion.

I think the reason one gets the "Buffer has wrong number of dimensions" error here is still because of the presence of the time_bounds variable. If we drop time_bounds upon reading the file in, I think things work OK.

In [2]: xray.open_dataset('/archive/Spencer.Hill/am3/am3clim_hurrell/gfdl.ncrc2-intel-prod-openmp/pp/atmos/ts/monthly/1yr/atmos.201001-201012.t_surf.nc', drop_variables='time_bounds') Out[2]: <xray.Dataset> Dimensions: (bnds: 2, lat: 90, lon: 144, time: 12) Coordinates: * lat (lat) float64 -89.0 -87.0 -85.0 -83.0 -81.0 -79.0 -77.0 ... * lon (lon) float64 1.25 3.75 6.25 8.75 11.25 13.75 16.25 18.75 ... * time (time) datetime64[ns] 2010-01-16T12:00:00 2010-02-15 ... * bnds (bnds) int64 0 1 Data variables: average_DT (time) timedelta64[ns] 31 days 28 days 31 days 30 days ... average_T1 (time) datetime64[ns] 2010-01-01 2010-02-01 2010-03-01 ... average_T2 (time) datetime64[ns] 2010-02-01 2010-03-01 2010-04-01 ... lat_bnds (lat, bnds) float64 -90.0 -88.0 -88.0 -86.0 -86.0 -84.0 ... lon_bnds (lon, bnds) float64 0.0 2.5 2.5 5.0 5.0 7.5 7.5 10.0 10.0 ... t_surf (time, lat, lon) float64 245.9 245.9 245.8 245.7 245.7 245.6 ... 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 $

I think ultimately, these are going to end up as Variables, not Coordinates. The CF convention refers to them as "Boundary Variables", and although they are essentially metadata for the Coordinates, I don't think that sort of complexity makes sense for xray right now.

It shouldn't be too hard to fix the 2-d bounds problem though.

Is it possible for you to share a netcdf file that reproduces the issue? Based on the ncdump result, I think xray should handle it fine...