Icon grids support - #66
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 481b7c86e8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| lon_c, lat_c = coarse["lon_cell_centre"].values, coarse["lat_cell_centre"].values | ||
| lon_f, lat_f = fine["lon_cell_centre"].values, fine["lat_cell_centre"].values |
There was a problem hiding this comment.
Resolve ICON coordinates consistently in validator
When grid files use clon/clat (which icon_grid_to_mgrid explicitly accepts), this function raises KeyError instead of returning an ordering verdict because it only reads lon_cell_centre/lat_cell_centre. That prevents the advertised preflight check for an otherwise supported ICON grid pair; resolve the coordinate variable names using the same fallback logic as the grid builder.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
maybe something like
lon_name = "clon" if "clon" in ds else "lon_cell_centre"
lat_name = "clat" if "clat" in ds else "lat_cell_centre"|
|
||
| lon_c, lat_c = coarse["lon_cell_centre"].values, coarse["lat_cell_centre"].values | ||
| lon_f, lat_f = fine["lon_cell_centre"].values, fine["lat_cell_centre"].values | ||
| d0 = gc_deg(lon_f[::4], lat_f[::4], lon_c, lat_c) |
There was a problem hiding this comment.
Validate all children before approving nested ordering
For a candidate grid where entry 4*i is near coarse cell i but entries 4*i+1:4*i+4 have been shuffled among parents, this calculation still returns True. The purported guard would then approve reshape-based coarsening that mixes unrelated cells, because it checks only the first child in each four-cell block; verify all four children (and their group membership) before reporting success.
Useful? React with 👍 / 👎.
ICON grids are not so different from HEALpix grids in terms of multi-scale decomposition.
ICON grids, each parent triangle has four child triangles, similar to each HEALpix parent pixel has four child pixels; In ICON grids,
n_cells(R2Bk) = 20 · 4^(k+1)/4 = 80 · 4^k(equivalently 20·2²·4^k) — the same "fixed base-tile count, then exact ×4 per level" shape as HEALPix's 12·4^z, just with 20 base icosahedron faces instead of 12 base pixels.ICON grids are stored in a "nested" way, these 4 children occupy contiguous indices, always ordered
[center, corner1, corner2, corner3]. The cell centre that corresponds to thecorner1may different in different cells. but the order is not really important for coarsening and refining.further validation shall that the result should be mathematically correct.
Therefore, three new functions are added in the
grid_utils.py:icon_neighbor_cell_index_to_adjc, which corresponds tohealpix_get_adjacent_cell_indices;icon_grid_to_mgridwhich corresponds tohealpix_grid_to_mgrid, and a new function to make sure the nested layoutvalidate_nested_ordering.The following scripts can be used for testing, and the
test_data(R2B4 fine grids, R2B3 coarse grids, and an example data with variable ['u_10m']) can be found here/work/mh0033/m300883/data_share/test_data.