I’ve been trying to restart a historical run with no success. I want to restart it from year 1960 and apply some perturbations.
What I’ve done so far:
git cloned the esm-historical configuration directory
changed start year at config.yaml to 1960
changed ‘inidate’ and ‘init_date’ to 19600101 in ice/input.nml
changed ‘model_basis_time’ to 1960
changed the following in warm_start.sh: project=p66; user=cm2704; expname=HI-14; source_year=1960 and run the warm start scripts
when running the warm start script I’ve got the following warnings:
/g/data/hh5/public/apps/miniconda3/envs/analysis3-23.04/lib/python3.9/site-packages/mule/stashmaster.py:259: UserWarning:
Unable to load STASHmaster from version string, path does not exist
Path: $UMDIR/vn7.3/ctldata/STASHmaster/STASHmaster_A
Please check that the value of mule.stashmaster.STASHMASTER_PATH_PATTERN is correct for your site/configuration
warnings.warn(msg)
/g/data/hh5/public/apps/miniconda3/envs/analysis3-23.04/lib/python3.9/site-packages/mule/validators.py:198: UserWarning:
File: work/atmosphere/restart_dump.astart
Field validation failures:
Fields (1114,1115,1116)
Field grid longitudes inconsistent
File grid : 0.0 to 358.125, spacing 1.875
Field grid: 0.5 to 359.5, spacing 1.0
Extents should be within 1 field grid-spacing
Field validation failures:
Fields (4935,4937,6676,6715)
Skipping Field validation due to irregular lbcode:
Field lbcode: 31320
warnings.warn(msg)
If I try to put the model to run it crashes at the very begging with payu error code 134. This seems to be related to forcing/restart files and the same warning as above appears in the payu error log file.
Any ideas on how to make this restart work are welcome.
I’m still not able to restart any historical CSIRO run. For now, I’ve started my own historical simulation from scratch (previous PI control). However, I will need to run an ensemble; so, figuring out how to restart historical CSIRO run would save lots of computational time.
In time, I’ll also need to run a CMIP6 SSP126 scenario with some perturbations applied. I could find a payu configuration for the SSP585 scenario (GitHub - coecms/esm-ssp585), but not SSP126. Is the SSP126 setup somewhere else? If not, is it possible to configure this run for payu?
Hi @gpontes. I am not familiar (yet) with the payu framework and I am still running ACCESS-ESM1.5 in a script based environment. However there are a number of people who have done restarts from different runs and points in time. Maybe @tammasloughran or @ariaan have any suggestions?
Hi @gpontes. With regards to setting up an SSP126 run, this should be relatively straight forward. We ran SSP126 with ACCESS-ESM1.5 for CMIP6 (but not with payu) and all the forcing files are available. @holger has been helping in the past with converting the script based setup with ACCESS-ESM1.5 into payu. However, since we already have an SSP585 payu setup it should be relatively easy to copy this and replace the forcings etc. with SSP126. I can help with providing the relevant forcings, but again I am not familiar with payu.
Related to the error you were getting:
I have poor knowledge about the payu configurations as well, but I get the same error code (134) you are getting, even when I try to run a simulation freshly cloned from the repo (after setting source=PAYU in the warm-start.sh file).
So I believe the error does not relate to the change in the restart date. I am going to write an issue on the Github repo and email @holger about it (unless he replies to this post).
For the setup of SSP126 simulation, you can follow what @tiloz suggested (thank you @tiloz for your reply!)
Many thanks. I’'l try to simply replace the SSP585 forcing files with the ones from SSP126.
I get back to you in case I have any issues or am unsure about the forcing files.
Unfortunately, I have not been able to get any response on my help request for ACCESS-ESM1.5 historical repo error.
Just to make sure we’re talking about the same repo though, can you please point out which repo you were trying to use that produced the error code 134?
I tried replicating your error, and what you described happens to me as well.
I am going to write an email to @holger to hopefully solve this issue.
Just a question on the error you are getting:
When you run the warm-start.sh file, after the warnings you mentioned, do you also get the following output?