html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/7721#issuecomment-1498773949,https://api.github.com/repos/pydata/xarray/issues/7721,1498773949,IC_kwDOAMm_X85ZVXm9,1610850,2023-04-06T09:39:43Z,2023-04-06T09:39:43Z,CONTRIBUTOR,Ping @leofang in case you have thoughts?,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1655290694
https://github.com/pydata/xarray/issues/6847#issuecomment-1199637580,https://api.github.com/repos/pydata/xarray/issues/6847,1199637580,IC_kwDOAMm_X85HgQRM,1610850,2022-07-29T16:10:12Z,2022-07-29T16:10:12Z,CONTRIBUTOR,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](https://twitter.com/rabernat/status/1553003580122169344?s=20&t=oPBm0sFl0yaOxV-xKpPCnA) around not doing this though.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1322112135
https://github.com/pydata/xarray/issues/5648#issuecomment-924108418,https://api.github.com/repos/pydata/xarray/issues/5648,924108418,IC_kwDOAMm_X843FMaC,1610850,2021-09-21T15:37:12Z,2021-09-21T15:38:56Z,CONTRIBUTOR,I can be there! @jakirkham and @pentschev are also Dask maintainers so there should be good representation. ,"{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,956103236
https://github.com/pydata/xarray/issues/5648#issuecomment-889909886,https://api.github.com/repos/pydata/xarray/issues/5648,889909886,IC_kwDOAMm_X841CvJ-,1610850,2021-07-30T13:55:56Z,2021-07-30T13:55:56Z,CONTRIBUTOR,Happy to attend. It might also be useful to have @pentschev involved too.,"{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,956103236
https://github.com/pydata/xarray/issues/3245#issuecomment-662555403,https://api.github.com/repos/pydata/xarray/issues/3245,662555403,MDEyOklzc3VlQ29tbWVudDY2MjU1NTQwMw==,1610850,2020-07-22T16:31:14Z,2020-07-22T16:31:14Z,CONTRIBUTOR,Thanks for writing that up @dcherian. Sounds good to me!,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484240082
https://github.com/pydata/xarray/issues/3245#issuecomment-661087703,https://api.github.com/repos/pydata/xarray/issues/3245,661087703,MDEyOklzc3VlQ29tbWVudDY2MTA4NzcwMw==,1610850,2020-07-20T14:49:55Z,2020-07-20T14:49:55Z,CONTRIBUTOR,"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?","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484240082
https://github.com/pydata/xarray/issues/3245#issuecomment-661050583,https://api.github.com/repos/pydata/xarray/issues/3245,661050583,MDEyOklzc3VlQ29tbWVudDY2MTA1MDU4Mw==,1610850,2020-07-20T13:47:45Z,2020-07-20T13:47:45Z,CONTRIBUTOR,"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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484240082
https://github.com/pydata/xarray/issues/4212#issuecomment-660210572,https://api.github.com/repos/pydata/xarray/issues/4212,660210572,MDEyOklzc3VlQ29tbWVudDY2MDIxMDU3Mg==,1610850,2020-07-17T16:36:18Z,2020-07-17T16:36:18Z,CONTRIBUTOR,"_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](https://github.com/xarray-contrib/pint-xarray). 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?","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654135405
https://github.com/pydata/xarray/issues/3245#issuecomment-660201690,https://api.github.com/repos/pydata/xarray/issues/3245,660201690,MDEyOklzc3VlQ29tbWVudDY2MDIwMTY5MA==,1610850,2020-07-17T16:22:06Z,2020-07-17T16:22:06Z,CONTRIBUTOR,"@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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484240082
https://github.com/pydata/xarray/issues/4234#issuecomment-660192634,https://api.github.com/repos/pydata/xarray/issues/4234,660192634,MDEyOklzc3VlQ29tbWVudDY2MDE5MjYzNA==,1610850,2020-07-17T16:07:31Z,2020-07-17T16:08:34Z,CONTRIBUTOR,"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](https://developer.nvidia.com/blog/gpudirect-storage/). 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](http://xarray.pydata.org/en/stable/examples/area_weighted_temperature.html) 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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,659129613
https://github.com/pydata/xarray/issues/4234#issuecomment-660154476,https://api.github.com/repos/pydata/xarray/issues/4234,660154476,MDEyOklzc3VlQ29tbWVudDY2MDE1NDQ3Ng==,1610850,2020-07-17T14:58:53Z,2020-07-17T14:58:53Z,CONTRIBUTOR,"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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,659129613
https://github.com/pydata/xarray/issues/4234#issuecomment-660148433,https://api.github.com/repos/pydata/xarray/issues/4234,660148433,MDEyOklzc3VlQ29tbWVudDY2MDE0ODQzMw==,1610850,2020-07-17T14:48:01Z,2020-07-17T14:54:41Z,CONTRIBUTOR,"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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,659129613
https://github.com/pydata/xarray/issues/4234#issuecomment-660136749,https://api.github.com/repos/pydata/xarray/issues/4234,660136749,MDEyOklzc3VlQ29tbWVudDY2MDEzNjc0OQ==,1610850,2020-07-17T14:26:35Z,2020-07-17T14:32:03Z,CONTRIBUTOR,"@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()
```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,659129613
https://github.com/pydata/xarray/issues/4234#issuecomment-660030480,https://api.github.com/repos/pydata/xarray/issues/4234,660030480,MDEyOklzc3VlQ29tbWVudDY2MDAzMDQ4MA==,1610850,2020-07-17T10:37:46Z,2020-07-17T10:37:46Z,CONTRIBUTOR,cc @quasiben,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,659129613
https://github.com/pydata/xarray/pull/4214#issuecomment-657662153,https://api.github.com/repos/pydata/xarray/issues/4214,657662153,MDEyOklzc3VlQ29tbWVudDY1NzY2MjE1Mw==,1610850,2020-07-13T16:31:34Z,2020-07-13T16:31:34Z,CONTRIBUTOR,"Nightlies are running. Sorry we can't do more than this right now.

![image](https://user-images.githubusercontent.com/1610850/87329313-a70c7380-c52e-11ea-8d6c-5fd22f1b57b9.png)
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654678508
https://github.com/pydata/xarray/pull/4214#issuecomment-657627277,https://api.github.com/repos/pydata/xarray/issues/4214,657627277,MDEyOklzc3VlQ29tbWVudDY1NzYyNzI3Nw==,1610850,2020-07-13T15:27:01Z,2020-07-13T15:27:01Z,CONTRIBUTOR,Many thanks! We will start running nightlies from today. ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654678508
https://github.com/pydata/xarray/pull/4214#issuecomment-656761038,https://api.github.com/repos/pydata/xarray/issues/4214,656761038,MDEyOklzc3VlQ29tbWVudDY1Njc2MTAzOA==,1610850,2020-07-10T16:18:01Z,2020-07-10T16:18:01Z,CONTRIBUTOR,Ok great! Once this is merged we will get that set up on our end.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654678508
https://github.com/pydata/xarray/pull/4214#issuecomment-656629069,https://api.github.com/repos/pydata/xarray/issues/4214,656629069,MDEyOklzc3VlQ29tbWVudDY1NjYyOTA2OQ==,1610850,2020-07-10T11:34:37Z,2020-07-10T11:34:37Z,CONTRIBUTOR,"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.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654678508
https://github.com/pydata/xarray/issues/3232#issuecomment-656627686,https://api.github.com/repos/pydata/xarray/issues/3232,656627686,MDEyOklzc3VlQ29tbWVudDY1NjYyNzY4Ng==,1610850,2020-07-10T11:30:36Z,2020-07-10T11:30:36Z,CONTRIBUTOR,"@fjanoos I'm afraid I don't. In [RAPIDS](https://rapids.ai/) 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!","{""total_count"": 3, ""+1"": 3, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,482543307
https://github.com/pydata/xarray/pull/4214#issuecomment-656613425,https://api.github.com/repos/pydata/xarray/issues/4214,656613425,MDEyOklzc3VlQ29tbWVudDY1NjYxMzQyNQ==,1610850,2020-07-10T10:50:32Z,2020-07-10T10:50:32Z,CONTRIBUTOR,"@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](https://github.com/rapidsai) 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.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654678508
https://github.com/pydata/xarray/issues/4212#issuecomment-656604704,https://api.github.com/repos/pydata/xarray/issues/4212,656604704,MDEyOklzc3VlQ29tbWVudDY1NjYwNDcwNA==,1610850,2020-07-10T10:27:29Z,2020-07-10T10:27:29Z,CONTRIBUTOR,This PR for adding pint support is a useful reference. https://github.com/pydata/xarray/pull/3238,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654135405
https://github.com/pydata/xarray/issues/3232#issuecomment-656178897,https://api.github.com/repos/pydata/xarray/issues/3232,656178897,MDEyOklzc3VlQ29tbWVudDY1NjE3ODg5Nw==,1610850,2020-07-09T14:58:40Z,2020-07-09T14:58:40Z,CONTRIBUTOR,"@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.","{""total_count"": 4, ""+1"": 4, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,482543307
https://github.com/pydata/xarray/pull/2449#issuecomment-426377254,https://api.github.com/repos/pydata/xarray/issues/2449,426377254,MDEyOklzc3VlQ29tbWVudDQyNjM3NzI1NA==,1610850,2018-10-02T18:15:28Z,2018-10-02T18:15:28Z,CONTRIBUTOR,"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. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,365367839
https://github.com/pydata/xarray/issues/2335#issuecomment-412947889,https://api.github.com/repos/pydata/xarray/issues/2335,412947889,MDEyOklzc3VlQ29tbWVudDQxMjk0Nzg4OQ==,1610850,2018-08-14T17:15:01Z,2018-08-14T17:15:01Z,CONTRIBUTOR,Yup seems fine in 0.10.8.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,346525275
https://github.com/pydata/xarray/issues/2335#issuecomment-412939138,https://api.github.com/repos/pydata/xarray/issues/2335,412939138,MDEyOklzc3VlQ29tbWVudDQxMjkzOTEzOA==,1610850,2018-08-14T16:47:15Z,2018-08-14T16:47:15Z,CONTRIBUTOR,Great! We are still on 0.10.7 so I'll update and give it another go.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,346525275