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, 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

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