ORCHIDEE-CN-CAN

What to expect from this model?

ORCHIDEE-CN-CAN is based on the latest version of the trunk, the latest version of the ORCHIDEE-CN branch and the key functionality of ORCHIDEE-CAN (aka ORCHIDEE-DOFOCO on the svn server). The committed version can be considered a light version of ORCHIDEE because some of the available functionality was not yet commited (for example, the DGVM). Nevertheless, this light version is believed to contain all functionality that affects the parameterization of the model. The functionality that is not yet included depends on vegetation growth, soil hydrology or the energy budget but does not affect these processes at the pixel level.

Known conflicts with the trunk: tot_bare_soil, VIS/NIR snow albedo Missing functionalities compared to the trunk: DGVM, fire disturbances, and net land cover change Missing functionalities compared to ORCHIDEE-CAN (add these and we can close the branch): wind throw, land cover change, and species change Better functionalities than those available in the trunk, ORCHIDEE-CN or ORCHIDEE-CN-CAN: spitfire for fire disturbanmces and gross land cover changes.

Coupling: Trunk has been extensively tested, ORCHIDEE-CN? ORCHIDEE-CAN has been used nudged and zoomed. Several key parameters have changed: albedo, roughness is now dynamic, more landscape heterogeneity when using age classes.

What is the future of the version?

Now that the AR6v0 is becoming stable, a robust well tested verion of ORCHIDEE can soon be committed and tagged. This gives us the opportunity to prepare for the future. The first ambition is to add CN into AR6v0 to obtain AR6v1. In parrallel we will start testing and discussing ORCHIDEE-CN-CAN to make this an acceptable trunk.

How can I contribute to this version?

Given the large number of code changes, there is no guarantee that the current version will run flawless for all set-ups and possible combinations of flags currently being used by ORCHIDEE users and developpers. Use one of the attached run.def as a starting point for your favourite set-up. Report on the outcome of your tests during the ORCHIDEE meetings.

Coupling: a first benchmark but expect many changes to come

How do I run this version?

Add instructions

Some explanations about the (new) parameters

Allocation

ORCHIDEE-CN-CAN uses the allometric allocation as developed in OCN. In ORCHIDEE-CAN the approach was adjusted to work for more than one diameter class. Since it was developed this allocation has been used in ORCHIDEE-CN, ORCHIDEE-CNP and ORCHIDEE-MICT. In those three branches only a single diameter class was used. Except for the way the reserves and labile pools are calculated, the allocation scheme is identical between all aforementioned versions. The model is, however, very sensitive to the way the reserves and labile pools are calculated. The allocation makes use of a labile pool for which the activity is calculated based on the temperature. As such the model addresses the sink/source discussion initiated by Korner.

ORCHIDEE-CN-CAN calculates the number of individuals and uses this as a criterion to initiate a stand replacing disturbance. This approach, guided by the self-thinning relationship, avoids the need for a stand-level turnover time. ORCHIDEE-CN, ORCHIDEE-CNP and ORCHIDEE-MICT still make use of stand-level turnover.

There are no options to revert to the allocation based on resource limitation. All references and parameters for allocation based on resource limitation have been removed from the code.

Diameter classes

Diameter classes were introduced to better simulate the canopy structure, they are a tool to simulate heterogeneity within a single PFT. Given that the canopy is the interface between the land and the atmosphere this feature has effects well beyond forest management. Stand structure was observed to affect albedo, transpiration, photosynthesis, soil temperature, roughness length, and recruitment. Using diameter classes adds very little complexity to setting-up the simulations as well as to the output files. The complexity is mostly within the code.

The computational cost of using diameter classes is negligible and when a reasonable low number of diameter classes is used, the memory cost remains very small as the dimensions of only two variables are increased. The number of diameter classes is the same for all PFTs and is set by the parameter NCIRC. ORCHIDEE-CN, ORCHIDEE-CNP, and ORCHIDEE-MICT are all coded and used for NCIRC = 1. ORCHIDEE-CAN and ORCHIDEE-CN-CAN are coded and tested for NCIRC = 3. Until further testing, three diameter classes are considered sufficient.

Given earlier choices in ORCHIDEE, we either need to define the boundaries of each diameter class or the diameter distribution. While developing the code, we considered the second approach the most flexible. To allow maximal flexibility, each diameter class needs to be defined separately by the variable CIRC_CLASS_DIST_0000X, where X is the number of the diameter class. The smallest number presents the smallest diameter class. From literature it is known that a truncated exponential distribution is a good first guess:

CIRC_CLASS_DIST_00001=9
CIRC_CLASS_DIST_00002=3
CIRC_CLASS_DIST_00003=1 

The above declaration implies that 9/13th of the trees will always be in the smallest diameter class, 3/13th will be in the medium class and 1 tree out of 13 will be in the largest diameter class. These ratios are kept throughout the simulations and the boundaries of the diameter classes are adjusted to respect this constraint. Consequently, an even-aged stand will be simulated with three diameter classes where the diameter of the first class may be, for example, 20.3 cm, the diameter of the second class 20.4 cm and the diameter of the third class 20.5 cm. The same code and set-up allows to simulate, in the same simulation, an uneven-aged stand for the same PFT but in a different pixel with, for example, the smallest diameter 7 cm, the medium diameter 25 cm and the largest diameter 45 cm.

Age classes

Age classes were introduced to better handle heterogeneity at the landscape level. The feature allows us to distinguish between different successional stages of the same PFT. Age classes are independent of the number of diameter classes. Using age classes adds a lot of details in both the biophysics and the biogeochemistry following natural disturbances, forest management and land cover change. If half of a grassland is afforested with a PFT that already exists in the pixel, previous versions of ORCHIDEE will combine this newly forest land and the existing forest in a single PFT. This will result in a low albedo, a high roughness, ... When age classes are used, the newly afforested and the existing forest will end up in separate PFTs. One will have a high albedo, the other a low, ...

Age classes were defined as separate PFTs and if wanted different age classes of the same PFT could be run with different parameters. This option has not been tested yet because it is expected to result in discontinuities when the biomass is moved from one age class to another. The number of age classes is fixed but for each PFT it can be decided whether age classes are used or not. This adds a lot of flexibility to the model. ORCHIDEE-CAN, for example, has been run with 64 PFTs, using age classes for European forest and using no age classes for all forests outside the domain of interest. Setting-up a simulation with age classes will require some thinking when setting-up the run.def. A python-script was written to create this kind of run.def. Increasing the number of PFTs has important consequences for the speed of the model and the memory use. Because a single run can contain PFTs with and PFTs without age classes, processing of the simulation output needs to account for the relationship between PFTs of the same species but a different age class.

The number of age classes is defined by the parameter NAGEC. Setting this parameter to 1 is a good start unless you have a special interest in using age classes. When NAGEC is set to more than 1, PFT_TO_MTC', AGEC_GROUP and PFT_NAME will all need to be carefully defined. See the attached run.def for a functional example. See below for some principles: NAGEC = 4 Assume we want to use four age classes for all forests. We will end-up with 37 PFTs, the 1 for bare soil, C3 grass, C4 grass, C3 crop and C4 crop and 4 times 8 for the 8 forest PFTs. Thus NVM = 37

Because we still use the 13 default MTC we can use the default maps. Let the model know how many MTCs it should find on the maps: NVMAP=13

If you want to use IMPOSE_VEG=y then only vegetation should be added to the youngest age class. ORCHIDEE will update the vegetation fractions during the simulations

SECHIBA_VEG_01=0.0769230769231
SECHIBA_VEG_02=0.0769230769231
SECHIBA_VEG_03=0.0
SECHIBA_VEG_04=0.0
SECHIBA_VEG_05=0.0
...

SECHIBA_VEGMAX_01=0.0769230769231
SECHIBA_VEGMAX_02=0.0769230769231
SECHIBA_VEGMAX_03=0.0
SECHIBA_VEGMAX_04=0.0
SECHIBA_VEGMAX_05=0.0
...

Link PFTs to MTCs

PFT_TO_MTC_01=1
PFT_TO_MTC_02=2
PFT_TO_MTC_03=2
PFT_TO_MTC_04=2
PFT_TO_MTC_05=2
...

Tell ORCHIDEE which PFTs have a successional relationship

AGEC_GROUP_01=1
AGEC_GROUP_02=2
AGEC_GROUP_03=2
AGEC_GROUP_04=2
AGEC_GROUP_05=2
...

Give all PFTs a name for clarity

PFT_NAME__01=Soilbare
PFT_NAME__02=Broadleavedevergreentropical_age01
PFT_NAME__03=Broadleavedevergreentropical_age02
PFT_NAME__04=Broadleavedevergreentropical_age03
PFT_NAME__05=Broadleavedevergreentropical_age04
...

CWRR vs Choinell

Albedo

ORCHIDEE-CN-CAN makes use of a two stream radiative transfer scheme through the canopy. The scheme is based on Pinty et al 2006. This approach accounts not only for the leaf mass but also for the vertical and horizontal distribution of the leaf mass (=canopy structure). In ORCHIDEE-CN-CAN the same scheme is used to simulate the reflected, transmitted and absorbed light. This implies that albedo and photosynthesis are now fully consistent as well as the light reaching the forest floor (the latter is used in for example recruitment). ORCHIDEE-CN-CAN cannot revert to previous approaches for calculating albedo. The radiative transfer through the canopy is controlled by 3 parameters for each wavelength/band: single leaf scattering leaf_ssa_xxx, forward scattering leaf_psd_xxx and background reflectance bgrd_ref_xxx. At present VIS and NIR have been parameterized. Parameterization is based on running an inverse radiation scheme on the MODIS albedo product while accounting for the different land cover types. The inverted parameters are provided by the JRC as the JRC TIP product.

Background albedo

If covered by snow, the background albedo is calculated by the snow module and accounts for snow age and snow density (needs to be checked – last time snow did not account for NIR). If not covered by snow the background albedo is not simulated but prescribed by the parameters bgrd_ref_vis and bgrd_ref_nir. In deciduous forest, grasslands and croplands, the background albedo is known to be strongly affected by the phenology and senescence of the understory vegetation. ORCHIDEE-CN-CAN has two options to prescribe the background albedo:

1 - The background albedo is prescribed per PFT but is constant throughout the year. This is the option that has been used in ORCHIDEE-CAN and is the option that has been validated over Europe.

2 - The background albedo varies with time but is constant across PFTs. This option reads background maps. Given that those maps are based on the JRC TIP product, they should be compatible with the new albedo scheme. This option, however, has not been validated yet.

Single layer vs multi layer energy budget

The are still some issues with the multi-layer energy budget, and it is currently only possible to run for one PFT. Thus, we suggest you use the single layer energy budget. This can, however, be done by two different methods that gives the exact same results:

A: use the energy scheme as found in the original enerbil.f90

B: use the multi-layer energy scheme for a single canopy layer. This collapses the multi-layer energy scheme to the original enerbil code, but if you wish to take hydraulic water stress with feedback on stomatal conductance into account in your simulation, you need to choose this method.

Several flags exist to control these choices. For simplicity, a flag has been made to automatically control several of the flags related to the multi-layering, called multi_layer_control. Multi_layer_control has 4 possibilities

1 – single layer, using the multi layer energy scheme (i.e. choice B above)

2 – multi-layer energy budget

3 – user specific as set in the run.def

4 – single layer, using the original enerbil scheme (i.e. choice A above)

The default setting of multi_layer_control in ORHIDEE-CN-CAN is 1. This is well tested and considered save to use. More details of the flags controlling the multi-layer can be found below and within the model code.

The flags controlled by the multi_layer_control are:

ok_hydrol_arch: Flag that activates the hydraulic architecture routine (true/false). The trunk version of ORCHIDEE (false) uses soil water as a proxy for water stress and applies the stress to Vcmax. When set to true the hydraulic architecture of the vegetation is accounted for to calculate the amount of water that can be transported through the plant given the soil and leaf potential and the conductivities of the roots, wood and leaves. Water supply through the plant is compared against the atmospheric demand for water. If the supply is smaller then the demand, the plant experiences water stress and the stomata will be closed (water stress is now on gs rather than Vcmax). Note that whether stomatal regulation is used or not is controled by a separate flag: ok_gs_feedback. ok_gs_feedback: Flag that activates water stress on stomata (true/false). This flag is for debugging only! It allows developers to calculate GPP without any water stress. If the model is used in production mode and ok_hydrol_arch is true this flag should be true as well.

ok_mleb: Flag that activates the multilayer energy budget (true/false). The model uses 10 (default) canopy layers to calculate the albedo, transmittance, absorbance and GPP. These canopy layers can be combined with 10 (default) layers below and 9 layers above the canopy to calculate the energy budget (ok_mleb=y). If set to no, this flag will make the model use 10 layers for the canopy albedo, transmittance, absorbance and GPP and just a single layer for the energy budget. Be aware that if you wish to run with hydraulic architechture ok_mleb needs to be se to true as well. Furthermore, if you wish to run with the original energy scheme (enerbil), set the layers for mleb to 1.

ok_impose_can_structure: This flag is for debugging only! It allows developers to use a prescribed canopy structure rather then the structure calculate by ORCHIDEE. The flag activates the sections of code which directly link the energy budget scheme to the the size and LAI profile of the canopy for the respective PFT and age class that is calculated in stomate, for the albedo. If set to TRUE and the multi-layer budget is activated the model takes LAI profile information and canopy level heights from the run.def. If set to FALSE, and the multi-layer energy budget is used the profile information and canopy levels heights comes from the PGap-based processes for calculation of stand profile information in stomate.

ok_mleb_history_file: Flag that controls the writing of an output file with the multi-layer energy simulations (true/false). Note that this is a large file and writing slows down the code.

The multi_layer_control set these flags in the following manner:

1 – single layer, using the multi layer energy scheme

       ok_hydrol_arch = .TRUE.;  
       ok_gs_feedback = .TRUE.; 
       ok_mleb = .TRUE.; 
       ok_impose_can_structure = .TRUE.; 
       ok_mleb_history_file = .FALSE.

2 – multi-layer energy budget

       ok_hydrol_arch = .TRUE.; 
       ok_gs_feedback = .TRUE.; 
       ok_mleb = .TRUE.; 
       ok_impose_can_structure = .FALSE.; 
       ok_mleb_history_file = .FALSE.

3 – user specific as set in the run.def

       All read from the run.def

4 – single layer, using the original enerbil scheme

       ok_hydrol_arch = .FALSE.; 
       ok_gs_feedback = .FALSE.; 
       ok_mleb = .FALSE.; 
       ok_impose_can_structure = .FALSE.; 
       ok_mleb_history_file = .FALSE.

Plant water stress

Dynamic SLA

Similar to ORCHIDEE-CN, ORCHIDEE-CN-CAN users can choose to use a constant specific leaf area (SLA) or a dynamic (SLA) by setting the flag dyn_sla. SLA is a fundamental parameter in the allocation scheme and it is well established that SLA is dynamic in nature especially during leaf onset. The current implementation of dynamic SLA is basic and there is room to enhance consistency in the calculations, for example, by recalculation the allocation factors KF and LF as a function of SLA.

Forest management

Consistency checks

The code distinguishes between three options to check for mass balance problems. These options are controlled by the parameter ERR_ACT. Always use ERR_ACT = 3 when developing and testing the code. Note that in addition to checking for mass balance closure ORCHIDEE-CN-CAN will also check for the preservation of veget_max. This is useful to make sure no surface area is lost when moving biomass from one PFT to another following natural disturbances, forest management, land cover changes and when using age classes. In some parts of the code, for example, modules that deal with disturbances, it is assumed that the tallest trees are stored in the last diameter class. When the difference in diameter between diameter classes becomes very small, this assumption could be violated. Therefore, the diameter classes are sorted to enforce the assumed order and where needed the order is checked.

1 - ERR_ACT = 1 is recommended when running global long-term simulations. Under this option, mass balance closure is checked for all biogeochemical processes but only at the highest level thus stomate.f90 and stomate_lpj.f90. Although the mass balance checks are not very expensive in terms of computer time, skipping the numerous lower level checks is expected to save some time. Under this option the mass balance error is only written to the history file. No information is provided in which subroutine the problem occurred.

2 - ERR_ACT = 2 is recommended when developing and testing the model. Now the mass balance is explicitly checked in stomate.f90, stomate_lpj.f90 and all its subroutines. Under this option the mass balance error is written to the history file and if the mass balance is not closed, the warning message will indicate in which subroutine the problem likely originated.

3 - ERR_ACT = 3 is recommended when having a problem with mass balance closure. The mass balance is explicitly checked in stomate.f90, stomate_lpj.f90 and all its subroutines. If a mass balance occurs, the model is stopped.

Nitrogen cycle

ORCHIDEE-CN-CAN strictly follows ORCHIDEE-CN where it concerns the implementation of the N-cycle. Following mass balance problems caused by negative N mineralization and followed by negative immobilization, the code has been slightly adjusted to ensure mass balance closure. The parameter ímpose_cn is used to control the N-cycle calculations. If set to y, C/N ratios are calculated but whenever N appears to be limiting, it is taken from the atmosphere to satisfy this need. This is the preferred setting when testing/developing the code without a proper spin-up. N-limitation will only be accounted for when setting imnpose_cn = n. With this setting the N-cycle is closed (checked when checking for mass balance closure) it will require a spin-up to produce reasonale results.

Recruitment

When stands grow old the tree density decreases and under certain conditions the LAI can no longer cover the ground area. When this happens productivity will start to decrease. In nature the decrease in LAI comes with an increase in the amount of light reaching the forest floor which enables seedlings to grow and to restore the LAI. This process is known as recruitment. Note that in managed forest and forest with a lot of stand replacing disturbances (for example, fire) the forest may never reach the stage where the canopy sufficiently opens up to enable recruitment.

ORCHIDEE-CN-CAN can simulate recruitment for each PFT separatly by setting recruitment_pft_xx to true or false. When using age classes it makes sense to have the same setting for all age classes of the same species. When developing and testing the code it was considered too time consuming to change the settings at the PFT level so a flag ignoring the setting for recruitment_pft_xx was introduced. If the recruitment flag is set to true, the settings of recruitment_pft_xx will be used. If the recruitment flag is set to false, the settings of recruitment_pft_xx will be ignored and the model runs without recruitment.

Recruitment has been developed, tested and validated for tropical forests. There is no reason why it shouldn't work for other forests but that needs to be confirmed. At present recruitment was introduced at the PFT level. It probably makes more sense to link it to the management strategy than to the PFT. This needs to be checked.