Fix computation of angleEdge in NetCDF-C mesh converter #710
Fix computation of angleEdge in NetCDF-C mesh converter #710xylar merged 5 commits intoMPAS-Dev:masterfrom
angleEdge in NetCDF-C mesh converter #710Conversation
|
See E3SM-Project/polaris#479 for more discussion of this issue. |
945708e to
6a007f9
Compare
angleEdge in NetCDF-C mesh converter
|
@cbegeman, no rush on this but have a look when you can. |
| write_netcdf(dsMask, 'antarctic_mask.nc') | ||
|
|
||
|
|
||
| def test_conversion_angle_edge(): |
cbegeman
left a comment
There was a problem hiding this comment.
Approving based on visual inspection. Did you test any meshes with finer resolutions than 1290km?
|
No, I figured if it works for one mesh, it should work for all but happy to check something higher res before I merge. |
The old spherical `angleEdge` calculation in `MpasMeshConverter.x` inferred the edge angle from the latitude difference between edge vertices and then used a sign correction based on a nearby artificial "north pole" point. This approximation becomes inaccurate and unstable near the poles, where local east/north directions are poorly represented by latitude differences. This merge replaces that logic with a Cartesian geometric formulation: compute the edge normal from the vertex chord and edge position on the sphere, project it onto the local east/north basis at the edge, and compute `angleEdge` with `atan2`. This matches the downstream Polaris fix and gives robust spherical angles across the globe, including polar regions.
Add `mpas_tools.mesh.spherical` with utilities to compute local east/north vectors, edge-normal vectors, and recomputed spherical `angleEdge` values from mesh geometry. These routines mirror the corrected spherical formulation used for the C++ mesh converter and provide a reusable Python reference implementation.
Add a conversion test that runs `MpasMeshConverter.x` on the low-resolution QU test mesh, recomputes `angleEdge` in Python from spherical geometry, and verifies the converted mesh agrees to tight tolerance. This gives us a lightweight regression test for the polar `angleEdge` fix without introducing a dedicated C++ unit-test harness.
6a007f9 to
9d2d739
Compare
|
@cbegeman, I tested this in a similar way (C++ vs. python) on an EC30to60 mesh, again without any problems. I also added some fixes to the documentation I noticed when I was trying to install the conda package into my local pixi environment. |
|
Just a note to say that I emailed @mgduda and he agreed that we could proceed here without his input. They use a different tool (not in MPAS-Tools) to compute |
The old spherical
angleEdgecalculation inMpasMeshConverter.xinferred theedge angle from the latitude difference between edge vertices and then used a
sign correction based on a nearby artificial "north pole" point. This
approximation becomes inaccurate and unstable near the poles, where local
east/north directions are poorly represented by latitude differences.
This merge replaces that logic with a Cartesian geometric formulation:
compute the edge normal from the vertex chord and edge position on the
sphere, project it onto the local east/north basis at the edge, and
compute
angleEdgewithatan2. This matches the downstream Polarisfix and gives robust spherical angles across the globe, including polar
regions.
This merge also adds
mpas_tools.mesh.sphericalwith utilities to compute local east/northvectors, edge-normal vectors, and recomputed spherical
angleEdgevalues frommesh geometry. These routines mirror the corrected spherical formulation used
for the C++ mesh converter and provide a reusable Python reference
implementation.
Finally, this merge adds a regression test to make sure a QU1920 mesh gets the same
angleEdgefrom the python and C++ codes.