Set up M_regional_template branch

[dougiesquire]

Summary:

This PR is to set up a “template” branch for regional configurations (M_regional_template is currently the same as helen/access-rM-tas5km_jra_iaf+wombatleg). This branch will act as a stencil for the regional-mom6 package, but also will serve as something we can test against when we make updates/test upstream changes.

@ashjbarnes, sorry it took me so long to get to this. This branch runs with the latest ACCESS-OM3 exe. However, there are still some things that will need to be addressed before this can be merged:

• The input files used by helen/access-rM-tas5km_jra_iaf+wombatleg are no longer available. Some have been deleted and others have been moved into a “to_delete " folder. So for now, I’ve instead just used a copy of inputs @ashjbarnes had at /g/data/tm70/ab8992/rom3-boundary-troubleshooting/rom3-run (luckily I made a copy because these also no longer exist).
• I haven’t really edited the MOM_input settings other than to turn off generic tracers and a few other small changes. The MOM_input will need to be reviewed and maybe updated.
• I have used @ashjbarnes' MOM_override from /g/data/tm70/ab8992/rom3-boundary-troubleshooting/rom3-run. The MOM_override will need to be reviewed and maybe updated.
• The config uses a very simple diag_table with some grid metrics and depth, temp, salt, horizontal velocities on native grid. This is maybe fine given the purpose of the config.
• A metadata.yaml file should be added.
• Once ready, we'll need to update the checksums

@ashjbarnes and @helenmacdonald, you'll need to decide what to do about the input files. These need to be available in vk83 with provenance information in their metadata so that they can be regenerated.

Please feel free to push changes to this PR (e.g. to update MOM_input, MOM_override etc)

Issues Addressed:

• Set up M_regional_template branch #1463

[ashjbarnes]

Awesome thanks so much @dougiesquire !!

[ashjbarnes]

I've tested and run the model with the latest rmom6 (post a lot of changes that @manishvenu and I made at NCAR) and these template files, so all is well. A few thoughts in order of the bullet points above:

• I'll put the Tasmania input files somewhere in vk83 for testing purposes. Importantly though, the intention is for users to generate all input files when learning to use rmom6 with the demo, so these input files will only be used for ACCESS-NRI testing
• For MOM_input, shall we start from NCAR's MOM_input parameterisation choices for regional? They've done a lot more optimisation for generic regional configs recently so we could leverage what they've learned
• MOM_override is always generated by rmom6, so we shouldn't update it manually if this repo is used to test rmom6. If there are any changes due to rmom6 changes, I'll push these.
• For the diag table: even this simplified one produces a lot of files. For a small regional run, could we have multiple variables in a single file like 3d_weekly or something? Or is that not the ACCESS-NRI way? I'd also change the outputs to weekly not monthly since for the demo we probably only want users running for like 10 days at a time

One last thing: using JRA surface forcing with GLORYS boundary forcing is a very unlikely choice for science runs due to the mismatch in data product. My preference would be that the rmom6 template used ERA5 surface forcing. I could do this now with a modified fd.yaml and datm_in file so we leverage rmom6's inbuild ERA5 functionality (it just mimics JRA forcing fields), or if the ERA5 forcing branch is ready and stable we could try that again.

[ashjbarnes]

As discussed with @helenmacdonald and @dougiesquire , before merging we need to put rmom6 version used to generate each .nc file into the metadata of each .nc file. Ashley to do this.

Quick changes:

• Update diag_table to weekly output (maybe even daily for surface fields so user can at least see a bit of a timeseries for short runs? @dougiesquire ?)
• Copy rmom6 demo notebook into this repo. This notebook is to be manually kept up to date with the rmom6 repo one by ACCESS-NRI by copying the latest version, at the same time updating the config.yaml to point to the newly generated .nc input files. This doesn't affect rmom6 since the config.yaml is overwritten to point to user's .nc files, but important for NRI testing. @dougiesquire did I explain that right?

Other items will be done as later PRs, including

• Update the MOM_input to match NCAR's that @manishvenu has worked on. @helenmacdonald to do this while looking into inputs for superaus
• Include ERA5 forcing, hopefully using @ezhilsabareesh8 's method as long as there's no longer significant slowdown on small regional domains when trying to read global datasets. If not we can still use rmom6's era5 method

[ashjbarnes]

Having thought about it more, I'm not a fan of having a copy of the notebook in this repo. The issue is that if the workflow is:

1. Get the notebook from regional-mom6 repo, where it's embedded in the docs
2. Follow the notebook which then tells you to...
3. git clone the template

then the user will now have just cloned another notebook almost identical to the first one into the run directory but that they have no use for. I think this is messy and confusing for new users.

@helenmacdonald , @dougiesquire can we think of another way to do this? Preferably this could be something done quietly in the background and not muddy things for users. Perhaps whoever maintains this template at ACCESS NRI can copy the notebook to the same folder as where the rmom6-generated forcing files will live for your OM3 testing?

[ashjbarnes]

I've now implemented the appending of rmom6 version to the .nc metadata in this PR:

https://github.com/COSIMA/regional-mom6/compare/deploy_rom3?expand=1

As this was the only other thing to handle, my preference would be to get this merged into the main template and handle the above issue in a separate PR

[ashjbarnes]

Another thing that needs fixing that's not really in my wheelhouse is payu checking the manifests:

After a fresh git clone of this branch, running through the regional-mom6 workflow to the end, which modifies the config.yaml to point to the newly generated input files, I tried the usual payu setup in the run directory and got this error, followed by a long list of all the new input files with mismatched hashes

laboratory path:  /scratch/gb02/ab8992/access-om3
binary path:  /scratch/gb02/ab8992/access-om3/bin
input path:  /scratch/gb02/ab8992/access-om3/input
work path:  /scratch/gb02/ab8992/access-om3/work
archive path:  /scratch/gb02/ab8992/access-om3/archive
Metadata and UUID generation is disabled. Experiment name used for archival: rOM3-tassie-demo
payu: work path already exists.
      Sweeping as --force option is True.
Removing work path /scratch/gb02/ab8992/access-om3/work/rOM3-tassie-demo
Removing symlink /g/data/gb02/ab8992/rom3-rundirs/rOM3-tassie-demo/work
payu: Found modules in /opt/Modules/v4.3.0
Loading access-om3/2026.05.002
  Loading requirement: access3-share/2026.03.002-m65pkhf access-cice/CICE6.6.3-1-uqsyhj7 access-mocsy/2025.07.002-5awgzcl
    access-generic-tracers/2026.05.000-7jsawsl access-mom6/2026.05.001-impfcxi access-ww3/2026.03.000-kjy7rmt
    access3/2026.03.002-7t6n2ft
Setting up access-om3
Checking exe, input and restart manifests
Run cannot reproduce: manifest manifests/input.yaml is not correct
Manifest path: stored hash != calculated hash

I've tried deleting the manifest folder entirely figuring payu might make a new one for me but that didn't work. I understand why there's all the checking of manifests, but this template necessarily needs to be easily modifiable by the user, since the point is that they'll re-generate all of the input files themselves

@aidanheerdegen @dougiesquire @anton-seaice @jo-basevi any suggestions as to how to set things up so that the input files in config.yaml can be modified and user can then just run

payu setup
payu run -f

?

[manodeep]

@ashjbarnes You have to set manifest->reproduce->input to False and then run payu setup. That should overwrite the stored hash

[dougiesquire]

Yup, we should change that in the config.yaml for this config given how you're saying the config will be used

[ashjbarnes]

Thanks! I did find the manifests section of the payu docs, but the "manifest options" section was pretty vague. Could these settings please be included there? I've made an issue

[ashjbarnes]

ok @helenmacdonald just for future reference we now have the "controversial era5 commit" to be undone when era5 forcing is done and someone has capacity to test it out on regional configs

[ashjbarnes]

@helenmacdonald I'd rather not have the notebook in the repo. For users running the regular regional-mom6 workflow to generate new bespoke domains, they will be cloning this repo and end up with an unrelated notebook for the Tassie demo. Since this notebook isn't attached to regional-mom6, which will be updated independently of this template, you could have situations where a new user clones this repo and then finds a notebook that's different than the new example notebook on regional-mom6

I'd like this repo to be as clean as possible and avoid confusion for new users. Since the only need for the notebook is provenance, could they just live on disk alongside where the inputfiles will be saved on vk83?