Add online mixed-layer tracer budget diagnostics

[rmholmes]

Integrates three-dimensional tracer budget process terms across the mixed layer at every model time step and divides by the mixed layer depth, enabling accurate online computation of the mixed-layer tracer budget (Holmes and Malan, article submitted to JAMES). Uses some existing mixed layer routines in ocean_tracer_diag_mod.

Addresses the mixed layer budgets part (but not the hat-averaging part) of #77

Two core routines added to ocean_tracer_diag_mod:
compute_budget_mld — MLD-averages a 3D tendency field
compute_tracer_at_mlb — linearly interpolates a tracer to the MLD base

Mixed layer budget tracer diagnostics:
temp/salt_in_mld — MLD-averaged tracer concentration (times rho0)
temp/salt_at_mlb — tracer at the MLD base (C_ent)

MLD-averaged tracer budget process diagnostics:
temp/salt_tendency_in_mld — total tracer tendency
temp/salt_advection_in_mld — resolved advective convergence
temp/salt_submeso_in_mld — submesoscale parameterized advection
temp/salt_vdiffuse_diff_cbt_in_mld — vertical diffusion
temp/salt_vdiffuse_diff_cbt_conv_in_mld — convective vertical diffusion
temp/salt_vdiffuse_k33_in_mld — along-isopycnal K33 mixing
temp/salt_vdiffuse_sbc_in_mld — surface boundary condition flux
temp/salt_nonlocal_KPP_in_mld — nonlocal KPP
temp/salt_rivermix_in_mld — river mixing
neutral_physics_ndiffuse_in_mld — neutral diffusion
neutral_physics_gm_in_mld — GM mesoscale eddy parameterization
frazil_3d_in_mld — frazil ice formation
sw_heat_in_mld — shortwave penetration below surface
swflx/lw_heat/sens_heat/evap_heat_in_mld — individual surface heat flux components
net_sfc_heating_in_mld — total surface heat flux
sfc_hflux_pme_in_mld — P-E+R tracer flux at surface
pme_river_in_mld — P-E+R mass flux within MLD
temp/salt_eta_smooth_in_mld — SSH smoother tendency within MLD

GVC-to-Eulerian correction terms (see Holmes and Malan appendix):
eta_t_tendency_times_temp/salt_in_mld — ∂η/∂t × MLD-avg tracer
pme_river_times_temp/salt_in_mld — P-E+R × MLD-avg tracer
eta_smoother_times_temp/salt_in_mld — SSH smoother × MLD-avg tracer
s_surf_ent_temp/salt — z* coordinate entrainment at MLD
base: (1-H/(D+η)) × ∂η/∂t × C_ent

Testing diagnostics:
eta_t_tendency_times_temp/salt_at_mlb — ∂η/∂t × tracer at MLD base

For more information including analysis code see:

• https://github.com/rmholmes/access-om2-sst-budget, in particular the Theory_and_Diagnostics.ipynb notebook.
• Holmes and Malan, journal article submitted to JAMES.

The changes in this commit were developed on an older version of MOM5. Claude Sonnet 4.6 assisted in porting them onto the current ACCESS-NRI MOM5 codebase (upstream/upstream-master) by extracting a patch from the development branch, applying it with conflict resolution, and improving inline Fortran documentation in the new code.

[rmholmes]

Ok I think this is ready to go, but I need to figure out how to test it in NRI simulations (rather than my old OM2 setup).

A few years with a 1-degree configuration (with my diagnostics added to the diag_table) should be sufficient. I can probably follow the instructions here to do that.

However, I'm not entirely sure how to deal with including the new MOM5 executable based on this PR in that testing run. In my setup I would have compiled it myself and then modified the config.yaml to point to that new executable - but with the new CI system I'm not sure if I still need to follow a similar process?

Any help would be appreciated. Maybe @chrisb13 or @dougiesquire - could you provide me with some pointers?

[dougiesquire]

Thanks @rmholmes. Would you be able to push your changes to a branch in this repo, rather than your own fork. Then we can use our CI workflows to easily deploy a version of ACCESS-OM2 with your changes for you to test (they don't run from forks for security reasons). You already have write access to this repo, so something like the following should work:

git remote add access-nri https://github.com/ACCESS-NRI/MOM5.git
git checkout mixed_layer_tracer_diagnostics_nri
git push -u access-nri mixed_layer_tracer_diagnostics_nri

Then you can open a new PR from that branch. Note, you'll also want the PR to be into the master branch, rather than upstream-master.

[rmholmes]

@dougiesquire I started looking at this and am somewhat confused. I thought the README (https://github.com/ACCESS-NRI/MOM5) suggested that I should be submitting the PR to upstream-master (note upstream-master, not upstream/master which is what the readme says), not master. But rereading it - should I instead be putting it against the canonical MOM5 repo (i.e. https://github.com/mom-ocean/mom5) first?

My changes were made against upstream-master, so I guess I should be cherry-picking my commit and then applying it to master instead?

[dougiesquire]

Thanks @rmholmes. Yeah I agree the README could be confusing - sorry about that.

Please make your PR to the master branch on this repo (ACCESS-NRI/MOM5). We'll test it it ACCESS-OM2 from there. Once it's review and merged into master of the ACCESS-NRI fork, we may want to also submit a PR to include it "upstream" (mom-ocean/mom5), but we can discuss that later on.

Fortunately I don't think you should have any conflicts rebasing or cherry-picking onto the master branch.