Repository navigation
Add more Dataset methods/properties to uxarray.Grid #1647
Description
Proposed new feature or change:
uxarray.Grid objects behave mostly like xarray.Datasets, but with some additional fancier behavior related to unstructured grids. They even display similarly to how Dataset objects display! So, I have come to expect/want all relevant Dataset-like behaviors to apply to Grids, too.
Examples of code I expected to work on Grids which currently does not work:
grid.get("node_lon"),grid.keys()and other dict-like behaviorsgrid.identical(other_grid)grid.nbytes(relevant: ASV better memory benchmarks #1609 (comment)) as well as other attributes likegrid.coords,grid.data_vars,grid.dtypesgrid.compute()and other dask-related methods, in case some of the underlying data is chunked
Examples of code which should maybe work on Grids but which currently does not work:
grid.roll(n_node=10)-- I would think this should probably roll along the n_node dimension and maybe renumber nodes as needed? But, it's a bit ambiguous.grid.rename(extra_var='newname')-- should probably return a new grid with extra_var renamed accordingly, if it isn't one of the core names for grids (like "node_lon" or "n_face"). This assumes Grid objects continue to support extra variables when present (e.g. when the input file contains non-grid-data, maybe something like "custom_node_labels" containing string labels for each node, in a small grid).grid.isnull()could probably be allowed?
Examples of code which should continue to not be supported on Grids:
grid.mean()as well as min, max, std, and other statistics which don't really make sense to apply to a Gridgrid.interp(...)probably wouldn't really make sensegrid.integrate()and any other math functions which don't really make sense to apply across all data variables within a Grid
A 100% complete solution to this issue would require considering every single method and attribute supported by xarray.Dataset, deciding whether they should be supported by Grid, and implementing if needed.
That would probably be way too much to review within a single PR. On the other hand, it could get unwieldy to handle too many tiny PRs each implementing only a single new method or attribute, especially when the implementations are as simple as simply calling the corresponding method from the underlying grid._ds. My suggestion would be to instead create a few PRs which each form reasonably-natural groupings. For example, one PR might try something like "implements dict-like behaviors for Grids: get(), keys(), items(), ..." while another might do "adds Dataset-like attributes for Grids: nbytes, coords, data_vars, chunks, dtypes, ...". Each of them would address part of this issue. Comments in thread on this issue could be used to track a more exhaustive list of available Dataset methods and discussion about whether they should be implemented for Grid.
Activity
erogluorhan commentedon Aug 18, 2026
Thanks very much for considering this @Sevans711 !
I don't agree that they currently mostly behave or should increasingly behave like
Datasets though:UxDataset.uxgridandUxDataArray.uxgridin most cases (i.e. unless Grid lieves standalone) should give the indication that grids are rather properties of datasets.GridandUxDatasetare distinct from each other by both design and the driving use cases.All that said, this is a big lift, and I am not sure if we should go this route with its entirety (there might be need for individual things, and hearing scientific workflows to see if there is actual need for them might be useful, e.g. renaming a grid, etc.)
Sevans711 commentedon Aug 18, 2026
Quick clarifications/followups:
GridandUxDatasetare very different, and I think the docs do a good job distinguishing between them. Above I was instead attempting to say thatGridfeels like a specializedxarray.Dataset(not UxDataset). This is primarily because its main purposes seem to be (dataset-like) bookkeeping for dimensions and coordinates and (specialized) handling unstructured grid functionality. The underlyingGriddata also seems to be primarily stored in .nc files, which I understand as mapping naturally into xarray Datasets.grid.nbytesandgrid.compute(). We discussed that it might be a good idea to make separate sub-issues for those pieces, especially if any user workflow would need them directly.erogluorhan commentedon Aug 18, 2026
100%. Thanks for clarifying! The
Gridobject has axr.Dataset(i.e. composition) to handle all that you mentioned above, and the similarity feeling comes from that I believe.Agreed. Let's even go further and close this overarching issue that has too many points that may or may not be voted for implementation, and when the time comes, rather open individual issue(s) for only corresponding task. e.g. issue for grid.compute().
I've added a May Revisit label for this to help with future issues.