ACCESS-ESM1.6 development

Hi all,

As promised, I’ve tried to compile some relevant details for ocean and ice model development in ACCESS-ESM1.6. I’m sure things will be missing or unclear so please send questions to Anton or Aidan (particularly for Spack questions).

Please also feel free to contact me, though I’ll be on leave and may take longer to respond.

Some general info about cloning and branching code from Github.

All the code that makes up ACCESS-NRI-supported models is in Github repos. To interact with Github, you will need to set up ssh-keys for authentication. I’ve put together some instructions here to do this. Note, these instructions are to set up ssh-keys for both Gadi and Github. The process will be slightly different if you already have ssh-keys set up for Gadi. Anton can help with questions.

You can clone a Github repo (i.e. download a local copy) using the git clone command:

git clone <repo_url>

where <repo_url> can be obtained from the Github repo webpage: click on the green “Code” button, click on the “SSH” tab and copy the url.

To clone a specific branch, use:

git clone -b <branch> <repo_url>

This will create a local directory with the same name as the Github repo. E.g. if <repo_url> = git@github.com:ACCESS-NRI/MOM5.git, I would end up with a local MOM5 directory containing MOM5 source code after running the above.

Changes to code should happen in development branches. To create your own development branch from the current branch, cd into the cloned directory and run:

git pull
git checkout -b <development_branch_name>

Call the development branch something that makes it clear what changes will be in that branch.

If you need help committing and pushing your changes back to Github as you do your developments, please ask.

ACCESS-ESM1.5

Key code bases used in the ACCESS-NRI-released ACCESS-ESM1.5 are here:

These are the sources that are used by Spack for official ACCESS-NRI ACCESS-ESM1.5 releases.

Developers can also use Spack to build ACCESS-ESM1.5 from locally cloned (and modified) versions of the components. Unfortunately, we don’t yet have dedicated documentation for how to do this for ACCESS-ESM1.5, but the ACCESS-OM2 documentation here can be easily extended. I think Aidan is planning to give a demo of this process soon and he and his team can help with any questions.

ACCESS-ESM1.6

This is obviously still in a state of flux. Currently, the ACCESS-NRI Spack-built ACCESS-ESM1.6 uses:

I.e. the only difference from ACCESS-ESM1.5 at the moment is in MOM5 (ACCESS-ESM1.6 uses the same version of MOM5 as ACCESS-OM2 and uses generic WOMBATlite).

Development with Spack can be done in the same way as for ACCESS-ESM1.5.

Pearse is already set up developing into generic WOMBATlite using Spack.

As discussed in our meeting today, Anton will set up a “access-esm1.6” branch of CICE5 that Dave can start using. Anton/Aidan can also help with the Spack modifications required to use CICE5 instead of CICE4 during development.

Finally, there’s a working test Payu configuration for ACCESS-ESM1.6 in the “dougiesquire/preindustrial+concentrations” branch of GitHub - ACCESS-NRI/access-esm1.6-configs: Standard ACCESS-ESM1.6 configurations released and supported by ACCESS-NRI. The executable paths in this config will need to be updated if you want to run this with modified executables (e.g. during development) - Anton or Aidan can help with this.

3 Likes

Does CABLE sit in the UM repository? Will this change for ACCESS-ESM1.6?

Hi @tiloz , right now CABLE sits in the UM repository. Once I get someone in my team with some time, I would like to investigate using a library for CABLE in ESM1.6 and 3. This should happen shortly after the workshop.

CABLE as a library was abandoned for ACCESS because when it was first done, it was a headache to use during development. I’m pretty sure we can solve the issue there, but we have to look into it to be sure.

3 Likes

Hi all, my name is Chris Bull (@cbull) and I’ve recently started as the Ocean Team Lead at ACCESS-NRI.

I caught up with @dougiesquire yesterday (presently on leave) and he’s brought me up to speed on the dev’ work going on for ESM1.6. Just to say, please reach out if there’s anything you need assistance with regarding dev work. I’m contactable on here and email chris.bull@anu.edu.au, happy to chat too.

2 Likes

building with a library was also a headache:

  • as the same compile environment was necessary across both.
  • fcm just picked up whatever you added and built it the same way
  • working with two checkouts was a headache

it was adding work rather than simplifying it. i.e. it made more sense just to have the code next to the parent. issue 1 build command and not have to worry about consistent compile environments. It was hard to find a reason to maintain it, especially when we moved to CM2, JAC.

Welcome Chris (@cbull ) - perhaps you can join us (virtually) for one of our CSIRO team meetings over the next couple of weeks for a ‘meet and greet’.

@Jhan - I’m assuming one of the benefits of using spack is dealing with all the compile environments etc. It reminds me that I need to coordinate with Aidan to organise some training for us to get more comfortable in doing development work using these tools.

Yes. The calculus changes when we have tools that can support this, and when we want to include a component, like CABLE, in multiple models, and test multiple versions.

Absolutely happy to, but we also need to establish some on-going communication/coordination/collaboration channels.

At ACCESS-NRI we have found weekly 15-30 min meetings (stand-up) to organise releases a very effective way to get the people we need in the same (virtual) room to share up to date information and make quick decisions.

Hi @RachelLaw, sounds good. Feel free to email me an invite (chris.bull@anu.edu.au).

Thanks for inviting me along yesterday to the ACCESS dev meeting, great to meet so many of you: @sofarrell @RachelLaw @dhb599 @Harun_Rashid!

I’ve now relayed what was highlighted yesterday. As in, the near-term need to sync our efforts for CICE and MOM changes for ESM 1.6. I’m aware the preferred release date is fast approaching! I’ve chatted to @anton and @Aidan about this, as a starting point, we need to get what’s been happening on a branch on GitHub (i.e. @dougiesquire above post) and we’d like to support workflows towards that. It’s completely okay if the code is still in development, we just need to see it. This allows us to understand what changes have occurred, how to merge any changes from us and what is involved if there’s a wish to pull in any upstream changes. All useful things for official release later.

With that in mind, I think the best way forward is for us to have a weekly “standup” meeting. I’m happy to arrange these. The idea is that there very short and focused, ideally 15 minutes with the overrun possibility of 30. @Aidan and @harshula can give release related input.

We will rotate people and focus as needs permit. To start though, @dhb599, it sounds like you’re the person to talk to about MOM, and perhaps CICE changes. How does Tuesday at 9.45am sound? Can you also nominate some other times as we have quite a few people to work around.

@harshula, @Aidan, @anton: can you also make Tuesday at 9.45am? All welcome of course.


p.s. perhaps @dhb599 your current code is already on GH and I’ve misunderstood, please post a link if that’s the case.

Tuesdays at 9:45 is good for me.

1 Like

Tuesdays at 9.45 would generally be fine with me - just noting that Oct 22 is a day (once a year) when CSIRO focuses on HSE and staff are encouraged not to do their normal work - Nov 5 is Cup Day so that would take out Melbourne-based people - and Dec 3 (&4) is a NESP Climate Systems Hub meeting involving many of us.

Tuesdays at that time work for me.

When is the date of the ESM1.6 release? Good to have a firm deadline.

pearse

···

From: Rachel Law via ACCESS Hive Community Forum notifications@access1.discoursemail.com
Date: Thursday, 10 October 2024 at 9:25 AM
To: pearse.buchanan@hotmail.com pearse.buchanan@hotmail.com
Subject: [ACCESS Hive Community Forum] [PM] ACCESS-ESM1.6 ocean/ice development



Image removed by sender.



RachelLaw
9 October

Tuesdays at 9.45 would generally be fine with me - just noting that Oct 22 is a day (once a year) when CSIRO focuses on HSE and staff are encouraged not to do their normal work - Nov 5 is Cup Day so that would take out Melbourne-based people - and Dec 3 (&4) is a NESP Climate Systems Hub meeting involving many of us.


Visit Message or reply to this email to respond to RachelLaw, anton, cbull, Aidan, Jhan, clairecarouge, tiloz, dougiesquire, MartinDix, harshula and 6 others.

To unsubscribe from these emails, click here.

1 Like

Hi @pearseb
On release date - I guess that depends on how we define a release. Our aim was always to have a ‘complete’ ESM1.6 ready by the end of the year. This would allow us to use the Christmas break to begin an initial test spin-up. It is likely that we would continue to ‘tweak’ the model through the first 6 months of next year as we extend/refine spin-up runs and check sensitivity to forcings such as increased CO2. A final version/configuration is needed by the middle of next year so that we can start production runs.
Does it make sense to characterise this as a development release by the end of this year and a user release in mid-2025?

I think so yes. End of the year is good. I aim to have WOMBAT-lite working in generic tracers by the end of this month. Although, there are a few trip hazards for that, hopefully it will be smooth.

···

From: Rachel Law via ACCESS Hive Community Forum notifications@access1.discoursemail.com
Date: Thursday, 10 October 2024 at 10:19 AM
To: pearse.buchanan@hotmail.com pearse.buchanan@hotmail.com
Subject: [ACCESS Hive Community Forum] [PM] ACCESS-ESM1.6 ocean/ice development



Image removed by sender.



RachelLaw
9 October

Hi @pearseb
On release date - I guess that depends on how we define a release. Our aim was always to have a ‘complete’ ESM1.6 ready by the end of the year. This would allow us to use the Christmas break to begin an initial test spin-up. It is likely that we would continue to ‘tweak’ the model through the first 6 months of next year as we extend/refine spin-up runs and check sensitivity to forcings such as increased CO2. A final version/configuration is needed by the middle of next year so that we can start production runs.
Does it make sense to characterise this as a development release by the end of this year and a user release in mid-2025?


Visit Message or reply to this email to respond to RachelLaw, anton, cbull, Aidan, Jhan, clairecarouge, tiloz, dougiesquire, MartinDix, harshula and 6 others.

To unsubscribe from these emails, click here.