Skeleton ideas for radiation interfaces

[bischtob]

Ideas for an RRTMGP.jl interface. WIP.

[glwagner]

Another idea is to add an extension for RRTMGP, which would avoid adding those explicit dependencies?

[glwagner]

this probably belongs in test/ directory

[glwagner]

we can also create a validation directory for user-like scripts that are not formal tests but just for sandboxing stuff

[bischtob]

Yes. This belongs into test.

[glwagner]

Can you explain how we have both a grid argument as well as a lat argument (eg latitude?) In the case of any curvilinear grid, we can extract the latitudes from the grid itself so would not need an independent input. But I might be misunderstanding how this should work. I could also imagine that radiation works only with column grids (eg RectilinearGrid with (Flat, Flat, Bounded) topology)

[bischtob]

Yep, we'll have to extract the latitude from the grid.

[bischtob]

Basically, you have to supply for each column where it is located in latitude. This could be derived from the grid.

[glwagner]

Can you explain how we have both a grid argument as well as a lat argument (eg latitude?) In the case of any curvilinear grid, we can extract the latitudes from the grid itself so would not need an independent input. But I might be misunderstanding how this should work. I could also imagine that radiation works only with column grids (eg RectilinearGrid with (Flat, Flat, Bounded) topology)

[bischtob]

Another idea is to add an extension for RRTMGP, which would avoid adding those explicit dependencies?

Can you elaborate?

[glwagner]

Another idea is to add an extension for RRTMGP, which would avoid adding those explicit dependencies?

Can you elaborate?

an "extension" is a feature of the package manager that allows conditional code loading. There is some documentation here:

https://pkgdocs.julialang.org/dev/creating-packages/#Conditional-loading-of-code-in-packages-(Extensions)

by convention, we implement extensions in a directory ext. We usually create the extension as a module (or nested modules) with a specific name; in this case it would be BreezeRRTMGPExt.

There are several examples in Oceananigans, eg:

https://github.com/CliMA/Oceananigans.jl/tree/main/ext

For example, we have extended Oceananigans architecture/device interface to support CUDA, AMDGPU, intel oneAPI, and Metal. All of the methods / functionality necessary to use these devices is contained in corresponding extensions, eg:

https://github.com/CliMA/Oceananigans.jl/blob/main/ext/OceananigansMetalExt.jl

The extension packages become weakdeps in Project.toml, and the extension is added to a list under the heading [extensions]:

https://github.com/CliMA/Oceananigans.jl/blob/49c0a09b0e5e56b27b42780c3448297c5dd4b683/Project.toml#L57

on the user side, they will invoke RRTMGP by writing

using Breeze
using RRTMGP

# etc

in other words RRTMGP is not shipped in Breeze by default, but must be loaded / part of the user environment.

This design enforces modularity --- if we wanted to discontinue support for RRTMGP in the future, all we have to do is delete the extension. Conversely, adding support for other radiation codes is relatively simple because we have defined the interface.

[navidcy]

what's an "execution context"?

[glwagner]

I'm not sure. It might be the ClimaComms equivalent of what we call "architecture" in Oceananigans.

I think we should move all of this into an extension so that we don't pollute the source code with ClimaComms stuff, but this will be easy.

[glwagner]

@bischtob do you understand the distinction between "context" and "architecture"?

[bischtob]

I believe they are equivalent, but I am not 100% certain in all cases (e.g., distributed).