issues: 700907310
This data as json
| 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 700907310 | MDU6SXNzdWU3MDA5MDczMTA= | 4420 | Multi-mesh support | 5637662 | open | 0 | 0 | 2020-09-14T08:52:46Z | 2020-09-14T08:52:46Z | CONTRIBUTOR | Is your feature request related to a problem? Please describe. I am not sure what the best way to have data from different meshes is. My simulations use logical Cartesian meshes, but they can be of different sizes (number of points). They describe 2D surfaces in 3D and aren't necessarily connected. Describe the solution you'd like I would like to store the different meshes in the same dataset with a nice interface. Describe alternatives you've considered I have considered several options: 1) I could use a list of datasets. That would be easy to implement, but it feels wrong, as this is really one dataset. 2) Add another dimension some index for the mesh number. That would require to expand all meshes to the largest one (in each spatial dimension). Then the coordinates (x,y,z) would also be required to be 3D, a 2D slice for each index. That has some overhead, as all structures are expanded, and it is not easy to see what shape each slice has. This might also cause issues with plotting, as the data seems to be 3D rather then 2D. 3) merge all data, e.g. merging all data in x direction, with an index-offset in x, that different meshes have different indices. Then only the y-dimension would need to be alligned, thus it would involve less storage cost. Plotting would work somewhat - only ensuring that non-connected meshes are not plotted connected might be a bit tricky. 4) suffix all data and coordinates with an index. Would allow to e.g. plot by iterating over the index - a variation of 1) but allows to store as one file 5) use unstructured grids. That would avoid the additional storage cost, as the full grid info is anyway stored, but then plotting or searching in the data will be (much) more expensive. Additional context
The data is not point-centered, but area/volume based (see #1475) - thus recovering whether data needs to be plotted together or not in 3) would be doable, but transforming from the xarray format to the
format for |
{
"url": "https://api.github.com/repos/pydata/xarray/issues/4420/reactions",
"total_count": 1,
"+1": 1,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
13221727 | issue |