1OK: Quality control and quality assurance of the model code¶

1.1DONE: Mass balance checks for carbon and nitrogen¶

An overarching daily mass balance check consists of comparing the pool-based net biome production Chapin et al., 2006 calculated as the changes in carbon and nitrogen in the vegetation, soil, litter and product pools with the flux-based net biome production calculated as the sum of all the carbon and nitrogen fluxes from and to the atmosphere, and between the vegetation, litter, soil, and products. The residual of this check is written to the output files.

For each subroutine related to the calculation of the carbon or nitrogen cycle in ORCHIDEE v4.2, changes in the pools involved in the calculations of that subroutine are compared to the sum of the fluxes involved in that subroutine. If the residual exceeds a threshold, the model is stopped.

1.2OK: Water balance checks¶

An overarching water balance check is run at the same temporal resolution as the calculation of the water pools and fluxes, i.e., sub-daily (section 1.12). Mass changes in the three water reservoirs, i.e., the soil water, the canopy interception, and the snow pack, are compared against the difference between the water sources and sinks. The sources considered are, rain and snow precipitations, water from irrigation returning to soil moisture, fluxes out of floodplains, routed water which comes back into the soil from the bottom, and routed water which comes back into the soil at the top. The sinks considered are surface runoff, drainage, interception loss, transpiration, bare soil evaporation, snow and evaporation, floodplain evaporation. The residuals of this check are written to the output files.

Note that the current approach to calculate the residuals of the water budget does not include the stream, fast and slow routing reservoirs. XXX.

Depending on the model configuration, routing may be calculated on a different grid than the other water pools and fluxes (section 1.8). If this is case, global water conservation is enforced every time the calculations change grids.

1.3DONE: Surface area checks¶

In ORCHIDEE the surface area of each PFT within a grid cell is represented by the share of that PFT within the grid cell. At the start of a simulation, the share of each PFT within each grid cell is read from a vegetation distribution map (section 1.2). When the information from the map is transferred to ORCHIDEE, the residual between the sum of the shares of PFTs and unity is declared as no biological fraction (currently treated as glacier in ORCHIDEE). Therefore, the sum of the vegetation, bare soil and no biological fractions is unity for each grid cell. If the simulation accounts for land cover changes, an annual vegetation map is read for each year of the simulation and the aforementioned check is repeated annually.

Area conservation is also checked at the grid cell for each subroutine in which the surface area of the PFTs may change, e.g, land cover change, disturbances, and age class dynamics. Within these subroutines the sum of shares and the no biological fraction should remain unity.

Due to long term effects of land cover change, disturbances, age class dynamics, or a combination of these processes, the share of a PFT may become too small to justify its computational costs. If that happens, the biomass at the PFT is moved into the harvest pool, and the litter pools, soil pools, and the area share are moved to the PFT with the largest share or the bare soil. Although the bare soil PFT is not initialized with any carbon or nitrogen pools, this process could result in carbon and nitrogen pools and subsequent fluxes from the bare soil in ORCHIDEE v4.2.

1.4DONE: Technical quality control of the code¶

After committing code changes to the versioning server, a series of technical tests are launched automatically during the night. This includes 14 technical tests with a stand-alone configuration of ORCHIDEE as well as 7 technical tests with the coupled land-atmosphere configuration of ORCHIDEE called LMDZOR. These 21 tests in total enable checking whether: (1) the model compiles and runs both in debug and production mode; (2) the exact same results (bit-by-bit) are obtained irrespective of the number of processors used; (3) the exact same results (bit-by-bit) are obtained irrespective of the restart frequency of the model; (4) the exact same results (bit-by-bit) are obtained with the land-atmosphere configuration for runs with different parallelization schemes; (5) the model can run with different climate forcing files; (6) the model can run with both the previous and current driver to read and interpolate the climate forcing files; (7) the model runs with settings that are still under development or testing but that should become the default setting in the future. The full series of tests are run at the most powerful server whereas a subset is run as well at a smaller server. Running the tests at both servers is by itself the 22^nd test.