FLBC overwrite of CO2 field

[gold2718]

What happened?

The CO2 from the FLBC file overwrites the prognostic CO2 when GHG chemistry is combined with emissions-driven CO2.

When running the default CAM7 chemistry mechanism (pp_ghg_mam4) with emissions-driven CO2 (co2_cycle, co2_flag=.true.), the fixed lower boundary condition silently overwrites prognostic CO2 in the lowest model layer.

In this configuration CO2 is both a chemistry solution species (map2chm("CO2 index") > 0) and an advected co2_cycle tracer receiving coupler surface fluxes via cam_in%cflx, applied in the bottom layer by clubb_emissions_cam (in CAM7, older versions used vertical_diffusion). Every timestep, chem_timestep_tend calls gas_phase_chemdr which calls flbc_set(vmr, ncol, lchnk, map2chm), which resets vmr(:,pver,"CO2 index") to the interpolated flbc_file value whenever CO2 is in flbc_list.

I believe this overwritten value is also passed back to the surface via cam_out%co2prog.

I believe this bug was first noticed / reported by @klindsay28.

I tried to verify that this bug is still in ESCOMP/CAM via code inspection.

What are the steps to reproduce the bug?

Run ghg_mam4 chemistry with -co2_cycle in CAM_CONFIG_OPTS.

What CAM tag were you using?

cam6_4_189

What machine were you running CAM on?

Other (please explain below)

What compiler were you using?

Other (please specify below)

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

No

Extra info

I have a fix for NorESM (which is in different files). I can propose this fix as a draft PR if you are interested. The main idea is to use a new array that is identical to map2chm except for CO2 when co2_transport is on.

[gold2718]

Note: I believe this combination is triggered with these compsets: B1850E_MTt4s, B1850EM (which I think is identical to B1850E_MTt4s), BHISTE_MTt4s, and BHISTEM (which seems identical to BHISTE_MTt4s). I think the overwrite also happens with FHIST_BDRD and F1850_BDRD.

[fvitt]

The fix should be as simple as not including CO2 in flbc_list. However, there are a few gotchas.

[adamrher]

Francis, Keith, Peter, Jesse, Haipeng and I met last week to discuss the underlying issue of incompatibility between the CO2 species in co2_cycle.F90 and in the CO2 chemical species. The major takeaway is that we will not need to resolve this incompatibility for the CESM3 release, and therefore the "Must have CESM3" tag has been removed from this issue. This is because Keith has a branch where he is implementing emissions driven CO2 capabilities entirely within the chemistry workflow, to avoid using co2_cycle and the need to resolve its incompatibility altogether. Keith's branch introduces a new config option "-co2e" that will turn on this capability. He resolves this specific issue w/ the flbc_list by adding logic to the use_case xml files that removes CO2 from the list when co2e is active.

[gold2718]

Hi @adamrher,

I have a few questions about your writeup above.

• Can you briefly explain this "incompatibility between the CO2 species"? There was an incompatibility resolved by cam6_4_186: Do not create two CO2 tracers #1581, what is the issue now (and is there a GitHub issue for it)?
• Will @klindsay28's branch handle emission-driven runs where CO2 is not a chemical specie or will that still use co2_cycle?
• Is CESM planning to run emission-driven runs using the standard GHG chemistry for CMIP7? If so, what (if anything) is being done about the FLBC overwrite issue (this issue)?