CCSM_CO2_PPMV logic issues

[jedwards4b]

From CESM_DEVELOPMENT issue 121

There are some problems with CCSM_CO2_PPMV as it stands now:

It apparently doesn't do anything for many CLM/CAM compsets, or for any compsets without CLM. For transient runs, the CO2 isn't constant, regardless of configuration. For runs using BGC BPRP/BDRD, WACCM, or some CAM-CHEM compsets, the model chemistry is producing non-constant CO2 concentrations, and there is also typically some time/space varying boundary condition for concentrations or emissions at the surface. It is potentially confusing that we have this switch that looks very important, but often does nothing.

Note that some compsets actually set CCSM_CO2_PPMV to some tiny value to try to get the model to crash or do something crazy if CLM tries to actually use this value. However, besides being just one more hack that can confuse new users, this has some mixed results.

For instance, my recollection is that CESM 1.1.0 had exactly the kind of bug that the unrealistic CO2 value was intended to prevent, accidentally using -co2_type constant for a CAM compset. Indeed, the low value of CO2 was noticed by Mike Mills. However, this didn't happen until shortly after the release, which forced us to do an "emergency" CESM 1.1.1 release immediately afterward. If we still need to check for this error (which seems much less likely to happen in the current scripts), we should use a guard that will actually cause an automated test to fail, rather than requiring a human to notice that a bug is producing unrealistic output.

It's not actually necessary to coordinate this value between CAM and CLM. If CAM is on, CLM never uses -co2_type constant, and therefore CCSM_CO2_PPMV is ignored by CLM. If CAM is off, there is no possibility of having an inconsistent CO2 value between components. We still need CLM_CO2_TYPE to be set in the CIME scripts, because it has a different value based on whether or not CAM is on, but the actual CO2 concentration can be defined by the CAM/CLM use cases, without setting it at the CIME level.

In fact, CAM already sets the CO2 concentration in some use cases, but this is overridden by CIME, which is another potential source of confusion. Again, we have settings that look important, but are not actually used, except in CAM standalone builds. See, e.g., the discussion in #108.

If we remove CCSM_CO2_PPMV and just set the value in CAM/CLM use cases, the only real issue is that some CLM climatological runs could potentially drift from their CAM counterparts (e.g. I1850 runs could accidentally use a different value than F1850 for CO2). This does not seem too high a risk (especially since these values are changed so rarely), but it is present.

Note also that Erik proposed that DATM set this value for I compsets, rather than a CLM use case. It's not clear to me that either approach is superior. This value is used by CLM itself, not DATM, however, if a CLM use case is used, it may not be obvious to CLM users that the value in the use case is ignored when CAM is on. So it could be good to have the atmosphere component always be the one providing a value (even for data models).

There are a some little silly issues with the implementation that we wouldn't have to address if this variable just goes away. For instance, the outdated CCSM prefix, and the fact that you can't use scientific notation in the value (at least for CAM).

CC @ekluzek @brian-eaton @billsacks

I am marking this as a backwards compatibility issue, because the current {cam,clm}.buildnml scripts won't work properly without CCSM_CO2_PPMV defined, and because we don't want the components to start ignoring this variable until it's time to actually remove it. (Otherwise, some scientist using a beta tag might try to rely on this variable, unaware that it no longer does anything.)

[klindsay28]

Actually, CCSM_CO2_PPMV does get used in compsets without clm. It is used by POP's build-namelist script to set defaults for different POP namelist variables. Please take into consideration if this variable is to be altered.

[rljacob]

This has been fixed.

[mvertens]

This has actually not been fixed on the component side for CESM. Please reopen this issue.

…

On Fri, Apr 7, 2017 at 11:55 AM, Robert Jacob ***@***.***> wrote: This has been fixed. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#863 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHlxE8Dl5Hfjx68QLycGAkeMAr8S535zks5rtnh1gaJpZM4LArX7> .

[mvertens]

Also this variable needs to be totally removed in CIME from the CESM config_component_cesm.xml.

…

On Fri, Apr 7, 2017 at 11:55 AM, Robert Jacob ***@***.***> wrote: Closed #863 <#863>. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#863 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHlxE8Dl5Hfjx68QLycGAkeMAr8S535zks5rtnh1gaJpZM4LArX7> .

[rljacob]

There was some change you made to CO2 values in config_components that we were thinking of. Sorry to get it mixed up.

[mvertens]

No problem. Thanks for reopening this. I need to have this done before the release.

…

On Fri, Apr 7, 2017 at 8:05 PM, Robert Jacob ***@***.***> wrote: There was some change you made to CO2 values in config_components that we were thinking of. Sorry to get it mixed up. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#863 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHlxE9-CWuWX2Lp1w3nXfOE1AYQgcjMiks5rtuuBgaJpZM4LArX7> .