@kmuehlbauer It looks like a bug in the code if indeed tuples are meant to be treated the same as any sequence of data. These lines https://github.com/pydata/xarray/blob/0f4e99d036b0d6d76a3271e6191eacbc9922662f/xarray/core/variable.py#L259-L260 suggest that when a tuple is passed in, it is converted to a 0-dimension array of type object via https://github.com/pydata/xarray/blob/0f4e99d036b0d6d76a3271e6191eacbc9922662f/xarray/core/utils.py#L344-L348

Maybe removing the tuple type check and relying on this line https://github.com/pydata/xarray/blob/0f4e99d036b0d6d76a3271e6191eacbc9922662f/xarray/core/variable.py#L287-L288 is better?

Does this work for an array of quantiles and also does it require the time coordinate to have a single chunk?

@alrho007 I still get this error using version 2022.9.0: ```python In [1]: import pandas as pd [5/182] ...: import xarray as xr ...: import numpy as np ...: ...: da = xr.DataArray( ...: ...: np.random.rand(4, 3), ...: ...: [ ...: ...: ("time", pd.date_range("2000-01-01", periods=4)), ...: ...: ("space", ["IA", "IL", "IN"]), ...: ...: ], ...: ...: ) ...: da.curvefit(coords=["time"], func=lambda x, params: x, method="trf")

TypeError Traceback (most recent call last) Cell In[1], line 18 3 import numpy as np 5 da = xr.DataArray( 6 7 np.random.rand(4, 3), (...) 16 17 ) ---> 18 da.curvefit(coords=["time"], func=lambda x, params: x, method="trf")

TypeError: curvefit() got an unexpected keyword argument 'method'

In [2]: xr.version Out[2]: '2022.9.0' ```

More concise syntax for the same thing

```python import xarray as xr import fsspec

url = 'https://www.ldeo.columbia.edu/~rpa/NOAA_NCDC_ERSST_v3b_SST.nc' with fsspec.open(url) as fobj: ds = xr.open_dataset(fobj) print(ds) ```

When trying this snippet more than once I get a ValueError: I/O operation on closed file. exception. Any Idead why this might be the case?

Based on the docs

The default format is NETCDF4 if you are saving a file to disk and have the netCDF4-python library available. Otherwise, xarray falls back to using scipy to write netCDF files and defaults to the NETCDF3_64BIT format (scipy does not support netCDF4).

It appears scipy engine is safe is one does not need to be bothered with specifying engines.By the way, what are the limitations of the netcdf3 standard vs netcdf4?

I never needed to specify an engine when writing, you only need it when reading the file. I use the engine="scipy" one for reading.

What didn't work: python f = fsspec.filesystem("s3", anon=False) with f.open("some_bucket/some_remote_destination.nc", mode="wb") as ff: xr.open_dataset("some_local_file.nc").to_netcdf(ff) this results in a OSError: [Errno 29] Seek only available in read mode exception

Changing the above to python with fsspec.open("simplecache::s3://some_bucket/some_remote_destination.nc", mode="wb") as ff: xr.open_dataset("some_local_file.nc").to_netcdf(ff) fixed it.

'/silt/usgs/Projects/stellwagen/CF-1.6/BUZZ_BAY/2651-A.cdf') outfile = fsspec.open('simpl

Thanks, this actually worked for me. It seems as though initializing an s3 store using fs = fsspec.S3FileSystem(...) beforehand and using it as a context manager via with fs.open(...) as out: data.to_netcdf(out) caused the failure.

Is there any reliable to use to write a xr.Dataset object as a netcdf file in 2023? I tried using the above approach with fsspec but I keep getting a OSError: [Errno 29] Seek only available in read mode exception.

Any plans to support this?

I experienced something similar, but instead when using a string glob. The encoding["source"] causes a KeyError exception when trying to preprocess the data loaded by open_mfdataset.

This is expected behavior: Xarray variable objects can wrap numpy arrays but generally they don't make copies of the underlying data. So it is possible that two different variables wrap the same numpy array, like in your example and in the example below.

```python data = np.array([1, 2, 3])

v1 = xr.Variable("x", data) v2 = xr.Variable("x", data)

print(v1)

<xarray.Variable (x: 3)>

array([1, 2, 3])

print(v2)

<xarray.Variable (x: 3)>

array([1, 2, 3])

data[0] = 10

print(v1)

<xarray.Variable (x: 3)>

array([10, 2, 3])

print(v2)

<xarray.Variable (x: 3)>

array([10, 2, 3])

```

Dataset.copy(deep=True) makes a deep copy, thus copying the underlying data.

Thanks for the quick response. I wasn't aware of this. I had assumed a new Dataset object will have data that is a copy of the underlying var_map data pass into it. Maybe this could be mentioned as a note in the docstring somewhere?