Opened 9 years ago

Closed 4 years ago

#20 closed defect (fixed)

Problem of closure for the Carbon Budget

Reported by: nvuilsce Owned by: nvuilsce
Priority: major Milestone: ORCHIDEE 2.0
Component: Biogeochemical processes Version: orchidee_1_9_5_2
Keywords: C budget, closure Cc:

Description (last modified by nvuilsce)

When analysing CMIP5 ORCHIDEE outputs, P. Cadule detected a problem in the closure of the Carbon Budget. She highlighted the problem when comparing the difference of C stocks between a certain time and the beginning of the simulation (delta_stock) and the C net flux cumulated over the same time period (cum_flux). Normally, delta_stock and cum_flux should be equal. Figure 1 shows how delta_stock and cum_flux differ for a simulation with no land-use change from 1850 to 2005. After 156 years, the difference equals ~10 Gt C.

Cum_Flux and Delta_Stock trends over timeGlobal distribution of the diff between Cum_Flux and Delta_Stock for all PFT's
Figure 1 Figure 2

Figure 2 shows how the diff between delta_stock and cum_flux after 156 years is spatially distributed. Figure 3, 4 and 5 show the spatial distribution of this difference for tree PFT, grass PFT and crop PFT, respectively. The main PFT contributors globally are the grasslands, but crops and trees PFT don't close the C budget, too. The main regions where cum_flux and delta_stock differ the most are non productive areas such as the Sahelian band or central Australia.

Global distribution of the diff between Cum_Flux and Delta_Stock for tree PFT'sGlobal distribution of the diff between Cum_Flux and Delta_Stock for grass PFT'sGlobal distribution of the diff between Cum_Flux and Delta_Stock for crop PFT's
Figure 3 Figure 4 Figure 5
  • The script that helps to generate the figures is in attachment.

Attachments (8)

figure1.gif (7.1 KB) - added by nvuilsce 9 years ago.
Cum_Flux and Delta_Stock trends over time
figure2.gif (16.8 KB) - added by nvuilsce 9 years ago.
Global distribution of the diff between Cum_Flux and Delta_Stock for all PFT's
figure3.gif (20.7 KB) - added by nvuilsce 9 years ago.
Global distribution of the diff between Cum_Flux and Delta_Stock for tree PFT's
figure4.gif (20.3 KB) - added by nvuilsce 9 years ago.
Global distribution of the diff between Cum_Flux and Delta_Stock for grass PFT's
figure5.gif (16.9 KB) - added by nvuilsce 9 years ago.
Global distribution of the diff between Cum_Flux and Delta_Stock for crop PFT's
closure_C_budget.jnl (6.8 KB) - added by nvuilsce 9 years ago.
script used for generating the figures
figure6.gif (10.5 KB) - added by nvuilsce 9 years ago.
Total biomass for PFT 10
check_biomass.jnl (1.1 KB) - added by nvuilsce 9 years ago.
script used for generating figure 6

Download all attachments as: .zip

Change History (12)

Changed 9 years ago by nvuilsce

Cum_Flux and Delta_Stock trends over time

Changed 9 years ago by nvuilsce

Global distribution of the diff between Cum_Flux and Delta_Stock for all PFT's

Changed 9 years ago by nvuilsce

Global distribution of the diff between Cum_Flux and Delta_Stock for tree PFT's

Changed 9 years ago by nvuilsce

Global distribution of the diff between Cum_Flux and Delta_Stock for grass PFT's

Changed 9 years ago by nvuilsce

Global distribution of the diff between Cum_Flux and Delta_Stock for crop PFT's

Changed 9 years ago by nvuilsce

script used for generating the figures

Changed 9 years ago by nvuilsce

Total biomass for PFT 10

Changed 9 years ago by nvuilsce

script used for generating figure 6

comment:1 Changed 9 years ago by nvuilsce

  • Description modified (diff)
  • Status changed from new to accepted

I looked at the dynamic of the living biomass for a point where delta_stock and cum_flux differ (x=130E,y=-25N, in Australia) for PFT 10 (C3 grass). The total living biomass switches from 0 to a positive value (~20 gC m-2) frequently (~every year or less). See figure 6 (the script file used for generationg figure 6 is also in attchment).
Total biomass for PFT 10
Figure 6

Looking in details to each pool, this is indeed the reserve pool that switches from 0 to a positive value. There is no flux associated to this 'creation' of biomass. For instance, the co2_to_bm (CO2_TAKEN in the output file) variable (that represents CO2 taken from the atmosphere to create, from scratch, biomass, especially when the DGVM is activated, but not only) equals zero in the simulations discussed here.

This bug is due to a block of code in stomate_prescibe where we initialize the biomass pools (reserve pool only for grass and crop PFTs). This initialization is conditioned to (FIRSTCALL eq TRUE) and (TOTAL_BIOMASS le min_stomate). This initialization should happen only once, when we start a simulation from scratch (no restart). In this particular case, we should anyway declare this creation of biomass as C taken from the atmosphere. In the other cases, we should never pass into this block of code. There is still the possibility to restart the growth of a PFT that looses all its biomass, in stomate_phenology if the flag ALWAYS_INIT is activated. In our simulation, we pass several times in this initialization section because we chain the simulations (monthly runs) and because in arid regions, biomass of some PFT decreases down to min_stomate. This block of initialization should not be activated with a test on the Firstcall boolean but with a check on the presence of a restart as it is the case in the readstart subroutine (stomate_io.f90).
Actions needed:

  • To fix the bug. Do we move the initialization into the subroutine readstart (stomate_io.f90) ?
  • To check all the FIRSTCALL sections within stomate, to ensure that there are no other instructions that should be done only when there is no input restart file.

When tracking the bug, other less-critical issues have been identified :

  • When checking for the closure of the C budget, for the stock-based approach, we should account for PROD10 and PROD100, that are the Wood biomass products with a lifespan of 10 and 100 years, respectively. PROD10 and PROD100 are positive when Land-Use change occurs (else they equal 0). We should also account for the blackcarbon pool when the Fire module is activated.
  • There are too numerous output variables within ORCHIDEE and some of them are redundant with others (they just differ by the units or by the output name). We should reduce the number of output variables. Among these variables, some are probably not correctly defined:
    • The maintenance respiration is calculated at the time step of sechiba (half-hour) within the routine 'maint_respiration'. But the maintenance respiration can also be modified (reduced) at a daily time step in order to avoid negative biomass. This is done in the routine npp_calc (section 5.). Some output variables do not account for this correction: maint_resp, npp, nee and NEE.
    • The 'nbp' output variable does not account for the co2_to_bm (=CO2_TAKEN) flux.

comment:2 Changed 9 years ago by nvuilsce

Solution for Fixing the bug

  • We want to do the instructions that re-initialise the biomass and some other variables (leaf_frac, when_growthinit, ...) in the routine prescribe when it is the first call and that no restart file for the stomate component is used. Within the code, there is no flag for checking the use of a restart file. The flag ldrestart_read used in sechiba relates to the first call within intersurf. As it is used, ldrestart_read appears useless and could be - maybe - deleted.
  • I suggest to directly use the variable named stom_restname_in that stores the name of the restart file read in input for the STOMATE component. Currently, stom_restname is defined into intersurf_main (like restname_in, restname_out, stom_restname_out). The declaration of stom_restname_in could be moved into constantes.f90. By that way, stom_restname_in will be visible from stomate_prescribe and check if (stom_restname_in == 'NONE'). In parallel, we add the biomass created from scratch in the routine prescribe to the variable co2_to_bm. Consequently, co2_to_bm is now an argument to the routine prescribe.
  • The code with the suggested modifications is ready for being commited.

comment:3 Changed 9 years ago by nvuilsce

The code has been modified as described above. See commit on the trunk, revision r1055

comment:4 Changed 4 years ago by nvuilsce

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.