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/7539#issuecomment-1438965753,https://api.github.com/repos/pydata/xarray/issues/7539,1438965753,IC_kwDOAMm_X85VxN_5,2448579,2023-02-21T19:07:48Z,2023-02-21T19:07:48Z,MEMBER,"That's true,`join=""exact""` would've raised an error, which would've been less confusing perhaps.
If we do want this use-case to work out of the box, then I too agree that a new top-level method would be best. `stack` would've been a good name but that;s taken.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1588461863
https://github.com/pydata/xarray/issues/7539#issuecomment-1438877252,https://api.github.com/repos/pydata/xarray/issues/7539,1438877252,IC_kwDOAMm_X85Vw4ZE,35968931,2023-02-21T17:48:30Z,2023-02-21T17:48:30Z,MEMBER,"> Or indeed at least make it clearer in the docs that something like drop_indexes or reset_coords should be used first in order to skip auto-alignment for some variables.
I think we should do this regardless. I don't know of anywhere in the docs that these kind of subtleties with `concat` are clearly documented.
> I guess easiest for a concat version with no auto-alignment would be to drop the index when such case happens.
Right - in this case that would have given the intuitive result.
> We could get halfway to a better xr.concat by changing https://github.com/pydata/xarray/issues/2064 IMO.
>
> I propose join=""exact"", data_vars=""minimal"", coords=""minimal"", compat=""override""
That wouldn't have helped with this specific issue though right?
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1588461863
https://github.com/pydata/xarray/issues/7539#issuecomment-1438817270,https://api.github.com/repos/pydata/xarray/issues/7539,1438817270,IC_kwDOAMm_X85Vwpv2,2448579,2023-02-21T17:03:27Z,2023-02-21T17:03:27Z,MEMBER,"We could get halfway to a better `xr.concat` by changing [the defaults](https://github.com/pydata/xarray/issues/2064) IMO.
I propose `join=""exact"", data_vars=""minimal"", coords=""minimal"", compat=""override""`
1. this would only concatenate variables that have `concat_dim` (if none do, then I think it will just concatenate all of them?)
2. It would skip any expensive equality checks and https://github.com/pydata/xarray/issues/5381
This would also drastically improve `open_mfdataset` by default. It will be pretty backwards-incompatible though.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1588461863
https://github.com/pydata/xarray/issues/7539#issuecomment-1438377578,https://api.github.com/repos/pydata/xarray/issues/7539,1438377578,IC_kwDOAMm_X85Vu-Zq,4160723,2023-02-21T12:13:18Z,2023-02-21T12:13:18Z,MEMBER,"In general I also find that `xr.concat` is a powerful feature (incl. auto-alignment and merge options) at the expense that it may sometimes (often?) be hard to reason about. Would it make sense to have a simpler version? To avoid making `xr.concat` signature even more complicated, maybe another top-level function like `xr.concat_noalign`? Or any suggestion in #7045 to deactivate auto-alignment Xarray-wise. Or indeed at least make it clearer in the docs that something like `drop_indexes` or `reset_coords` should be used first in order to skip auto-alignment for some variables.
> I don't really know what I would prefer to happen with the coordinates. I guess to have created a time coordinate of size {new: 2, time: 4, cols: 2}, but then I don't know what that implies for the underlying index. @benbovy do you have any thoughts?
I guess easiest for a concat version with no auto-alignment would be to drop the index when such case happens. (note: one problem in your example is that the Xarray data model still does not allow having a multi-dimensional ""time"" variable with ""time"" as also one of its dimensions, but this could be now relaxed).
I've been also wondering whether some kind of `NDPandasIndex` would make any sense, i.e., a n-d coordinate variable with an internal 1-d (flattened) pandas index and some logic to convert between those n-d vs. 1-d spaces. This is the kind of approach used in xoak for using a kd-tree with coordinates of arbitrary dimensions, where labels in the form of nd-arrays for each coordinate are mapped into the `[n_points, n_coords]` shape (and inversely for getting the integer indices back as nd-arrays). This works well for point-wise indexing, but I doubt it would be very useful beyond that (e.g., slicing, etc.).
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1588461863