pass all CO2 fields in CO2 emissions compsets with CAM7

[klindsay28]

Description of changes

Pass all CO2 fields in CO2 emissions compsets with CAM7.
This is done by setting CCSM_BGC=CO2C.

Specific notes

Contributors other than yourself, if any: none

CMEPS Issues Fixed (include github issue #):
There is not a corresponding CMEPS issue for this.

Are changes expected to change answers? (specify if bfb, different at roundoff, more substantial)
Answers change in CO2 emissions compsets with CAM7, which are
under development and not in use yet.

Any User Interface Changes (namelist or namelist defaults changes)?
Changes flds_co2c to '.true.' in CO2 emissions compsets with CAM7.

Testing performed

ERS_Ld5 and SMS_D_Ld2 tests in an 1850 CO2 emissions compsets with CAM7 pass
on derecho-intel.
Testing was done with branches in development of CAM, CTSM, and MOM6 that enable
CO2 emissions.

[billsacks]

Can you explain why there is a move away from use of the BGC component of the compset long name? I have a few concerns with this new convention... I realize that this convention is already being used in compset long names so maybe this ship has sailed, but I'd still like to better understand it and consider whether it really makes sense.

I see that CSEG discussed this about two years ago (raised by @ekluzek ) and I raised this concern then, too. I'm not sure what happened following that point... I assume there was a breakdown in communication: https://docs.google.com/document/d/186U6-dt_wWZZGU9NzYQ5zNlMnpx9XX6oweuTXzQY-oo/edit?tab=t.0#heading=h.xjh4bj6ux171

If you weren't involved with this decision, I'd like to engage others here. If possible, I'd really like to change these long names to follow a more robust convention.

Some of my concerns are:

(1) It appears that there are now multiple ways to do the same thing, which generally feels problematic and error-prone (e.g., if current or future logic is written to handle one but not the other mechanism).

(2) It appears that a 'C' or 'E' is put at the end of the time period. As far as I know, there are no restrictions on the naming of the time period, so there could later be a time period designation that accidentally ends with C or E, triggering this logic.

(3) The match here only works with CAM7. What about DATM or other compsets? Building a robust match seems difficult with C/E at the end of the time period, which is part of why I'd prefer to see it in the BGC modifier if possible.

(4) Other components will need a similar change - e.g., there's the following in CTSM:

  <entry id="CLM_CO2_TYPE">
    <type>char</type>
    <valid_values>constant,diagnostic,prognostic</valid_values>
    <default_value>constant</default_value>
    <values>
      <value compset="_CAM"        >diagnostic</value>
      <value compset="_BGC%BDRD"   >diagnostic</value>
      <value compset="_BGC%BPRP"   >prognostic</value>
      <value compset="HIST.*_DATM" >diagnostic</value>
      <value compset="SSP.*_DATM"  >diagnostic</value>
    </values>
    <group>run_component_ctsm</group>
    <file>env_run.xml</file>
    <desc>Determines how CLM will determine where CO2 is set.
      If value is constant, it will be set to CCSM_CO2_PPMV,
      if value is either diagnostic or prognostic, the atmosphere model
      MUST send it to CLM. CLM_CO2_TYPE is normally set by the specific
      compset, since it HAS to be coordinated with settings for the
      atmospheric model. Do not modify this variable. If you want to modify for
      your experiment, use your own user-defined component set
      This is an advanced flag and should only be used by expert users.</desc>
  </entry>

[klindsay28]

I'm basing this pattern matching on compset name presented in https://docs.google.com/spreadsheets/d/1nJl4lbbwBq60quyaERJ6OvVJxF4kDu4xX7zZenZgyB8/edit?gid=1387633814#gid=1387633814 and are in use. I'm not ready to revisit the agreed upon comset naming scheme.

In CESM2 there were 2 different, and incompatible, implementations of CO2 constituents in CAM. In particular CO2 surface emissions could not be run with CO2 implemented by CAM-MOZART. This has been resolved in CESM3 by enabling surface CO2 emissions with the CAM-MOZART CO2 constituent and using the CAM-MOZART CO2, instead of the co2_cycle implementation for CO2 constituents that was used by CESM in CESM2. The 'C' and 'E' suffixes to the date string in the compset name reflects if the lower boundary condition in the CAM-MOZART CO2 tracer is a specified concentration or an emission. This PR enables passing of CO2 fields for the 'E' suffix.

The BDRD and BPRP suffixes are still available for users of the co2_cycle implementation of CO2 constituents.

So the multiple ways of doing this reflects the multiple implementations of CO2 constituents in CAM.

This PR is targeting coupled CO2 emissions based runs with CAM7, enabling exchange of CO2 fields in those compsets. I have submitted analogous PRs to CTSM, ESCOMP/CTSM#4068, and MOM6, ESCOMP/MOM_interface#336.

[billsacks]

Sorry for my delay in replying here. From the CSEG meeting yesterday, the consensus was that we want to make the specification of the CO2 forcing in the compset long name to be more similar to what was done in CESM2 - i.e., using the BGC% specifier or something similar - rather than the current mechanism of putting it at the end of the time period. I believe that @briandobbins will be initiating a discussion soon to pin this down better. I'm sorry that we didn't realize this issue earlier - causing you unnecessary additional work.

[briandobbins]

Yes, various ideas on this, and just aiming to balance what is simple and easy with what is clear and intuitive. We'll try to nail this down in the next few days, ideally. My apologies for throwing a monkey wrench into this from my own lack of understanding!

[ekluzek]

@billsacks already expressed that there is a drive to reasses the compset name change for compset long names. So I'm putting "request changes" here just to reflect that the convention to use needs to be decided there, before this can move forward.

I also point out that the description at the top will need to change.

[ekluzek]

Note that description at the top needs to change as well.

And I think if we move ahead with this convention we should also remove the _BGC%BPRP/_BGC%BDRD options. But, that should be done as a seperate step.

[ekluzek]

Although it looks like from @klindsay28 comment above:

The BDRD and BPRP suffixes are still available for users of the co2_cycle implementation of CO2 constituents.

So the multiple ways of doing this reflects the multiple implementations of CO2 constituents in CAM.

that the _BGC%BPRP/_BGC%BDRD options are still needed for some CAM configurations. So it sounds like this can't be removed because it's needed for those options.

[ekluzek]

I put some discussion and options in a CTSM issue around this here:

ESCOMP/CTSM#4078

[ekluzek]

@klindsay28 thanks for this detailed explaination here:

I'm basing this pattern matching on compset name presented in https://docs.google.com/spreadsheets/d/1nJl4lbbwBq60quyaERJ6OvVJxF4kDu4xX7zZenZgyB8/edit?gid=1387633814#gid=1387633814 and are in use. I'm not ready to revisit the agreed upon comset naming scheme.

In CESM2 there were 2 different, and incompatible, implementations of CO2 constituents in CAM. In particular CO2 surface emissions could not be run with CO2 implemented by CAM-MOZART. This has been resolved in CESM3 by enabling surface CO2 emissions with the CAM-MOZART CO2 constituent and using the CAM-MOZART CO2, instead of the co2_cycle implementation for CO2 constituents that was used by CESM in CESM2. The 'C' and 'E' suffixes to the date string in the compset name reflects if the lower boundary condition in the CAM-MOZART CO2 tracer is a specified concentration or an emission. This PR enables passing of CO2 fields for the 'E' suffix.

The BDRD and BPRP suffixes are still available for users of the co2_cycle implementation of CO2 constituents.

So the multiple ways of doing this reflects the multiple implementations of CO2 constituents in CAM.

This PR is targeting coupled CO2 emissions based runs with CAM7, enabling exchange of CO2 fields in those compsets. I have submitted analogous PRs to CTSM, ESCOMP/CTSM#4068, and MOM6, ESCOMP/MOM_interface#336.

I'm wondering what the config_component.xml changes need to look like in CAM for this to work? Right now CAM allows for an "E" in the timeperiod, but won't do anything different with it. So presumably there will be a setting for CAM that will be turned on with the "E_CAM70" that's different from the _BGC%BPRP. What exactly will that be? Presumably it will be part of the CAM_CONFIG_OPTS setting where the co2_cycle setting you refer to is...

      <value compset="_CAM40%TMOZ">-chem trop_mozart</value>

      <value compset="_CAM.*_BGC%B">-co2_cycle</value>

[klindsay28]

@klindsay28 thanks for this detailed explaination here:

I'm basing this pattern matching on compset name presented in https://docs.google.com/spreadsheets/d/1nJl4lbbwBq60quyaERJ6OvVJxF4kDu4xX7zZenZgyB8/edit?gid=1387633814#gid=1387633814 and are in use. I'm not ready to revisit the agreed upon comset naming scheme.
In CESM2 there were 2 different, and incompatible, implementations of CO2 constituents in CAM. In particular CO2 surface emissions could not be run with CO2 implemented by CAM-MOZART. This has been resolved in CESM3 by enabling surface CO2 emissions with the CAM-MOZART CO2 constituent and using the CAM-MOZART CO2, instead of the co2_cycle implementation for CO2 constituents that was used by CESM in CESM2. The 'C' and 'E' suffixes to the date string in the compset name reflects if the lower boundary condition in the CAM-MOZART CO2 tracer is a specified concentration or an emission. This PR enables passing of CO2 fields for the 'E' suffix.
The BDRD and BPRP suffixes are still available for users of the co2_cycle implementation of CO2 constituents.
So the multiple ways of doing this reflects the multiple implementations of CO2 constituents in CAM.
This PR is targeting coupled CO2 emissions based runs with CAM7, enabling exchange of CO2 fields in those compsets. I have submitted analogous PRs to CTSM, ESCOMP/CTSM#4068, and MOM6, ESCOMP/MOM_interface#336.

I'm wondering what the config_component.xml changes need to look like in CAM for this to work? Right now CAM allows for an "E" in the timeperiod, but won't do anything different with it. So presumably there will be a setting for CAM that will be turned on with the "E_CAM70" that's different from the _BGC%BPRP. What exactly will that be? Presumably it will be part of the CAM_CONFIG_OPTS setting where the co2_cycle setting you refer to is...

      <value compset="_CAM40%TMOZ">-chem trop_mozart</value>

      <value compset="_CAM.*_BGC%B">-co2_cycle</value>

@klindsay28 thanks for this detailed explaination here:

I'm basing this pattern matching on compset name presented in https://docs.google.com/spreadsheets/d/1nJl4lbbwBq60quyaERJ6OvVJxF4kDu4xX7zZenZgyB8/edit?gid=1387633814#gid=1387633814 and are in use. I'm not ready to revisit the agreed upon comset naming scheme.
In CESM2 there were 2 different, and incompatible, implementations of CO2 constituents in CAM. In particular CO2 surface emissions could not be run with CO2 implemented by CAM-MOZART. This has been resolved in CESM3 by enabling surface CO2 emissions with the CAM-MOZART CO2 constituent and using the CAM-MOZART CO2, instead of the co2_cycle implementation for CO2 constituents that was used by CESM in CESM2. The 'C' and 'E' suffixes to the date string in the compset name reflects if the lower boundary condition in the CAM-MOZART CO2 tracer is a specified concentration or an emission. This PR enables passing of CO2 fields for the 'E' suffix.
The BDRD and BPRP suffixes are still available for users of the co2_cycle implementation of CO2 constituents.
So the multiple ways of doing this reflects the multiple implementations of CO2 constituents in CAM.
This PR is targeting coupled CO2 emissions based runs with CAM7, enabling exchange of CO2 fields in those compsets. I have submitted analogous PRs to CTSM, ESCOMP/CTSM#4068, and MOM6, ESCOMP/MOM_interface#336.

I'm wondering what the config_component.xml changes need to look like in CAM for this to work? Right now CAM allows for an "E" in the timeperiod, but won't do anything different with it. So presumably there will be a setting for CAM that will be turned on with the "E_CAM70" that's different from the _BGC%BPRP. What exactly will that be? Presumably it will be part of the CAM_CONFIG_OPTS setting where the co2_cycle setting you refer to is...

      <value compset="_CAM40%TMOZ">-chem trop_mozart</value>

      <value compset="_CAM.*_BGC%B">-co2_cycle</value>

@ekluzek, in my CAM sandbox I introduced a new configure option, -co2e, with description

With this option, the chemistry CO2 constituent uses surface flux as the lower boundary condition.

This configure option is triggered based on the compset longname. There is a corresponding namelist variable mo_co2e, standing for MOZART CO2 emissions. The implementation in Fortran depends on this flag.
This sandbox is still under development so there is not yet a corresponding PR to CAM.