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
659129613,MDU6SXNzdWU2NTkxMjk2MTM=,4234,Add ability to change underlying array type,1610850,open,0,,,12,2020-07-17T10:37:34Z,2021-04-19T03:21:54Z,,CONTRIBUTOR,,,,"**Is your feature request related to a problem? Please describe.**

In order to use Xarray with alternative array types like `cupy` the user needs to be able to specify the underlying array type without digging into internals.

Right now I'm doing something like this.

```python
import xarray as xr
import cupy as cp

ds = xr.tutorial.load_dataset(""air_temperature"")
ds.air.data = cp.asarray(ds.air.data)
```

However this will become burdensome when there are many data arrays and feels brittle and prone to errors.

As I see it a conversion could instead be done in a couple of places; on load, or as a utility method.

Currently Xarray supports NumPy and Dask array well. Numpy is the defrault and the way you specify whether a Dask array should be used is to give the `chunks` kwargs to an `open_` function or by calling `.chunk()` on a `DataSet` or `DataArray`. 

*Side note: There are a few places where the Dask array API bleeds into Xarray in order to have compatibility, the `chunk` kwarg/method is one, the `.compute()` method is another. I'm hesitant to do this for other array types, however surfacing the `cupy.ndarray.get` method could feel natural for `cupy` users. But for now I think it would be best to take Dask as a special case and try and be generic for everything else.*

**Describe the solution you'd like**

For other array types I would like to propose the addition of an `asarray` kwarg for the `open_` methods and an `.asarray()` method on `DataSet` and `DataArray`. This should take either the array type `cupy.ndarray`, the asarray method `cp.asarray`, or preferably either.

This would result in something like the following.

```python
import xarray as xr
import cupy as cp

ds = xr.open_mfdataset(""/path/to/files/*.nc"", asarray=cp.ndarray)

# or

ds = xr.open_mfdataset(""/path/to/files/*.nc"")
gds = ds.asarray(cp.ndarray)
```

These operations would convert all data arrays to `cupy` arrays. For the case that `ds` is backed by Dask arrays it would use `map_blocks` to cast each block to the appropriate array type.

It is still unclear what to do about index variables, which are currently of type `pandas.Index`. For `cupy` it may be more appropriate to use a `cudf.Index` instead to ensure both are on the GPU. However this would add a dependency on cudf and potentially increase complexity here.

**Describe alternatives you've considered**

Instead of an `asarray` kwarg/method something like `to_cupy`/`from_cupy` could be done. However I feel this makes less sense because the object type is not changing, just that of the underlying data structure.

Another option would be to go more high level with it. For example a `gpu` kwarg and `to_gpu`/`from_gpu` method could be added in the same way. This would abstract things even further and give users a choice about hardware rather than software. This would also be a fine solution but I think it may special case too much and a more generic solution would be better.

**Additional context**
Related to #4212.

I'm keen to start implementing this. But would like some discussion/feedback before I dive in here.
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4234/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,issue
654135405,MDU6SXNzdWU2NTQxMzU0MDU=,4212,Add cupy support,1610850,open,0,,,7,2020-07-09T15:06:37Z,2021-02-08T16:50:38Z,,CONTRIBUTOR,,,,"I'm intending on working on cupy support in xarray along with @quasiben. Thanks for the warm welcome in the xarray dev meeting yesterday!

I'd like to use this issue to track cupy support and discuss certain design decisions. I appreciate there are also issues such as #4208, #3484 and #3232 which are related to cupy support, but maybe this could represent an umbrella issue for cupy specifically.

The main goal here is to improve support for array types other than numpy and dask in general. However, it is likely there will need to be some cupy specific compatibility code in xarray. (@andersy005 raised issues with calling `__array__` on cupy in #3232 for example).

I would love to hear from folks wanting to use cupy with xarray to help build up some use cases for us to develop against. We have some ideas but more are welcome.

My first steps here will be to add some tests which use cupy. These will skip in the main CI but we will also look at running xarray tests on some GPU CI too as we develop. A few limited experiments that I've run seem to work, so I'll start with tests which reproduce those.


","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4212/reactions"", ""total_count"": 11, ""+1"": 11, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,issue