ACCESS-CM2 pacemaker set ups

Hi all,

I am wanting to setup a pacemaker experiment in ACCESS-CM2, using a different restoring climatology for each model year.
I already know how to set up an experiment that restores to the same climatology for each model year over a region mask. This is done by adding the following to



and changing lines in this file



However I want to change the file that is used to restore at each model year/cycle or use one restoring file that has 50 years of data instead of 12 months to restore

I am hoping someone will be able to assist in setting this up?

It would be similar to the pacemaker setup in this study but using SST restoring

Thanks in advance!

1 Like

Similar work has been done on ESM, however I forgot how to and need do dig it out. Meanwhile, to make it simple we can just copy Dave’s run (u-bx973):




However, need to be noted that Dave has modify the code:
so that you need to use his suit


cp -rf /home/599/dhb599/ACCESS-CM2/submodels/mom5_access2_TASST $CYLC_SUITE_SHARE_DIR/mom

If you can not access P66, I have copied to


Let me know if you need more info.


Thanks so much for this!
I’ll take a look and let you know how it goes in the next few days.

I am assuming that this means the restoring SST file needs to be labelled in this format where $THISYEAR is the model year? So if I change this the directory and file name to where I have my specific yearly climatology files as long as it has $THISYEAR it should work right?

My restoring files would be monthly, so I assume they would work, or do they need to be daily?

monthly should work.

Thanks again
The bx973 suite looks like it is a branched historical experiment. My other pacemaker experiment is branched from a piControl experiment.

I am wondering if there is much I need to change, to ensure that runs are identical except for the SST restoring values? just turn off time varying gas mmr and change restart files/dates?

In other suites I have used, there is usually a warm restart directory, start date etc under Run Initialisation and cycling, but in this suite that I have copied it seems to be under jinja2 but this also has other options like things for ozone which I am not sure is the same as the other suite.

This is side by side view of the suites left is bx973 copy I am modifying and right is my first experiment that has run (cw323)

I am also wondering, what is the restoring timescale in this suite, or do you know how to check/change?

Let me know what if you can answer any of this, thanks!


Also, for the SST restoring file, what should the time dimension look like? I can’t check Daves files as I don’t have permission. This is what I have at the moment:

        double TIME(TIME) ;
                TIME:long_name = "time" ;
                TIME:units = "days since 0000-01-01 00:00:00" ;
                TIME:time_origin = "01-JAN-0000 00:00:00" ;
                TIME:modulo = 365.242492675781 ;
                TIME:axis = "T" ;
                TIME:calendar = "gregorian" ;

if based on piControl, your changes are shown as following:


if [ -d mom ] ; then
  rm -rf mom
module load git
#dhb599: git clone -b CM2-0.1 $CYLC_SUITE_SHARE_DIR/mom
#dhb599: use local code modified for the SST pacemaker exp
cp -rf /home/599/dhb599/ACCESS-CM2/submodels/mom5_access2_TASST $CYLC_SUITE_SHARE_DIR/mom

Dave modified the mom code directly.




The rest keep using the one from piControl. (follow yours no need to use Dave’t)

as for the starting year ( I guess, you can give a test. Getting old can’t remember everything sorry, but I hope this is the one)



The modified code is in Dave’s home directory which isn’t necessarily accessible to everyone. It should be pushed to GitHub. Probably as a branch on a fork, but even better if it could be incorporated into MOM5 in a way that it could be “turned on” with a namelist option or compiler pre-processor flag.

NB: Arnold, I modified the suite changes to be in code blocks instead of block quotes. That way whitespace is preserved correctly, long lines are rendered better and it is simple to copy the code changes with the in-built copy to clipboard functionality of code blocks. Hope that is ok.

Many thanks, Aidan!!! Somehow code blocks are not working with my school email address but my personal one, many thanks for your help.

Dave’s code … mmmm I will have a separate email with you. But many years ago Arrian has done one without changing the code. I need to double-check with her. I forget how to do it.

1 Like

Dear all,

Many thanks to Zoe and Ariaan for their assistance, and a special thanks to Holger @HoWol76HoWol76 for generously creating the instructions on how to run the pacemaker experiment in CM2 without modifying the MOM code (following Dave’s approach).

The idea is to prepare all of your SST files (not just a single file) in advance. Then, when the model runs each year, you submit the corresponding SST file for that specific year along with it.

More details please refer to
Holger’s note:


1 Like

Hi thanks for this @holger @ars599
I have a question based on an error I got.

I followed the instructions above in my own suite (u-cy286). In step 3 in the config file you need to define the location of the SST files (FILE_TEMPLATE) and the place that the files are copied to for the model to read from - (SST_FILE).
FILE_TEMPLATE works fine, but the error relates to SST_FILE.

I defined SST_FILE as below.


This is based off a different suite where there is restoring but SST file doesn’t change.

This ended up giving an error after 1 model cycle, when update_sst runs again. Basically, the directory I am telling the code to copy the new SST file doesn’t exist yet. Here is the job.err

cp: cannot create regular file '/home/561/sm2435/cylc-run/u-cy286/work/09520101/coupled/OCN_RUNDIR/INPUT/': No such file or directory
[FAIL] <<'__STDIN__'
[FAIL] '__STDIN__' # return-code=4
2023-07-12T23:17:08Z CRITICAL - failed/EXIT

So, the script failed when it tried to copy the file to the location of SST_FILE
The job.out file suggests that the update_sst script did not fail when it tested this directory in the start of the script which is weird, I think it must only test if you have set the variable, maybe better to make it test whether the directory exists?

So I would like to know

  1. Does the location of SST_FILE matter? can it just be the same directory for each (I don’t think so, as looking at the previous run cycle of other run and these input files all appear in a similar spot)
  2. How can we fix this to make sure that these directories are made prior to this running?

I am thinking maybe we can add a line in the script that creates the directory if it doesn’t exist, but not sure if this will cause issues e.g.

mkdir -p ${SST_FILE}

Let me know your thoughts

Actually, here are the changes I have made to the steps shown above. This appears to be working so far.
I added some lines before the copy of the restoring file is made

test -z ${SST_FILE_DIR} && exit 5
mkdir -p ${SST_FILE_DIR}

For this to work, I changed app/update_sst/rose-app.conf, to look like this:



And in metadata file app/update_sst/meta/rose-meta.conf I added these lines:

description=directory to send SST File to
help=directory for SST file expected by model

Making these changes worked so that the next cycle could start without the work/09520101/coupled/OCN_RUNDIR/INPUT/ having been created by the coupled job. The coupled job is now running fine

Hi Sebastian

The process I described in my little how-to assumes that the model expects the Sea Surface Temperatures to be located in a specific file.

The new task then overwrites this file every year with a new one.

So SST_FILE is the file to be overwritten and FILE_TEMPLATE is the template of where to find the file which should become the new sst file (with the text YEAR to be replaced by the actual year).

So say


Then when the task runs, it would look for the year, say 1998, and then execute this command:

cp /g/data/w40/hxw599/sst_updates/ /scratch/w40/hxw599/access/expt/um/data/

And then the next year, it would run the command:

cp /g/data/w40/hxw599/sst_updates/ /scratch/w40/hxw599/access/expt/um/data/

thus overwriting the previous file. (Of course the data file on /g/data remains untouched.)

As for your error, I would suspect that the directory /home/561/sm2435/cylc-run/u-cy286/work/09520101/coupled/OCN_RUNDIR/INPUT/ does not exist. I don’t know how best to solve this.