Proposal: a non-orthogonal `SphericalGrid` (equiangular cubed-sphere panel + OctaHEALPix, FV3-capable)

[glwagner]

Summary

I'd like to propose a new grid type, tentatively SphericalGrid, that relaxes the two structural assumptions baked into OrthogonalSphericalShellGrid (OSSG):

1. Orthogonality of the horizontal coordinate lines, and
2. the thin-shell (shallow-atmosphere) approximation.

This is a new grid — it does not modify or replace OSSG. The first target is a single panel of the equiangular gnomonic cubed sphere (as used in ClimaAtmos and FV3), with SpeedyWeather's OctaHEALPix grid as a second client that gives us whole-sphere tests on a single logically-rectangular panel. A hard design requirement is that the grid be able to host the FV3 dynamical-core algorithm (Lin & Rood 1996; Putman & Lin 2007), so the grid must carry the metric information FV3-style finite-volume transport needs.

Motivation

• A gnomonic (equiangular) cubed-sphere panel is the natural home for FV3-style finite-volume transport and for porting FV3 dycore features. OSSG can't represent it because its cells are non-orthogonal.
• The thin-shell relaxation opens the door to deep-atmosphere / deep-shell configurations (relevant to the atmospheric work in Breeze, and to anyone wanting a non-thin-shell ocean/atmosphere).
• OctaHEALPix (equal-area) is a nice, cheap, whole-sphere testbed that — crucially — needs no multi-panel machinery (details below).

What's actually new vs. the existing grids

The happy finding from scoping is that non-orthogonality is cheap if we adopt FV3's convention of covariant prognostic velocities (components projected onto the local coordinate tangents). With covariant winds:

• vorticity stays the plain circulation form (metric-free), and coordinate-direction gradients stay plain differences (metric-free);
• all non-orthogonality concentrates into three places: the covariant→contravariant conversion ũ = (u − ⟨v⟩ cosα)/sin²α, a single sinα factor on flux face-lengths (Putman & Lin's "simple non-orthogonal extension"), and the kinetic-energy quadratic form (u² + v² − 2uv cosα)/sin²α.

So relative to an OSSG-like field set, the grid needs only 8 new 2D arrays: cosα and sinα (the coordinate-line intersection angle) at the four horizontal staggers. FV3 stores exactly this information as its 9-point cos_sg/sin_sg supergrid, which reduces to these four staggers.

Design sketch

Struct (subtype AbstractHorizontallyCurvilinearGrid, like OSSG). Same coordinate/length/area arrays as OSSG, plus:

• cosαᶜᶜᵃ, cosαᶠᶜᵃ, cosαᶜᶠᵃ, cosαᶠᶠᵃ and sinα… (store both; sin loses precision via √(1−cos²) near orthogonality);
• a shell :: S type parameter, ThinShell (reproduces OSSG behavior) or DeepShell (activates (r/R) radial scaling of the metrics — Δx ∝ r/R, Az ∝ (r/R)² — with no 3D metric storage, following ClimaCore's deep flag);
• a provenance slot analogous to OSSG's conformal_mapping, but the gnomonic map isn't conformal, so a more general name (mapping) holding e.g. an EquiangularGnomonicMapping (panel index, rotation, 1-D computational angles).

Overarching operator principle: differencing and interpolation stay as simple as on the other grids — no panel/quadrant branching. This works by respecting the existing three-layer separation:

1. primitive stencils (δx, ℑx, …) are pure (i,j) index arithmetic — panel-blind, unchanged;
2. metric-weighted composites read 2D (i,j) arrays (now including cosα/sinα) — non-orthogonality is array values + two new operator forms, applied uniformly, no per-panel logic;
3. topology (seams) lives only in halo filling.

TripolarGrid is the in-repo existence proof: a single panel that folds onto itself via a Zipper halo BC while running the stock interior operators.

Prototypes and scope

This push: single-panel only. No MultiRegion six-panel cubed-sphere composition (that's a separable follow-on — panel connectivity, two-sided edge angles, cube-corner solves).

1. Equiangular gnomonic cubed-sphere panel. Note CubedSphere.jl currently provides only the Rančić conformal map, so we'd add the (short, analytic) equiangular gnomonic map + inverse — either locally or as a small PR to CubedSphere.jl.
2. OctaHEALPix as a single chart. Confirmed against SpeedyWeather's RingGrids source: although it has 4 base faces, they tile a single 2·nlat_half × 2·nlat_half matrix (matrix_size, Base.Matrix, ring2xy: "north pole in the middle, South Pole in 4 corners, like a stereographic projection"). So it's implementable as one logically-rectangular panel + fold BCs on the four sides — no MultiRegion. This gives whole-sphere Williamson-type tests within the single-panel scope. The only bounded halo-confined items are the four-sided fold and the N-pole 4-way junction.

FV3 compatibility

I inventoried the GFDL FV3 fv_grid_type and confirmed that every grid metric FV3 stores is 2-D horizontal and derives from the cell-corner positions by spherical geometry (great-circle lengths, spherical-excess areas, angle-between-great-circles). The cosα/sinα staggered arrays above cover FV3's cosa_s/cosa_u/cosa_v/cosa (+ their rsin* reciprocals, which we'd compute on the fly as Oceananigans already does for reciprocal metrics). FV3 is itself strictly thin-shell, so FV3 compatibility constrains only the 2-D horizontal metric set and is orthogonal to the deep-shell extension.

Relationship to existing issues

• Implement staggered grid production from node information only #5514 (build a staggered grid from node information only) — the SphericalGrid vertex-array constructor is a natural generalization; FV3 confirms corner nodes are sufficient input for the entire metric set.
• Flux form advection on curvilinear grids is not energy conserving or valid for nonhydrostatic models #5426 (flux-form advection on curvilinear grids / hydrostatic vs. nonhydrostatic metric terms) — this is exactly the operator layer SphericalGrid consumes; I'd like the metric-term rework there to be the numerics dependency rather than duplicating it.
• Non-hydrostatic curvilinear shell? #3943 (non-hydrostatic curvilinear shell) — earlier deep-atmosphere discussion; the thin-shell hook is the Az/spacing accessors in src/Operators/spacings_and_areas_and_volumes.jl.

Open questions

• Naming (SphericalGrid? something more specific?).
• Whether the equiangular map lands in CubedSphere.jl or locally.
• Exact vs. midpoint radial integration convention for V/Ax/Ay in DeepShell.
• Whether to guard orthogonal-only code paths with an isorthogonal trait so misuse is loud.

cc @simone-silvestri @navidcy

[glwagner]

cc @kaiyuan-cheng

[simone-silvestri]

This is a good idea. however, since the orthogonality is not a baked in assumption of the grid but only of the naming, we could change it to SpericalShellGrid such that we decouple the idea of a "extruded" grid from the idea of a "orthogonal" grid and an extruded - non orthogonal grid can be defined using the same machinery we have now?

[glwagner]

There are two things here:

1. The non-orthogonal grid needs additional metrics that are not needed for the orthogonal grid. We could generalize OSSG by adding these additional metrics. The complication is that they should all be nothing for the orthogonal case.

2. For deep vs thin shell, it's true that we can generalize OSSG to OrthogonalSphericalGrid

It might be better to implement SphericalGrid (the general case) and then replace OSSG with a type alias as a second step.