(#629) - Sync with the work on JULES

[ccarouge]

CABLE

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

Description

Fixes #629

This goes with the work in JULES to remove the CABLE files from JULES for the licence change.

The changes are as follow:

• remove files we decided belong to JULES for licensing reasons. Some of the files will need to be modified in JULES when we figure out the compilation to use the CABLE constant modules. But we can't keep the original of these files here (licensing reasons) so we'll need to refer to the JULES history for the details.
• Some science files had small differences between JULES and CABLE. Most were trivial and would not affect the results. A difference about spitter() was present but correspond to relatively new work in CABLE so I have chosen to accept the new version from CABLE. See notes:
  • params/cable_phys_constants_mod.F90: formatting and documentation differences only
  • science/roughness/roughnessHGT_effLAI_cbl.F90: differences in documentation only
  • science/albedo/cbl_snow_albedo.F90: different from JULES one but only because the sfact parameters have been given names instead of being hard-coded directly within the algorithm
  • science/radiation/cbl_init_radiation.F90: differences due to the documentation and the recent spitter() bug (bug in spitter call (MAIN branch) #355) . Original lines for the radiation split in JAC:

RadFbeam(:,1) = spitter(mp, cpi, metDoy, coszen, SW_down(:,1))
RadfBeam(:,2) = spitter(mp, cpi, metDoy, coszen, SW_down(:,2))

Two parameter files show differences between JULES and CABLE and need to be brought in sync in future work. These are copied under JAC/params/cable

Type of change

Please delete options that are not relevant.

• Sync with JAC work

Checklist

• The new content is accessible and located in the appropriate section
• I have checked my code/text and corrected any misspellings

Testing

The changes do not impact offline CABLE at all. They are linked to the JAC project and will only be used once we work on the new compilation to link JULES and CABLE.

Please add a reviewer when ready for review.

---

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

[JhanSrbinovsky]

All the changes being under JAC I don't really need to read through all the code. We can combine common files later. Hopefully even just submit a library to JULES as the plan was after CMIP5. The plan was rewound back then but I don't think we'll face the same resistance this time. We shall see

[har917]

as an aside - this parameter (at least) should be converted to a namelist read since it varies between ESM1.6, CM2, AM/CM3 and offline.

I'm also not sure why some of the dimension setting numbers aren't set in the grid_constants_mod

[ccarouge]

Opened issue for max_snow_depth (#640).

The rationalisation of the constant files is on going. Only the constants that were used in JAC have been rationalised. So there is a bit of a mix currently (no more than before though).

[har917]

niter shouldn't be being given here and in other_constants_mod - if nothing else you can add to the USE grid_constants_mod line

[JhanSrbinovsky]

an error. we would have to check which it even uses. I suspect grid-----. But this is only JULES coupled right, so hopefully not in all models

[har917]

Since it's JAC we won't ever have got to the point where the potential for conflict is an issue.

Most of what is in grid_constants and other_constants is common across all apps - so ideally these MODULES would be in the library. However for compilation purposes we'll need a version of these in JULES I think [I'm getting lost what's where now]

[ccarouge]

@har917 all CABLE constants will come from the library. For JULES currently (i.e. before the compilation is worked out), the constants are hard-coded in the JULES files with a comment to change when we work on the compilation.

Since these constant files are not currently used, I'll remove the niter declaration in grid_constants_cbl.F90 (because niter is not a constant defining the grid).

[ccarouge]

Sorry, just realised niter is currently (and annoyingly) a grid constant. So should be in grid_constants for now.

[har917]

Two changes needed I think

1. niter is defined twice
2. number of carbon stores nsCs should surely be 2 (INH edit on 27/10/2025 - this was supposed to read nsCS should surely be 3 - but I'm now leaning towards 2 being correct and being mistaken earlier).

@JhanSrbinovsky please note point 2. I am completely confused here. Yes, there is a difference between the CASA variables and the bgc% variables - but the luc3 code (which is based on CASA) also appears to use nsCs, as does the sli code.

Basically worth checking - and there is a longer-term question around whether to maintain the older bgc% code for carbon cycle work.

[JhanSrbinovsky]

dec of nsCs is only once:

params/cable_other_constants_mod.F90:USE grid_constants_mod_cbl, ONLY: nrb, nsl, nsCs, nvCs, msn => nsnl
params/grid_constants_cbl.F90:INTEGER, PARAMETER :: nsCs      = 2  ! # soil carbon stores

dec of niter is only once:

cable_other_constants_mod.F90:USE grid_constants_mod_cbl, ONLY: niter                    ! # iterations za/L
cable_phys_constants_mod.F90:REAL, PARAMETER :: zetmul = 0.4     ! if niter=2, final zeta=zetmul*zetar(2)

IN CABLE:main, ESM1.6.

I thought (if not already the same) @ccarouge 's plan was that we can sort this out later when we re-engage with JULES?

[ccarouge]

Ready for review @har917 . I would think the nsCs and ncs and casadimension nightmare is for another day.

[har917]

okay by me.

As an aside - we likely need an exercise to update/correct the FORD documentation in light of all the the code re-organisation. I suspect that some of the inline links are out of date