[RFC] EAMxx: Desired behavior of radiation in forward integration

[AaronDonahue]

Follow up from Dev Meeting conversation on 07-25-2025. The purpose of this issue is to store the conversation over what behavior we expect from EAMxx with respects to the radiation. Specifically having to do with timestepping.

The issue was first brought up in #7258 which observed that radiation outputs were 0.0 in some output from an ne256 run.
PR #7337, dating back to June 5th, addressed this issue by changing the logic in the radiation/cosp supercycling.
This was followed up by #7424 on July 7th, which set rad values to FillValue when rad is not run (i.e. during supercycling).
#7424 was eventually reverted by #7540 after it was determined that production runs had FillValue data for rad fields.

During the call the bottom line question was, what behavior is expected in radiation?
The simple answer is, we should try to match what EAM does.

There may be some complications with matching EAM perfectly due to differences in how EAMxx handles the first timestep.

We can discuss the plan here as well as explicitly discuss what behavior we want to implement for radiation.
Then we can set up an action plan to solve the issue.

[bartgol]

"We should match what EAM does" is not a real answer here. Or, better, it does not tell us what we need to do, since EAM timestep sequence is different, so we can't just "copy what EAM does".

[mahf708]

"We should match what EAM does" is not a real answer here. Or, better, it does not tell us what we need to do, since EAM timestep sequence is different, so we can't just "copy what EAM does".

That's a good point. I think we should detail our understanding of "what eam does" here in our own words and how they apply to EAMxx. I am personally quite poor at F90, but I will try to look into papers (not code) describing this stuff... I will also ask around

[whannah1]

Stating the obvious - radiation in the real world is a "fast" process that is always "on", although various quantities can be zero from time to time (such as short-wave fluxes). super-cycling does not mean that radiation is "off" between calls - only that radiative fluxes are not updated. During any given coupling step of the entire coupled model radiation needs to be filtered through the atmosphere to yield the fluxes needed by the surface components.

So if we are within an atmosphere step where radiation is not being updated, the previously calculated fluxes need to applied (accounting for any change in mass). Similarly, any diagnostic that involves radiative fluxes should reflect the fluxes that were applied in that step.

If instantaneous LW_flux_up_at_model_top is requested on one of these steps, the output should reflect the previously calculated fluxes. Obviously, this is "wrong" in the sense that this sort of diagnostic ignores changes in the cloud field - but by providing the "old" diagnostic TOA fluxes we are still providing a value consistent with the fluxes that should ave been applied to the atmosphere on that time step.

However, maybe I'm thinking about this wrong, and a variable like LW_flux_up_at_model_top shouldn't just "persist" across steps where radiative fluxes are not recalculated...?

I suspect that the vast majority of use cases the users are interested in averages, and aggregating these "incorrect" values makes no difference in the long-term means or qualitative assessments of things like cloud feedbacks.

[AaronDonahue]

This might be a naive question, but is it enough for us to decide what behavior we expect from radiation when

• supercycling?
• restarting?

and then spec out a plan to implement it? If so, then we can start with Walter's comment above and build on that.

Doesn't COSP throw a bit of a wrench in things as well?

[mahf708]

Doesn't COSP throw a bit of a wrench in things as well?

imho, COSP shouldn't enter the discussion here AT ALL. COSP is a diagnostic impl. For starters, it shouldn't even be an atm proc (it should be an atm diag). Second, it is very reasonable to just force users to use COSP in an extremely specific way we prescribe ahead of time. The users don't need flexibility wrt to COSP

[bartgol]

Doesn't COSP throw a bit of a wrench in things as well?

imho, COSP shouldn't enter the discussion here AT ALL. COSP is a diagnostic impl. For starters, it shouldn't even be an atm proc (it should be an atm diag). Second, it is very reasonable to just force users to use COSP in an extremely specific way we prescribe ahead of time. The users don't need flexibility wrt to COSP

Do you think we should just get started on moving COSP to be a diagnostic? I suppose the fact that COSP computes 2+ fields conflicts with the current design, so maybe we should first change the diags implementation to compute N fields inside the same diag instance... Thank you for following this latest episode of "ask a question and then give yourself an answer"!

[bartgol]

I think the behavior "rad outputs, diagnostics, and cosp should ALWAYS be available" is reasonable. I agree with Walter that if rad is not "computed" in the current step, and fluxes are kept constant to the latest computed value, then also downstream quantities (like diags or cosp) should reflect this behavior.

Assuming this is a shared feeling, the core issue becomes the RESTART process. In particular, if we allow rad to NOT run the very first step after a restart, in order to keep outputs as in the monolithic run, we are forced to write all rad fluxes (or whatever rad computes) to a restart file. This seems like a bad idea, as rad computes quite a few 3d fields. The alternative is to roll back to what we had before, where rad runs on steps 1,1+rad_freq,1+2rad_freq, etc, and ensuring that rest and rad frequencies are in agreement (i.e., rad_freq divides rest_freq). The reason we moved away from that was that asking for instant output at the exact time when rad ran was pretty much impossible, since Nout_freq and 1+M*rad_freq will never overlap except in trivial cases. However, as Walter pointed out, probably most people are interested in some sort of average output, in which case this is a non-problem. Also, if we manage to keep rad outputs "flat" between rad steps, we can also ask for INSTANT output (we will just get the values that rad computed last time it ran).

I guess what I'm saying is that we can roll back also the other PR (I forgot the number) where we made rad run on steps 1,rad_freq,2*rad_freq, etc. We can reinstate the original rad frequency scheme, and just fix whatever inconsistency we had for COSP.