claireyung:dev-MC_4km_jra_ryf+regionalpanan+isf+draft

[claireyung]

1. Summary: New ACCESS-rOM3 panantarctic 4km with ice shelves config.

• Currently set to run from a restart because running from scratch requires a very short timestep, so not suitable for optimisation work. See instructions here https://github.com/claireyung/access-om3-configs/blob/dev-MC_4km_jra_ryf%2Bregionalpanan%2Bisf%2Bdraft/ice_shelf_instructions.md
• Note requires a custom mom6 executable with changes for ice shelves, currently a local version since this MOM6 symmetric with ice shelf debugging ACCESS-OM3#142 (comment) (which should be identical to my local version) didn't compile now using access-om3/pr142-17
• Based on claireyung:dev-MC_4km_jra_ryf+regionalpanan #713 no ice shelf panan, but it diverged, so there are some upstream commits e.g. changes to authors list that I haven't added yet here
• Also has new input files (see config.yaml)
• Using the version that I ran for one year with internal tide dissipation off.
• Has known problems with frazil/heat conservation and is not well evaluated. For testing/performance use only.
• Expected cost is 20kSU/month, walltime 5:30:00/month

What has changed? Added ice shelf cavities

Why was this done? New capability

2. Issues Addressed:

3. Dependencies (e.g. on payu, model or om3-scripts)

This change requires changes to (note required version where true):

• payu:
• access-om3:
• om3-scripts:

4. Ad-hoc Testing

What ad-hoc testing was done? How are you convinced this change is correct (plots are good)?

5. CI Testing

• !test repro has been run

6. Reproducibility

Is this reproducible with the previous commit? (If not, why not?)

• Yes
• No - !test repro commit has been run.

7. Documentation

The docs folder has been updated with output from running the model?

• Yes
• N/A

A PR has been created for updating the documentation?

• Yes:
• N/A

8. Formatting

Changes to MOM_input have been copied from model output in docs/MOM_parameter_docs.short?

• Yes
• N/A

9. Merge Strategy

• Merge commit
• Rebase and merge
• Squash

[claireyung]

Hi @chrisb13,

As discussed, I've been running an RYF control spin-up. I've paused the spin-up at 5.5 years as we are finding large biases in the Getz ice shelf region that appear to be resolved by moving to IAF forcing, so I'm ready to update this RYF PR with the latest config used to run that short spin-up.

I've squashed a bunch of my runlogs/commits of development made since this original draft PR. Hopefully the size of commits is more manageable now and can be simply cherry-picked on top of the squashed commit you made of everything that came before, chrisb13@299e0de

Some notes: the commit below is from where I have branched off an IAF run, so it would be ideal if this doesn't get squashed to avoid future conflicts (though it seems I already changed the hash by doing the cherrypick onto this branch, so not sure how salvageable that will be):

[2025-11-27 15:46:01: Run 35] https://github.com/ACCESS-NRI/access-om3-configs/pull/814/commits/f6a785fc4bb23794dfba3cd4e882c03e02055b7c

changes made (non-exhaustive list, apologies for my poor documentation of changes strung between many runlog commits)

• THICKNESSDIFFUSE off as mentioned above
• changes to melt parameterisation (CDRAG_SHELF = 0.0075, HMIX_SFC_PROP = 2, HMIX_UV_SFC_PROP = 2 so that circumpolar melt rate after ~5 years is tuned to be approximately 1300Gt/yr in the RYF config)
• using a new initial conditions file based on the Yamazaki 2024 climatology (discussion) to avoid WOA cold bias in the Amundsen Sea shelf region
• updated the boundary condition file to add axes attributes
• updated the tidal roughness file to be zero below the internal tide critical latitude spin-up of ice shelf melt rate - config and IC choices claireyung/mom6-panAn-iceshelf-tools#42 (comment)
• frazil turned off under ice shelves (discussion), using a scaled tidal amplitude for friction velocity in melt parameterisation (discussion)
• Angus fixed one of the segfault bugs (can now increase DT_THERM to 800) - segmentation faults in panan configs #863 (comment)
• code changes to MOM6 from above points, now using prerelease exe MOM6 symmetric with ice shelf debugging ACCESS-OM3#142 (comment)
• layout changes (using a masktable now to ensure parallel IO factor is reasonable, increase in cores from before, Runtime performance optimisation for the panan 4km config #832 (comment))
• ice shelf instructions updated (due to moderate scale up in cores, running the first month at short timestep should now just fit within the 10hr SR maximum walltime so there is no need for a 5 day + 26 day run), but note that running from scratch still requires a short timestep at the start of the run + a manual change to input.nml
• added some diagnostics e.g. Kd_interface, volcello and h that Dougie added capability for (Error when outputting rhopot0 and volcello on ocean_model_z using make_diag_table.py #688)

There are plenty of issues remaining in this config that may be an area for future development, I plan to create a list of these in the next few weeks (update: here is the list claireyung/mom6-panAn-iceshelf-tools#49). Also, some of the code changes to MOM6 required for ice shelves should probably be made PRs to ACCESS-NRI/MOM6 rather than just sitting on the ice-shelf-dev branch, and possibly PR'd to the whole MOM6 consortium for some of the code changes. I will also try to organise a list of these

[chrisb13]

Thanks @claireyung, sorry for my delay on this.

I've squashed a bunch of my runlogs/commits of development made since this original draft PR.

Where have these commits been made? Are you suggesting I take these new commits and cherry-pick them to be added on top of 299e0de? (Details)

Some notes: the commit below is from where I have branched off an IAF run, so it would be ideal if this doesn't get squashed to avoid future conflicts (though it seems I already changed the hash by doing the cherrypick onto this branch, so not sure how salvageable that will be):

I think I'd need to understand more about what kind of conflicts you are trying to avoid. I agree though, a cherrypick changes the hash so the ship may have sailed.

[claireyung]

Thanks @claireyung, sorry for my delay on this.

I've squashed a bunch of my runlogs/commits of development made since this original draft PR.

Where have these commits been made? Are you suggesting I take these new commits and cherry-pick them to be added on top of 299e0de? (Details)

Yeah I was thinking the 14 commits above from 4097005 to d53f527 could be moved on top of your 299e0de big sqashed commit. THen you'd have the same state as this current branch, but with a cleaner history.

Some notes: the commit below is from where I have branched off an IAF run, so it would be ideal if this doesn't get squashed to avoid future conflicts (though it seems I already changed the hash by doing the cherrypick onto this branch, so not sure how salvageable that will be):

I think I'd need to understand more about what kind of conflicts you are trying to avoid. I agree though, a cherrypick changes the hash so the ship may have sailed.

Perhaps it's just my discomfort/unfamiliarity with git and merging things, but I'll try to explain: let's say everything gets squashed in the above 14 commits to make one commit, and I have a IAF branch that branched off in the middle of it (after 13 commits). Then when making a future alpha release for the IAF, there will be all the previous changes before where I branched the IAF off that will have conflicts with the IAF branch? So there will be lots of cases of different commits modifying the same files, since one has 13 commits and the other has a big squashed one that ends up at a different head (the 14th commit)? I haven't tried it so maybe I'm being overly cautious/confused

[chrisb13]

Yeah I was thinking the 14 commits above from 4097005 to d53f527 could be moved on top of your 299e0de big sqashed commit. THen you'd have the same state as this current branch, but with a cleaner history.

Okay, I'll look into if this is practical. It seems it's not straightforward to retrieve a squash history -- it may turn out to be more confidence inspiring to re-do the big squash including the latest changes.

let's say everything gets squashed in the above 14 commits to make one commit, and I have a IAF branch that branched off in the middle of it (after 13 commits). Then when making a future alpha release for the IAF, there will be all the previous changes before where I branched the IAF off that will have conflicts with the IAF branch? So there will be lots of cases of different commits modifying the same files, since one has 13 commits and the other has a big squashed one that ends up at a different head (the 14th commit)? I haven't tried it so maybe I'm being overly cautious/confused

Ok, I think the challenge here is that you're (understandably) moving between development and running experiments. Unfortunately, Payu isn't the best at this. At ACCESS-NRI (e.g. ESM1.6/OM3 dev work) we separate these two processes out by having a dev branch with no runlog on access-nri/access-om3-configs and then a repo that just stores "experiments" (see 1 and 2). The experiment runs do not have config changes in them. Rather when experiments reveal that config changes are needed, they are fed back to the dev version of the configuration. I can't think of a way to achieve what you're after when these two processes are combined (open to ideas!). We can give you access to the experiment repo if that's useful but I think it's probably a slower way of working -- we don't want to slow you down.

So there will be lots of cases of different commits modifying the same files, since one has 13 commits and the other has a big squashed one that ends up at a different head (the 14th commit)?

I don't think I followed this bit fully.

I think you're saying the aspiration is to have a specific commit in the release ("commit 13") that is relatable to the IAF control run in which others could pick this up and run from and have the same shared history? This is something @aidanheerdegen would like us to work towards but we are yet to have precedent for how this will work in practice (i.e. best practice is still being determined).

With all the above in mind, given this is pre-alpha, I would suggest we do not try to have an exact history that is relatable to the current control run.

I've paused the spin-up at 5.5 years as we are finding large biases in the Getz ice shelf region that appear to be resolved by moving to IAF forcing

Moreover, in terms of community value, should we instead be focusing on alpha releases of the IAF versions? As in: dev-MC_4km_jra_iaf+regionalpanan+isf and dev-MC_4km_jra_iaf+regionalpanan.

Happy to chat if easier.

[chrisb13]

Also, some of the code changes to MOM6 required for ice shelves should probably be made PRs to ACCESS-NRI/MOM6 rather than just sitting on the ice-shelf-dev branch, and possibly PR'd to the whole MOM6 consortium for some of the code changes. I will also try to organise a list of these

I think this is a good point, please let us know if you get a chance to put this together. @dougiesquire might have some comments about what is helpful / timing etc.

[chrisb13]

Okay, so @claireyung and I had a chat about this.

As it's still under development, we'll just squash everything and then cherry-pick when needed later.

[claireyung]

Also, some of the code changes to MOM6 required for ice shelves should probably be made PRs to ACCESS-NRI/MOM6 rather than just sitting on the ice-shelf-dev branch, and possibly PR'd to the whole MOM6 consortium for some of the code changes. I will also try to organise a list of these

I think this is a good point, please let us know if you get a chance to put this together. @dougiesquire might have some comments about what is helpful / timing etc.

Hi, here is a draft PR so that you can see a cleaner version of the changes made in the ice-shelf-dev branch. Not all of the commits are relevant for the whole of MOM6 community, and some of the commits need some work still. ACCESS-NRI/MOM6#38

[chrisb13]

Closing this PR as it's being picked up again here: #1078
(additional notes)

[dougiesquire]

(Reopened temporarily to give me permission to push the updated repro checksums to Claire's branch)