I am looking to use daily updating SSTs/SICs in the nesting suite. I’ve created a global, daily ancillary file using the Reynolds SST/SIC fields (and XAncil) for the time I’m targeting (early 2024), but when I pass this through the regional ancillary suite, it creates an empty file (no other obvious errors)… I want to pass the ancillaries the RAS as I’m running on a rotated polar grid, so want the regridding done in the same way as the rest of the fields… So don’t really want to have to create them manually… I’ve copied the changes I made to the RAS below…
So my question is - is this the right way to go about it? Or are the other existing SST/SIC daily datasets that we know work that I should use instead? @cbengel@cchambers - any ideas?
Once I have the RAS generated ancil files, I will then tell the RNS to look for them rather than use the default - that is simple enough hopefully!
Anyway - any advice would be appreciated!
Cheers,
Sonya
We ran AUS2200 with daily updating SSTs, Dale Roberts @dale.roberts ran this case, so not sure if I can help but will put a couple of notes here.
We used the ERA5 skin temperatures over water rather than the ERA5 SSTs so it was the skin temperatures that were updated daily. This is because the UM uses a ‘surface temperature’ input field.
To run it Dale introduced a new restart file every 24 hours that contained updated Skin temperatures over water.
As well as the ERA5 data, there is also the OSTIA dataset that may be useful for SST/SIC. It is not currently available on NCI as a hosted dataset but you can download files. For help on downloading OSTIA you could talk to @anton.
In terms of integrating the ERA5 or OSTIA SST information with daily updating into the RNS I will have to get back to you.
Hi Chermelle, yes thanks. I’m not overly fussed which underlying sst/sic dataset I use, I think that is simple enough to acquire - I’ll take a look at the OSTIA data too though as it looks to be more high res!
Help with integrating into the RAS is what I really need I think - if you have time!
The Bureau’s climate workflow generates time-varying ancillaries using suite u-cj933 - you could try starting from or copying settings from there? Domain information is read in using STATIC_ANCIL_PATH in rose-suite.conf, can be pointed to to the output of the regional ancillary suite on your required grid. Some changes will be necessary to make this suite read OSTIA.
Once you’ve got the ancillaries generated, Mat Lipson has run the nesting suite with time-varying SSTs in u-dh954 by setting:
l_amipii_ice_processing=.false. ->.true.
and by modifying the SST ancil request namelist to:
I also take a look at u-cj933! And yep - I’ve messed with ancillaries before so hopefully once I have the correct files to read, making the changes as you say in the RNS will be straightforward!
@EmmaHoward shared her method used in BARPA with me, and I was able to adapt it for use in a free-running Regional Nesting Suite. This method is in line with Chemelle’s description of using ERA5 skin temps as a lower boundary.
It involves
Changing the suite’s um config to expect updating daily SST ancillaries.
Creating SST data from ERA5 using suite u-cj933 for the period/domain of interest
Replacing your standard static SST with the time varying u-cj-933 one.
1. Updating UM config
Update your /app/um/rose-app.conf to match to this revision in u-dh513
Include all changes except do not change rimweightsa
2. Creating SSTs
edit: I’ve simplified this step to remove the optional file
Checkout suite u-cj933
Update u-cj933/rose-suite.conf to include:
At the top of the .conf file
root-dir=*=$HOME
then your scratch project info for remaining lines.
PROJECT=[your project]
GRID_NAME=‘barpa-auM’
STATIC_ANCIL_PATH=‘[your_ancil_dir]’
INIT_YEAR=[your simulation year]
NUM_YEARS=[if you need multiple years processed]
The GRID_NAME variable is for the sst_seaice app opt_file. It is located at app/sst_seaice/opt/rose-app-barpa-auM.conf, but shouldn’t need to be changed.
Run the suite.
3. Replacing the standard static SST
u-c933 outputs are store in years (with a month buffer at each side). Sonya, does your simulation extend over a calendar year? If not, I think it’s much simpler just to manually symlink the correct year (which also includes the previous Dec and the following Jan). If your sim is more than a year… let’s talk about other options then (it can get complicated adding tasks, changing suite graphs etc).
I got u-cj933 to produce a year of sst and sea-ice values over my chosen area.
To do so though I had to produce monthly ERA5 GRIB files with SST/Sea ice for the time period.
I think we could definitely get together to work out shorter time periods if that is something anyone is interested.
We may need to talk about a way this can be set up to be supported.
In the meantime, I have scripts era5grib_parallel based scripts that could be used to produce the monthly ERA5 GRIB files. Please contact me if you would like to get a copy of them. (Or let me know your dates and a regional ancillary suite to run them for).
Please note though that using the daily varying sea-ice values caused my reconfiguration job to crash but the reconfiguration ran successfully if pointing to the climatology (as outlined in Scott’s post).
UPDATE: ran successfully for the 1st level of a double-level nest. Will have to work out how to update the paths for the 2nd level.
I will look into how this could be used to package OSTIA values as well.
I ran u-dj933 twice: once for nest1 and once for nest2 and saved the results in separate files.
I then created two um/app/rose-suite.conf files one with SST and Sea-ice ancils for nest 1 and one for nest 2. I switched between the two um/app/rose-suite.conf files as appropriate (using rose suite-run --reload) and successfully completed a double-level nest with SST replacement at 06Z.
I will look into rose/cylc variables for the nested naming of the files then look further into using OSTIA.
Last update. I have modified the jinjia2 and have a double-level nest running with the daily-updating SSTs (and sea-ice if you use the l_amipii_ice_processing=.false. ->.true. suggested by @EmmaHoward and @mlipson) with different daily updating files for each level of the nest.
These changes will be discussed in terms of the u-dg768 interim release (and eventual folding back into the trunk).
Please note - the changes will be checked into the u-dg768 trunk after a review.