issues

Table actions

2 rows where user = 4762711 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date), closed_at (date)

state 2

type 1

repo 1

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
412080974 MDU6SXNzdWU0MTIwODA5NzQ= 2779 Bring xr.align objects specification in line with other top-level functions? zbarry 4762711 open 0     2 2019-02-19T19:13:33Z 2020-11-26T21:44:09Z   NONE      

Was wondering if this might be useful given that I ran into this point of confusion. Observing the following argument specifications for various top-level xarray functions:

xarray.align(*objects, join='inner', copy=True, indexes=None, exclude=frozenset())

xarray.concat(objs, dim=None, data_vars='all', coords='different', compat='equals', positions=None, indexers=None, mode=None, concat_over=None)

xarray.concat(objs, dim=None, data_vars='all', coords='different', compat='equals', positions=None, indexers=None, mode=None, concat_over=None)

xarray.merge(objects, compat='no_conflicts', join='outer')

the odd man out here would be xr.align utilizing the *args formulation whereas all the others just take a single objs / objects param, instead. Would it make sense to add functionality to align such that if *args (*objects) is of length 1 and is a list or tuple (or something in this ballpark), you just treat it as the other methods currently operate?

For reference, if you don't notice that align works differently, if you pass an iterable without *args-ifying it, you get this somewhat unhelpful error:

 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/2779/reactions",
    "total_count": 2,
    "+1": 2,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 issue
473000845 MDU6SXNzdWU0NzMwMDA4NDU= 3161 .reduce() on a DataArray with Dask distributed immediately executes the preceding portions of the computational graph zbarry 4762711 closed 0     4 2019-07-25T18:09:22Z 2019-11-13T15:48:46Z 2019-11-13T15:48:46Z NONE      

MCVE Code Sample

.mean() on a DataArray pointing to a Dask array returns a Dask array-containing DataArray as expected:

python da = xr.DataArray(np.zeros((500, 500, 500))).chunk((100, 100, 100)).mean('dim_0') da

<xarray.DataArray (dim_1: 500, dim_2: 500)> dask.array<shape=(500, 500), dtype=float64, chunksize=(100, 100)> Dimensions without coordinates: dim_1, dim_2

Calling .compute() on this result produces the expected result:

python da = xr.DataArray(np.zeros((500, 500, 500))).chunk((100, 100, 100)).mean('dim_0').compute()

<xarray.DataArray (dim_1: 500, dim_2: 500)> array([[0., 0., 0., ..., 0., 0., 0.], [0., 0., 0., ..., 0., 0., 0.], [0., 0., 0., ..., 0., 0., 0.], ..., [0., 0., 0., ..., 0., 0., 0.], [0., 0., 0., ..., 0., 0., 0.], [0., 0., 0., ..., 0., 0., 0.]]) Dimensions without coordinates: dim_1, dim_2

The .reduce() method immediately executes all of the previously queued computations leading up to the new reduce method before even calling the supplied function.

```python def func(x, axis=None): return x

da = xr.DataArray(np.zeros((500, 500, 500))).chunk((100, 100, 100)).mean('dim_0').reduce(func) ```

<xarray.DataArray (dim_1: 500, dim_2: 500)> array([[0., 0., 0., ..., 0., 0., 0.], [0., 0., 0., ..., 0., 0., 0.], [0., 0., 0., ..., 0., 0., 0.], ..., [0., 0., 0., ..., 0., 0., 0.], [0., 0., 0., ..., 0., 0., 0.], [0., 0., 0., ..., 0., 0., 0.]]) Dimensions without coordinates: dim_1, dim_2

Expected Output

A Dask array when .reduce(func) isn't followed up by .compute().

Problem Description

When using Dask distributed, the computational graph you are constructing is immediately executed if you call .reduce() instead of adding that function as another node in the DAG. This graph execution happens before the function you pass to reduce is called.

Output of xr.show_versions()

INSTALLED VERSIONS ------------------ commit: None python: 3.7.3 | packaged by conda-forge | (default, Jul 1 2019, 21:52:21) [GCC 7.3.0] python-bits: 64 OS: Linux OS-release: 3.10.0-693.21.1.el7.x86_64 machine: x86_64 processor: x86_64 byteorder: little LC_ALL: None LANG: en_US.UTF-8 LOCALE: en_US.UTF-8 libhdf5: 1.10.4 libnetcdf: 4.6.2 xarray: 0.12.3 pandas: 0.25.0 numpy: 1.16.4 scipy: 1.3.0 netCDF4: 1.5.1.2 pydap: None h5netcdf: None h5py: 2.9.0 Nio: None zarr: None cftime: 1.0.3.4 nc_time_axis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: 2.1.0 distributed: 2.1.0 matplotlib: 3.1.1 cartopy: None seaborn: None numbagg: None setuptools: 41.0.1 pip: 19.2.1 conda: None pytest: 5.0.1 IPython: 7.6.1 sphinx: 2.1.2 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/3161/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   completed xarray 13221727 issue

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issues] (
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [number] INTEGER,
   [title] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [state] TEXT,
   [locked] INTEGER,
   [assignee] INTEGER REFERENCES [users]([id]),
   [milestone] INTEGER REFERENCES [milestones]([id]),
   [comments] INTEGER,
   [created_at] TEXT,
   [updated_at] TEXT,
   [closed_at] TEXT,
   [author_association] TEXT,
   [active_lock_reason] TEXT,
   [draft] INTEGER,
   [pull_request] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [state_reason] TEXT,
   [repo] INTEGER REFERENCES [repos]([id]),
   [type] TEXT
);
CREATE INDEX [idx_issues_repo]
    ON [issues] ([repo]);
CREATE INDEX [idx_issues_milestone]
    ON [issues] ([milestone]);
CREATE INDEX [idx_issues_assignee]
    ON [issues] ([assignee]);
CREATE INDEX [idx_issues_user]
    ON [issues] ([user]);