I will take a stab at this, but I could be wrong.
There is some complexity involved in specifying the CO2. I think a lot of this complexity arises from two issues. First, there is a lot of historical baggage that CESM carries, and it takes a long time to change/remove things... that's why there are still parameters that have the old 'CCSM' name in them, for example. Second, as the model has evolved to be an Earth System Model and not just an "AOGCM" (to use an term that is probably out of fashion now), there are options for running an interactive carbon cycle. So there are many different configurations of "CO2" even with the supported compsets.
You haven't specified how you plan to run your experiments, so I'll try to provide a general response and you can follow up. Again, this is my current understanding, and I could get something wrong.
In coupled configurations, you can control how the CO2 works by specifying
co2_flag = [.true. | .false.]. When it is true, then the
co2flux_fuel_file can be provided to drive atmospheric CO2 as emissions. Here is an example from a
historical run's atm_in file:
Code:
&co2_cycle_nl
co2_flag = .true.
co2_readflux_aircraft = .true.
co2_readflux_fuel = .true.
co2flux_fuel_file = '/glade/p/cesmdata/cseg/inputdata/atm/cam/ggas/emissions-cmip6_CO2_anthro_surface_175001-201512_fv_0.9x1.25_c20181011.nc'
/
In the
1%/year run, CO2 is supposed to ramp up from pre-industrial values. In this case
co2_flag = .true., but no
co2flux_fuel_file is specified. Instead, the CO2 is taken from the surface "fixed lower boundary conditions." Here is how that is specified in atm_in:
Code:
&chem_surfvals_nl
flbc_file = '/glade/p/cesmdata/cseg/inputdata/atm/waccm/lb/LBC_CMIP6_1pctCO2_y1-165_GlobAnnAvg_0p5degLat_c180929.nc'
flbc_list = 'CO2','CH4','N2O','CFC11eq','CFC12'
flbc_type = 'SERIAL'
scenario_ghg = 'CHEM_LBC_FILE'
/
Another coupled case is the pre-industrial control, where CO2 should NOT be evolving. In this case again
co2_flag = .true. in atm_in, but now neither
co2flux_fuel_file nor
flbc_file are specified. Instead, the atmospheric CO2 is directly specified using
co2vmr = 284.7e-6. Note that this appears in the same sub-namelist as
flbc_file, here is the example:
Code:
&chem_surfvals_nl
ch4vmr = 791.6e-9
co2vmr = 284.7e-6
f11vmr = 12.48e-12
f12vmr = 0.0
flbc_list = ' '
n2ovmr = 275.68e-9
/
So that covers the coupled cases in "AOGCM" type of configurations. I'm not going to touch the ESM configurations. If you want to run in atmosphere-land configurations ("AMIP" or "F-case"), then the approach is similar.
For
AMIP cases, the CO2 changes in time based on observed concentrations. That is specified just like in the ramped case above:
Code:
&chem_surfvals_nl
flbc_file = '/glade/p/cesmdata/cseg/inputdata/atm/waccm/lb/LBC_1750-2015_CMIP6_GlobAnnAvg_c180926.nc'
flbc_list = 'CO2','CH4','N2O','CFC11eq','CFC12'
flbc_type = 'SERIAL'
scenario_ghg = 'CHEM_LBC_FILE'
/
For cases where the CO2 should not vary in time, such as you can specify just like in the coupled case. Here is an example from a pre-industrial case where CO2 is specified to be quadrupled:
Code:
&co2_cycle_nl
co2_flag = .true.
/
&chem_surfvals_nl
ch4vmr = 791.6e-9
co2vmr = 1138.8e-6
f11vmr = 12.48e-12
f12vmr = 0.0
flbc_list = ' '
n2ovmr = 275.68e-9
/
Just as an extra complication, you might also want the land model to use one value, but the radiative transfer to use another value of CO2. For example, the CFMIP case piSST-4xCO2-rad does this with the land using the pre-industrial CO2 and the radiation using quadruple that value. This can be specified as:
Code:
co2vmr = 284.7e-6
co2vmr_rad = 1138.8e-6
I have been setting these via
user_nl_cam. Sometimes you can use CCSM_CO2_PPMV in env_run.xml, but in this last case it is important to
not set it there because that will set the value that the land model sees.
I hope this is helpful. If you find that any of this is incorrect, let me know.
