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’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.

1. Implementation

1.1 Land-use change in CABLE coupled to ACCESS

CABLE within ACCESS does not distinguish between primary and secondary forests and land-use change only accounts for net transitions in land cover type. At the start of the year when land-use change occurs (forest to crops for example), the logged biomass is allocated evenly to three anthropogenic wood product pools. These pools then decay to the atmosphere at exponential decay rates of 1, 10 and 100 years^-1, representing paper, buildings and other long-lived wood products. The leaf and root biomass are reallocated to the metabolic and structural litter pools of the new vegetation type based on the C/N ratios. Wood from tundra and shrubs is allocated to the Coarse woody debris litter pool of the new vegetation type.

1.2 Thinning implementation

The biomass allocation for thinning is much the same as for land-use change above, however, it only occurs for forest vegetation types and leaf and root biomass are allocated to the litter pools of that forest type.

Thinning occurs once a year during the initialisation of CASA. The forest thinning (the removal of biomass from the plant pools) is done in the subroutine casa_reinit_pk in the module casa_um_inout_mod (file casa_um_inout.F90) immediately after land-use change occurs. There is also a subroutine newlitter_thin, located in the landuse_mod module (file casa_landuse.F90), which reallocates the leaf and root biomass to the litter pools.

The thinning ratio applied to the CNP pools uses the convention that a value of 1 means no thinning and 0 means all biomass is removed.

1.3 Procedure

  1. Calculate CNP pools after thinning.
  2. Add the removed wood to the wood_flux variable.
  3. Add the wood harvest from thinning to the 3 wood product pools.
  4. Redistribute the harvested plant mass to litter pools.
    1. Find the difference between the plant biomass pools before and after thinning.
    2. Ignore wood biomass (because it’s already transferred to wood harvest).
    3. Calculate the plant to litter ratio matrix based on C/N.
    4. Transfer biomass to litter pools.

The existing implementation of product pools is then used to calculate the resulting land-use change emissions. That is, the wood product pools respire at decay rates of 1, 10 and 100 years^-1.

Code changes are documented in the CABLE github issue and pull request.

2. Forcing data

The forcing data for thinning ratio are derived from the LUH2 transition variables:

  • primf_harv: Primary forest area harvest fraction
  • secmf_harv: Secondary mature forest area harvest fraction
  • secyf_harv: Secondary young forest area harvest fraction

These variables are added together and remapped to ACCESS resolution using CDO’s second order area conserving remapping. Missing values on land points from the remapping are filled with 0’s. The thinning fraction is converted to CABLE’s convention of 1 being no thinning by multiplying by -1 and adding 1. The thinning fractions are then broadcast to CABLE’s forest vegetation types by multiplying by the land cover fractions.

Scripts used to process the forcing data are here:

The forcing data are stored on gadi here: /g/data/p66/tfl561/thinning/harvest_frac

The forcing data are ingested through the ACCESS’s atmosphere restart files. The restart file stashvar variable that contains the thinning fields for a single year has code 916. ACCESS is typically resubmitted to the queue once a year. For each year, a new map of wood thinning data is injected in the restart dump before the start of the simulation.

At runtime the restart file is loaded and the thinning data is then passed through the UM to CABLE via arguments to subroutine calls as follows.

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_thin
3 Likes

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:
/g/data/p66/jxs599/ESM15-CABLE3/ESM1.5-CABLE3_thinning/submodels/UM/umbase_hg3/src

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

image

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

image

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

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.