Warm starts in the new release of ACCESS-ESM1.5

Earth System Earth System Model
,
1

Inquiry About Warm Starts in ACCESS ESM1.5

Hello everyone,

I am currently working with the new release of the ACCESS ESM1.5 model, using a pre-industrial configuration to run some freshwater flushing experiments. In the previous release of the model, there was the option to use warm starts to branch the model into new ensembles through a shell script (warm_start.sh). This script utilized restart files located in /g/data/p73/archive/CMIP6/ACCESS-ESM1-5/PI-01/restart/.

I have not been able to locate this functionality in the new version, so I was hoping to get some help on implementing warm starts with the current model setup.

Steps Taken

To adapt to the new release, I have attempted the following:

  1. Copied warm start scripts: I copied the following scripts from the old version to the new release:
    /g/data/p73/archive/CMIP6/ACCESS-ESM1-5/PI-01/
    control/
    ├── warm_start.sh
    └── scripts/
    │ ├── cicedumpdatemodify.py
    │ ├── post.sh
    │ ├── set_restart_year.sh
    │ ├── umfile.py
    │ ├── utils.sh
    │ ├── warm-start-payu.sh
    │ ├── pre.sh
    │ ├── um_fileheaders.py
    │ ├── update_um_year.py
    │ └── warm-start-csiro.sh

  2. Edited warm-start-csiro.sh and set_restart_year.sh: I modified these scripts to create restart files as similarly as possible to the new release’s format. (Most of the changes I identified were to the ice restart files and some changes to the ocean restart files)

If anyone has experience with implementing warm starts in the new version of ACCESS ESM1.5 or has suggestions for troubleshooting, I would really appreciate your insights. I am also happy to share any specific changes I made to the scripts if that would be helpful.

Thank you in advance for your help!

2 Likes
3

Hi @katner99,

Thanks for your question. That’s correct that the ice restart files have changed with the latest release, meaning that the available warm-start scripts won’t work right away – some details on the changes to the ice restarts are included here.

I’ll take a look into what changes might be needed to get the warm start scripts working, and wanted to double check where you copied them from? There’s a chance that there are different versions around and so wanted to make sure I’m looking at the same one.

Thanks,
Spencer

4

Hi Spencer,

Thank you for your response and the link to the new ice restarts.

The warm start scripts I used were taken from the historical configuration of ACCESS-ESM, (GitHub - coecms/esm-historical) and adapted for the PI-control by Ariaan Purch (@ariaan).

But I suppose ideally it would be good to have warm start capability for the different experiments.

Thanks again for your help!
Kat

5

Hi @katner99,

I’ve had a look at the warm start scripts from GitHub - coecms/esm-historical, and it does look like the only changes we need are to adjust the way the sea ice restarts are handled.

I’ve uploaded a version of the scripts with some quick changes to a gist here, which are currently working when branching off the PI-02 simulation in /g/data/p73.

I’ll outline the main changes in case any of the details are useful!

As mentioned in the previous topics here, ESM1.5 no longer uses the timing information given by the variables init_data and initdate from the <control-directory>/ice/input_ice.nml file, instead reading them from a new file restart_date.nml placed in the restart directory.

Likewise, the runtime0 and runtime variables from the <restart-directory>/ice/input_ice.nml are no longer used.

As a result the parts of the warm start scripts which set these variables can be removed. These include the three sections here, here, and here which I’ve either deleted or commented out in the updated version.

The final step is to make the new restart_date.nml file to carry the new timing information, which is added here.

Let me know if you have any questions about the changes to the scripts, or any issues with running them!

6

Hi Spencer,

Thank you again so much for your help with this!! Another thing we were wondering about the new release of ACCESS-ESM (I’m not sure if I need to start a new post for this) was whether the new release allows for post-processing.

Ariaan Purich (@ariaan) when using the previous release of ACCESS-ESM1.5 would use the ACCESS archiver and APP4 scripts to compress and CMOR-ise the model output. Do you know if these scripts would also work on the new release, or what edits we would need to implement to get these to work?

All the best,
Kat

7

Hi @katner99,

APP4 has been superseded by ACCESS-MOPPeR, which we recommend using. MOPPeR offers support for Python 3 and CMOR3, making it more up-to-date and versatile.

For further assistance, @Paola-CMS is the best point of contact with extensive experience in this tool.

Feel free to reach out if you have any questions!

Romain

8

The latest version is available in analyssi3-unstable conda environment. It should work for ESM1.5 files.

2 Likes
9

Note that the ACCESS-ESM1.5 configurations released by ACCESS-NRI include automated conversion of the UM files to compressed netCDF, which may be all that you require.

See this topic for details about what is saved in the various profiles and the final storage requirements:

10

Hi Paola,

I was going through the documentation for MOPPeR. My data, as output by ACCESS-ESM1.5, is stored on scratch in the format /scratch/…/expt/output0[…]/atmos, for example, with each year saved in its own output directory. Do the scripts in MOPPeR account for this in some way, or do I need to move the output files into a single experiment directory?

My plan is to compare this data with previous CMIP output, so it would be great if I could make the output as comparable as possible.

Thanks again for everyone’s help!

Kat

11

For the latest version, it doesn’t matter how you store the files, it just needs the root directory. Said so, it’s probably better to remove the restart files from under the same directory so they get ignored. If it says differently in the readthedocs, please let me know as I might have left some obsolete information there. And just adding it’s a public holiday here tomorrow so I might not be able to answer any other question until Monday, but let me know if you have issues or want some help to work out how to use the tool.

1 Like
12

edit
Nevermind I figured it out! Thanks again for everyone’s help!

Kat

original text
Hi Paola,

Thanks again so much for your help! Just two final questions: I see in the GitHub documentation that it says MOPPeR is to be used on ACCESS files that have been archived using the ACCESS-Archiver scripts—is this correct? Or can I run it on my raw output in my scratch directory?

Also, I tried to pip install the MOPPeR repository following the instructions in the documentation, but the installation failed, saying I lack the required package ‘cmor.’ Do I just need to install CMOR following this guide (Source installation | CMOR 3)?

Thanks again so much for your help!

13

Hi Kat,

that’s only the readme file (thanks I will update that) the documentation is linked in github too but it’s:
https://access-mopper.readthedocs.io/en/latest/
And you don’t need to install the tool as it’s available in our conda environments in hh5. The installation instructions are only if you want to use a different version. Even in that case, it can be installed on top of the existing environment so there’s no need to install cmor.

14

Hi Paola,

Thanks again for your help! I’ve successfully mapped the data and am now working on preparing the configuration template for the file setup. Specifically, I’m using the CMIP template, and I have a few questions about lines 68 to 74 in the config file, which refer to the ancillary paths: ACCESS-MOPPeR/CMIP6_conf.yaml at main · ACCESS-Community-Hub/ACCESS-MOPPeR · GitHub.

ancils_path: "data/ancils" For ancils_path, should I specify the overarching directory (e.g., data/ancils), or does it need a more specific path pointing to individual ancillary files?

land_frac: "" 
tile_frac: ""

I’m uncertain about what files are expected for land_frac and tile_frac. I have a grid.nc file with the following structure:

netcdf grids {
dimensions:
        nxo = 360 ;
        nyo = 300 ;
        nco = 4 ;
        nxa = 192 ;
        nya = 94 ;
        nca = 4 ;
        nx1 = 192 ;
        ny1 = 145 ;
        nc1 = 4 ;
        nx2 = 192 ;
        ny2 = 145 ;
        nc2 = 4 ;
        nx3 = 192 ;
        ny3 = 144 ;
        nc3 = 4 ;
variables:
        double cice.lon(nyo, nxo) ;
                cice.lon:units = "degrees_east" ;
                cice.lon:title = "cice grid T-cell longitude" ;
        double cice.lat(nyo, nxo) ;
                cice.lat:units = "degrees_north" ;
                cice.lat:title = "cice grid T-cell latitude" ;
        double cice.ang(nyo, nxo) ;
                cice.ang:units = "degrees" ;
                cice.ang:title = "cice grid T-cell local rotation angle" ;
        double cice.clo(nco, nyo, nxo) ;
                cice.clo:units = "degrees_east" ;
                cice.clo:title = "cice grid T cell corner longitude" ;
        double cice.cla(nco, nyo, nxo) ;
                cice.cla:units = "degrees_north" ;
                cice.cla:title = "cice grid T-cell corner latitude" ;
        double nt62.lon(nya, nxa) ;
                nt62.lon:units = "degrees_east" ;
                nt62.lon:title = "nt62 grid T-cell longitude" ;
        double nt62.lat(nya, nxa) ;
                nt62.lat:units = "degrees_north" ;
                nt62.lat:title = "nt62 grid T-cell latitude" ;
        double nt62.ang(nya, nxa) ;
                nt62.ang:units = "degrees" ;
                nt62.ang:title = "nt62 grid T-cell local rotation angle" ;
        double nt62.clo(nca, nya, nxa) ;
                nt62.clo:units = "degrees_east" ;
                nt62.clo:title = "nt62 grid T-cell corner longitude" ;
        double nt62.cla(nca, nya, nxa) ;
                nt62.cla:units = "degrees_north" ;
                nt62.cla:title = "nt62 grid T-cell corner latitude" ;
        double um1t.lon(ny1, nx1) ;
                um1t.lon:units = "degrees_east" ;
                um1t.lon:title = "um1t grid center longitude" ;
        double um1t.lat(ny1, nx1) ;
                um1t.lat:units = "degrees_north" ;
                um1t.lat:title = "um1t grid center latitude" ;
        double um1t.ang(ny1, nx1) ;
                um1t.ang:units = "degrees" ;
                um1t.ang:title = "um1t grid local rotation angle" ;
        double um1t.clo(nc1, ny1, nx1) ;
                um1t.clo:units = "degrees_east" ;
                um1t.clo:title = "um1t grid corner longitude" ;
        double um1t.cla(nc1, ny1, nx1) ;
                um1t.cla:units = "degrees_north" ;
                um1t.cla:title = "um1t grid corner latitude" ;
        double um1u.lon(ny2, nx2) ;
                um1u.lon:units = "degrees_east" ;
                um1u.lon:title = "um1u grid center longitude" ;
        double um1u.lat(ny2, nx2) ;
                um1u.lat:units = "degrees_north" ;
                um1u.lat:title = "um1u grid center latitude" ;
        double um1u.ang(ny2, nx2) ;
                um1u.ang:units = "degrees" ;
                um1u.ang:title = "um1u grid local rotation angle" ;
        double um1u.clo(nc2, ny2, nx2) ;
                um1u.clo:units = "degrees_east" ;
                um1u.clo:title = "um1u grid corner longitude" ;
        double um1u.cla(nc2, ny2, nx2) ;
                um1u.cla:units = "degrees_north" ;
                um1u.cla:title = "um1u grid corner latitude" ;
        double um1v.lon(ny3, nx3) ;
                um1v.lon:units = "degrees_east" ;
                um1v.lon:title = "um1v grid center longitude" ;
        double um1v.lat(ny3, nx3) ;
                um1v.lat:units = "degrees_north" ;
                um1v.lat:title = "um1v grid center latitude" ;
        double um1v.ang(ny3, nx3) ;
                um1v.ang:units = "degrees" ;
                um1v.ang:title = "um1v grid local rotation angle" ;
        double um1v.clo(nc3, ny3, nx3) ;
                um1v.clo:units = "degrees_east" ;
                um1v.clo:title = "um1v grid corner longitude" ;
        double um1v.cla(nc3, ny3, nx3) ;
                um1v.cla:units = "degrees_north" ;
                um1v.cla:title = "um1v grid corner latitude" ;
}

Does this grid.nc file contain the necessary information for land_frac and tile_frac?

Lastly, for history_data: "", I’m not entirely sure what to include here. Could you clarify what’s generally expected?

Thanks for your guidance!

15

Unless you’re producing data for CMIP6 use the other configuration files. They’re very similar but there are extra requirements in the CMIP6 ones that are hard to define outside CMIP project itself. You can still use the CMIP6 variable definitions and get a CMIP like output. “history_data” is an example.

For the ancillary files, you don’t need necessarily to define all of them it really depends on what variables you’re trying to calculate.
The ancils_path is the path to the directory that should have the ancil files you want to use. From our example the tool will epxect to have a /data/ancils folder and would look in there for any ancil files you list after.
If you want, you can pass the full path (i.e. /g/data/…) and then it won’t pre-append .
In the land_frac etc you put the filenames.
The land_frac, tile_frac use dto be called esm_landfrac.nc, esm_tilefrac.nc, at leats the versions I’ve seen for old runs. I’m not sure what they might be called in your configuration.
It’s the reason why I decided to let a user define them.

land_frac: should contain lat, lon and the land area fraction variable: usually fld_s03i395. If you have this in your output you don’t need to specify an ancillary file.

tile_frac: similar but with surface tile fraction variable, usually: fld_s03i317. Again this might be included already in your model output.

I will try to make this clearer in the documentation and config files :slight_smile:

Hope this helps,
Paola

16

Hi Paola,

Thank you again for all your help! The main variable I’m focusing on for CMORizing is the ocean meridional overturning mass streamfunction (msftmz). Since I plan to compare my simulations with CMIP output, I want to ensure that the variables are calculated consistently, so that my results are fully transferable.

Thanks!

17

As long as you choose msftmz as defined for example in CMIP6_Omon than they should be equivalent and comparable to any other msftmz published in CMIP6. Said so, we adapted the calculation from the old APP4 tool used for the published ACCESS data, it should be equivalent but it’s not exactly the same. CMOR controls only the definitions of the variables, how they are calculated depends on the models and/or tools used for post-processing.

18

Hi @katner99,

I just wanted to check whether you had any questions remaining about the warm start scripts? If everything is resolved I’ll close this topic.

Cheers,
Spencer