Bring up to date with ACCESS3 science

[Whyborn]

CABLE

Thank you for submitting a pull request to the CABLE Project.

Description

These are the science changes that occurred in the CABLE code that sits within JULES for AM3, that we want to move into the library. The changes removing the calculation of gamzz and trad_corr were discussed in the CABLE science update PR, here and here. I had missed the change from using ssnow%otss to snow%tss in the soil_trad calculation, but appears to be a deliberate change from this JULES commit.

I am a little confused though- in your comment here @har917, you said that the trad_corr is still required in the impl call, but this JULES commit removes it from both expl and impl call. Should the trad_corr be re-introduced to the impl call?

It may also be preferred to leave cbl_cbm_mod.F90 within JULES- at the moment, I only moved it since it lived in the same directory as all the geophysics type definitions, which must live within the library, but this isn't required for any of the science code. It may make more sense to leave it within JULES.

Testing

• Are the changes bitwise-compatible with the main branch? If working on an optional feature, are the results bitwise-compatible when this feature is off? If yes, copy benchcab output showing successful completion of the bitwise compatibility tests or equivalent results below this line.

2026-07-03 12:23:52,415 - INFO - benchcab.benchcab.py:391 - 0 failed, 168 passed

---

📚 Documentation preview 📚: https://cable--729.org.readthedocs.build/en/729/

[JhanSrbinovsky]

I'll wait for comment from @har917 before I approve

[har917]

Where is the equivalent bit of science in the library - i.e. where is %gamzz being initialised on the first call in offline and AM3 (likely um_init_soilsnow)?

[Whyborn]

Apparently this is now stored in the restart. We had a long conversation about this in the JULES PR, and the gist was that this bit of code can be removed. In offline mode, we call spec_init_soil_snow from the driver which overrides this anyway.

[har917]

I am a little confused though- in your comment https://github.com/ACCESS-NRI/JULES/issues/320#issuecomment-3765844984 @har917, you said that the trad_corr is still required in the impl call, but this JULES commit removes it from both expl and impl call. Should the trad_corr be re-introduced to the impl call?

aargh - this brings back "war" memories which I have (thankfully) mostly forgotten.

For definite - trad_corr should not be in cbm_expl

For cbm_impl: Basically we need to use %tss [end of time step] or (%otss [start of time step] and trad_corr [change over time step] together in partnership). If I remember the deliberations/testing, properly Martin and I landed on using %tss (for consistency with how we deal with the vegetation contribution to rad%trad which is also the [end of time step] value).

But probably worth looking through the issue/PR around temperature oscillations.

[Whyborn]

I found the relevant issue- seems the current form is the one that was deemed to be most accurate i.e. not using trad_corr in either expl or impl and using the end of timestep temperature tss.

[har917]

Happy with this.

[Whyborn]

I'll do a quick benchcab run to make sure nothing unexpected has happened. If it shows no differences, I'll merge.

[Whyborn]

Benchcab reports identical results.