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

image image image

Litter pools

image image image

Harvest pools

image image image

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):

Re-ran and plotted using esmscripts. Better now. The wood_flux must not include harvest from thinning…

Wood flux from land use change


Wood harvest pools

image image image

Wood products respiration

image image image
1 Like

I’m not sure I understand: did you change anything in the code or configuration or did you change something in what you are plotting?

Are the big differences in wood harvest pools and wood products respiration expected? The *_1 from the thinning seem to trend towards the blue line but not the other *_2 and *_3. So it looks quite different. Are we expect large differences or something similar?

No code changes other than the initialization fix, it was the configuration. I’m not exactly sure what the problem was but I tried using the ksh esmscripts to do the same thing. I wanted to first reproduce the HI-25 simulation and then turn on the thinning. I will go back and try and do the same for payu.

Are the big differences in wood harvest pools and wood products respiration expected?

I expect it to be higher but by how much I’m not sure. The point of all this is to increase the land-use change flux so that NBP more closely matches the Hoffman dataset. Here is the resulting NBP (NPP+RH+wood_respiration):

Previously ACCESS NBP was negative (net sink). I want the blue line as close as possible to the grey line. So far, so good.

Thanks. I wasn’t sure what was the link between what you plotted before and the NBP. I didn’t know if we would need to sum or subtract the terms etc.

It looks amazingly close to Hoffman now!

It’s only 16 years of data, so that remains to be seen :slight_smile:

Thanks for putting in the effort @tammasloughran. We definitely need to know if there is something missing from existing payu configurations.

It is not tenable to have a scripts that do there right thing if we don’t understand why.

Screenshot from 2024-05-03 10-18-10

The new NBP with wood thinning included does well for most of the historical period but diverges after 1950. At least we have the right sign now.

1 Like

One question remains why the wood respiration is larger than the wood harvest pools. I’ve treated wood_harvest pools here differently to the wood_respiration.
I know that wood respiration variable output by the model has already been multiplied by the tile fractions, so it should only be multiplied by the land cover fraction and tile area to do a global sum. I assumed that wood harvest pools should be multiplied by the tile fractions. Am I wrong here?

Which variables do/do not need to be multiplied by the tile fractions to do aggregations is not documented anywhere and it has tripped me up several times.

I was concerned that there would be more large spikes in the latter part of the historical period as new regions begin being harvested (like we see at the start of the run), but that does not seem to be the case.