Model name

[emlawer]

This implementation is based on RTE+RRTMGP (https://agupubs.onlinelibrary.wiley.com/doi/10.1029/2019MS001621), but the name provided here for the implementation only mentions RRTMGP. I hope this can be corrected. Also, the full name of the model on the github page is not correct. The full name of RRTMGP is "RRTM for General circulation model applications—Parallel" while RTE stands for "Radiative Transfer for Energetics".
These codes were developed by Robert Pincus, Eli Mlawer, and Jennifer Delamere.

[glwagner]

@emlawer to clarify this request, are you suggesting to rename this package? For example, the package could be renamed to RTERRTMGP.jl ?

I think the same comment may apply to a python-JAX implementation here: https://github.com/climate-analytics-lab/jax-rrtmgp . There is no mention of RTE in the README for that package, or Jennifer Delamere's contributions.

Here's a relevant quote from the RTE+RRTMGP paper:

The toolbox consists of two related code bases: Radiative Transfer for Energetics (RTE), which computes fluxes given a radiative transfer problem defined in terms of optical properties, boundary conditions, and source functions; and RRTM for General circulation model applications—Parallel (RRTMGP), which combines data and algorithms to map a physical description of the gaseous atmosphere into such a radiative transfer problem.

Another paragraph states:

Like its predecessors, RRTMGP uses a k‐distribution for computing the optical properties and source functions of the gaseous atmosphere based on profiles of temperature, pressure, and gas concentrations, while RTE computes fluxes using the Independent Column Approximation in plane‐parallel geometry.

It seems like an alternative design might also implement "RTE" (a radiation solver based on the independent column approximation) in a different package. This "radiation solver package" could then be made compatible with radiation property packages, including RRTMGP and ecckd.

Something that eludes me is why the rte-ecckd project: https://github.com/earth-system-radiation/rte-ecckd needs to depend on both RTE and RRTMGP. Should rte-ecckd depend only on RTE and not on RRTMGP?

@milankl may be interested in this discussion.

[RobertPincus]

@glwagner Thanks for your response. There are a couple distinctions to be made (maybe @milank is also interested).

@emlawer can correct me but I understand that, according to the authors, the name of the model is RRTM, with variations RRTMG and RRTMGP. It is not, as I understand it, an abbreviation for "Rapid Radiative Transfer Model." (This is like how the band's name is REM, not Rapid Eye Movement.)

More broadly, although we've considered keeping RTE and RRTMGP as separate repos on the Fortran side, RRTMGP depends on infrastructure provided by RTE. On the Fortran side we are building new optics parameterizations (a simple spectral model is under active development, as is a framework for computing actinic fluxes and photolysis rates; we have ambitions to implement data-driven quadrature as well.) The current plan is to keep these all in a single repo, but to rename the package to "RTE" at release 2.0 in the first part of this year.

rte-ecckd is deprecated.

I've opened #591 in case you want to address @emlawer's concerns about naming. Depending on how disruptive it would be you could also consider renaming the Julia package to RTE.jl to align with coming changes to the Fortran.

[milankl]

Why not give it a name that's not a 3 to 9 letter acronym but easier to remember and possible to pronounce? Sounds like a good chance if you want to change the name anyway?

We originally had thought about using RRTMGP.jl (I always need to double check that the order of letters is correct 🤣 ) but then were pushed off by it doing the parallelisation for you. If there's some modular functionality that could be called within a kernel and takes a horizontal index ij such that we can do kernel fusion with other parameterizations that's what we'd rather look for. Because in SpeedyWeather we fuse all parameterizations into single kernel launched over all ij independently doing one parameterization after another. Multiple dispatch on the GPU then allows us to have all the modularity we want.

[glwagner]

thank you @RobertPincus ! If #591 is all that is needed, the concern was indeed smaller than I realized.

On the Fortran side we are building new optics parameterizations (a simple spectral model is under active development, as is a framework for computing actinic fluxes and photolysis rates; we have ambitions to implement data-driven quadrature as well.) The current plan is to keep these all in a single repo, but to rename the package to "RTE" at release 2.0 in the first part of this year.

I am excited to see those developments!

Depending on how disruptive it would be you could also consider renaming the Julia package to RTE.jl to align with coming changes to the Fortran.

It is perhaps neither here or there, but I agree with @milankl that descriptive names can be useful.

Would it be useful to have a package that provides solvers / kernels based on the plane parallel approximation as its core functionality? And then the utility might support a variety of optics models within that framework, including RRTMGP, ECCKD, and future data-driven ones as well?

[RobertPincus]

@glwagner We have in the past considered breaking the RTE repo out from optics packages. We decided against that. Some reasons perhaps @skosukhin could explain; others revolve around the ability to leverage the testing infrastructure. But it also reflects the fact that RTE provides infrastructure alongside the solvers - several classes needed to represent radiative transfer problems, more classes for post-processing spectrally-resolved fluxes, and a template and helper classes for interfacing with (gas) optics. So for the moment at least we will keep the package together.

[milankl]

Sounds like a situation for a monorepo to me. Diviing up functionality into subpackages and registering them separately can be a bit of an effort but just means that people (incl yourself) can reuse parts of the repo without depending on everything. And forces you to think about interfaces.

[milankl]

Let me know if you want to share some experience regarding monorepo, we just monorepoed SpeedyWeather and while it takes a while to understand how Julia monorepos are supposed to be setup (this is better documented now) I'm quite happy with it and would generally recommend it for any package that's large with conceptually many subpackages that are developed together.