Wood thinning in ACCESS

In CABLE, when land-use change occurs, for example from forest to grass, the forest is completely cleared and the harvested wood is placed into wood product pools. However it’s possible to remove wood from a forest by selective logging that does not involve a complete transition to grass. We have an implementation of this in CABLE, which we call “thinning”. Despite this being developed before CMIP6, the testing of it was incomplete and the impending CMIP6 deadlines resulted in it being disabled in those simulations. Since then, it has been largely forgotten. It is however potentially very useful. Considering the fact that ACCESS’ land-use change flux is too low (and consequently NBP), additional wood thinning may help.

I have done an 18-year simulation for testing purposes using ACCESS-ESM1-5 with wood thinning enabled.

I’m currently in the process of trying to understand the LUH2 wood thinning inputs and the outputs of the model. The purpose of this post is to share the progress and information about wood thinning in CABLE as I work on it.


Some plots from my first attempt at running this.

Vegetation pools


Litter pools


Harvest pools


The code seems to work.
Carbon is harvested from the vegetation pools and is put into the litter pools much like regular land use change.
The wood product pools (wood_harvest_n) decay over time except for the slowest pool with accumulates.

The problem seems to be that the thinning forcing data is not being used. The vegetation is harvested everywhere and a lot is being harvested (almost all of it).
The variable code in the restart file it’s supposed to use is 916. This is a spatially explicit fraction of harvested biomass. 0 means all wood is harvested and 1 means no wood is harvested. I suspect that this is initialized with 0s and then the UM somehow never passes the thinning data to CABLE. I’m not really familiar with the UM-CABLE interface code.

Maybe I’m injecting the thinning data into the wrong field in the restart file? I know it’s supposed to be 916 but there are several 916s in the restart file.

1 Like

I’ve traced back the THINNING variable through cable to the UM:

  • ATM_Step
    • Atmos_Physics2
      • Ni_bl_ctl
        • LB_INTCT
          • BDY_LAYR
            • SF_EXPL
              • SF_EXCH
                • cable_explicit_driver
                  • interface_UM_data
                    • init_casacnp
                      • casa_init_pk
                        • casa_reinit_pk
                          • newlitter

THINNING is pointed to the D1 superarray in set_atm_fields in the UM, which I assume contains the STASH variable from the restart file.

The STASHC in the payu configuration does indeed have a 916 code in it.

1 Like

This is the xconv display of stash code 916 after I have injected the thinRatio data into it:

Thanks @Jhan! Whatever it is that comes out of cable and back into the restart dump is full of zeros again.

I’m guessing you’re talking about this line of CABLE?

The version of CABLE coupled to ESM1.5 that I’m looking at does not have this line.
I think my local repository is not the exact same version as the UM executable that I’m using.

yeah it was but I really dont think that is the problem.

Last time I looked at this was incomplete. I looked for thinning at the CABLE end, found it in _explicit, passed to the interface data, then I turned around and followed it back up through the UM to the IO where the entry wasn’t in the STASHmaster. So this time I found it at the CABLE end and followed it down to where it was PACKed into the cable field. It isn’t. It curiously gets used (potentialy). It’s inside a nested IF, IF,IF loop, so might never be executed. I dont think it is even evaluated anywhere. I thought OK so at the very least I can’t see it. Let’s look at where it is UNPACKed. It isn’t. Searching for “thinning” in cable_implicit*, the lines for thinning in the arg list are commented out. Actually there are lots of fields commented out there that would be of interest to you.

At first I was going to pass them all through, but then I decided against that and only do the THINNING field. I had to trace it back through the UM. I got this to build and in the interim my plan was to work out where to UNPACK it from, run it and check if it was fixed or not. So I had another look at casa_um_inout to find where it was packed to etc. It definitely isn’t.

You might be able to find where it is missing, but as it stands it just hangs there. #916 is in the restart as 1 everywhere. I don’t know where the evolution over a year is coming from. This should be investigated as well. I’ll look int this shortly. Did your monthly values come from a .pm file?

My code with all that threading I mentioned is at:

This code is ESM1.5-CABLE3 code so may look slightly different than the CMIP6 code.

Many thanks Jhan,

the repo you pointed me to is CABLE3. For better comparability to the existing historical simulation I might want to use the CABLE2.5 code.

Now that I have a working development pipeline, I’ve recompiled UM+CABLE2.5 with the thinning = 0 line removed and that seems to have improved the situation.

The below is the wood_harvest_1 pool after 1 month and it looks like the thinning fraction data is being used now.

I will have more plots later when the simulation has finished.

Something is wrong. :frowning: The wood flux (biomass removed from land-use change clearing and thinning) is orders of magnitude larger than the standard historical simulation (blue=thinning, orange=historical).


Looking at a specific grid point (left is with wood thinning on and right is wood thinning off):