Ping @leofang in case you have thoughts?

I think ideally you could pass a DataArray to something that takes GPU arrays (like Numba kernels). If that doesn't make sense then perhaps passing the DataArray.data would be simpler. @rabernat made some interesting points on Twitter around not doing this though.

I can be there! @jakirkham and @pentschev are also Dask maintainers so there should be good representation.

Happy to attend. It might also be useful to have @pentschev involved too.

Thanks for writing that up @dcherian. Sounds good to me!

Thanks @keewis. I did consider that but I assumed that kind of thing wouldn't be encouraged. Happy to go down that path, but I wonder if life would be easier if there were an extension API for this purpose.

I was thinking of something along these lines which would help keep things in check.

```python @xr.register_dataarray_as_method("cupy") class CupyAsMethod: def to_cupy(self): """Convert all data arrays to cupy."""

    for var in self.data_vars: 
        self.data_vars[var].data = cp.asarray(self.data_vars[var].data)

    return self

def to_numpy(self):
    """Convert all data arrays to numpy."""

    for var in self.data_vars: 
        self.data_vars[var].data = self.data_vars[var].data.get()

    return self

```

There would need to be some logic around dispatching as_numpy to CupyAsMethod.as_numpy, but only if the underlying data is cupy.

Perhaps some is_numpy, is_cupy boolean attributes would be useful?

I could go as you suggest and use the current accessor tooling to test this functionality out. Then upstream it into something more maintainable if it works out ok?

Given the current guidance in #4212 is to aim for cupy to mostly be handled via accessors I wonder if xarray could be extended a little further to allow as_ methods to be registered in the same way as accessors.

Currently with the accessor model a user would need to do something like ds.cupy.as_cupy and ds.cupy.as_numpy. When casting a DataSet or DataArray to use cupy under the hood I expect folks would look for a top level as_cupy method. And once it has been cast it would need a cupy specific as_numpy method to be able to cast back.

Enabling accessors to register as_ methods at the top level would really help neaten this up.

I've written this comment a few times to try and not come across as confrontational. I'm not intending to be at all, so please don't take it that way 😅. Tone is hard in comments! I'm just trying to figure out how to proceed quickly.

I've noticed a diverging theme that seems to be coming up in various conversations (see #3234 and #3245) around API design for alternative array implementations.

It seems to boil down to whether an array implementation has 1st party or 3rd party support within xarray.

For numpy and Dask they appear to be 1st party. They influence the main API of xarray and xarray contains baked in logic to create and work with them.

The work on pint so far points towards it being 3rd party. While I'm sure some compatibility code has gone into xarray much of the logic lives out in an accessor library. Given that pint is extending the numpy API this makes sense.

I initially started this work assuming that cupy would be added as 1st party type, given that it attempts to replicate the numpy API without addition. However I'm not sure this is the right stance.

There are a few questions such as "should .plot coerce cupy arrays to numpy?" (with the conversation in #3234 pointing towards no) which are making me think that perhaps it should be more 3rd party.

I think it would help with API design and speed here if a decision were to be made about cupy (and sparse) being 1st or 3rd party.

Perhaps some core maintainers could weigh in here?

@dcherian pointed me over here after I raised #4234.

I like as_sparse and as_dense, because it makes clear that the objects are still xarray objects. I agree with @fujiisoup that to_sparse``todense could be confused to return sparse arrays directly.

I very much agree with this reasoning. to_ sounds like it is converting the whole thing to another type. as_ sounds like it is remaining the same but something about it (the underlying array type) is changing.

Basically, we should leave the decision about whether automatic coercion is safe up to the authors of duck array libraries.

I also agree with this reasoning. In cupy many things will break because np.asarray(cupy_array) will raise. So something like cupy_da.plot() will raise. But the exception will be ValueError: object __array__ method not producing an array which isn't particularly user friendly in this case.

For cupy I do think that automatic coercion to numpy for .values and plot() is a reasonable thing to do. But I understand that may not be true for all duck type arrays.

One suggestion is to add an accessor to make things explicit. So it would become cupy_da.cupy.plot(). Where this plot function coerces to numpy and then calls the upstream plot method. However this feels less satisfying.

Those as_ methods sounds good. Would as_dense be the same as as_numpy?

Yeah it is possible to read direct to GPU from storage with GDS. We've experimented a little with zarr, I expect if something like zarr got GDS support and a zarr dataset was configured to use GDS then xr.open_zarr('zarr/path') would be already backed by cupy because the zarr internal array would be cupy.

Re: index variables.Can we avoid this for now?

I think that would be best.

However I did run into issues when trying to run the Compare weighted and unweighted mean temperature example with cupy. In that example the weights data array is generated from the latitude index. So the resulting DataArray is backed by numpy. I would expect that if it were a cuDF Index it would end up as a cupy data array.

In my testing I just cast the weights data array to cupy and carried on. So perhaps with this change users will just need to sprinkle some weights = weights.as_cupy() or weights = weights.asarray(cp.ndarray) type calls throughout their code when they need to.

The only things I can think of that would make sense initially in an accessor would be to_cupy/from_cupy to move back and forth from the GPU, plus maybe an alias for get to from_cupy to match the cupy API.

An accessor does seem like a reasonable place to put that logic, but it also seems like a tiny amount of code to make, ship and maintain a separate package for. Plus those methods will either need to be used or duplicated in the core codebase to support things like plotting.

This does sound like an option. However there are many situations within xarray where we need explicit cupy logic. Converting back to numpy before plotting is one example. I don't think that kind of logic can live in an accessor.

Unless you expect users to do something like this.

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

ds = xr.tutorial.load_dataset("air_temperature") gds = ds.cupy.to_cupy()

Do some manipulation on the GPU

Grab a time slice

time_slice = gds.air.isel(time=0)

time_slice.cupy.to_numpy().plot() # I would hope that time_slice.plot() would work ```

I would be tempted to say that cupy is more like dask in that it is trying to implement the numpy array interface exactly but in a different paradigm (distributed, GPU, etc). And of course there are limitations and divergences because of the different paradigm. However it's not the same as pint which is trying to extend numpy and add more functionality.

So it makes sense to me that accessors for pint exist to add this extra functionality to xarray. But at least in theory cupy should be a drop-in replacement for numpy. So I don't expect a huge amount of logic will live in an accessor, compared to the amount of compatibility code that will need to go into xarray itself.

@jthielen Something like this?

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

@xr.register_dataset_accessor("cupy") class CupyAccessor: def to_cupy(self): """Convert all data arrays to cupy."""

    for var in self.data_vars: 
        self.data_vars[var].data = cp.asarray(self.data_vars[var].data)

    return self

```

Which would then be used like this.

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

ds = xr.open_mfdataset("/path/to/files/*.nc") gds = ds.cupy.to_cupy() ```

cc @quasiben

Nightlies are running. Sorry we can't do more than this right now.

Many thanks! We will start running nightlies from today.

Ok great! Once this is merged we will get that set up on our end.

I think what we can offer at the moment is to run a nightly against the default branch on some GPU hardware. If the nightly fails we will open an issue and look into resolving it.

Not as neat as hooking into PRs like the rest of the CI though. Hopefully this will improve over time.

@fjanoos I'm afraid I don't. In RAPIDS we support cupy as our GPU array implementation. So this request has come from the desire to make xarray compatible with the RAPIDS suite of tools.

We commonly see folks using cupy to switch straight over to a tool like pytorch using DLPack. https://docs-cupy.chainer.org/en/stable/reference/interoperability.html#dlpack

But I don't really see #4212 as an effort to make cupy the GPU backend for xarray. I see it as adding support for another backend to xarray. The more the merrier!

@TomNicholas I've been trying to find a way to do this. In order for the cupy tests to be run the CI machine will need an NVIDIA GPU. But setting up a GPU CI would be a burden on the xarray team both technically and financially. This is why I'm just skipping for now.

For projects over in RAPIDS we have have a private GPU CI. We aren't in a position to integrate this here but we may be able to run nightlies. I'll update when I have more info.

This PR for adding pint support is a useful reference. https://github.com/pydata/xarray/pull/3238

@andersy005 I'm about to start working actively on cupy support in xarray. Would be great to get some of your input.

Cupy requests that instead of calling __array__ you instead call their .get method for explicit conversion to numpy. So we need to add a little compatibility code for this.

Thanks for the feedback.

I think when working in iris that you expect multiple cubes to be returned as a cube list. Also when calling iris.load you expect a cubelist.

I would propose that to_iris is fine, however if you feel strongly I would be happy to change it.

Yup seems fine in 0.10.8.

Great! We are still on 0.10.7 so I'll update and give it another go.