Skip to content

Generalize VarDims to VarLocation and make domains explicit in all variables definitions - #194

Merged
bgroenks96 merged 31 commits into
mainfrom
bg/var-domains
Oct 5, 2026
Merged

bgroenks96 merged 31 commits into
mainfrom
bg/var-domains

Conversation

@bgroenks96

@bgroenks96 bgroenks96 commented Sep 20, 2026 •

Copy link
Copy Markdown
Collaborator

This PR is a continuation of #193 that makes a few wide reaching changes to the variable system to accommodate the new spatial domains defined by LandGrid:

  • Adds VarDomain with four subtypes: Ground, Snow, Canopy, and Surface, the latter of which supports 2D surface/skin variables only and does not correspond to a domain in LandGrid
  • Adds VarLocation which consists of both a VarDims (XY or XYZ) and a VarDomain
  • Allows variables to be defined at fixed points along an axis (typically the vertical axis) via Coordinate; concrete use cases are Top and Bottom which allow fluxes to be defined at the top Face or Center of a grid axis. The resulting Field is constructed with indices set accordingly. This differs from a 2D field with Nothing location in that Oceananigans treats the Field as having a specific location on the axis rather than having no location at all (see discussion in Issues with bloated model state and long compile times #66)
  • As a consequence of the above, 2D Top or Bottom located Fields are now indexed in kernels with i, j, end rather than i, j, 1

Closes #178
Closes #182

@bgroenks96
bgroenks96 added this pull request to stack #195 September 20, 2026 14:56

@olivierbonte olivierbonte left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think in general that his a nice addition. Main omments:

  • Ideally (low prioririty), you would also have the option to not be forced to use a variable domain (e.g. for simple models)
  • Surface is always a bit of an ambiguous term (top of soil/snow vs. interface). Here goal is for it to function as interface, but this can become a bit uncelar for some configurations( e.g. canopy air space as interface, or canopy temperature being used as surface temperature so then not belonging to the canopy anymore if you set it as Surface)
  • Would be nice to have separate domain for atmospheric inputs

Comment thread docs/src/running/input_sources.md Outdated
Comment thread docs/src/running/input_sources.md Outdated
Comment thread examples/extending/linear_ode_exp_growth.jl Outdated
Comment thread examples/hybrid_models/neural_snow_melt.jl Outdated
Comment thread examples/simulations/speedy_dry_land.jl Outdated
Comment thread src/processes/surface/runoff/direct_surface_runoff.jl Outdated
Comment thread src/abstract_variables.jl Outdated
Comment thread src/abstract_variables.jl Outdated
Comment thread test/surface/hydrology/surface_runoff_tests.jl
@bgroenks96
bgroenks96 force-pushed the bg/var-domains branch 2 times, most recently from 106a8b9 to 3cc4cad Compare September 24, 2026 13:52
@bgroenks96
bgroenks96 marked this pull request as ready for review September 24, 2026 14:09
@bgroenks96

Copy link
Copy Markdown
Collaborator Author

@maximilian-gelbrecht I may need your help with this Reactant test failure. None of my fixes so far work.

@olivierbonte olivierbonte left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only some minor comments on domain choices. I am not that familiar with the interals, but all changes seem reasonable / logic to my limited understanding.

Comment thread docs/src/extending/state_variables.md Outdated
Comment thread docs/src/running/input_sources.md Outdated
Comment thread docs/src/running/input_sources.md Outdated
Comment thread examples/extending/simple_snow_ddm.jl Outdated
Comment thread src/grids/column_ring_grid.jl Outdated
Comment thread src/processes/surface/canopy_interception/canopy_interception.jl Outdated
Comment thread test/surface/hydrology/surface_runoff_tests.jl
Replace literal `[i, j, 1]` vertical indices with `[i, j, end]` throughout the
kernel functions. A variable declared at the top or bottom of a domain is stored
at that interface rather than at `k = 1`, so `end` is the index which resolves
correctly for every slab field: `XY` and `Bottom` fields give 1, a `Top` field
at `Center` gives `Nz`, and a `Top` field at `Face` gives `Nz + 1`.
Move fluxes and other quantities which exist at a single interface from the
domain's bare `XY()` dimensions to `Top()` or `Bottom()`, so that the
declaration states where the variable lives rather than leaving it
implicit.

Stepping a prognostic declared at an interface also required a fix to
`explicit_step!`, which dispatched on the vertical location parameter alone.
`XY` and `XYZ` lost their docstrings when they were converted from `@kwdef`
structs to type aliases, which left every existing `[`XY`](@ref)`/`[`XYZ`](@ref)`
in the documentation unresolvable. `Top`, `Bottom`, and the four `VarDomain`
markers were not previously documented.
Hopefully fixes a ReactantError arising from `apply_type_with_promotion`
@bgroenks96

Copy link
Copy Markdown
Collaborator Author

The reactant errors are fixed but at the cost of loosening type bounds in 2d832d4 which I am not happy about. This change should be reverted when the upstream bug is fixed.

@olivierbonte olivierbonte left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me all looks good now!

@bgroenks96

Copy link
Copy Markdown
Collaborator Author

I will wait for @maximilian-gelbrecht to comment on this before merging.

@maximilian-gelbrecht maximilian-gelbrecht left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this. I just think that it needs to be documented a bit better in the main docs and examples.

The Reactant issue has been fixed and a new released will probably issued within the next days. Do you want to wait for this or adjust in a follow up?

Comment thread docs/src/extending/coupling_processes.md
Comment thread examples/extending/linear_heat_conduction.jl
Comment thread examples/extending/simple_snow_ddm.jl Outdated
Comment thread src/diagnostics/surface_fluxes.jl
Comment thread src/domains.jl
@bgroenks96

Copy link
Copy Markdown
Collaborator Author

Do you want to wait for this or adjust in a follow up?

I would look at it again in a follow-up PR.

Comment thread docs/src/extending/state_variables.md
@bgroenks96

bgroenks96 commented Oct 5, 2026 •

Copy link
Copy Markdown
Collaborator Author

It seems that the Reactant "fix" actually broke our build again...

Either that or the merge broke something. I'll have Claude investigate.

@bgroenks96
bgroenks96 merged commit ed652ed into main Oct 5, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

3 participants