Add support for CO2 emissions compsets with CAM7

[klindsay28]

Description of changes

Use prognostic CO2 in CO2 emissions compsets with CAM7.

Specific notes

Contributors other than yourself, if any:

• none

CTSM issues resolved or otherwise addressed, if any:

• Resolves Change how CLM_CO2_TYPE is set from the compset longname #4078

If answers are expected to change, describe (delete this line otherwise):
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 co2_type to 'prognostic' in CO2 emissions compsets with CAM7.

Testing planned or performed, if any:
ERS_Ld5 and SMS_D_Ld2 tests in an 1850 CO2 emissions compsets with CAM7 pass.

Requirements before merge:

• I have followed the CTSM contribution guidelines.

• The code in this PR branch builds with no errors.
• The code in this PR branch runs with no errors. Briefly describe tested configuration(s):
• This either (a) does not change answers, (b) it only changes answers at roundoff level, or (c) I have performed a scientific evaluation of the answer changes. Which?:
  This only changes answers in CO2 emissions compsets with CAM7,
  which have not been vetted yet. This PR is a step towards enabling them.

• I have reviewed relevant parts of the CLM documentation Tech Note or User's Guide to determine if anything needs to be changed or added. If it does, describe:
• This PR either (a) does not create a need to update the documentation or (b) includes required documentation updates (see guidelines for contributing documentation). Which?: a

[wwieder]

Thanks @klindsay28 , will there be additional changes to CMEPS or other submodules that we need to bring in?

@ekluzek this one-liner seems simple enough, but there may be additional infrastructure / testing we need to support?

[klindsay28]

I submitted a 1-line PR to CMEPS today, ESCOMP/CMEPS#658.
That one, like this one, is only relevant for fully coupled CO2 emissions compsets with CAM7.
So I imagine that you'll ultimately pull in an updated CMEPS that has this,
but I don't think it will matter to non-CESM clones of CTSM.
(This statement is based on my understanding that non-CESM clones of CTSM are for
running CTSM only composts, i.e. not fully coupled compsets.)

There are also changes to CAM and MOM_interface, but it doesn't look like these are submodules of CTSM.

[billsacks]

As noted in the corresponding CMEPS PR, we will be changing this specification in the compset long name, so we'll need to change how this is done.

[ekluzek]

This is something that can only be tested in a CESM or CAM checkout context. From the CTSM angle it's b4b, and we should make sure that's the case, by running our normal tests.

But, when this is brought in we should make sure to do additional testing that brings the CMEPS update in, and shows that answers change for Emissions compsets.

There are no "E_CAM70" compsets currently, so the only ones are these CESM compsets: B1850E_MTt4s, B1850EM, BHISTE_MTt4s, BHISTEM.

But, also as @billsacks points out there is discussion on CO2 emissions prognostic or diagnostic should be triggered in the longname of compsets. That needs to be nailed down before moving forward. So this will be on hold until that's determined.

[ekluzek]

Actually, we should be able to test this in I compsets, with change in CMEPS and CDEPS where CDEPS sends the CO2 in the "prognostic" stream rather than "diagnostic". But, then we could have compsets and tests for this that validate the use of the prognostic CO2 stream through the coupler.

[ekluzek]

@klinday28 thanks for figuring this out and proposing this PR! Your doing that was really needed in order to get CESM moving forward on emissions driven scenarios. For such a small PR I have lengthy comments and requests for changes that aren't really directed at you -- but really CESM as a whole to decide how we are going to specify this in CESM3.

In the CSEG meeting this week we talked about how Concentration Driven vs. Emissions Driven should be specified in the compset longnames vs. the compset aliases. I created issue #4078 to reflect some of the concerns in that discussion. And I put some notes here as well. Once, that is decided we can change this to what's agreed upon and move forward with this.

I also had other comments to talk about how to test this change. Right now it can only be tested in either a CESM or CAM checkout context. So that should be part of the testing we do when bringing this in. We also should be able to setup DATM for Emissions driven scenarios as an offline "I compset" way to test this.

Once, this is decided in CESM I'll likely take this on and do the needed testing for it and bring it in. We could also end up starting a new PR -- we'll see. If we do stick with this one, please make sure I have permissions to collaborate on your CTSM fork, so I can push changes to this one.

[ekluzek]

This will trigger for any compset with an "E" on the end of the timeperiod. This will function for the convention where C or E can be given after the timeperiod. But, this isn't a very robust way to define it, since the timeperiod and the CO2 type are unrelated. The mechanism we still have in place with _BGC that you see below is more clear. But, it has the problem of being confused with the BGC setting being used for CLM (i.e. CLM60%BGC). The difference between BDRD and BPRP is also not clear below either which is part of the reason for the "C" vs. "E" convention. But, it's even less clear.

So one proposal was to have something like:

_CO2%CONC and _CO2%EMIS

which is much clearer. One problem is that we have to make the change for all components. But, the "E_CAM70" proposal requires the same, and is really not very clear at all.

[ekluzek]

Thinking about it more, this also will ONLY work if the longcompset name has E_CAM70. So Emissions compsets that aren't using CAM70 will silently do the wrong thing and end up being concentration driven. If we go with the "E" at the end of the timeperiod to specify concentration or emissions, we need a way to make sure it isn't just being silently ignored.

This isn't really a problem with what's proposed here, as much as it's a problem with compsets in general. We really need ways to do error checking to make sure they work like they should. That's a more general problem.

[billsacks]

This isn't really a problem with what's proposed here, as much as it's a problem with compsets in general. We really need ways to do error checking to make sure they work like they should. That's a more general problem.

Agreed. See ESMCI/cime#3816 - but I have no idea when I or others will get time to tackle this.

[billsacks]

Actually, we should be able to test this in I compsets, with change in CMEPS and CDEPS where CDEPS sends the CO2 in the "prognostic" stream rather than "diagnostic".

As of some recent changes that Mariana made, this should be possible already in CDEPS:

https://github.com/ESCOMP/CDEPS/blob/259be816daf8bf1eb051a018d525cac94c5bf87f/datm/datm_pres_co2_mod.F90#L86-L95

That was one part of my rationale for reworking the specification in the compsets – so that this could be more easily triggered / tested in I compsets if that's desired.

[billsacks]

Thanks for all of your thoughts here, @ekluzek - it's very helpful to have this all laid out and I appreciate the thought you've put into it!