Change long name specifier for CO2 forcings

[billsacks]

Description of changes

We have decided to use the CESM2 scheme for this.

See ESCOMP/CMEPS#658 for some relevant discussion.

I did this with two regex search & replaces:

(1) Concentration-driven:

• Search for <lname>([^_]*)C_(.*)</lname>
• Replace with <lname>$1_$2_BGC%BDRD</lname>
• Update 2026-06-18: we later decided to remove the _BGC%BDRD from these compsets

(2) Emissions-driven:

• Search for <lname>([^_]*)E_(.*)</lname>
• Replace with <lname>$1_$2_BGC%BPRP</lname>

This should be coordinated with the following component changes:

• This should come in at the same time as the CAM PR that changes compsets similarly: cam6_4_187: Change specification for CO2 concentration-driven compsets CAM#1584
• Ideally, this CTSM PR and this CDEPS PR would come in at the same time. However, it's safe for either or both of them to come later. (The reason that it's ideal for them to come in at the same time is just to ensure that they are bit-for-bit across a wide range of configurations - so it would be ideal to include them in the bit-for-bit prealpha testing that is planned for this PR.)
• For emissions-driven compsets to work correctly, this also needs the changes in this CAM PR; however, emissions-driven compsets currently aren't tested, so it's safe for that CAM PR to come in later

Specific notes

Contributors other than yourself, if any: none

Fixes: none

User interface changes?: No

Expected answer changes: Bit-for-bit for concentration-driven compsets (which are the only ones currently tested). (B1850E* and BHISTE* compsets would change answers, but we currently don't test them.)

Testing performed (automated tests and/or manual tests):

Ran these tests; they pass and are bit-for-bit:

• ERS_Ld5.ne30pg3_t232.B1850C_LTso.derecho_intel.allactive-defaultio
• ERS_Ld5.ne30pg3_t232.BHISTC_LTso.derecho_intel.allactive-defaultio
• ERS_D_Ld3.ne30pg3_t232.B1850C_LTso.derecho_intel.allactive-defaultio

[billsacks]

@klindsay28 - can you please look over these changes and verify that I have made the correct changes to the compsets?

@briandobbins - FYI

[billsacks]

I originally did this with two regex search & replaces:

(1) Concentration-driven:

• Search for <lname>([^_]*)C_(.*)</lname>
• Replace with <lname>$1_$2_BGC%BDRD</lname>

(2) Emissions-driven:

• Search for <lname>([^_]*)E_(.*)</lname>
• Replace with <lname>$1_$2_BGC%BPRP</lname>

But it sounds like we may be using CONC / EMIS rather than BDRD / BPRP, so I changed those in a follow-up commit.

[billsacks]

I'm changing this to a draft because it sounds like the exact specifier (CONC / EMIS, BDRD / BPRP, ...) is still under discussion.

[billsacks]

Based on discussion this morning, we're going to use _BGC%BDRD and _BGC%BPRP after all, so I have reverted to those specifiers and marked this ready for review. This will need to be coordinated with at least a CAM tag... I'll figure out all the component coordination needed soon.

[billsacks]

@klindsay28 - based on our recent discussion, I'm questioning whether I did the right thing here with the concentration-driven compsets: My initial thinking was that I should change the comcentration-driven compsets to BDRD, but based on our discussion a couple of days ago, should those actually have no _BGC specifier?

[billsacks]

@klindsay28 - based on our recent discussion, I'm questioning whether I did the right thing here with the concentration-driven compsets: My initial thinking was that I should change the comcentration-driven compsets to BDRD, but based on our discussion a couple of days ago, should those actually have no _BGC specifier?

@klindsay28 - also a similar question for CAM: do you know if these compsets should have _BGC%BDRD or no _BGC specifier?:

https://github.com/ESCOMP/CAM/blob/9e9c1371e6c3b8aafa6d1c7480cac7988335f163/cime_config/config_compsets.xml#L437-L469

[billsacks]

@klindsay28 - based on our recent discussion, I'm questioning whether I did the right thing here with the concentration-driven compsets: My initial thinking was that I should change the comcentration-driven compsets to BDRD, but based on our discussion a couple of days ago, should those actually have no _BGC specifier?

@klindsay28 - also a similar question for CAM: do you know if these compsets should have _BGC%BDRD or no _BGC specifier?:

https://github.com/ESCOMP/CAM/blob/9e9c1371e6c3b8aafa6d1c7480cac7988335f163/cime_config/config_compsets.xml#L437-L469

Looking into this a little more myself, I see that most of the B compsets in CESM2 had _BGC%BDRD; this makes me think that _BGC%BDRD may be the right thing to do here, too. (However, I see that the WACCM compsets did not have any _BGC specifier in CESM2.) But most F compsets in CESM2 did not have a _BGC specifier, so I'm wondering if that behavior should be maintained for CESM3 as well??

But my confidence here is very low, so I'm looking forward to clarity from @klindsay28.

[mvertens]

@billsacks - my understanding is that _BGC%BDRD or _BGC%BPRP turns on an emission driven scenario (based on triggering CO2C) and the lack of _BGC%XXX triggers concentration driven scenario (based on triggering COA). This can also be seen based on what happens in CAM with co2_cycle. I'm happy to chat about this.

[gold2718]

@billsacks,
_BGC%BDRD is emission driven but CO2 is radiatively passive (implemented by setting co2_cycle_rad_passive=.true. in CAM_NAMELIST_OPTS which sets CO2 as a passive species in the rad_climate namelist variable).

[billsacks]

@mvertens and @gold2718 - thank you both for this input! I think the main question at this point is: what is the intent for CESM3? Based on what you two have said and the understanding I've gotten from conversations with @klindsay28, I'm starting to think that the intent is that the compsets that previously had a C at the end of the time period should now have no _BGC specifier. I'd like confirmation from @klindsay28 on that. Note that that would mean that we currently don't have any _BGC%BDRD compsets, in contrast to CESM2, where most B compsets were _BGC%BDRD. I'll push a commit here that makes this change, for review.

I'm also realizing that there will probably be answer changes to any compset that now has a _BGC specifier, since this specifier changes behavior in various components. That means that at least the emissions-driven compsets - with BGC%BPRP - will change answers. If the concentration-driven compsets map to having no BGC specifier, then I think they won't change answers, but if they map to BGC%BDRD then I think they'll change answers, too.

[billsacks]

I'm also realizing that there will probably be answer changes to any compset that now has a _BGC specifier, since this specifier changes behavior in various components. That means that at least the emissions-driven compsets - with BGC%BPRP - will change answers. If the concentration-driven compsets map to having no BGC specifier, then I think they won't change answers, but if they map to BGC%BDRD then I think they'll change answers, too.

Oh, it looks like we currently don't have any tests of the B1850E or BHISTE compsets, so I think that the latest version of this PR (which maps concentration-driven compsets to no BGC specifier) should be bit-for-bit in testing.

I like the idea that this will be bit-for-bit in testing, partly because I'd like to be assured that the changes to the compset matches in RUN_STARTDATE don't change answers for any tests.

[billsacks]

Based on discussion with @klindsay28 we're actually inclined to use _BGC%BDRD for most B compsets. According to Keith, even though this leads to a coupling of CO2 fluxes, this just leads to extra diagnostics and doesn't impact the evolution of the system. So, as far as model evolution is concerned, _BGC%BDRD is equivalent to not having a _BGC specifier, and so really is effectively concentration-driven. It is preferable in terms of having additional diagnostics; the possible downside is the performance cost of the additional tracers.

I have therefore backed out my last commit (9dbf792), which removed the _BGC%BDRD from concentration-driven compsets. (To keep git history simpler I force pushed to remove that commit from history, but it should still be available on GitHub for a while.)

I have some tests in the queue to verify that _BGC%BDRD indeed doesn't change answers, and to check the performance impact. (However, derecho seems overloaded right now, so I don't know how soon they'll actually run.)

[billsacks]

Based on discussion with @klindsay28 we're actually inclined to use _BGC%BDRD for most B compsets. According to Keith, even though this leads to a coupling of CO2 fluxes, this just leads to extra diagnostics and doesn't impact the evolution of the system. So, as far as model evolution is concerned, _BGC%BDRD is equivalent to not having a _BGC specifier, and so really is effectively concentration-driven. It is preferable in terms of having additional diagnostics; the possible downside is the performance cost of the additional tracers.

@mvertens and @gold2718 - I'm interested to hear how this sounds to you. Do you see something wrong with this logic based on your understanding of the system? (I'd be happy to find a time to talk about it if that would be easier.)

[gold2718]

@mvertens and @gold2718 - I'm interested to hear how this sounds to you. Do you see something wrong with this logic based on your understanding of the system? (I'd be happy to find a time to talk about it if that would be easier.)

Here is our understanding of the system. I am checking these statements against the ESCOMP code (not NorESMhub):

TL;DR: We believe that _BGC%BDRD is not the same as a concentration driven compset.

Details:

• Both BDRD and BDRP set CCSM_BGC = CO2C (in cmeps/config_component_cesm.xml)
• BGC_MODE="CO2C" sets flds_co2c = .true. (cmeps/config_component_cesm.xml line 2472)
  • Side note: Any CAM compset will have both 'Sa_co2prog' and 'Sa_co2diag' set
• flds_co2c also adds 'Fall_fco2_lnd' and 'Faoo_fco2_ocn' (so CO2 from surface) in the CAM cap (atm_import_export.F90).
• Both BDRD and BDRP set -co2_cycle in CAM which is the trigger for emission-driven runs in CAM (config_component.xml line 156)
  • Side note: In ESCOMP/CAM, co2_cycle requires aircraft emissions
• co2_cycle turns on fossil fuel emissions in CAM (e.g., 'co2_readflux_fuel' and 'co2_readflux_aircraft') for transient runs (e.g., NHIST but not 1850 or 2000 in ESCOMP/CAM)
• Turning on _BGC%BDRD in CAM sets co2_cycle_rad_passive=.true. (config_component.xml line 387). I would expect this to affect the simulation.

By the way, the description on line 30 of config_component_cesm might be misleading here.

There are also mentions of BDRD in CICE, CLM, and MOM but I did not investigate.

[klindsay28]

Steve is correct, I stand corrected. I was mistakenly still thinking of co2_cycle constituents as separate from the rest of the system in BDRD compsets. This is no longer the case with Steve's CAM PR, as the co2_cycle CO2 constituent points to the MOZART CO2 constituent. Apparently I haven't completely wrapped my head around the full consequences of the CAM PR.

…

On Wed, Jun 17, 2026 at 4:09 AM goldy ***@***.***> wrote: *gold2718* left a comment (ESCOMP/CESM#407) <#407 (comment)> @mvertens <https://github.com/mvertens> and @gold2718 <https://github.com/gold2718> - I'm interested to hear how this sounds to you. Do you see something wrong with this logic based on your understanding of the system? (I'd be happy to find a time to talk about it if that would be easier.) Here is our understanding of the system. I am checking these statements against the ESCOMP code (not NorESMhub): TL;DR: We believe that _BGC%BDRD is not the same as a concentration driven compset. Details: - Both BDRD and BDRP set CCSM_BGC = CO2C (in cmeps/config_component_cesm.xml) - BGC_MODE="CO2C" sets flds_co2c = .true. (cmeps/config_component_cesm.xml line 2472) - Side note: Any CAM compset will have both 'Sa_co2prog' and 'Sa_co2diag' set - flds_co2c also adds 'Fall_fco2_lnd' and 'Faoo_fco2_ocn' (so CO2 *from* surface) in the CAM cap (atm_import_export.F90). - Both BDRD and BDRP set -co2_cycle in CAM which is the trigger for emission-driven runs in CAM (config_component.xml line 156) - Side note: In ESCOMP/CAM, co2_cycle requires aircraft emissions - co2_cycle turns on fossil fuel emissions in CAM (e.g., 'co2_readflux_fuel' and 'co2_readflux_aircraft') for transient runs (e.g., NHIST but not 1850 or 2000 in ESCOMP/CAM) - Turning on _BGC%BDRD in CAM sets co2_cycle_rad_passive=.true. (config_component.xml line 387). I would expect this to affect the simulation. By the way, the description on line 30 of config_component_cesm might be misleading here. There are also mentions of BDRD in CICE, CLM, and MOM but I did not investigate. — Reply to this email directly, view it on GitHub <#407?email_source=notifications&email_token=ADWZPO4UELIOXVCV42XTHBT5AJU6VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZSHA2TSMZQGYY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4728593061>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADWZPO4AVCRDHRBUWLQEFCT5AJU6VAVCNFSNUABFKJSXA33TNF2G64TZHMYTCMBYGY4TCNBYHNEXG43VMU5TINRSGUYDKNZRHE2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ADWZPO3COQSHHV3A6X5CNO35AJU6VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZSHA2TSMZQGYY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/ADWZPO2FHGW6CD7XCHSWXH35AJU6VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZSHA2TSMZQGYY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[gold2718]

@klindsay28, while my draft PR fixes a bug in current CAM, my analysis was done on today's ESCOMP/(CAM,CMEPS) code. While I think it is true that running _BGC%BDRD today will not affect the model state, I do not think that running _BGC%BPRP will either, at least not correctly since all the emissions go into the second CO2 tracer which is ignored by the rest of the model.

[billsacks]

Thank you for sharing your analysis of this, @gold2718 . Based on your input and further discussion with @klindsay28 we have decided to have no _BGC specifier for concentration-driven compsets for now. We might revisit that later, but for now that will allow these compsets to remain bit-for-bit with their previous behavior, which is useful for testing this PR and the linked PRs in CAM, CTSM and CDEPS.

I have updated this PR accordingly - both with the changes to config_compsets and changing the top-level PR description. I think it's finally ready for review.

[fischer-ncar]

@billsacks It looks like we'll be ready to start prealpha testing for this as soon as the CAM tag is made. So if the PR is ready, you can merge it.