EAMxx: need for and design of a prescribed chemistry process

[brhillman]

The purpose of this issue is to open up the discussion about the design and implementation of a separate chemistry process. The immediate use case for this is to move the handling of gases out of the radiation interface and provide for some kind of time-varying prescribed ozone process, but we should probably think ahead to how we would eventually want an interactive chemistry process to be implemented. That is, if we implement prescribed chemistry as a separate process now, we should design it such that the API can remain somewhat unchanged when we eventually add an interactive chemistry option.

Note that for the immediate use case of allowing for time-varying ozone concentrations, we could just hijack SPA to include seasonally-varying, cyclic ozone, but this is probably not the long-term solution we want if we are eventually going to add interactive chemistry to EAMxx.

This issue is related to the need/want for time-varying forcing data, and a prescribed chemistry process might need to allow for the following three use-cases, discussed on various EAMxx calls:

1. Constant (but spatially-varying) concentrations
2. Time-varying prescribed concentrations
3. Cyclic concentrations, to include the case where we have a multi-year dataset of forcing but want to cycle through a specific year

Even if this remains a process just to handle prescribed chemical species right now (like prescribed ozone), I think it makes sense to move the handling of these to a separate process rather than expecting radiation to handle them, as the current treatment kind of breaks the concept of encapsulation/separate of concerns.

[whannah1]

Rather than a generic prescribed chemistry process I wonder if it makes more sense to have separate prescribed ozone and trace gas processes with a "shared" set of methods that can be used for other prescribed chemistry and/or aerosol processes? Maybe the better terminology would be to have separate "sub-processes" for each prescribed constituent within the parent prescribed chemistry process?

I'm thinking about how we might handle the mixing and matching of various prescribed and prognostic things. Perhaps we end up with prescribed CO2 alongside a semi-prognostic methane scheme (i.e. prescribed in the troposphere and diagnosed by linoz in the stratosphere).

I'm also thinking about how separate processes might be more flexible when the input data and need for updating is different across species. For example, maybe we have annual global mean CO2 and monthly spatially varying O3 - separate processes would make it very clear what is happening internally.

[whannah1]

Another part of this discussion I find particularly interesting is the optical property calculations. @mahf708 and I were discussing this yesterday and a seemingly sensible approach is to make every chemistry/aerosol scheme be responsible for the optical property calculations of the tracers they are also responsible for updating. But does this also make sense for all prescribed trace gases like N2, CO2, CH4, etc?

[mahf708]

While I think it makes sense to want to design a chem proc for the future, I do think people should consider handling prescribed aerosols and chemistry in a simple unified approach in existing SPA (renaming it is an option). These things (aerosols, chemistry) are interconnected, and the tools will be there in the same general area, which will make things simpler and more efficient, software-wise. For readability, it also helps if similar things are treated similarly in the same region of the code. My worry is that figuring out a truly generic chem proc whose API can remain unchanged is a tall order, considering there's no concrete plan to have a chem proc now (we don't know exactly what it will/not have)

Regardless, scientifically, I think the following options are important for chemical species that are radiatively active; for each one,

1. choosing spatially varying or not (well-mixed)
2. choosing interpolation (ramping in lingo of eam) or not (fixed in lingo of eam, i.e., step function year bounds)
3. choosing transient or static cyclical forcing

[crterai]

I agree with the sentiment that we can't expect to make something that will remain unchanged with time and that anticipates future compatibility. If we can manage it, it would be nice to make it a little less painful in the future though. For now, what we need is a capability to run both transient simulations (F20TR and WCYCL20TR) as well as cyclic simulations (e.g., F2010, F1850, or WCYCL1850) that pretty much behave the same way they do when running with EAM (unless there are things that clearly need to be improved from how they have been done).

For these simulations, we may or may not run with MAM4xx, which means that we'd run with or without prescribed aerosols from SPA. That's part of my arguments for having a process separate from SPA. But I could be convinced of putting everything under a larger process with the appropriate flags determining whether we use SPA or MAM4xx or we run SPC or not. There's also the consideration of some backward compatibility, which I would imagine those running simulations would prefer to have.

As for whether we make the chemistry/aerosol scheme provide the optical properties or not, I'd be curious to hear from @brhillman about how they're treated in RRTMGP. For aerosols, my impression is that they are passed aerosol optical properties (rather than aerosol concentrations). For gases, is it the same? Or do they take in the radiatively-active gas concentrations? At this point, I don't think we want to tinker heavily with the RRTMGP code to make things work, unless there's strong motivation to do so. So I think this simplified 'chemistry' process should just provide the inputs that RRTMGP takes as input for running the radiation.

And I imagine this process with then handle the 1, 2, 3's of Ben and Naser's comments based on the inputs regarding the configuration of the simulation. I think we have all of the tools for doing them except for the step-function interpolation method of EAM, but maybe not?

[crterai]

I've also added the word 'prescribed' to the title so people who are unfamiliar don't start thinking that we're talking about adding an interactive chemistry scheme into EAMxx.

[brhillman]

I've also added the word 'prescribed' to the title so people who are unfamiliar don't start thinking that we're talking about adding an interactive chemistry scheme into EAMxx.

@crterai this is fine, but I was under the impression that part of this discussion was about designing the interface for (and the need/want for) a full interactive chemistry in the future. I'm fine leaving this as a prescribed discussion though. In that case, I'd probably suggest we just hijack SPA for now, especially if prescribed chemistry is a ways off on the roadmap.

Regarding optical properties, this is a nice idea in theory, but calculation of the gas optics is fairly involved and intricately tied to RRTMGP/RRTMG. I think this starts to get into a conversation about which processes you want to break the separation of concerns: either the prescribed gas processes know more than they should need to about the radiation, or radiation knows more than it should about the chemical processes. I'm not sure which is worse. Might require a more careful survey of the code to determine this. But, in the spirit of keeping like-handled processes together like @mahf708 suggested, right now all of the gas optics are calculated together in RRTMGP given volume mix ratios and RRTMGP's absorption coefficient data. Splitting this up into individual subprocesses of chemistry would probably get a lot less efficient.

[whannah1]

Is it too late to rebrand "SPA" as "SPAC" for "Simple Prescribed Aerosols and Chemistry"?

I also want to share a relevant line of thought following a recent friendly argument with @mahf708.

It seems that the original underlying philosophy of SCREAM aimed to maximize the independence of processes (for the sake of better software engineering). I can attest that many of the headaches I've encountered working with CAM/EAM stem from the haphazard way that various processes are coupled together. So I fully understand the allure of the notion that we should strive for a more "modular" model where processes can be easily combined at will.

However, I've since come around to the idea that the haphazard coupling of prior model generations is a good thing(!) because each of these instances were rooted in a desire to make the model more realistic. Almost none of these things can be considered independent in the real world. I've even heard arguments that the separation of processes in LES models is problematic! We might be tempted to make an argument about the disparity of characteristic time scales between two processes, but I doubt it would hold up to close scrutiny across a range of plausible scenario that our model needs to be cabale of addressing.

Thus, it seems that maximizing process independence for the sake of better software is incompatible with maximizing the realism of the model. I'm sure many will disagree, but I feel pretty strongly that this is a reality of our field. How do we all get on the same page about how to strike a balance in this impossible tradeoff????

I predict we will eventually end up with our own unique set of haphazardly coupled physics schemes no matter how much we try to avoid it. So maybe we should just start embracing that now? For example - in the context of prescribed chemistry, this might mean not worrying about a consistent interface across multiple chemistry schemes and just having if blocks to switch between different calls based on which processes are active.

[bartgol]

I don't know anything about atm modeling, but I'll share my thoughts on separation of concerns and software.

I have pushed for separation of concerns as much as I could, and sometimes it backfired dramatically, as much needed hacks ended up making certain things a bit "obscure" (see pg2 hacks here and there). This taught me that maybe we should separate as much as possible, but leaving a path for a few spaghetti here and there. The trick, is to make the spaghetti connections trackable and well defined. So if we can make the interaction between 2+ processes well defined and not hidden, I think that's ok. E.g., we could foresee an upgrade to the atm proc interface that allows a process to specify which other processes it needs to know about (e.g., "rrtmgp needs to know whether there is a chem process" or "shoc needs to know if tms is present"). I think Walter is right, in that the model is so complex that we cannot achieve a perfect tree-like structure of the code, and we may be doomed to always see some cyclic connections. Alas, making those more "official" via ad-hoc interfaces may be a reasonable tradeoff between code clarity and model efficacy.