How do I start a simulation from a different date?

Hello,

I am trying to run AMIP simulations with ACCESS-CM2 and I would like to conduct an experiment where I run a 4 month simulation for a random year. I am trying to figure out how to initialise the model with a random start date instead of the default 19750101T0000Z. Do I need to create my own initialisation files from a previous control run and then restart the model from a new date with the outputs from the previous run as the new input files (like a warm restart)? Or is there another way to go about this?

Thanks!

Hi Sramana,

What date are you looking to start from? I have start dumps for the 1st of every month from 2015-2019 at this stage, if that helps? (for nudged AMIP style runs). @Matt_Woodhouse might have some more files too.

In an older version of ACCESS (CMIP5 version) - I ran an ā€˜ensembleā€™ of simulations, and used start dumps from the ā€˜wrongā€™ year, but just had to make sure the month/day was right. Then had a year of spin up that I removed. I assume that the later version can do the same - so I guess it depends on what you are trying to do!

1 Like

Hi Sonya,

Thanks for that, that was very helpful.

Iā€™m trying to run a 3 month simulation (DJF) for any ā€œrandomā€ year that is initialised on 1st November of the same year. I think the ā€˜ensembleā€™ approach you mentioned would work well here. Iā€™m looking for some help with how to go about it, specifically how to create my own start dumps and where to find some existing ones. Do you have any advice for me?

Iā€™ve got a few years of 1st nov restarts which I can share with you if you like. Iā€™m not sure there are any for that time in the access project (I only had a quick look). Otherwise someone else might have some - you just need to ask around I guess - again looking at someone from CSIRO probably. Other than that - if you do a longer run then start dumps are automatically created and saved in the output and you just need to then save them somewhere for later use.

3 Likes

Hi Sramana,

Using existing restart dumps, for example those suggested by @sonyafiddes makes sense and saves you time.
However, depending on how many different simulations (restart dumps) you need, your best approach (but more time-consuming) might be to produce the restart dumps yourself, by running a control simulation for the amount of years correspondent to your desired simulations.
Every simulation should already produce a restart dump at the end of each month, so you can use the end of October for every year to produce a new warm restart for your simulations.

However, in case you want/need to set a different dump frequency, you can do it in the Rose GUI by changing the dumpfreqim field under um ā†’ namelist ā†’ Model Input and Output ā†’ Dumping and Meaning.

2 Likes

Hi Davide,

Thanks, following your advice I will be creating new restart dumps and see how I go. If I encounter any errors I will update here.

For the dump frequency, can you let me know how it is calculated? It looks at the moment the value is a dummy value of ā€˜999999ā€™ (please correct me if Iā€™m wrong, Iā€™m not sure!). How can I set this to something like every 2 months (for eg.)?

1 Like

CM2 automatically produces dumps at the end of every month for Gregorian calendar climate runs. This is managed by the greg_monthly_dump field below dumpfreqim.

Separately, you can choose a frequency to dump your restart files. This is controlled by the dumpfreqim field, which represents the number of days between two consecutive dumps. By default this is set to 99999999 (days), that is far greater than any simulation length, so practically no dumps will be generated (apart from the end of the month ones).
If you change this, for example, to 30, it will dump a restart file every 30 days.

On a side note, generally thereā€™s not much need to change dumpfreqim, also because this does not account for the leap years in the Gregorian calendar, meaning there is no way (or at least I donā€™t know any) to dump restart files every specific day of the month (unless you dump every single day, but PLEASE DONā€™T!!! :sweat_smile: )

Hope that clarifies things!

2 Likes

Thanks that helped!

1 Like

Hi Davide,

Thanks for your advice, that helped.

I was wondering if you have any suggestions on how to go about the warm restarts using the restart files from the end-of-October from a particular year. I have tried changing the value of ā€˜ainitialā€™ to point to the restart file (so as to reconfigure to a start dump) and also changing the ā€˜basisā€™ to start the simulations from 1st November but the model is unable to read the restart dump file. Is there a documentation somewhere on doing the warm-restarts?

Hi Sramana,

What you wrote sounds correct to me.
If you cannot read the restart file I presume there is either an issue with the restart file itself, or maybe the file is not in your project and you did not update the ā€œstorageā€ variable in for PBS? (Just wondering)

What error message are you getting?

Hi Davide,

This is the error that I get:

I think the restart file is not being read. I think it might be because I am making a mistake regarding where to store the restart file. Is it advisable to store the file in the /scratch/$project/$user/cylc-run/ā€¦ directory instead of the home directory, given that accessdev canā€™t access the scratch directory on gadi? What is the best recommended practice here?

I donā€™t think the suites have permission to read files from your /home directory.

You can store it in /scratch/$PROJECT/$user/cylc-run/, however, this directory might get updated and changed when you run suites (or if you clean suites), therefore I would not advise to put your files there.

What I would do, is placing them somewhere under /g/data/$PROJECT/.
Check if it works that way.

I tried the above suggestion and itā€™s the same error. I put the restart file in my default project so I assumed there wouldnā€™t be a problem reading the file. Hereā€™s the error:

UPDATE: The issue of the restart files not being read was solved by adding the gdata/$Project to the storage in PBS. Thanks for all your help!

1 Like