Carbon cycle evaluation - ACCESS and CABLE-POP

Land Surface CABLE
1

A place to document any land carbon cycle evaluation from ACCESS runs or CABLE-POP runs that we want to follow up

Suggestions

  • iLAMB cumulative NBP, comparison with Hoffman data
  • IAV of carbon fluxes (CABLE3 vs ACCESS-ESM1.5)
  • Comparison of wood harvest, turnover times etc. between ACCESS and CABLE-POP
  • Run iLAMB with ACCESS and CABLE-POP output side-by-side
2

I have written a carbon conservation check script for ACCESS-ESM1.5 output.
Carbon conservation is checked (that left hand side=right hand side) for \Delta C_{pool} = NBP where \Delta C_{pool} are year-to-year variations in the carbon ppols, NBP = NEP - R_{wood} and NEP = NPP - R_h.
This was based on one of Tilo’s ncl scripts. That script used tile based output, so it could potentially look at conservation per PFT, but ACCESS-ESM1.5 does not output R_h on tiles/PFTs.

At the moment when I run this, there is an imbalance of about 0.1% of NBP for the PI-02 simulation.

1 Like
3

Hi @tammasloughran, this will be really useful.
I think stash code = 3173 is soil respiration on tiles. It is field number 35 (counting from 0) when I ‘xconv’ one of the monthly output (.pa) files from my ACCESS-ESM1.5 control test runs.

4

Thanks Rachel!
If 3173 is soil respiration, then the umfile_utils/stashvar.py module (which is used by ACCESS_Archiver) is wrong. It says 3173 is:
atm_stashvar[3173] = ["QCF INCR: bdy layer negative", "", "", "", ""]
Looking at the data itself, it looks more like soil respiration than whatever QCF INCR is. I’ve made an issue of github so that hopefully this will be fixed one day.

1 Like
5

I also don’t know what the units are. I’m going to assume that they are kg m-2 s-1 like the other flux variables.

6

Yes. kg C m-2 s-1 (not kg CO2).

7

Some carbon conservation plots from pre-industrial PI-02.

Snapshot of the imbalance for a few years
imbalance_year_0
imbalance_year_01280×960 125 KB
imbalance_year_2
imbalance_year_21280×960 120 KB

Time series of the global sum of the imbalance. (per PFT below)

Cumulative
total_global_carbon_imbalance_all_pfts total_cumulative_global_carbon_imbalance_all_pfts
total_global_carbon_imbalance_per_pft total_cumulative_global_carbon_imbalance_per_pfts

Absolute NBP and ΔcLand for a single grid cell (in Europe).
absolute_gridpoint_(5,110)
imbalance_realative_to_nbp_(5,110)

The relative imbalance is usually only very large when NBP is small.

The imbalance is worse for a historical simulation with land use change. @inh599 , Alison tells me that you may be aware of a bug with land-use change that affects carbon conservation?

8

@tammasloughran - these are from ESM runs? The ‘bug’ that Alison is referring to relates to how POPLUC interrogates LUH2 so would be irrelevant in that case.

It sort of makes sense that the issue will be worse on PFTs with higher magnitude NBP - possibly pointing to this being a simple numerical precision issue.

@Jhan This utility could be really useful - given we’re almost at the point where vanilla CM3+CASA can be run. @tammasloughran A couple of pointers to check

  • you’re using appropriate output - the states used when evaluating Delta C need to be instantaneous values (not monthly means), the fluxes need to be annual averages (with appropriate weighting for length of month if going from monthly output). I think that means extra output is needed over/above CMIP values.
  • labile carbon needs to be included in the balance somehow - I do not know if/where this pool gets output using ESM terms. (Equally I don’t see how that would be a long-term loss)
9

these are from ESM runs?

Yes, this is from ACCESS-ESM1.5.

the states used when evaluating Delta C need to be instantaneous values (not monthly means)

I think the carbon pools are end-of-month values, so I used December of the previous year and December of the current year for ΔC.

the fluxes need to be annual averages

This is surprising to me. I would have thought that the yearly-monthly-mean would not yield and accurate flux over the year, since you lose information when you average. I guessed (perhaps incorrectly) that the NPP and Rh are output as monthly means, therefore I multiplied them by 60x60x24x(days-per-month) and then did the sum over the whole year. I’m not sure if this would give the same answer as taking the weighted average and then multiplying by 365.

labile carbon needs to be included

It’s included :slight_smile:

10

Quick replies:

  • With the assumption that the carbon pools are end-of-month values then this is a/the correct way to evaluate Delta C over each year.
  • Unfortunately when assessing for conservation you have to be really careful when aggregating variables over the year - small errors on the gross fluxes (NPP, Rh) end up looking large on the net (NEP) because of the cancellation. Your approach is how I do it. It would be worth checking the calendar the ESM uses (e.g. leap years? Are these output on as averages over calendar months or 30 day months? Some variants of ACCESS used 360 day years!)

Basically I don’t see any obvious reason why the approach you have is wrong. It maybe worthwhile assessing for conservation on a monthly basis.