Generalize VarDims to VarLocation and make domains explicit in all variables definitions - #194
Conversation
olivierbonte
left a comment
There was a problem hiding this comment.
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
106a8b9 to
3cc4cad
Compare
|
@maximilian-gelbrecht I may need your help with this Reactant test failure. None of my fixes so far work. |
74d0e61 to
e7b4cbe
Compare
olivierbonte
left a comment
There was a problem hiding this comment.
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.
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.
Hopefully fixes a ReactantError arising from `apply_type_with_promotion`
5b8bda6 to
2d832d4
Compare
Co-authored-by: Olivier Bonte <65309133+olivierbonte@users.noreply.github.com>
|
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
left a comment
There was a problem hiding this comment.
For me all looks good now!
|
I will wait for @maximilian-gelbrecht to comment on this before merging. |
maximilian-gelbrecht
left a comment
There was a problem hiding this comment.
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?
I would look at it again in a follow-up PR. |
aaef46b to
4ede916
Compare
4ede916 to
4a64b63
Compare
|
It seems that the Reactant "fix" actually broke our build again... Either that or the merge broke something. I'll have Claude investigate. |
16b35bf to
8813eb2
Compare
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:VarDomainwith four subtypes:Ground,Snow,Canopy, andSurface, the latter of which supports 2D surface/skin variables only and does not correspond to a domain inLandGridVarLocationwhich consists of both aVarDims(XYorXYZ) and aVarDomainCoordinate; concrete use cases areTopandBottomwhich allow fluxes to be defined at the topFaceorCenterof a grid axis. The resultingFieldis constructed withindicesset accordingly. This differs from a 2D field withNothinglocation in that Oceananigans treats theFieldas 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)ToporBottomlocatedFields are now indexed in kernels withi, j, endrather thani, j, 1Closes #178
Closes #182