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

Diameter classes

Diameter classes were introduced to better simulate the canopy structure. 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-DOFOCO 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

CWRR vs Choinell

Albedo

Background albedo

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

Forest management

Consistency checks

Nitrogen cycle

Recruitment