CABLE Library for AM3/ACCESS3 by Whyborn · Pull Request #724 · CABLE-LSM/CABLE

Whyborn · 2026-05-22T04:33:36Z

CABLE

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

Description

This builds the library for AM3 and future ACCESS3 applications. It requires a rejig of the original library, taking some files out of the default library and including them only in ESM1.6. The intention was that the library would only be the science code, but this is not possible with the current setup.

A summary of things that the science directory depends on, that extends outside the science directory that I've identified:

The biogeophysics derived types are not defined within the science directory, as opposed to the CASA derived types which are defined within the science directory. Each of these have different definitions for each application (offline, ESM1.6, AM3). Logically, there should only be one definition, but I don't think this will happen any time soon. In the mean time, including the type modules in src/coupled/AM3/control/cable/CM3 in the library should be an acceptable solution.
The trickier problems are the namelists and surface types handling. These are related issues, as the cable_surface_types_mod module also reads the namelist that sets the CABLE surface types. Do the surface types need to be handled in this way? Is there any foreseeable situation where anyone would not use the standard CABLE PFT indexing? If we remove this, it makes things significantly easier. It also does the extra work of defining a bunch of required JULES variables. I think the best solution is go back to hard-coded CABLE PFT indices, see this JULES PR.

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.

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

Whyborn · 2026-07-03T06:48:02Z

This now, along with JULES PR #346, access-spack-packages PR #460 and UM PR #148 successfully builds AM3 with CABLE as a library and achieves bitwise compatible results.

ccarouge · 2026-07-06T06:16:04Z

@Whyborn Can you please add the benchcab results for bitwise reproducibility?

ccarouge

A few requests for more explanation and some relatively minor changes.

ccarouge · 2026-07-06T06:19:14Z

      spack-manifest-data-path: .github/build-ci/data/standard.json
      # We need to install the compilers manually here because the upstream image is too large to run on GitHub-hosted runners
      spack-compiler-manifest-path: .github/build-ci/compilers/spack.yaml
+      access-spack-packages-ref: 1d9acf45c39229ff4e90a9aa49922b1169305476


What is this line doing? Why is it needed now and not before?

That's to make the CI use the correct version of the spack packages. I should get the spack packages PR merged in first, tag it, then refer to that tag here.

Oh actually I think I can remove that line completely when the spack packages update is merged, as I think it uses the head of the default branch if not specified?

ccarouge · 2026-07-06T06:20:21Z

Why is this file modified for the library work? I would guess we do not compile this for AM3.

This was intended to be a bit of future proofing, as Sean's MPI slightly modified the land use change code which was referred to by the AM3 code, even if not yet active. We came up with a better solution in this merged PR. I'll remove this change.

ccarouge · 2026-07-06T06:22:30Z

Why are we adding this to science/ when it is only to be used in ESM1.5/1.6? Should the # define ESM15 YES be # define ESM15 NO in the offline repository? Or even, remove that line from the file and deal with it at compilation as usually done for pre-processor flags.

And why is it part of the AM3 library work?

Unfortunately the land use code had moved in a bit from the form that is in AM3. The JULES src/science_cable/landuse/landuse3.F90 should be the same as src/science/landuse/landuse3, but it isn't, and the coupling code is written based on the JULES version. A few routine signatures have changed, and I was getting type mismatch errors when I tried to quickly fix it.

I should remove the #ifdef and #def. I think it's best to get this in first, then reconcile the differences between the way this routine is called in the coupling and then remove this file.

Files that are modified from the offline version for the coupled versions should all be stored under src/coupled/AM3. Can we put this under src/coupled/AM3/cable/landuse? If there are other files that are slightly different

Can you also clean up the src/coupled/AM3 directory tree of everything that isn't needed for the library, please? These files are not used and should not be kept around. As part of this PR, please.

Yep, can do.

ccarouge · 2026-07-06T06:26:40Z

-        src/science/casa-cnp/casa_dimension.F90
        src/science/casa-cnp/casa_feedback.F90
        src/science/casa-cnp/casa_inout.F90
        src/science/casa-cnp/casa_param.F90
-        src/science/casa-cnp/casa_phenology.F90
-        src/science/casa-cnp/casa_readbiome.F90
        src/science/casa-cnp/casa_rplant.F90
        src/science/casa-cnp/casa_sumcflux.F90
-        src/science/casa-cnp/casa_variable.F90


What happens to all these CASA files for the ESM1.6 library? Were they added but are in fact not needed?

Unfortunately these are bits that had been rewritten for AM3- the way the derived types are structured is different to offline, see this JULES issue. This is related to the duplicate ALLOCATABLE/POINTER type definitions that I wanted to unify some time back. The AM3 versions of these live in the JULES src/util/casa.

I don't think I follow what you are saying. So these files are not the same between ESM1.6 and AM3, ok. But it does not explain what happens for these files for ESM1.6. Right now, these files completely disappear of the compilation of ESM1.6 library in this PR, making me doubt that the compilation of the ESM1.6 library would work..
At the same time, I'm pretty sure we said this version of CABLE won't be compatible with ESM1.6, so should we not include an ESM1.6 library in the CMakeLists.txt file?

Yea, I think its either:

Include those files in the ESM1.6 library build

Drop the ESM1.6 library build altogether

With the conversations around BLAZE ongoing, I think it would be wise to keep the ESM1.6 library code there and add the files. I don't think it would be much work to make the ESM1.6 library build again, but keeping the list of files up to date would make future life easier if someone else was to come work on it.

OK, when you have time, can you look at making sure the ESM1.6 library works. Can it also be added to the compilation CI in CABLE's PRs then so we would do 2 library builds?

Can I make that a separate PR? Separate that work from the AM3 work.

Should we keep the files in the list then so that it's easier to identify these files are problematic for the work on ESM1.6? Or comment them out with enough explanation to know what's needed?

We can't leave them in the list uncommented, as the build with fail, but I think commenting them out with an explanation is a good idea.

Whyborn · 2026-07-09T06:05:08Z

Benchcab output:

2026-07-09 15:54:21,176 - INFO - benchcab.benchcab.py:391 - 0 failed, 168 passed

ccarouge

A few more things to do I think. Small things.

ccarouge · 2026-07-23T04:08:15Z

+            src/coupled/AM3/control/cable/CM3/air_type_cbl.F90
+            src/coupled/AM3/control/cable/CM3/balances_type_cbl.F90
+            src/coupled/AM3/control/cable/CM3/bgc_pool_type.F90
+            src/coupled/AM3/control/cable/CM3/cable_define_types.F90
+            src/coupled/AM3/control/cable/CM3/cbl_canopy_type.F90
+            src/coupled/AM3/control/cable/CM3/cbl_cbm_mod.F90
+            src/coupled/AM3/control/cable/CM3/climate_type.F90
+            src/coupled/AM3/control/cable/CM3/met_type_cbl.F90
+            src/coupled/AM3/control/cable/CM3/radiation_type.F90
+            src/coupled/AM3/control/cable/CM3/roughness_type.F90
+            src/coupled/AM3/control/cable/CM3/soil_type_cbl.F90
+            src/coupled/AM3/control/cable/CM3/ssnow_type.F90
+            src/coupled/AM3/control/cable/CM3/sum_flux_type.F90
+            src/coupled/AM3/control/cable/CM3/veg_type.F90
+            src/coupled/AM3/control/casa/types/casa_balance_type.F90
+            src/coupled/AM3/control/casa/types/casa_biome_type.F90
+            src/coupled/AM3/control/casa/types/casa_files_type.F90
+            src/coupled/AM3/control/casa/types/casa_flux_type.F90
+            src/coupled/AM3/control/casa/types/casa_met_type.F90
+            src/coupled/AM3/control/casa/types/casa_phenology_type.F90
+            src/coupled/AM3/control/casa/types/casa_pool_type.F90
+            src/coupled/AM3/control/casa/types/sum_casa_flux_type.F90
+            src/coupled/AM3/control/casa/types/sum_casa_pool_type.F90
+            src/coupled/AM3/control/casa/types/casa_variable.F90
+            src/coupled/AM3/control/casa/types/phen_variable.F90
+            src/coupled/AM3/control/casa/types/casa_dimension.F90
+            src/coupled/AM3/control/casa/types/casa_inout.F90
+            src/coupled/AM3/control/casa/types/casa_readbiome.F90


I would simplify these paths:

src/coupled/AM3/cable/types/ and src/coupled/AM3/casa/types.

ccarouge · 2026-07-23T04:11:56Z

Files that are modified from the offline version for the coupled versions should all be stored under src/coupled/AM3. Can we put this under src/coupled/AM3/cable/landuse? If there are other files that are slightly different

Can you also clean up the src/coupled/AM3 directory tree of everything that isn't needed for the library, please? These files are not used and should not be kept around. As part of this PR, please.

ccarouge · 2026-07-23T04:13:47Z

-        src/science/casa-cnp/casa_dimension.F90
        src/science/casa-cnp/casa_feedback.F90
        src/science/casa-cnp/casa_inout.F90
        src/science/casa-cnp/casa_param.F90
-        src/science/casa-cnp/casa_phenology.F90
-        src/science/casa-cnp/casa_readbiome.F90
        src/science/casa-cnp/casa_rplant.F90
        src/science/casa-cnp/casa_sumcflux.F90
-        src/science/casa-cnp/casa_variable.F90


Should we keep the files in the list then so that it's easier to identify these files are problematic for the work on ESM1.6? Or comment them out with enough explanation to know what's needed?

…ke-AM3-library

Whyborn · 2026-07-28T05:39:13Z

Ok, I think this is ready to go. Aside from the main purpose of making the library for AM3, this PR:

Removes all the files that are not necessary for the library build, so that they only exist in one place (i.e. JULES).
Moves the old landuse code to the coupled/AM3/cable/landuse directory, until it can be unified with the offline version.
Adds CI for the ACCESS3 library build with GCC and Intel, as well as a build of UM with the head of the AM3-dev branches for both UM and JULES. This is the bit I'm not sure is the best choice, since neither of those repositories have CI set up either, so people could break CABLE builds without realising. I can add CI to both those respective repositories as part of the respective library PRs.

Future work related to this is the unifying of the types used between the coupled and offline models. This should be possible with a "medium" amount of work.

Whyborn and others added 30 commits May 22, 2026 14:19

Rejig library config for AM3

785febe

Add library manifests to CI

5e0bd5a

Add library manifests to CI

5ea70cd

Set ref for spack-packages

1bdd923

Remove templates taken from spack-packages

3cb4057

Fix quotes

329c302

Misspelled matches

4a692ca

Move some files to common library

395b1fa

Add type files to library

d033810

Fix some file names

f84c396

Fix more file names

fea2e45

Drop coupled namelists mod

b5e9b4d

Add surface types mod

367ba2f

Fix name

878632d

use new cable_surface_types_mod.F90

114cf54

Wrong end subroutine name

cb6ac5c

Add stash mapping

26c5d59

Add ncpft back

8b94bfb

Add dimension declaration

6f9b9b0

Remove CASA IO from library

0bd7975

Readd landuse

de283d4

Fix file name

921abd5

Add cable_iovars.F90 to the build with slight adjustment

feb632b

Readd casa_inout

dc432f7

Library now builds

4813a19

Remove casa_variable.F90 from library

911c2b3

Add all the CASA types

f5662be

Update CASA types

c6fe3e5

Use new cable_surface_types_mod.F90

8d4ebc6

Fix dummy argument intents

6d8f1a1

Whyborn requested a review from ccarouge July 3, 2026 07:05

Whyborn added 2 commits July 3, 2026 17:06

Merge branch 'main' into make-AM3-library

e413350

Didn't fix the merge conflict properly

7cd8286

ccarouge requested changes Jul 6, 2026

View reviewed changes

Address PR feedback

ef8cdfd

Whyborn requested a review from ccarouge July 9, 2026 06:25

Whyborn mentioned this pull request Jul 10, 2026

Changes to UM build system and CABLE package to build AM3 with CABLE library ACCESS-NRI/access-spack-packages#460

Merged

Add files back to ESM1.6 library

4d4c117

ccarouge requested changes Jul 23, 2026

View reviewed changes

Whyborn added 16 commits July 27, 2026 15:28

Modify CI for ACCESS3

9d5714e

File name typo in things moved to ESM1.6 lib

f2acc72

Move cable_iovars.F90 to core library

1003d02

Remove duplicate cable_iovars.F90

713372e

Move type files to more logical location

49435ab

Remove all files that exist in the coupling code

b6c0646

Merge branch 'main' into make-AM3-library

85c8a86

Move the ESM1.5 landuse file

f11d99c

Merge branch 'make-AM3-library' of github.com:CABLE-LSM/CABLE into ma…

0e72a98

…ke-AM3-library

Somehow the old CI manifests came back

d7f4be8

Add CI for UM in ACCESS3

a9c3331

Bad indenting

360c0ae

Fix model variant spec

1f63ec5

Try adding python dep

5a6d286

Add @ for compiler spec

2548615

For some reason this needs Python?

def2a99

Whyborn requested a review from ccarouge July 28, 2026 05:39

Uh oh!

Conversation

Whyborn commented May 22, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

CABLE

Description

Testing

Uh oh!

Whyborn commented Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ccarouge commented Jul 6, 2026

Uh oh!

ccarouge left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Whyborn Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Whyborn commented Jul 9, 2026

Uh oh!

ccarouge left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Whyborn commented Jul 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Whyborn commented May 22, 2026 •

edited by github-actions Bot

Loading

Whyborn commented Jul 3, 2026 •

edited

Loading

Whyborn Jul 13, 2026 •

edited

Loading