Opened 8 weeks ago

#798 new enhancement

Mass balance issues in post-processing of history files

Reported by: Chao Yue Owned by: somebody
Priority: major Milestone: Not scheduled yet
Component: Biogeochemical processes Version: trunc
Keywords: Cc:


The mass balance closure principle dictates that cumulative incoming fluxes over a certain period of time should be equal to cumulative outgoing fluxes plus the change in the carbon pool between the end and starting time of the concerned period.

In the case of wood harvest, the cumulative harvest wood should be equal to the cumulative wood degradation fluxes plus change in wood product pool (ΔC=Ct1-Ct2). This is confirmed by both activating the mass balance error check when performing the simulation (i.e., ERR_ACT in the orchidee.def) and by using daily output variables.

However, slight mismatch could happen when using monthly or files. There are three issues.

(1) within the same, mismatch happens for the same variable of ‘HARVEST_WOOD_c’ between the daily and monthly output files. (figure below). This leads to incomplete closure of mass balance when using monthly The operation for ‘HARVEST_WOOD_c’ in field_def_orchidee.xml is ‘accmulate’, which means that summing over different days for each month is taken care of by XIOS when writing to monthly file, so the error is not caused by post-processing (in contrast to the case where mean value over a month is outputted, then multiplication by the number of days in the month is required). So such an error in monthly file should be ascribed to accuracy in the output process. The output unit for this variable is g C, which has a value on the order of 1014, which could be the reason for accuracy problem in output process. Otherwise, within the code, when mass balance is checked for this variable, it is divided by area (on the order of 1010), which likely explains that it successfully passed the mass balance check in the code.

possible solution: adjust the unit of this variable to Mg C or Tg C?

(2) the second issue causing incomplete mass closure when using monthly involves the intrinsic timestep mismatch in ΔC. Suppose we look at the interval of two months. Suppose the flux is simulated on each day and monthly output files perfectly writes out the monthly value as the cumulative daily value. So we need to sum the flux over these two months. The problem resides in the pool value. The default operation for pool variables are often ‘average’ (e.g., PROD_L_HARVEST_c, TOTAL_M_c), which means monthly value corresponds to the mean value of everyday of the given month. However, to close the mass balance, we need the t1 to be the first day of these two months, t2 as the last day of these two months. We need the beginning and end value of the pool variable at the native time step on which the pool dynamics are simulated. (The same also applies on the flux variable on 30 min step and pool value average over a day).

Possible solution: we will have to output the pool variable for both the start and end of the simulation, at the smallest time step on which it is simulated. For example, we can output the variable value for the last simulation time step for a given output time step. But we will also need some way to output the value for the first time step right before the model simulates, because not all pool variables have zero value at the start of the simulation.

(3) the third issue concerns with the variable ‘fWoodharves’ in stomata_ipcc_history. This variable, even at a daily time step, cannot fully match its counterpart variable in ( FLUX_PROD_X_HARVEST_LCT_c, also at daily time step). Therefore complete mass balance with post-processing cannot be achieved even with daily stomata_ipcc_history. This is rather a common issue for variables when division by ‘area’ variable is involved in the code. The variables used for were actually used for mass balance check in the code, but divided by area. The variables used for stomate_ipcc_hisotry were created in the code only for output purpose, again divided by area. However, such division leads to error in output files.

Possible solution: area is on the order of 1010 if the unit is m2, we can think change the unit to km2, which fits almost all simulation purpose. This makes a 106 difference, which might help to solve the digital error.

Attachments (1)

Wood_harvest.jpg (17.7 KB) - added by luyssaert 8 weeks ago.

Download all attachments as: .zip

Change History (1)

Changed 8 weeks ago by luyssaert

Note: See TracTickets for help on using tickets.