Catch cases where DATM_CO2_TSERIES = none but CCSM_BGC=CO2A or CO2C

[mnlevy1981]

trafficstars

Summary: CESM uses CCSM_BGC to control which components are expecting to send / receive CO2, but datm triggers a flds_co2 flag based on DATM_CO2_TSERIES. Despite that setting, it seems like datm still advertises the co2 fields when CCSM_BGC=CO2A and DATM_CO2_TSERIES=none, but in that case I get errors if I try to receive them in the ocean.

---

Long Version

Over in the MARBL driver for MOM, I'm working on adding an option to allow MOM6 to get CO2 concentration from the coupler. In a test run, starting with a CMOM compset, I set CCSM_BGC=CO2A but left DATM_CO2_TSERIES=none. Since DATM_CO2_TSERIES=none, datm sets flds_co2 to False:

https://github.com/ESCOMP/CDEPS/blob/296dfaad895623cae6ef3abcd9796ac9bfa152f2/datm/cime_config/namelist_definition_datm.xml#L295-L306

And I would think that is enough to avoid advertising Sa_co2prog and Sa_co2diag:

https://github.com/ESCOMP/CDEPS/blob/69e550218bb722372162965d2ab3d26ea2a6e3d6/datm/datm_datamode_core2_mod.F90#L136-L139

However, these lines from med.logstarted showing up when I set CCSM_BGC to CO2A (leaving DATM_CO2_TSERIES=none):

 (Advertise Fields):Fr_atm: Sa_co2prog
 (Advertise Fields):Fr_atm: Sa_co2diag
 (Advertise Fields):To_lnd: Sa_co2prog
 (Advertise Fields):To_lnd: Sa_co2diag
 (Advertise Fields):To_ocn: Sa_co2prog
 (Advertise Fields):To_ocn: Sa_co2diag

And it's unclear where they are coming from. Also, the model crashes if I try to actually access those fields:

20230413 122708.723 ERROR            PET0000 ESMF_GeomBase.F90:923 ? Object being used before creation  - Bad Object
20230413 122708.723 ERROR            PET0000 ESMF_FieldGet.F90:447 ESMF_FieldGetDefault Object being used before creation  - Internal subroutine call returned Error
20230413 122708.723 ERROR            PET0000 MED-TO-OCN:src/addon/NUOPC/src/NUOPC_Connector.F90:3007 Object being used before creation  - Passing error in return code
20230413 122708.723 ERROR            PET0000 ESM0001:src/addon/NUOPC/src/NUOPC_Driver.F90:2882 Object being used before creation  - Phase 'IPDv05p4' Initialize for connectorComp 1 -> 4: MED-TO-OCN did not return ESMF_SUCCESS
20230413 122708.723 ERROR            PET0000 ESM0001:src/addon/NUOPC/src/NUOPC_Driver.F90:1924 Object being used before creation  - Passing error in return code
20230413 122708.723 ERROR            PET0000 ensemble:src/addon/NUOPC/src/NUOPC_Driver.F90:2725 Object being used before creation  - Phase 'IPDv02p3' Initialize for modelComp 1: ESM0001 did not return ESMF_SUCCESS
20230413 122708.723 ERROR            PET0000 ensemble:src/addon/NUOPC/src/NUOPC_Driver.F90:1895 Object being used before creation  - Passing error in return code
20230413 122708.723 ERROR            PET0000 ensemble:src/addon/NUOPC/src/NUOPC_Driver.F90:481 Object being used before creation  - Passing error in return code
20230413 122708.723 ERROR            PET0000 esmApp.F90:134 Object being used before creation  - Passing error in return code
20230413 122708.723 INFO             PET0000 Finalizing ESMF

I can think of several possible solutions:

1. Change the default for flds_co2 to be based on CCSM_BGC instead of DATM_CO2_TSERIES, and then throw an error if flds_co2 is true but DATM_CO2_TSERIES is none
2. Change the default for flds_co2 to be (DATM_CO2_TSERIES != none) && (CCSM_BGC != none), and also fix whatever bug is causing CESM to advertise Sa_co2prog even if flds_co2 is false
3. throw an error if DATM_CO2_TSERIES is none but CCSM_BGC is not

and I'm not terribly familiar with this code, so maybe somebody from the land side should chime in? I wouldn't be surprised if @ekluzek pointed out something in the above options that may cause problems for CTSM, and if he has an alternate solution I'd be all for it.

[ekluzek]

I'm pretty sure this is also a problem for CTSM. But, we don't run this way, so we don't see it. But, I do agree that we want the user to be informed that this is setup wrongly and to give an error and let them know how to fix it.