Developing a CABLE4 work plan: Issues to consider

This topic captures issues that need addressing in planning CABLE4 coding. Issues could be summarised here as a list of dot points, with further information in separate posts.

  • Offline implementation first
  • Vegetation distribution mapping
  • New variables required
  • Test cases (simplified vegetation distributions, single site with multiple tiles)
  • 27 tile tests in offline, finding hard-wired vegetation types

Vegetation distribution

  • change PFT distribution we are using to have only one woody vegetation per gridcell
  • update the vegetation distribution map to use the same in offline and ACCESS
    • settle on the source of vegetation map.
  • change POP and POPLUC to work with an exogenous vegetation distribution instead of one that is calculated within CABLE.
  • BIOME information handling: How to get the woody fraction if reading an external vegetation map and not doing do_climate?

CABLE offline working with 27 tiles

  • remove hard-wired vegetation-type numbers
  • make sure it works with 2 tiles representing the same vegetation type (primary and secondary forest)
  • what do we want the tiled output to be like? Do we want to output the primary and secondary fractions separately or together?

Mapping of vegetation types between CABLE (27) and POP (3)

  • how to handle cells with no vegetation (lake, ice, bare soil, urban)
  • How to map out the 27 tiles to 3 tiles? How to identify secondary/primary? How to aggregate and disaggregate non-woody, vegetated types?

Efficient parallelization for CABLE4

  • review the entire implementation of MPI to ensure we have efficient parallelization capacity.
  • considerations of future development (river routing, lateral flow…)

Analytic spinup

  • currently not working with phosphorus. It should speed up the spinup significantly if we can get it working.

BLAZE, CROP models handling

  • How to handle them so we don’t completely remove the feature from the offline code, even if not going into the coupled code.

I’m replying instead of editing the first post, this way I can put my ideas in whatever order and use the first post to create the plan once we have more input.

Reorganise CABLE-POP_TRENDY directories and files

It needs to follow the same directory and file organisation as the main branch.

27 tiles

  • remove hard-wired vegetation-type numbers
  • figure out how to handle primary and secondary tiles of the same type:
    • where do we need to distinguish and where does it not matter?
    • if the code checks on a specific veg. type that can be primary and secondary (IF condition), we need a way to check against both vegetation indexes.
  • reprocess ancillary data for 27 vegetation types for offline and online

Work done in main or CABLE-POP_TRENDY. The choice of branch will be dictated by other work or considerations.

Tile mapping from CABLE to POP-POPLUC

  • From CABLE to POP-POPLUC: concatenate the grassy types together.

    • what happens to the non-vegetated types? Does POP assume primary+secondary+grass cover the whole grid cell area? Or does POP carry an area fraction for each tile and never use the fact these fractions add up to 1?

    • that’s complicated. See Ian’s documentation.

Work done in CABLE-POP_TRENDY? To be able to compare to current simulations with POP?

Working MPI implementation with POP

I’m not sure when we will need to be able to run a large configuration with POP.

Analytic spinup for phosphorus

Apparently this is broken and could lead to big gains in speed for the spinup.

Testcase: running TRENDY configuration with main?

Is that useful to have?

Testcase: idealised testcases

  • Single point testcase(s) with one type with primary and secondary to test implementation in the 27 tiles work, no POP and no LUC: should both tiles give the same results? Or is CASA different on secondary vegetation? Could be an array of single points to test for different climatic conditions.
  • Testcase with woody + grass + non-vegetated, with LUC: test that the non-vegetated area size is maintained.

@inh599 @Juergen If you have the time to jolt down some ideas in here before our meeting tomorrow that would be useful.

@clairecarouge @Juergen Are we meeting tomorrow? RL is on leave if I remember correctly.

yes we are. I’ll run the meeting. The aim is to advance this work plan around CABLE4.

(No regrets) Elements of a work plan:

  • removal of hard-wired indices throughout the CASA, POP etc. code
  • conversion of POP state variable from being carbon stocks in each patch/cohort/age class to proportion of total carbon stock in each patch/cohort/age class (will allow easier matching between CASA an POP)
  • design of technical method to connect between 17/27 tiles in CASA and 3 POPLUC tiles
    ** we will need to have 3-tile CASA TYPES either as work space or formally carried around
    ** we will need to have some generic way of identifying which CASA17 tiles get mapped to CASA3 and POP3 (and vice-versa) when in mp-vectors - likely requires new a TYPE.
    ** how to handle cells with no vegetation (lake, ice, bare soil, urban)
    ** streamlining the cable%climate TYPE
  • BLAZE (how to handle in the interim)
  • Add to POP_TRENDY a capability to read in externally provided land cover/transition/Biome-1 dependent inputs to avoid the need to co-run with the BIOME-1 model.


  • some form of automated namelist creation at the node/processor level (we will need some restart files to be identified at the minimum)
1 Like

small additions:

  • creating a POP namelist file should help in reducing the number of hard-coded constants and make experiments easier wrt modifying number of patches and cohorts

Another no regrets element to consider

  • rationalizing/simplifying the climate% TYPE

At the moment this is all encompassing and involves things like 20 year running means. I would not be surprised if we can’t handle these requirements in different (more efficient) ways without much impact on performance.

Slides from meeting on 11/7/2024

intro slide including a set of assertions about the current (baseline) condition of the offline and coupled models. A key challenge for CABLE4 and ESM3 is the desire to relax POP’s 3 tile configuration when inside ACCESS, without having to undertake a fundamental rewrite.

Box-stick diagram of the current offline POP-enabled code

Box stick diagram of proposed CABLE4 - note boxes with dashed line would require some technical modification or are new routines. Note the key move of POP and POPLUC from the end of year to beginning of year.

option for implementation within ESM3 - largely follows the current implementation within ESM1.5 and CM2. This method would require a mismatch between the albedo seen by the atmosphere and the albedo of the land during the first hour of each year.

Alternative for implementation within ESM3 - the key difference being that the carbon cycle (and if possible soil hydrology) is moved to extras. This move would better align CABLE-CASA-POP with the structure of JULES. This method would still require a mismatch between the albedo seen by the atmosphere and the albedo of the land for some of the first hour of each year.

Five broad technical tasks that would be necessary for this implementation method - note that the detail of the science of the interface is largely hidden inside task 4.