EAMxx: enable on/off switch for linoz in mam4xx

[odiazib]

In our MAM4XX evaluation meeting, @susburrows recommended adding an option to turn off the LINOZ computation.

The namelist parameters for the LINOZ computation in the microphysics interface:

• mam4_run_linoz turns the LINOZ computation on and off.

See also PR 464.

[BFB]
I tested this branch in Frontier for two tests using mam4_run_linoz=false:

• SMS_Ln5.ne4pg2_ne4pg2.F2010-EAMxx-MAM4xx.frontier_craygnu-hipcc
• REP_Ln5.ne4pg2_ne4pg2.F2010-EAMxx-MAM4xx.frontier_craygnu-hipcc

Both cases ran without issues.

[mahf708]

@singhbalwinder @odiazib

my 2c: you should strive the support the first case below through runtime options. I would discourage the second option, but people may request it at some point for testing. I would say, just don't do the second thing until someone requests it...

1. have rrtmgp and mam use the same O3 field (say through runtime option use_consistent_o3 is TRUE), this would be one of the two below (you will add something like read_o3_from_file):

   1. runtime param read_o3_from_file is TRUE, you will only need to override O3 in MAM with o3_volume_mixing_ratio (ensuring units are consistent)
   2. runtime param read_o3_from file is FALSE, you will only need to override setting o3_volume_mixing_ratio in rrtmgp (ensuring units are consistent). The work in RRTMGP is mostlyd done, you just need to edit a few lines of code to point to the correct O3 field

2. have rrtmgp and mam use different stuff by giving users options for a runtime flag for file,linoz2,linoz3, etc., and string filename to provide for the file

[mahf708]

Not quite. Your code may actually work for the intended result, but I don't think it is a good idea to do it this way. I think you should treat rrtmgp and mam separately.

Here's what I would do:

1. in mam, I would introduce a runtime param such that we use the O3 computed from Linoz or another value read from a file. Let's call this runtime param mam4_prognostic_limoz_o3 (or whatever else you want, though I don't think mam4_compute_linoz conveys what we actually care about here).

   1. if mam4_prognostic_limoz_o3 is TRUE, then we keep the code as it was before this PR (i.e., we use the O3 calculated from Linoz in mam calculatios)
   2. if mam4_prognostic_linoz_o3 is FALSE, then we diregard the computed O3 value from Linoz, and use o3_volume_mix_ratio which is already updated and set in radiation (we just read it). All we need to do for this is to point the view of the O3 field in mam to the view of o3_volume_mix_ratio field (introduced via add_field...).

2. in rrtmgp, we need to introducde a runtime param such that we use the O3 computed from Linoz or another value read from a file. Let's call this runtime param rrtmgp_prognositc_linoz_o3 (or something else, but please be descriptive).

   1. if rrtmgp_prognositc_linoz_o3 is TRUE, then we use the field O3 (calculated from Linoz) instead of o3_volume_mix_ratio. To do this, we add_field("O3", ...) in radiation and we set the views correctly (see link below).
   2. if rrtmgp_prognositc_linoz_o3 is FALSE, we keep the current behavior as it was before the PR (o3_volume_mix_ratio is read from a file).

In other words, we will need to do modify the code in rrtmgp as well. See the logic around here.

[singhbalwinder]

if rrtmgp_prognositc_linoz_o3 is TRUE, then we use the field O3 (calculated from Linoz) instead of o3_volume_mix_ratio. To do this, we add_field("O3", ...) in radiation and we set the views correctly

@odiazib and I were just talking about this. O3 in FM is a mass mixing ratio (kg/kg of wet air). RRTMGP needs volume mixing ratio (moles/moles). We can create a helper function to do these conversions outside of RRTMGP ( somewhere inshare?), so that we call this function in RRTMGP to get the most current O3.

[mahf708]

You will need that for both O3 to o3_volume_mix_ratio and o3_volume_mix_ratio to O3. Good places for those conversions

• components/eamxx/src/physics/share/physics_functions.hpp
• components/eamxx/src/share/util/eamxx_common_physics_functions.hpp

[mahf708]

O3 in FM is a mass mixing ratio (kg/kg of wet air)

Are you sure it is wet air? I thought the convention was to defined mixing ratios in terms of dry air...

[singhbalwinder]

Are you sure it is wet air? I thought the convention was to defined mixing ratios in terms of dry air...

Yes, we followed this convention as HOMEE expects all tracers to be wet mmr. It is the responsibility of each process to convert it to dry if it requires a dry MMR.

[mahf708]

Can't you just use these two btw? calculate_vmr_from_mmr and calculate_mmr_from_vmr to get the conversions right in both radiation and mam?

[singhbalwinder]

Yeah, I just checked, they are available in EAMxx. I thought they were internal to MAM4xx. We can use one of these, calculate_vmr_from_mmr, as O3 is an mmr in FM. Before this, we can use calculate_drymmr_from_wetmmr to convert from wet to dry mmr.

[brhillman]

I talked a little about this with @singhbalwinder and @odiazib yesterday. I want to be clear that I don't really think we should treat the current treatment of o3 volume mixing ratio in rrtmgp as sacred. What we have in there is the simplest hack possible to get a prescribed ozone profile to affect radiative heating. What probably makes more sense is to move o3 concentration out of radiation, and require it as an input/field available in the FM, assumed to be computed by another process. This could be mam4, or it could be a prescribed_gases process that reads these from input, or reads/interpolates a timeseries of prescribed gases. Regardless, I think it makes sense to pick a convention for how gases are stored in the FM (dry mmr, wet mmr, vmr, etc), and then require processes that need something different (like RRTMGP needing vmr rather than mmr and needing to already convert things like water vapor) to do that themselves.

[singhbalwinder]

Thanks, Ben.
I think we discussed wet/dry mmr issue a couple of years back (here is the Confluence page). We decided that all fields in FM will be in "wet" mmr, and it is the responsibility of the physics process to convert if needed to "dry" mmr (or any other conversions). After the process is done, the mmr should be converted back to "wet" mmr (for FM). I think P3 and SHOC follow this convention, and the same is true with MAM4xx processes.

Following this convention, I think, RRTMG should get the O3 tracer from FM and convert it the way it likes to consume it. This makes RRTMGP agnostic of which process computes O3. RRTMG "assumes" that O3 is present in FM as wet mmr (similar to all other tracers).

This is different from how O3 is prescribed now in RRTMGP. It is read from a file in the units of vmr. I am not sure if it is wet or dry.

[mahf708]

I want to be clear that I don't really think we should treat the current treatment of o3 volume mixing ratio in rrtmgp as sacred. What we have in there is the simplest hack possible to get a prescribed ozone profile to affect radiative heating.

Not about sacredness of either --- more about the continuity and scientific worthiness of results. We have three options:

1. Keep the 'simplest hack possible' to prescribe the ozone profile that's been used for a while (including the SPA reference runs we've done)
2. Get the ozone profile from another file stored somewhere
3. Use a prognostic ozone profile calculated by some version of Linoz and advected around by dycore/shoc/etc.

What this PR is trying to achieve is enable ON/OFF switch on option 3 in mam. If option 3 is OFF, we have to use option 1 or option 2 in mam. It's pretty simple; otherwise, what would one do? I would vote to use the existing option 1 instead of reading a file elsewhere (though O3 is likely read as an oxidant somewhere; in eam days, random fields would be read from random files and some would be unused; maybe the same case is here...)

What probably makes more sense is to move o3 concentration out of radiation, and require it as an input/field available in the FM, assumed to be computed by another process.

I think that's already the case, no? The concentration calculation is handled in the AD somewhere. All one does in radiation is require it as input and then convert it to the appropriate units. Are you seeing something different?

[singhbalwinder]

Thanks for the very careful work!

[mahf708]

Everything on the eamxx side looks good to me and is ok to merge as-is; some minor feedback below, but nothing blocking (feel free to take or leave as you wish). I am not sure if the code is good to go when the runtime flag is false, but I trust you will figure that part out.

• the title of the PR should be something like "EAMxx: enable on/off switch for linoz in mam4xx"
• The runtime flag 'mam4_compute_linoz" may not be as clear as you intend (maybe "mam4_run_linoz" or "mam4_compute_o3_linoz", i don't have good ideas)
• the runtime flag should be set to false by default (here or in a follow-up PR, up to you)
• if you want to keep both behaviors tested, you can add a test for the non-default behavior somewhere
• you can rebase and get rid of the commits that were reverted (~5+ of the commits were essentially reverted) --- if I were you, I would make the whole thing a single commit (EAMxx: turn on/off linoz.; i.e., in the rebase, fixup everything after it)

[odiazib]

• the title of the PR should be something like "EAMxx: enable on/off switch for linoz in mam4xx"

Title updated.

• The runtime flag 'mam4_compute_linoz" may not be as clear as you intend (maybe "mam4_run_linoz" or "mam4_compute_o3_linoz", i don't have good ideas)

I liked mam4_run_linoz.

• the runtime flag should be set to false by default (here or in a follow-up PR, up to you)

Let's switch this flag to false in a follow-up PR to BFB in this PR.

• if you want to keep both behaviors tested, you can add a test for the non-default behavior somewhere

Let's do this in a follow-up PR.

• you can rebase and get rid of the commits that were reverted (~5+ of the commits were essentially reverted) --- if I were you, I would make the whole thing a single commit (EAMxx: turn on/off linoz.; i.e., in the rebase, fixup everything after it)

It is done.

[mingxuanwupnnl]

@odiazib @singhbalwinder do you know which ozone file the rrtmgp is using? I tried to look at https://github.com/E3SM-Project/E3SM/blob/master/components/eamxx/cime_config/namelist_defaults_eamxx.xml but don't have a clue yet.

[singhbalwinder]

@odiazib @singhbalwinder do you know which ozone file the rrtmgp is using?

AFAIK, it is reading ozone from the IC file. @brhillman knows more about this implementation.

[mingxuanwupnnl]

@odiazib @singhbalwinder do you know which ozone file the rrtmgp is using?

AFAIK, it is reading ozone from the IC file. @brhillman knows more about this implementation.

Thanks. That's what I heard from last MAMxx meeting. It's a bit confusing when I think about the lifecycle of ozone. Although EAMxx (alone without MAMxx) does not have dry/wet removal for ozone, it might still miss the ozone hole if just read from initial condition once. If we only use ozone from IC file for EAMxx-MAMxx, the ozone might be gradually decayed?

[singhbalwinder]

For EAMxx-MAM4xx, MAM4xx will be reading O3 from the oxidants file (which is time varying, climatological), and RRTMGP will be using O3 from the IC file. So, MAM4xx and RRTMGP will see different O3s. This is what we planned for the current implementation.

[odiazib]

@mahf708

I am not sure if the code is good to go when the runtime flag is false, but I trust you will figure that part out.

I tested the case SMS_Ln5.ne4pg2_ne4pg2.F2010-EAMxx-MAM4xx.frontier_craygnu-hipcc using mam4_run_linoz=false, and this case ran without issues.

@singhbalwinder, should we proceed to merge this PR? We must also merge PR: 465 on the mam4xx side.

[singhbalwinder]

Yes, let's start merging this. We can first merge the MAM4xx submodule PR, point this PR to MAM4xx main, and then merge this PR.