Global forecasting / spherical domain support - consolidated track

[sadamov]

I have accumulated 4 open PRs that each add a piece of global forecasting groundwork independently, plus the already-closed #211. I propose to consolidate them into a single curated PR. This is the sibling pattern to #649 (probabilistic metrics).

Why consolidate rather than merge piecemeal:

1. No global datastore exists on main, no spherical graph builder, no global model. Every PR is groundwork pointing at a target that doesn't exist yet.
2. API collisions are already in flight: [Feat] Implement area weights for grid-point averaging #258 puts area weights in metric reduction, feat: add geometry utilities for global domains (spherical coords, area weights, KNN graph) #473 puts get_area_weights() in a new geometry.py. Sequential merges lock in the conflict.
3. The closed Make boundary forcing optional to support global forecasting #211 (parked for GSoC that didn't materialise) was the fifth piece. Reviving it requires model-side context that doesn't exist yet.
4. Upstream tracking issue Merge global forecasting capabilities from prob_model_global #63 ("Merge global forecasting capabilities from prob_model_global") is broader-scope strategic; this issue is the focused implementation track.

PRs being folded in (closing with credit):

PR	Author	What gets absorbed
#258	@prajwal-tech07	area-weighted (cos-lat) grid-point averaging in metric reduction
#291	@santhil-cyber	NWP-standard evaluation metrics for global forecasting
#444	@RajdeepKushwaha5	GlobalDummyDatastore with all-zero boundary mask for testing
#473	@ayushhbasu	geometry.py (spherical coords, cos-lat weights) + graph_builder.py (KNN graph on sphere)

Plus the already-closed #211 (@nehamanoj1105) which made boundary forcing optional in the old ARModel.

API contract to design here before implementation:

1. Where area weights live: geometry.py, metrics.py, or on the datastore? Currently [Feat] Implement area weights for grid-point averaging #258 and feat: add geometry utilities for global domains (spherical coords, area weights, KNN graph) #473 propose different homes.
2. How a global datastore signals "no boundary" (all-zero mask, None, or an is_global: bool property?). Add GlobalDummyDatastore for global domain testing #444 picked one; pick the canonical one.
3. Where spherical graph construction lives: in neural-lam or upstream in weather-model-graphs? Probably the latter, with neural-lam just consuming it.
4. Whether NWP-standard global metrics (cos-lat weighted RMSE/MAE, ACC, etc.) extend DEFINED_METRICS or live in a sibling registry.

Ownership: TBD. To be decided at the next dev meeting alongside #63.

Authors of the absorbed PRs: thanks for the work. Your changes will be cited as the source for the corresponding pieces of the consolidated PR. If you want to be involved in the design discussion above, please subscribe to this issue.

[ayushhbasu]

My preference would be to treat area weights as geometric metadata rather than metric-specific logic.

Area weights are fundamentally derived from the spatial structure of the grid (e.g., latitude, cell area, spherical geometry), so the actual computation seems most naturally placed in geometry.py alongside other geometry-related utilities such as spherical coordinate transformations and KNN graph construction. While area weights are consumed by metrics, they are also useful for other downstream components and future global forecasting functionality.

Conceptually, I see the dependency flow as:

geometry.py
│
▼
datastores/base.py
(get_area_weights(),
get_cartesian_coords())
│
├─► metrics.py
├─► models.py
└─► visualization.py

In this setup:

• geometry.py computes area weights (single source of truth)
• datastores/base.py exposes area weights and Cartesian coordinates through a common interface
• metrics.py, models, and visualization components consume them without owning the implementation

This keeps geometric primitives as a single source of truth while allowing downstream components to consume them through a well-defined interface, avoiding duplication and simplifying future extensions.

Happy to hear others' thoughts on this.