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 /roses/u-exp/app/coupled/rose-app.conf
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?
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)
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)
(Aidan Heerdegen, ACCESS-NRI Release Team Lead)
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 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.
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/temp_sfc_restore.nc': No such file or directory
[FAIL] update_sst.sh <<'__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
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)
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 update_sst.sh script that creates the directory if it doesn’t exist, but not sure if this will cause issues e.g.