How to switch from emissions-driven/interactive carbon cycle to a concentration-driven configuration in ACCESS-ESM1.5

(This user story is still incomplete. Stay tuned.)

User story

I wanted to run an ACCESS-ESM1.5 simulation that branched from an interactive carbon cycle simulation, but continued to run in a concentration-driven mode. In this simulation, I want to prescribe the atmospheric CO2 concentrations from the original interactive simulation.


This kind of simulation is useful for differentiating biogeochemistry and biogeophysics separately. For example, a simulation with land-use change, and a simulation without land-use change but the CO2 concentration as if land-use change occurs, allows for the biogeochemical effects to be isolated and removed by differencing.

Current workflow

  1. Create a time series of the required CO2 forcing
    • I used variable code fld_s00i252, long_name = “CO2 3D TRACER MASS MIXING RATIO”
    • Averaged values over the whole atmosphere, except for the top-most layer. (There are some anomalous values up there).
  2. Create the CLMCHFCG namelist
    • this namelist sits in the CNTLATM file and contains timeseries of greenhouse gas concentrations.
    • L_CLMCHFCG=.TRUE. turns on the prescription of CO2 concentrations.
    • CLIM_FCG_NYEARS(n) is an array of length 11. Each element is the number of years for each gas type.
    • CLIM_FCG_YEARS(:,n) is an array of years for each gas type up to CLIM_FCG_NYEARS(n).
    • CLIM_FCG_LEVLS(:,n) is the gas concentration in mass mixing ratio at each year up to CLIM_FCG_NYEARS(n)
    • After the final year in the table the mass mixing ratio are held constant.
    • The greenhouse gases are:
      • 1: co2
      • 2: methane
      • 3: n2o
      • 4: cfc11
      • 5: cfc12
      • 8: cfc113
      • 9: hcfc22
      • 10: hfc125
      • 11: hfc124a
    • since my simulation branches from an ssp585 simulation, I used constant ssp585 2030 values for the non-CO2 greenhouse gasses.
  3. Disable interactive carbon cycle in the namelist file.
    • L_CO2_EMITS=.FALSE.,
  4. Add the namelist entries to the ACCESS-ESM1.5 configuration.
    CSIRO ksh scripts
    • Turn off interactive CO$_2$ co2_flag=0 and co2_flag_o
    • Ensure that the emissions-driven STASHC file is used. There is an if clause that uses a different stash file, but this causes the expected restart variables to change. ACCESS-ESM1.5 will output a co23d variable but it will contain garbage.
    • same as above for the CNTLATM file.
    • Add the namelists to the ed commands near the end of the script.
  5. Run.


Too many prognostic variables in the restart file

The CSIRO ksh scripts use an old stash table when co2_flag=0. When this stash table is used, ACCESS expects a certain number of variables to exist in the restart dump. The CO2 tracer variable is the extra prognostic variable in this case. I simply used the stash table from the interactive carbon simulation. This means that the co23d variable will exist in the output, but it will contain garbage values.


Are you using the ksh scripts because that experiment isn’t set up with payu or because it is easier to modify in ksh than payu or that’s what you know?

How did you do that? f90nml is a great Python package to work with namelist files. In your case, it might help with setting the time series for the concentrations. And the package is used by payu so the maintenance is currently ensured.


I’m using the ksh scripts out of convenience. The simulation I’m branching from is 400 years into one of the global warming level simulations (the stabalized climate simulations branching from SSP585, with 0 emissions, but interactive co2). The original SSP585 scenario exists in payu but not the global warming level simulation. Tilo used the ksh scripts for those, so it’s easier for me to make a few minor changes to those. But I do have to understand those confusing scripts first so it could be easier. I’ve certainly run into problems, but I’ll add those roadblocks to the user story soon.

Manually. Copy/paste in a text editor. It was not fun.

Many thanks for the hint! I didn’t know about f90nml :slightly_smiling_face:

I’ve run this for 1 year so far.
In the first hour of the next year it has crashed with the error:

 UM ERROR (Model aborting) :           
 Routine generating error: Bi_linear_h 
 Error code:                     10    
 Error message:.                       
over-writing due to dim_e_out size     

Which seems to be doing some interpolation of wind fields. Does anyone have any ideas on how to troubleshoot this/seen this problem before?



The most given reply is to restart from the latest restart file but applying a small perturbation first. Or restart with a slightly smaller timestep.

The error is usually a sign the atmosphere is unstable and a small change in timestep or restart values is usually enough to get it through. Obviously, check that the latest outputs are still acceptable as well :slight_smile: .

1 Like

Hey Tam,

Try this to perturb the latest dump.

module use ~access/modules/pythonlib

module load umfile_utils

module load python2

python2 ~access/apps/pythonlib/umfile_utils/ FILE


1 Like

That didn’t seem to help at all. It still crashed right at the start of the second year of simulation.

From memory 7.3 errors in bi_linear are analogous to BicGstab errors in later versions of the UM. These are in Helmholtz numerical solvers, and you’re probably right in the wind. These errors are notoriously difficult to trace (like several weeks of chasing geese), may just be a numerical instability, and often (if you are lucky) perturbing the most recent dump and restarting might get past the problem. However, this in no way precludes the very likely possibility that something is indeed wrong.

IDK what you are changing, so as a contrived e.g. lets say you Aforrest a cell by changing the PFT fractions map. The soil properties might not have a corresponding value at the new active location and a NaN is generated. This enters the atmospheric at the surface and propagates into the wind. A Nan enters the solvers and you get the error you have found. The fact that it has run for a year, and crashes shortly after that suggests that the dump written at the end of the first year isn’t fully equipped to initialise the 2nd year? How often does it restart? i.e. is this the first AND is this doing LUC yearly? AND what are you changing?

Problem solved. I think this error turned out to be a land-use change problem. I had land use change turned off in my simulation, but I was still injecting new land-use maps into my restart files.

I’m revisiting this at the moment.

In addition to the CLIM_FCG_ namelist variables, there are also the following namelist variables:


Which does the same thing as far as I know. I’m told that possibly the CLIM_FCG_ variables are for specifying a time series where as the _MMR variables are for specifying a constant concentration in time. However a varying concentration could also be achieved by changing the _MMR variables each year…

  • Is one overwritten by the other if both are defined in a namelist file?
  • I’m assuming they are in the same units?

It would be good to have namelist file documentation, but I can’t find anything like this in the UM documentation.

1 Like

Documentation of the namelist items is in the rose metadata, e.g. /g/data/access/rose-meta/um/um-atmos/vn13.4/rose-meta.conf. Its going to be most usable if you’re using rose edit, but you can manually search the metadata too:

description=Specify CO2 mass mixing ratio for whole run (kg/kg)
help=Absorption by carbon dioxide may be included only if relevant data are
    =present in the spectral file. An appropriate mass mixing ratio must
    =be set here unless a more complex scheme is used.
    =WDCGG value for 2010 = 5.910e-04 kg/kg
ns=namelist/UM Science Settings/section01/gas

description=List of values for growth for active gas CO2
ns=namelist/UM Science Settings/section01/gas/clmchfcg/co2

description=No. of years at which forcing rate is specified for active gas CO2
ns=namelist/UM Science Settings/section01/gas/clmchfcg/co2

That’s great Scott! Many thanks!