# ACCESS-ESM1.5: ACCESS-NRI flagship release plans **URL:** \ **Category:** Earth System Model\ **Tags:** access-nri, access-esm\ **Created:** [2 February 2024 06:44 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772 "2024-02-02T06:44:41Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![Aidan](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/aidan/32/42_2.png) [@Aidan](https://forum.access-hive.org.au/u/Aidan)\ **Post date:** [2 February 2024 06:44 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/1 "2024-02-02T06:44:42Z")
# Introduction ACCESS-NRI is targeting ~~mid to late May~~ end of July for a supported ACCESS-ESM1.5 flagship release. A flagship release needs to meet some minimum criteria: - Source code under version control on [GitHub](https://github.com/ACCESS-NRI) - Reproducible build infrastructure (all models [built with spack](https://github.com/ACCESS-NRI/spack-packages)) - [Automated build infrastructure (CI)](https://github.com/ACCESS-NRI/build-ci) in place to ensure code correctness - Experiment configurations under version control on GitHub (e.g. [ACCESS-OM2](https://github.com/ACCESS-NRI/access-om2-configs)) - Automated reproducibility checking in place. Both for CI testing of experiment configuration updates, but also scheduled reproducibility checking of specific experiment configuration versions marked for long-term support - User documentation Additionally there should be - Full experiment provenance - Model documentation This is a more difficult task, and so will be an on-going process of improvement # Source code ACCESS-ESM1.5 contains four major components: - UMv7: atmosphere model - CABLE2: Land surface model - MOM5: ocean model - CICE4: sea-ice model - OASIS3: coupler Some other important dependencies include gcom, fcm and netCDF. ## CICE4 Currently available on the `ESM_1.5` branch in the `cice4` repo on the ACCESS-NRI GitHub organisation: [https://github.com/ACCESS-NRI/cice4/tree/ESM\_1.5](https://github.com/ACCESS-NRI/cice4/tree/ESM_1.5) ## MOM5 MOM5 version is currently in a separate COSIMA repository > **[GitHub - COSIMA/ACCESS-ESM1.5-MOM5: The MOM5-WOMBAT codebase for the ACCESS-ESM1.5...](https://github.com/COSIMA/ACCESS-ESM1.5-MOM5)** > > The MOM5-WOMBAT codebase for the ACCESS-ESM1.5 model ## UMv7 Access to the the Unified Model (UM) is restricted by a UK Met Office license, which limits where it can be stored, and who can access it. ## CABLE2 Version 2.4 is included as part of the UM source code ## OASIS3-mct This is available on the ACCESS-NRI GitHub organisation > **[GitHub - ACCESS-NRI/oasis3-mct: Derivative version of OASIS3-MCT 2.0 from CERFACS...](https://github.com/ACCESS-NRI/oasis3-mct)** > > Derivative version of OASIS3-MCT 2.0 from CERFACS (https://portal.enes.org/oasis). # Build infrastructure All components of ACCESS-ESM1.5 have been ported to use the spack build infrastructure by adding or modifying their [spack package definitions](https://github.com/ACCESS-NRI/spack-packages/). Thanks to @paulleopardi for this work, and @harshula who assisted with reviews and additional complementary updates. There is an active pre-release deployment of ACCESS-ESM1.5 that is being tested and is close to being released > > > :rocket: Deploying access-esm1.5 \`2024.05.0\` as prerelease \`pr5-20\` > \ > \Details and usage instructions\ > > This \`access-esm1.5\` model will be deployed as: > \* \`2024.05.0\` as a Release (when merged). > \* \`pr5-20\` as a Prerelease (during this PR). > > This Prerelease is accessible on Gadi using: > \`\`\`bash > module use /g/data/vk83/prerelease/modules/access-models/ > module load access-esm1p5/pr5-20 > \`\`\` > where the binaries shall be on your \`$PATH\`. > This Prerelease is also accessible on Gadi via \`/g/data/vk83/prerelease/apps/spack/0.21/spack\` in the \`access-esm1p5-pr5-20\` environment. > \ > :hammer\_and\_wrench: Using: spack-packages \`2024.05.28\`, spack-config \`2024.04.23\` > \ > \Details\ > > It will be deployed using: > \* \`access-nri/spack-packages\` version \[\`2024.05.28\`\](https://github.com/ACCESS-NRI/spack-packages/releases/tag/2024.05.28) > \* \`access-nri/spack-config\` version \[\`2024.04.23\`\](https://github.com/ACCESS-NRI/spack-config/releases/tag/2024.04.23) > > If this is not what was expected, commit changes to \`config/versions.json\`. > \ # Build CI Build CI has been added to model components that are open source and unencumbered by licensing issues. The UM and gcom components do not currently have build CI enabled as the current approach could expose compiled components to access by unlicensed persons. # Experiment Configurations Initially ACCESS-NRI plans to release and support three ACCESS-ESM1.5 experiment configurations: pre-industrial and concentration driven historical ~~and an emissions driven historical~~. Emissions driven configurations will be part of subsequent follow-up releases of ACCESS-ESM. The intention is to adopt, and where required modify, the CLEX CMS developed `payu` configurations: > **[GitHub - coecms/access-esm: Main Repository for ACCESS-ESM configurations](https://github.com/coecms/access-esm)** > > Main Repository for ACCESS-ESM configurations Emissions driven configurations will be from configurations developed by CSIRO (predominantly @tiloz). Configuration work is predominantly being done by @spencerwong and @MartinDix. ## Pre-industrial The pre-industrial configuration is being developed in this branch [https://github.com/ACCESS-NRI/access-esm1.5-configs/tree/pre-industrial](https://github.com/ACCESS-NRI/access-esm1.5-configs/tree/pre-industrial) ## Historical Concentration Driven The concentration driven historical configuration is being developed in this branch [https://github.com/ACCESS-NRI/access-esm1.5-configs/tree/historical](https://github.com/ACCESS-NRI/access-esm1.5-configs/tree/historical) # Reproducibility testing [Modular reproducibility testing developed for ACCESS-OM2](https://github.com/ACCESS-NRI/model-config-tests/) will be [applied to ACCESS-ESM1.5](https://github.com/ACCESS-NRI/model-config-tests/issues/21). ---
**Author:** ![paulleopardi](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/paulleopardi/32/92_2.png) [@paulleopardi](https://forum.access-hive.org.au/u/paulleopardi)\ **Post date:** [13 February 2024 00:19 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/2 "2024-02-13T00:19:55Z")
Is this thread the best place to discuss the Spack packages for the ACCESS-ESM build, or should I create a new topic? ---
**Author:** ![paulleopardi](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/paulleopardi/32/92_2.png) [@paulleopardi](https://forum.access-hive.org.au/u/paulleopardi)\ **Post date:** [13 February 2024 00:26 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/3 "2024-02-13T00:26:13Z")
Or should I move the discussion to the issue: [Spack package for ACCESS-ESM1.5 · Issue #59 · ACCESS-NRI/spack-packages · GitHub](https://github.com/ACCESS-NRI/spack-packages/issues/59) ? ---
**Author:** ![Aidan](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/aidan/32/42_2.png) [@Aidan](https://forum.access-hive.org.au/u/Aidan)\ **Post date:** [13 February 2024 00:27 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/4 "2024-02-13T00:27:09Z")
Yes I think that sounds best. The intention was to make this a “super topic” and link to other activities/topics. ---
**Author:** ![dkhutch](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/dkhutch/32/510_2.png) [@dkhutch](https://forum.access-hive.org.au/u/dkhutch)\ **Post date:** [15 February 2024 02:09 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/5 "2024-02-15T02:09:06Z")
Hi @Aidan, I’m pretty sure ACCESS ESM1.5 uses MOM5.1, as per the pre-industrial git repository that is available and discussed in a recent thread. Otherwise, great to hear you are planning a new release with additional provenance and reproducibility. Regards, David ---
**Author:** ![Aidan](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/aidan/32/42_2.png) [@Aidan](https://forum.access-hive.org.au/u/Aidan)\ **Post date:** [15 February 2024 05:11 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/6 "2024-02-15T05:11:36Z")
> [@dkhutch](#): > > I’m pretty sure ACCESS ESM1.5 uses MOM5.1, as per the pre-industrial git repository that is available and discussed in a recent thread. Yes you’re right, thanks. It was a mistake on my part. I have updated it and pointed to the GitHub repo where the current version of the source code resides. ---
**Author:** ![Aidan](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/aidan/32/42_2.png) [@Aidan](https://forum.access-hive.org.au/u/Aidan)\ **Post date:** [15 February 2024 05:17 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/7 "2024-02-15T05:17:14Z")
@tiloz mentioned at the [ESM Working Group meeting](https://forum.access-hive.org.au/t/esm-working-group-meeting-notes-2024/605/19) that it would be good to have an emissions driven Pre-Industrial (PI) control to match the emissions driven historical that is planned. @tiloz also pointed out there are `payu` based experiments developed by others in the community. It would be good to have an accounting of all that is currently available in case there are some that would be good, and simple, candidates for the ACCESS-NRI to adopt and support. ---
**Author:** ![dkhutch](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/dkhutch/32/510_2.png) [@dkhutch](https://forum.access-hive.org.au/u/dkhutch)\ **Post date:** [12 April 2024 03:54 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/8 "2024-04-12T03:54:41Z")
Hi @aidan et al, Following from a lunchtime discussion today and also our WG meeting: A notable issue with the current setup of ACCESS-ESM1.5 is that it churns too much raw data relative to what’s useful to be saved. For instance, the atmosphere saves out a restart file every month… one every 10 years is usually plenty. It also saves both monthly and daily data by default - many current users (like myself and others in paleo) will delete the daily data without even looking at it. It also saves atmosphere output in double precision, without compression. Also in the ocean, the monthly diagnostics are rather extensive, saving lots of 3D fields at monthly resolution, that could easily be made more compact by switching to annual outputs for most things other than surface ocean fields which are the ones that vary most on seasonal timescales. While some tools exist to help with this, such as the excellent [ACCESS Archiver tool](https://github.com/ACCESS-Community-Hub/ACCESS-Archiver), I think a fresh release of ACCESS-ESM1.5 could go much further in helping to enable users to keep their outputs more compact. A “compact diagnostic” option that new users could select would be helpful. In such an option I would suggest using the payu workflow to automatically enable: 1. Conversion of atmosphere files to netcdf 2. Change the STASHC file to get rid of atmosphere daily outputs (i.e. don’t generate them in the first place) 3. Shrink down the ocean outputs to mostly annual frequency for the purposes of spinup 4. Automatically remove monthly restarts The ACCESS-Archiver could be repurposed into payu for (1). I could share some examples for (2) and (3). (4) could be done via a postscript to run through payu. Cheers, Dave ---
**Author:** ![clairecarouge](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/clairecarouge/32/380_2.png) [@clairecarouge](https://forum.access-hive.org.au/u/clairecarouge)\ **Post date:** [12 April 2024 04:14 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/9 "2024-04-12T04:14:51Z")
I don’t want to derail the discussion from David’s request but is it time to update the first post on the intended timeline? The first sentence currently reads: > ACCESS-NRI is targeting mid to late March for an NRI supported ACCESS-ESM1.5 flagship release. ---
**Author:** ![Aidan](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/aidan/32/42_2.png) [@Aidan](https://forum.access-hive.org.au/u/Aidan)\ **Post date:** [12 April 2024 05:04 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/10 "2024-04-12T05:04:29Z")
> [@dkhutch](#): > > A “compact diagnostic” option that new users could select would be helpful. In such an option I would suggest using the payu workflow to automatically enable: > > 1. Conversion of atmosphere files to netcdf > 2. Change the STASHC file to get rid of atmosphere daily outputs (i.e. don’t generate them in the first place) > 3. Shrink down the ocean outputs to mostly annual frequency for the purposes of spinup > 4. Automatically remove monthly restarts All excellent suggestions @dkhutch. I believe @MartinDix has already [fixed for the problem with the monthly restarts being archived](https://github.com/payu-org/payu/pull/415), and that is [now available on `gadi`](https://forum.access-hive.org.au/t/payu-a-workflow-manager-for-some-access-models/1098/5). I agree automated post-processing (netCDF conversion) is a must. I agree that the model outputs waaaay too much data by default. The #access-om2 models have multiple configurations in different branches in the configs repo > **[Releases · ACCESS-NRI/access-om2-configs](https://github.com/ACCESS-NRI/access-om2-configs/releases)** > > Standard ACCESS-OM2 configurations released and supported by ACCESS-NRI - ACCESS-NRI/access-om2-configs Using the same approach we can support different versions of configurations for different purposes. Or maybe we could have a tool/script that does a wholesale conversion of diagnostics from one mode to another. I’m not too familiar with what would be required for that. And please do share your configs and what you’ve found to be useful settings for outputs etc in a paleo context. ---
**Author:** ![dkhutch](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/dkhutch/32/510_2.png) [@dkhutch](https://forum.access-hive.org.au/u/dkhutch)\ **Post date:** [12 April 2024 05:14 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/11 "2024-04-12T05:14:41Z")
Hi @aidan, That is really great to hear that the new version of payu has fixed the monthly restart problem. And also about the automation of archiving to netcdf. In regards to my personal changes to diagnostics: My edited STASHC with no daily outputs can be found here: ```auto /home/157/dkh157/ACCESS/mio_v4/atmosphere/STASHC ``` Here is a modified version of my ocean diagnostic outputs, trimmed down to mostly annual outputs with just a few 2D fields saved in monthly frequency: ```auto /home/157/dkh157/ACCESS/mio_v4/ocean/diag_table ``` (Note, I’m not saving any biogeochemistry!! This is not going to suit everybody.) Let me know if you can’t access those files. One year of output using these ocean diagnostics is only 228 MB. The original ocean\_month.nc for a year’s output is 4.9 GB. Getting rid of daily atmosphere outputs shrinks the atmosphere data by about a factor of 3x. Cheers, Dave ---
**Author:** ![Aidan](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/aidan/32/42_2.png) [@Aidan](https://forum.access-hive.org.au/u/Aidan)\ **Post date:** [12 April 2024 05:35 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/12 "2024-04-12T05:35:21Z")
> [@dkhutch](#): > > My edited STASHC with no daily outputs can be found here Thanks @dkhutch. Are they available in a GitHub repository? ---
**Author:** ![dkhutch](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/dkhutch/32/510_2.png) [@dkhutch](https://forum.access-hive.org.au/u/dkhutch)\ **Post date:** [12 April 2024 05:37 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/13 "2024-04-12T05:37:00Z")
Erm… not currently. The trouble is my full collection of input files is too large for a github repo. I could make a zenodo repo, but I’m inclined to do that later when I’ve finished tinkering with settings. I could make a mini repo just for the diagnostic input changes, if this is important to do. ---
**Author:** ![Aidan](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/aidan/32/42_2.png) [@Aidan](https://forum.access-hive.org.au/u/Aidan)\ **Post date:** [12 April 2024 05:52 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/14 "2024-04-12T05:52:06Z")
> [@dkhutch](#): > > The trouble is my full collection of input files is too large for a github repo. I could make a zenodo repo, but I’m inclined to do that later when I’ve finished tinkering with settings. We definitely want to encourage everyone in the community to make the most of GitHub, to make our science as open as discoverable as possible. So I’m interested in finding out the technical reasons why this is difficult, but I fear we are somewhat off-topic. So I have made another topic. I you had the time I’d be interested to hear your experience > [@Utilising GitHub effectively for experiments and configurations](https://forum.access-hive.org.au/t/utilising-github-effectively-for-experiments-and-configurations/2027): > > payu is the run-tool used for the #access-om2, #access-esm and #access-om3 models. payu uses git to track changes to experiment configurations and ACCESS-NRI GitHub to distribute model configurations Typically a user might clone a configuration to gadi, modify as required and run their own experiment. Ideally they would also git push their experiment control repository back to GitHub where it is discoverable by others. Discovery is good for open science, it allows others to build on what was… ---
**Author:** ![dkhutch](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/dkhutch/32/510_2.png) [@dkhutch](https://forum.access-hive.org.au/u/dkhutch)\ **Post date:** [12 April 2024 05:54 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/15 "2024-04-12T05:54:46Z")
Hi @aidan, I put the diagnostic files I mentioned [in a repo here](https://github.com/dkhutch/access_code/tree/main/diagnostic_edits). (I did this prior to seeing your last post.) Hmmm… I never quite got my head around payu’s github integration. This is because I am not very competent with github. I would be curious to learn, and will read the post you have linked. ---
**Author:** ![Aidan](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/aidan/32/42_2.png) [@Aidan](https://forum.access-hive.org.au/u/Aidan)\ **Post date:** [30 June 2024 07:58 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/16 "2024-06-30T07:58:26Z")
There is an open issue to decide on a naming scheme for the ESM1.5 configurations. > > > Anyone with opinions about what the names of the initial configurations should b…e please chime in here. The CMS repo just called them \`historical\`, \`pre-industrial\`, \`miocene\` etc. > > The OM2 configurations, by necessity, have resolution, forcing product and forcing mode in the name, e.g. \`release-1deg\_jra55\_iaf\`. > > Do we want to adopt any naming convention like this? Clearly a forcing product and mode is not required, but perhaps it useful to include a resolution as a standard part of our configuration naming for consistency and transparency, to make it obvious to users what this refers to. This may also be informed by/be consistent with the input file naming scheme. > > So we could start with: > > \`1deg\_n96\_hist\_conc\` > \`1deg\_n96\_pi\_conc\` > > given that emissions driven will be near-term targets they would be something like > > \`1deg\_n96\_hist\_emiss\` > \`1deg\_n96\_pi\_emiss\` > > Those are fairly terse, could go for longer and more descriptive \`historical\` and \`pre-industrial\`. > > Thoughts? Along the the lines of ```plaintext __+ ``` | Field | Possible values | | --- | --- | | atmosphere resolution | `n48`, `n96`, `n512` | | ocean resolution | `1deg`, `2deg`, `025deg` | | scenario | `historical`, `preindustrial`, `pliocene`, `lgm`, `ssp585` | | modifiers | `emiss`, `conc` | and we would value feedback from @tammasloughran and @tiloz, particularly around possible values of scenario, and if the idea of `modifiers` makes sense. ---
**Author:** ![tammasloughran](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/tammasloughran/32/209_2.png) [@tammasloughran](https://forum.access-hive.org.au/u/tammasloughran)\ **Post date:** [30 June 2024 23:27 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/17 "2024-06-30T23:27:40Z")
Should probably be named something like concentration-driven vs. interactive carbon cycle, because the pre-industrial simulation does not have emissions but can have an interactive carbon cycle enabled. The emissions, whether 0, constant or variable are indicated by the “scenario” descriptor. ---
**Author:** ![tammasloughran](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/tammasloughran/32/209_2.png) [@tammasloughran](https://forum.access-hive.org.au/u/tammasloughran)\ **Post date:** [1 July 2024 00:17 UTC](https://forum.access-hive.org.au/t/access-esm1-5-access-nri-flagship-release-plans/1772/18 "2024-07-01T00:17:33Z")
Possible value for modifier: no land-use change. eg. historical+noluc However this could be implied by the scenario name also.