Changes between Version 180 and Version 181 of DevelopmentActivities/ORCHIDEE-DOFOCO
- Timestamp:
- 2018-12-03T09:21:34+01:00 (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DevelopmentActivities/ORCHIDEE-DOFOCO
v180 v181 2 2 [[PageOutline]] 3 3 4 ORCHIDEE-CN-CAN is based on the latest version of the trunk, the latest version of the ORCHIDEE-CN branch and some 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 committed (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. 5 6 1 - The available functionality is described in more detail below 7 8 2 - Known conflicts with the trunk: tot_bare_soil, VIS/NIR snow albedo 9 10 3 - Missing functionalities compared to the trunk: DGVM, and fire disturbances 11 12 4 - Missing functionalities compared to ORCHIDEE-CAN (add these and we can close the branch): wind throw and species change 13 14 5 - Better functionalities than those available in the trunk, ORCHIDEE-CN or ORCHIDEE-CN-CAN: spitfire for fire disturbances and gross land cover changes 15 16 6 - Coupling: LMDZ coupled with ORCHIDEE-CAN has been used only with nudging and zoomed over Europe. Given that several key parameters for the coupling have changed: albedo, roughness is now dynamic, more landscape heterogeneity when using age classes, transpiration, … it is expected that lots of testing will be required to come to a satisfying result with LMDzOR-CN-CAN. 17 4 ORCHIDEE-CN-CAN is based on the trunk as it was in 2017, the ORCHIDEE-CN branch in 2016 and some 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 has not yet committed (for example, the DGVM). Nevertheless, this light version is believed to contain all functionality that affects the parameterization of the core 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. 5 * The available functionality is described in more detail below 6 * Known conflicts with the trunk: VIS/NIR snow albedo 7 * Missing functionalities compared to the trunk: DGVM, and fire disturbances 8 * Missing functionalities compared to ORCHIDEE-CN: none 9 * Missing functionalities compared to ORCHIDEE-CAN: none 10 * Better functionalities than those available in the trunk, ORCHIDEE-CN or ORCHIDEE-CN-CAN: spitfire for fire disturbances and gross land cover changes 11 * Coupling: LMDZ coupled with ORCHIDEE-CAN has been used only with nudging and zoomed over Europe. Given that several key parameters for the coupling have changed: albedo, roughness is now dynamic, more landscape heterogeneity when using age classes, transpiration, … it is expected that lots of testing will be required to come to a satisfying result with LMDzOR-CN-CAN. 18 12 19 13 == What is the future of the version? == 20 Now that the AR6v0 is becoming stable, a robust well tested version of ORCHIDEE can soon be committed and tagged. This gives the ORCHIDEE-team the opportunity to prepare for the future by making a series of far reaching changes to the code. The first ambition is to add CN into AR6v0 to obtain AR6v1. In parallel we will start testing and discussing AR6v2 before making this the trunk for both coupled and off-line simulations. The basis of AR6v2 is the current ORCHIDEE trunk (AR6v0) into which CN and CAN functionality is merged. At this stage key functionality from other branches may be merged as well (to be discussed in tandem with the fair use policy). In addition to the recent improvements to the trunk, the new trunk (AR6v2) should have an increased functionality (see below), increased internal consistency (see below, for example albedo and photosynthesis) and some long awaited fixes (for example no longer usingtot_bare_soil).14 Now that the AR6v0 is stable, a robust well tested version of ORCHIDEE has been tagged. This gives the ORCHIDEE-team the opportunity to prepare for the future by making a series of far reaching changes to the code. The first ambition is to add CN into AR6v0 to obtain AR6v1. In parallel we will start testing and discussing AR6v2 before making this the trunk for both coupled and off-line simulations. The basis of AR6v2 is the current ORCHIDEE trunk (AR6v0) into which CN and CAN functionality is merged. At this stage key functionality from other branches may be merged as well (to be discussed in tandem with the fair use policy). In addition to the recent improvements to the trunk, the new trunk (AR6v2) should have an increased functionality (see below), increased internal consistency (see below, for example albedo and photosynthesis) and some long awaited fixes (see below, for example tot_bare_soil). 21 15 22 16 == How can I contribute to this version? == 23 Given the large number of code changes, there is no guarantee that the current version of AR6v2 will run flawless for all set-ups and possible combinations of flags currently being used by ORCHIDEE users and developers. (1) All users and developers are invited to install AR6v2 and set-up their favorite simulation. Use one of the attached run.def as a starting point for your favorite set-up. Report on the outcome of your tests during the ORCHIDEE meetings. (2) All developers are invited to contribute bug fixes, and code for improved functionality to AR6v2. (3) adjust the interface such that AR6v2 can be coupled to the latest version of LMDz and can be used for regional simulations with WRF. 17 Given the large number of code changes, there is no guarantee that the current version of AR6v2 will run flawless for all set-ups and possible combinations of flags currently being used by ORCHIDEE users and developers. 18 * All users and developers are invited to install AR6v2 and set-up their favourite simulation. Use one of the attached run.defs as a starting point for your favourite set-up. Report on the outcome of your tests during the ORCHIDEE meetings. 19 * All developers are invited to contribute bug fixes, and code for improved functionality to AR6v2. 20 * Adjust the interface such that AR6v2 can be coupled to the latest version of LMDz and can be used for regional simulations with WRF. 24 21 25 22 == How do I run this version? == 26 For the moment, the instructions for ORCHIDEE-DOFOCO can be used to download and extract the model (see https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/UserGuide/ORCHIDEEDOFOCOInstall). Use this run.def for a set-up with 13 MTCs and no age classes (as the trunk) or this run.def ([attachment:run_r5006.def]) to make use of 13 MTC and 4 age classes for each forest MTC, thus resulting in 37 PFTs. 27 28 When running the model, the default setting should be XIOS. Thus, compile the model with gmake with_xios. Note that there currently is a bug on obelix when compiling XIOS. It keeps re-compiling, even though no changes has been made to XIOS. To avoid this and reduce compiling time, change the following line in the Makefile from 29 {{{ 30 with_xios : xios ioipsl driver_xios verif 31 }}} 32 to 33 {{{ 34 with_xios : ioipsl driver_xios verif 35 }}} 36 Once the model is compiled, make sure that XIOS=y in orchidee_ol.card. 37 38 Moreover, new output files for ORCHIDEE have been specified within the code. 23 For the moment, the instructions for ORCHIDEE-DOFOCO can be used to download and extract the model (see https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/UserGuide/ORCHIDEEDOFOCOInstall). Use this run.def for a set-up with 13 MTCs and no age classes (as the trunk) [+++ATTACH] or this run.def ([+++ATTACHattachment:run_r5006.def]) to make use of 13 MTC and 4 age classes for each forest MTC, thus resulting in 37 PFTs. 24 When running the model, the default setting should be XIOS. Thus, compile the model with gmake with_xios. Once the model is compiled, make sure that XIOS=y in orchidee_ol.card. Moreover, new output files for ORCHIDEE have been specified within the code. 39 25 40 26 Below is given an example for stomate_history_4dim. … … 79 65 then it is possible because you have not added the needed lines in stomate.card, stomate.driver, sechiba.card, and sechiba.driver. This error arises because the .xml files, when they have been copied to the working directory, cannot have values like "_AUTO_" in them. libIGCM is supposed to replace such values, which exist in the template .xml files in modeles/ORCHIDEE/src_xml/, when it copies files from the run directory to the working directory. If there is something missing in the .driver files, this replacement doesn't happen and XIOS throws the parsing error above. 80 66 67 If the models keeps recompiling XIOS the following may help. To avoid this and reduce compiling time, change the following line in the Makefile from 68 {{{ 69 with_xios : xios ioipsl driver_xios verif 70 }}} 71 to 72 {{{ 73 with_xios : ioipsl driver_xios verif 74 }}} 75 76 81 77 == Functionalities (alphabetical order) == 82 78 === Age classes === … … 85 81 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. 86 82 87 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: 88 NAGEC = 4 89 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 90 91 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: 92 NVMAP=13 93 94 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 83 Note that it doesn’t make sense to use age classes when running site level simulation, or ignoring land cover change. Not using age classes will make post processing of the simulation results considerable easier. 84 85 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: 86 * NAGEC = 4 87 * 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 88 * 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 89 * 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 95 90 {{{ 96 91 SECHIBA_VEG_01=0.0769230769231 … … 100 95 SECHIBA_VEG_05=0.0 101 96 ... 102 103 97 SECHIBA_VEGMAX_01=0.0769230769231 104 98 SECHIBA_VEGMAX_02=0.0769230769231 … … 108 102 ... 109 103 }}} 110 Link PFTs to MTCs104 * Link PFTs to MTCs 111 105 {{{ 112 106 PFT_TO_MTC_01=1 … … 117 111 ... 118 112 }}} 119 120 Tell ORCHIDEE which PFTs have a successional relationship 113 * Tell ORCHIDEE which PFTs have a successional relationship 121 114 {{{ 122 115 AGEC_GROUP_01=1 … … 127 120 ... 128 121 }}} 129 130 Give all PFTs a name for clarity 122 * Give all PFTs a name for clarity 131 123 {{{ 132 124 PFT_NAME__01=Soilbare … … 141 133 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. 142 134 143 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. 135 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. Seasonal variation in the background albedo was observed but small and therefore not accounted for. 136 137 When sow is present in a pixel, all snow is assumed to reach the ground and the background albedo and the snow albedo (calculated as a function of snow age) are weighted according to their cover fractions (see Background albedo). 144 138 145 139 === Allocation === 146 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 Körner.147 148 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-MICTstill make use of stand-level turnover.149 150 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 . Allometric allocation makes use of the following PFT-specific parameters: '''sla''', '''tau_root''', '''tau_leaf''', '''tau_sap''', '''pipe_density''', '''tree_ff''', '''pipe_tune_x''', '''k_latosa_max''', and '''k_latosa_min'''. In addition to this set of parameters that mainly describe the allometric relationships and the longevity of the different tissues, the calculation of the allocation coefficients makes use PFT-specific tissue conductivities, i.e., '''k_sap''', '''k_root''', and '''k_leaf''' (see also plant water stress). As such there is a functional link between C and N-allocation and the hydraulic architecture of a plant. Details on the parameters can be found in the SI of Naudts et al 2015 in GMD or in src_parameters/constantes_mtc.f90.140 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, and ORCHIDEE-CNP. In those 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 Körner. Whereas this approach resulted in an acceptable interannual variability in for example NPP in ORCHIDEE-CAN, adding N seems to have dampen the interannual variability too much. This dampening was observed in ORCHIDEE-CN and ORCHIDEE-CN-CAN. IN ORCHIDEE-CNP this temperature relationship was removed because the interannual variability became unrealistic. 141 142 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, and ORCHIDEE-CNP still make use of stand-level turnover. 143 144 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 (those that were overlloked can be removed). Allometric allocation makes use of the following PFT-specific parameters: '''sla''', '''tau_root''', '''tau_leaf''', '''tau_sap''', '''pipe_density''', '''tree_ff''', '''pipe_tune_x''', '''k_latosa_max''', and '''k_latosa_min'''. In addition to this set of parameters that mainly describe the allometric relationships and the longevity of the different tissues, the calculation of the allocation coefficients makes use PFT-specific tissue conductivities, i.e., '''k_sap''', '''k_root''', and '''k_leaf''' (see also plant water stress). As such there is a functional link between C and N-allocation and the hydraulic architecture of a plant. Details on the parameters can be found in the SI of Naudts et al 2015 in GMD or in src_parameters/constantes_mtc.f90. 151 145 152 146 === Background albedo === 153 147 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: 154 155 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. Set '''alb_bg_modis''' = n. 156 157 2 - The background albedo 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. Set '''alb_bg_modis''' = y. 148 * 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. Set '''alb_bg_modis''' = n. 149 * The background albedo 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. Set '''alb_bg_modis''' = y. 158 150 159 151 === Anthropogenic species change === … … 161 153 162 154 === Bare soil (under development) === 163 The flag '''ok_bare_soil_new''' controls how the bare soil is perceived and calculated. If set to FALSE the total bare soil is still calculated as a function of veget. When a deciduous PFT sheds its leaves, the gaps in the forest will contribute to bare soil fraction in the grid. Although this approach was introduced a long time ago to get acceptable evaporation estimates from forest, the approach also resulted in using the albedo of deserts as the background albedo of forest gaps. The new albedo scheme considers a specific background albedo for each PFT and calculates the albedo of the PFT including the canopy gaps. Moving gaps to the bare soil is no longer needed. So, if '''ok_bare_soil_new'''is set to TRUE, canopy gaps no longer contribute to the bare soil. It needs to be tested what will happen with the evaporation in the single-layer model. The multi-layer energy budget should be able to correctly deal with the gaps in the canopy because the diffusivity will increase when the canopy is becoming sparser. 155 The flag '''ok_bare_soil_new''' controls how the bare soil is perceived and calculated. If set to FALSE the total bare soil is still calculated as a function of veget. When a deciduous PFT sheds its leaves, the gaps in the forest will contribute to bare soil fraction in the grid. Although this approach was introduced a long time ago to get acceptable evaporation estimates from forest, the approach also resulted in using the albedo of deserts as the background albedo of forest gaps. The new albedo scheme (see Albedo and Background albedo) considers a specific background albedo for each PFT and calculates the albedo of the PFT including the canopy gaps. Moving gaps to the bare soil is no longer needed. So, if '''ok_bare_soil_new''' is set to TRUE, canopy gaps no longer contribute to the bare soil. It needs to be tested what will happen with the evaporation in the single-layer model. The multi-layer energy budget should be able to correctly deal with the gaps in the canopy because the diffusivity will increase when the canopy is becoming sparser. 156 157 === Bark beetles (coming soon) === 158 Bark beetle outbreaks. The core of this module has been developed but needs to integrated in ORCHIDEE-CN-CAN. The bark beetle module was developed such that it interacts with the windthrow module. 164 159 165 160 === C13 === 166 161 The concentration of C13 in the leaves can be calculated by setting '''ok_c13''' to y in the run.def. This calculation follows Farquhar's approach and is currently limited to the fractionation in the leaves. 167 162 168 === Coming soon ===169 1. The calculation of wind storm damage can be activated by setting '''ok_windthrow''' to y in the run.def. This module calculated the critical wind speed of a stand taking stand and soil properties into account. If the stand is managed, the damaged trees are salvaged logged. If the stand is unmanaged the damaged trees are left on-site to decompose. The default setting for ok_windthrow is n.170 171 2. Bark beetle outbreaks. The core of this module has been developed but needs to integrated in ORCHIDEE-CN-CAN. The bark beetle module was developed such that it interacts with the windthrow module.172 173 163 === Consistency checks === 174 164 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. 175 176 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. 177 178 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. 179 180 3 - arr_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 error occurs, the model is stopped. 165 * 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 total mass balance error is only written to the history file. No information is provided in which subroutine the problem occurred. 166 * 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. 167 * arr_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 error occurs, the model is stopped. 181 168 182 169 === CWRR vs Choinel === 183 ORCHIDEE-CN-CAN was developed and tested with CWRR. Set '''hydrol_cwrr''' to y. The Choinel code is still available. The hydrological schemes were not touched during the development of ORCHIDEE-CN-CAN.170 ORCHIDEE-CN-CAN was developed and tested with CWRR. The Choinel code is still available but was never used in ORCHIDEE-CN-CAN and can thus be removed. The hydrological schemes were not touched during the development of ORCHIDEE-CN-CAN. The hydraulic architecture in ORCHIDEE-CN-CAN relies on CWRR. 184 171 185 172 === Diameter classes === 186 173 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. 187 174 188 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.175 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, and ORCHIDEE-CNP are coded and used for NCIRC = 1. ORCHIDEE-CAN and ORCHIDEE-CN-CAN are coded and tested for NCIRC = 3 but the model has been run with one diameter class as well +++REDO. Until further testing, three diameter classes are considered sufficient. 189 176 190 177 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: 191 178 {{{ 192 179 CIRC_CLASS_DIST_00001=9 193 CIRC_CLASS_DIST_00002= 3180 CIRC_CLASS_DIST_00002=5 194 181 CIRC_CLASS_DIST_00003=1 195 182 }}} 196 The above declaration implies that 9/1 3th of the trees will always be in the smallest diameter class, 3/13th will be in the medium class and 1 tree out of 13will 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.197 198 === Forest management (change)===183 The above declaration implies that 9/15th of the trees will always be in the smallest diameter class, 5/15th will be in the medium class and 1 tree out of 15 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. 184 185 === Forest management and management changes === 199 186 70% of the global forest are managed invalidating the assumption in previous versions of ORCHIDEE that forests are long-lived natural vegetation. Forest management, inspired by ORCHIDEE-FM was implemented in ORCHIDEE-CAN. Owing to the allometric allocation scheme, the introduction of diameter classes and a canopy structure only the principles, i.e., Deleuze and Dhote and RDI based management were retained. If the forest management strategy is not specified the default value "unmanaged" (FM = 1) is used. This implies that there are no thinning or harvest. Once the stand density drops below the threshold or the tree diameter exceeds another threshold a stand replacing disturbance is applied and a new stand is prescribed in the next time step. Therefore, the biomass pools in ORCHIDEE-CN-CAN no longer depend on a prescribed longevity. 200 187 201 When developing and testing the model, a single forest management strategy can be applied for all pixels and PFTs. ORCHIDEE-CN-CAN distinguishes 4 different strategies: 202 203 1 – FM=1 unmanaged 204 205 2 – FM=2 high stand management: with RDI based thinnings and density/diameter based final harvest 206 207 3 – FM=3 coppice 208 209 4 – FM=4 short rotation coppice with willow or poplar 210 211 Set '''read_fm_map''' to n and specify the desired management strategy (1-4) through '''forest_managed_forced'''. 188 When developing and testing the model, a single forest management strategy can be applied for all pixels and PFTs. Set '''read_fm_map''' to n and specify the desired management strategy (1-4) through '''forest_managed_forced'''. ORCHIDEE-CN-CAN distinguishes 4 different strategies: 189 * FM=1 unmanaged 190 * FM=2 high stand management: with RDI based thinnings and density/diameter based final harvest 191 * FM=3 coppice 192 * FM=4 short rotation coppice with willow or poplar 212 193 213 194 For applications that focus on forestry or require landscape heterogeneity, a PFT-specific management strategy can be read from a spatially explicit map. Thus, the same PFT in different pixels can be assigned a different management strategy. However, within a pixel a single PFT can only have one management strategy. Unless, one wants to run forest management over Europe the user will have to create his/her forest management maps first. Set '''read_fm_map''' to y and specify the location of the forest management map in COMP/stomate.card. Check the existing forest management maps for Europe for an example of how the map should be defined. 214 195 215 When prescribing a forest stand (independent of forest management) the Initial density '''nmaxtrees''', and the range of the initial tree height of the seedlings needs to be specified '''height_init_min''' and '''height_init_max'''. Irrespective of the management strategy the maximum carrying capacity needs to be described. Carrying capacity was formalized through the self-thinning relationship which makes use of two parameters '''alpha_self_thinning''' and '''beta_self_thinning'''. As a fail-safe option the longevity of a stand is still defined but shouldonly be used when all other criteria fail to kill the stand (not observed). Longevity is defined by the parameter '''residence_time'''.216 217 The details of each of the 4 management strategies can be refined through a set of PFT-specific parameters. Note that not every management strategy makes use of all parameters. For more details see the SI of Naudts et al 2015 (last table). The different management strategies require parameter values for : first thinning height '''h_first''', stand replacing density '''ntrees_dia_profit''', harvest diameter '''max_harvest_dia''', c cppice diameter '''coppice_diameter''', rotation length '''src_rot_length''', number of rotations '''src_nrots''', fuelwood diameter '''fuelwood_diameter''' and the minimum and maximum alpha and beta (thus 4 parameters) specifying the RDI range '''alpha_rdi_upper''', '''alpha_rdi_lower''', '''beta_rdi_upper''' and '''beta_rdi_lower'''.196 When prescribing a forest stand (independent of forest management) the Initial density '''nmaxtrees''', and the range of the initial tree height of the seedlings needs to be specified '''height_init_min''' and '''height_init_max'''. Irrespective of the management strategy the maximum carrying capacity needs to be described. Carrying capacity was formalized through the self-thinning relationship which makes use of two parameters '''alpha_self_thinning''' and '''beta_self_thinning'''. As a fail-safe option the longevity of a stand is still defined but will only be used when all other criteria fail to kill the stand (not observed). Longevity is defined by the parameter '''residence_time'''. 197 198 The details of each of the 4 management strategies can be refined through a set of PFT-specific parameters. Note that not every management strategy makes use of all parameters. For more details see the SI of Naudts et al 2015 (last table). The different management strategies require parameter values for : first thinning height '''h_first''', stand replacing density '''ntrees_dia_profit''', harvest diameter '''max_harvest_dia''', coppice diameter '''coppice_diameter''', rotation length '''src_rot_length''', number of rotations '''src_nrots''', fuelwood diameter '''fuelwood_diameter''' and the minimum and maximum alpha and beta (thus 4 parameters) specifying the RDI range '''alpha_rdi_upper''', '''alpha_rdi_lower''', '''beta_rdi_upper''' and '''beta_rdi_lower'''. 218 199 219 200 According to economic theory, high-stand forest are harvested when the actual growth drops below the long-term growth. This has been implemented in ORCHIDEE-CAN and ORCHIDEE-CN-CAN. This feature was found to be very sensitive to the time frame for which actual increment was calculated. This option can be by-passed by setting this period unrealistically high, for example, '''n_pai''' =1000. Persons interested in further testing/developing this feature should set this parameter (unit: years) to 5 or 10. 220 201 221 While developing the code some conflicts were encountered between RDI and self-thinning. As a first solution an additional threshold was introduced '''rdi_limit_upper'''. When debugging progressed this threshold was set to 0.99 (if set to 1.00 there is no correction any more). The initial problem was resolved but the initial fix has not been removed yet. For the time being set rdi_limit_upper to 0.99. 222 223 CHECK: MAX_HARVEST_DIA 202 While developing the code some conflicts were encountered between RDI and self-thinning. As a first solution an additional threshold was introduced '''rdi_limit_upper'''. When debugging progressed this threshold was set to 0.99 (if set to 1.00 there is no correction any more). The initial problem was resolved but the initial fix has not been removed yet. For the time being set rdi_limit_upper to 0.99. Persons interested in simplifying the code could start with this removing this parameter. 224 203 225 204 Following a disturbance (which could be a clear cut), tree species changes and forest management change can be prescribed or read from a map in ORCHIDEE-CAN. Set '''lchange_species''' = y, '''read_species_change_map''' = y, and '''read_desired_fm_map''' = y and specify the paths of those maps in the COMP/stomate.card. This functionality replaces the DGVM in areas where humans rather than nature govern species distribution, for example, Europe. Note that there are some constraints on the possible management changes. If the species is a conifer, for example, the new management strategy cannot be coppicing (fm=3). Anthropogenic species change has not been developed to work together with land cover change (this would require some good bookkeeping for veget_max). Forest management change has not been tested together with land cover change but because they affect different variables, i.e., '''forest_managed''' and '''veget_max''' combining both functionalities seems not overly complex. 226 205 206 === Harvest === 207 All biomass harvest is recorded in a harvest variable +++ADD NAME, this variable also stores the reason of the harvest/mortality. Related variables were introduced to +++ADD NAMES. Wood product pools and fluxes from wood and biomass decomposition are calculated in a separate module dedicated to wood use. The dimension of the wood use pools were externalized and can be changed to better address regional differences when aiming for regional simulations. The default 1, 10 and 100 year pools should be replaced by 2, 17 and 50 years pools in Europe +++CHANGE in model. 208 227 209 === Land cover change (with age classes) === 228 Land cover change now accounts for age classes. It is controlled by the flags '''land_cover_change''' and '''veget_update'''. Set '''land_cover_change''' = n and '''veget_update''' = 0Y if land cover change should be disabled. 229 230 231 === Litter decomposition (needs editing) === 232 After large-scale dieback events (with a closed n-cycle, i.e., impose_cn = n), so much soil mineral N becomes immobilized to decompose litter that too little N is left for plant regrowth. To address this, we implicitly represent the action of fungivores, which eat the decomposing fungi and release N for the plants and increase N turnover rates. We set aside a fraction of qd (stomate_litter.f90) which becomes available for plant uptake in nitrogen_dynamics. This fraction is prescribed by '''fungivores''' and is allocated to '''n_fungivores''' which represents the nitrogen that is released by the fungivores and that is moved into the variable plant_uptake. This parameter is not very well constrained and has been calibrated to find a good compromise between plant regrowth and litter decomposition. The share of the n contained in the decomposing fungi that is released as an excrement from the fungivores should be between 0 and 1 and is set in the run.def: 233 {{{ 234 FUNGIVORES=0.3 235 }}} 236 237 After a die-back (with a closed n-cycle, i.e., impose_cn = n) too little N is available to reach the target C:N ratio of the receiving soil pool, meaning that carbon litter can not decompose. If the C:N ratio is not controlled it spins out of control reaching values of more than 600. The target C:N ratio, which is a variable in stomate_litter.f90, can now vary between 1 and '''max_cn''' where the latter can be set in the run.def. Good results were obtained by setting max_cn to 250. max_cn is bound between 1 and 400, the C:N ratio of wood which is the pool with the highest C:N ratio (and biomass that contributes to the litter). During the simulation the target C:N ratio varies and a couple of decades after the dieback reaches the expected value between 5 and 20. The ecological justification behind a max_cn above the C:N ratio of the fungi is that mycorrhizae receive their C from the plant photosynthesis products. Thus, litter can still decompose even though C is not incorporated into the plant biomass. max_cn can be set in the run.def: 210 Land cover change now accounts for age classes. It is controlled by the flags '''land_cover_change''' and '''veget_update'''. Set '''land_cover_change''' = n and '''veget_update''' = 0Y if land cover change should be disabled. The wood pool and its subsequent fluxes were moved from the land cover change routine to a separate routine. 211 212 === Litter decomposition === 213 After large-scale dieback events (with a closed n-cycle, i.e., impose_cn = n), so much soil mineral N becomes immobilized to decompose litter that too little N is left for plant regrowth. To address this, we implicitly represent the action of fungivores, which eat the decomposing fungi and release N for the plants and increase N turnover rates. We set aside a fraction of qd (stomate_litter.f90) which becomes available for plant uptake in nitrogen_dynamics. This fraction is calculated and is at its maximum when the litter pool is large compared to the biomass pool. The fraction is at its lowest when the living biomass is high compared to the litter biomass. The implemented principle mimics a Lokta-Volta dynamic where the predator are the fungivores and the prey the fungi. The share of the N contained in the decomposing fungi that is released as an excrement from the fungivores ranges between 0 and 1 and is calculated. 214 215 +++STILL NEEDED? SEEMS RELATED TO THE BUG ANNE SOFIE FIXED WHILE WORKING ON THE SPIN-UP. After a die-back (with a closed n-cycle, i.e., impose_cn = n) too little N is available to reach the target C:N ratio of the receiving soil pool, meaning that carbon litter cannot decompose. If the C:N ratio is not controlled it spins out of control reaching values of more than 600. The target C:N ratio, which is a variable in stomate_litter.f90, can now vary between 1 and '''max_cn''' where the latter can be set in the run.def. Good results were obtained by setting max_cn to 250. max_cn is bound between 1 and 400, the C:N ratio of wood which is the pool with the highest C:N ratio (and biomass that contributes to the litter). During the simulation the target C:N ratio varies and a couple of decades after the dieback reaches the expected value between 5 and 20. The ecological justification behind a max_cn above the C:N ratio of the fungi is that mycorrhizae receive their C from the plant photosynthesis products. Thus, litter can still decompose even though C is not incorporated into the plant biomass. max_cn can be set in the run.def: 238 216 {{{ 239 217 MAX_CN = 250 240 218 }}} 241 242 ORCHIDEE-CN allows negative n_mineralisation values to be passed to stomate_soilcarbon where they were treated as immobilization. If we have persistent negative n_mineralisation, however, we can reach a situation where we completely deplete our soil_n_min pools to satisfy the demand for immobilization. The model cannot recover from such a condition. This tends to happen when there is no plant recruitment, in which case a generation of trees will all reach their maximum diameter and die at the same time. This creates an enormous amount of litter, meaning our som_input values become relatively large and when we subtract som_input from n_mineralisation, the values become negative. To remedy this, we'll truncate som_input based on the current mineralisation pool, but we'll also limit the occurrence of negative values. We'll set a minimum '''min_n''' for n_mineralisation so we can keep some N in the soil (and so the simulation can recover). This problem was discovered and fixed before adding the fungivores and max_cn. It should be tested whether this fix is still needed. min_n can be set in the run.def: 219 ++++ 220 221 ORCHIDEE-CN allows negative n_mineralisation values to be passed to stomate_soilcarbon where they are treated as immobilization. If we have persistent negative n_mineralisation, however, we can reach a situation where we completely deplete our soil_n_min pools to satisfy the demand for immobilization. The model cannot recover from such a condition. This tends to happen when there is no plant recruitment, in which case a generation of trees will all reach their maximum diameter and die at the same time. This creates an enormous amount of litter, meaning our som_input values become relatively large and when we subtract som_input from n_mineralisation, the values become negative. To remedy this, we'll truncate som_input based on the current mineralisation pool, but we'll also limit the occurrence of negative values. We'll set a minimum '''min_n''' for n_mineralisation so we can keep some N in the soil (and so the simulation can recover). This problem was discovered and fixed before adding the fungivores and max_cn. It is not clear whether this fix is still needed but it looks like a good problem-catcher. min_n can be set in the run.def: 243 222 {{{ 244 223 MIN_N = .0001 … … 246 225 247 226 === Litter raking === 248 Tree litter was collected from the forest and used in the winter stables instead of straw. In spring the litter and manure was spread on the croplands. This lateral flow of C and N between PFTS in the same pixel can be accounted for in ORCHIDEE-CN-CAN by setting '''use_litter_raking''' = y. If litter raking is to be used, the model will search for annual maps. The path of these maps needs to be specified in COMP/stomate.card. Litter raking maps were prepared for Europe. Unless liter raking is your research topic set '''use_litter_raking''' = n.227 Tree litter was collected from the forest and used in the winter in stables instead of straw. In spring the litter and manure was spread on the croplands. This lateral flow of C and N between PFTS in the same pixel can be accounted for in ORCHIDEE-CN-CAN by setting '''use_litter_raking''' = y. If litter raking is to be used, the model will search for annual maps. The path of these maps needs to be specified in COMP/stomate.card. Litter raking maps were prepared for Europe. Unless liter raking is your research topic set '''use_litter_raking''' = n. 249 228 250 229 === Mortality === 251 ORCHIDEE-CN-CAN distinguished 3 types of natural mortality. The first two options are similar to those in previous version of ORCHIDEE and are set by the flag '''constant_mortality'''. If '''constant_mortality''' = y, the background mortality of a forests is calculated as a constant, prescribed fraction. In ORCHIDEE-CN-CAN, this fraction is given by '''residence_time''' (see also forest management). . If '''constant_mortality''' = y, the background mortality of a forest is a function of its net primary production (npp). If npp decreases, mortality will increase.230 ORCHIDEE-CN-CAN distinguished 3 types of natural mortality. The first two options are similar to those in previous version of ORCHIDEE and are set by the flag '''constant_mortality'''. If '''constant_mortality''' = y, the background mortality of a forests is calculated as a constant, prescribed fraction. In ORCHIDEE-CN-CAN, this fraction is given by '''residence_time''' (see also forest management). If '''constant_mortality''' = n, the background mortality of a forest is a function of its net primary production (npp). If npp decreases, mortality will increase. 252 231 253 232 Both options have been developed, tested and can be used in ORCHIDEE-CN-CAN. However, because of the introduction of self-thinning mortality in ORCHIDEE-CN-CAN, '''constant_mortality''' = y soon became the default setting. In ORCHIDEE-CN-CAN, the total mortality is the maximum of the background mortality and the mortality from self-thinning. Only if self-thinning is absent or too low, background mortality will play a role. This approach implies that when '''constant_mortality''' = y is used in combination with self-thinning, background mortality will only play a role in the first years to decade before self-thinning starts. Despite its limited use, it represents an essential process: owing to background mortality, the number of individuals decreases, the remaining individuals grow faster and thus manage to reach self-thinning in a reasonable amount of time. It needs to be tested how the interplay between background mortality and self-thinning will work out when '''constant_mortality''' = n is used. 254 233 255 234 === Nitrogen cycle === 256 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. First the flag '''stomate_ok_ncycle''' needs to be set to y, to run the model with a N-cycle. Subsequently the parameter '''impose_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 impose_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.257 258 The paths of the '''Nammonium_FILE''', '''Nnitrate_FILE''', '''Nfert_FILE''' and '''Nbnf_FILE''' will need to be set to prescribe the N-inputs from fertilization, biological nitrogen fixation and atmospheric N-deposition.235 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. First the flag '''stomate_ok_ncycle''' needs to be set to y, to run the model with a N-cycle. Subsequently the parameter '''impose_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 impose_cn = n. With this setting the N-cycle is closed (checked when checking for mass balance closure) it requires a spin-up to produce reasonable results. 236 237 The paths of the '''Nammonium_FILE''', '''Nnitrate_FILE''', '''Nfert_FILE''' , '''NManure_FILE''' and '''Nbnf_FILE''' will need to be set to prescribe the N-inputs from fertilization, biological nitrogen fixation and atmospheric N-deposition. 259 238 260 239 === Photosynthesis === 261 Photosynthesis is calculated as in ORCHIDEE-CAN, and ORCHIDEE-CN but the way the levels are defined has changed. The reason of this change is in the albedo and energy budget for which physical layers are required. For this reason the space between the bottom and the top of the canopy is divided into x layers. X is set by the parameter '''nlevels_photo'''. Applications with ORCHIDEE-CAN used nlevels_photo = 10. This values was retained in ORCHIDEE-CN-CAN. Contrary to ORCHIDEE-CN and previous versions of ORCHIDEE where each canopy layer contained 0.5 units of LAI, in ORCHIDEE-CN-CAN, each canopy layer will have the same depth (in m) but will contain a different amount of LAI because tree canopies are assumed spherical.240 Photosynthesis is calculated as in ORCHIDEE-CAN, and ORCHIDEE-CN but the way the canopy levels are defined has changed. The reason of this change is in the albedo and energy budget for which physical layers are required. For this reason the space between the bottom and the top of the canopy is divided into x layers. X is set by the parameter '''nlevels_photo'''. Applications with ORCHIDEE-CAN used nlevels_photo = 10. This values was retained in ORCHIDEE-CN-CAN. Contrary to ORCHIDEE-CN and previous versions of ORCHIDEE where each canopy layer contained 0.5 units of LAI, in ORCHIDEE-CN-CAN, each canopy layer will have the same depth (in m) but will contain a different amount of LAI because tree canopies are assumed spherical. 262 241 263 242 === Plant water stress === 264 243 With ORCHIDEE-CN-CAN there is two option to calculate waters stress. 265 266 1 - Same as in the trunk, where a soil moisture stress functions limits C assimilation through constraints on the carboxylation capacity. 267 268 2 - The second possibility takes hydraulic architecture of plants into account, when calculating the plant water supply. This scheme, based on Hickler et al (2006), calculates the water supply as the ratio of the pressure difference between the soil and leaves. The plant water supply is the amount of water the plant can transport from the soil to the stomate accounting for resistance of water transport in the roots, sapwood and leaves. The resistances are inversely proportional to the conductivities in these different tissues, with the sapwood conductivity decreasing when cavitation occurs. If transpiration rates exceeds plant water supply, stomatal conductance is reduced. 269 270 Moreover, as a further refinement to the hydraulic architecture, a more detailed description of the soil to root resistance has been included (now the default setting) and is activated with the flag '''OK_SOIL_ROOT'''. In the original scheme of the hydraulic architecture a tuning factor was used to calculate the soil to root resistance (PSI_SOIL_TUNE). When '''OK_SOIL_ROOT''' = y, an adjustment of the soil water potential (psi_soilroot) due to soil to root resistance is allowed. Pssi_soil is weighted by the fraction of evapotranspiration supplied by each soil layer, which depends on the soil to root resistance per layer that accounts for different root properties and hydraulic conductivity. 271 272 If you wish to make simulations with the hydraulic architecture the CWRR hydrology scheme needs to be activated ('''HYDROL_CWRR'''=y). Moreover, both '''mleb''' and '''ok_hydrol_arch''' needs to be true. These can be controlled by the overall flag '''multi_layer_control''' (see section on Single layer vs. multi-layer energy budget for more elaboration on these flags). 273 274 The following PFT dependent parameters are needed for the calculations accounting for plant hydraulic architecture; minimal leaf water potential '''PSI_LEAF_xx''', sapwood leaf water potential that causes 50 % loss of xylem '''PSI_50_xx''', additive tuning parameter to account for soil-root interactions '''PSI_SOIL_TUNE_xx''', maximum sapwood conductivity '''K_SAP_xx''', root conductivity '''K_ROOT_xx''', leaf conductivity '''K_LEAF_xx''', specific root lenght '''SRL_xx''', fine root radius '''R_FROOT_xx''', minimum root water potential '''PSI_ROOT_xx'''. 244 * Same as in the trunk, where a soil moisture stress functions limits C assimilation through constraints on the carboxylation capacity. 245 * The second possibility takes hydraulic architecture of plants into account, when calculating the plant water supply. This scheme, based on Hickler et al (2006), calculates the water supply as the ratio of the pressure difference between the soil and leaves. The plant water supply is the amount of water the plant can transport from the soil to the stomate accounting for resistance of water transport in the roots, sapwood and leaves. The resistances are inversely proportional to the conductivities in these different tissues, with the sapwood conductivity decreasing when cavitation occurs. If transpiration rates exceeds plant water supply, stomatal conductance is reduced. 246 247 Moreover, as a further refinement to the hydraulic architecture, a more detailed description of the soil to root resistance has been included (now the default setting) and is activated with the flag '''ok_soil_root'''. This overcomes the need of psi_soil_tune in ORCHIDEE-CN-CAN as needed in ORCIDEE-CAN. When '''ok_soil_root''' = y, an adjustment of the soil water potential (psi_soil_root) due to soil to root resistance is allowed. Psi_soil is weighted by the fraction of evapotranspiration supplied by each soil layer, which depends on the soil to root resistance per layer that accounts for different root properties and hydraulic conductivity. 248 249 If you wish to make simulations with the hydraulic architecture the CWRR hydrology scheme needs to be activated ('''hydrol_cwrr'''=y). Moreover, both '''mleb''' and '''ok_hydrol_arch''' needs to be true. These can be controlled by the overall flag '''multi_layer_control''' (see section on Single layer vs. multi-layer energy budget for more elaboration on these flags). 250 251 The following PFT dependent parameters are needed for the calculations accounting for plant hydraulic architecture; minimal leaf water potential '''psi_leaf''', sapwood leaf water potential that causes 50 % loss of xylem '''psi_50''', maximum sapwood conductivity '''k_sap''', root conductivity '''k_root''', leaf conductivity '''k_leaf''', specific root lenght '''srl''', fine root radius '''r_froot''', minimum root water potential '''psi_root'''. 275 252 276 253 === Prescribe initial vegetation === 277 At the start of the model run or after a die-back or clear-cut new vegetation needs to be planted as ORCHIDEE does not grow vegetation from seeds. The initial dimensions of the vegetation is thus prescribed. Given that the allocation follows allometric relationships, any of the tree dimensions or any mass of any component could have been used to prescribe. The variable height was chosen because it is easy to (mentally) visualize the prescribed vegetation. In the run.def '''HEIGHT_INIT_MIN''' and '''HEIGHT_INIT_MAX''' need to be prescribed. Typical values are 2 to 5 meter. If more than one diameter class is used, '''HEIGHT_INIT_MAX''' needs to larger than '''HEIGHT_INIT_MIN'''. The larger the difference between the min and max, the more vegetation layers the canopy will be composed from.278 279 In addition the initial number of seedlings needs to be prescribed as well. For this the parameter '''NMAXTREES''' needs to be set. '''NMAXTREES''' is a critical parameter to obtain acceptable model behavior. If it is too high, lai saturates but the stand-level GPP will be distributed over too many individuals, each individual will grow very little and so it will take very long before self-thinning is reached. If it is set too low, LAI will be too low resulting in a too low GPP and thus very slow growth. A good starting values is a bit below self-thinning. That way the vegetation starts growing, individual are killed thanks to the background mortality and within 10 to 20 years self-thinning is reached. Why not starting at self-thinning? During code development it was tried to have the model start at the exact number of trees at which self-thinning will start given the diameter of the tree. One issues was that when prescribing small individuals (2-3 m) the calculated number of trees could in the millions and so the GPP had to be distributed over too many individuals.280 281 The way the initial vegetation is prescribed can also be used to prescribe a mature vegetation right at the start of the simulation. One could set ''' HEIGHT_INIT_MIN''' and '''HEIGHT_INIT_MAX''' to for example 15 and 20. If '''NMAXTREES''' is not adjusted, massive self-thinning will take place on the first day. It is better to set '''NMAXTREES''' to a value just below the exact self-thinning value. Prescribing mature vegetation has been tested and works but it is very sensitive. If the combination of '''NMAXTREES''', '''HEIGHT_INIT_MIN''' and '''HEIGHT_INIT_MAX''' is far from realistic the model may crash (the change in KF following the change in gap probability could result in problems in allocation) and N-feedbacks will become apparent in for example the leaf mass (likely because when mature vegetation is prescribed at the start of a run, there is not enough soil N to maintain a mature vegetation).254 At the start of the model run or after a die-back or clear-cut new vegetation needs to be planted as ORCHIDEE does not grow vegetation from seeds. The initial dimensions of the vegetation is thus prescribed. Given that the allocation follows allometric relationships, any of the tree dimensions or any mass of any component could have been used to prescribe. The variable height was chosen because it is easy to (mentally) visualize the prescribed vegetation. In the run.def '''height_init_min''' and '''height_init_max''' need to be prescribed. Typical values are 2 to 5 meter. If more than one diameter class is used, '''height_init_max ''' needs to larger than '''height_init_min'''. The larger the difference between the min and max, the more vegetation layers the canopy will be composed from. 255 256 In addition, the initial number of seedlings needs to be prescribed as well. For this the parameter '''nmaxtrees''' needs to be set. '''nmaxtrees''' is a critical parameter to obtain acceptable model behaviour. If it is too high, lai saturates but the stand-level GPP will be distributed over too many individuals, each individual will grow very little and so it will take very long before self-thinning is reached. If it is set too low, LAI will be too low resulting in a too low GPP and thus very slow growth. A good starting values is a bit below self-thinning. That way the vegetation starts growing, individual are killed thanks to the background mortality and within 10 to 20 years self-thinning is reached. Why not starting at self-thinning? During code development it was tried to have the model start at the exact number of trees at which self-thinning will start given the diameter of the tree. One issues was that when prescribing small individuals (2-3 m) the calculated number of trees could in the millions and so the GPP had to be distributed over too many individuals. 257 258 The way the initial vegetation is prescribed can also be used to prescribe a mature vegetation right at the start of the simulation. One could set '''height_init_min''' and '''height_init_max''' to for example 15 and 20. If '''nmaxtrees''' is not adjusted, massive self-thinning will take place on the first day. It is better to set '''nmaxtrees''' to a value just below the exact self-thinning value. Prescribing mature vegetation has been tested and works but it is very sensitive. If the combination of '''nmaxtrees''', '''height_init_min''' and '''height_init_max''' are far from realistic, the model may crash (the change in KF following the change in gap probability could result in problems in allocation) and N-feedbacks will become apparent in for example the leaf mass (likely because when mature vegetation is prescribed at the start of a run, there is not enough soil N to maintain a mature vegetation). Although this was a convenient feature in ORCHIDEE-CAN, it lost much of it power after merging it into ORCHIDEE-CN-CAN. 282 259 283 260 === Recruitment === 284 261 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. 285 262 286 ORCHIDEE-CN-CAN can simulate recruitment for each PFT separat ly 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 '''ok_recruitment''' flag is set to true, the settings of recruitment_pft_xx will be used. If the '''ok_recruitment''' flag is set to false, the settings of recruitment_pft_xxwill be ignored and the model runs without recruitment.287 288 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.263 ORCHIDEE-CN-CAN can simulate recruitment for each PFT separately by setting '''recruitment_pft''' 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 was introduced. If the '''ok_recruitment''' flag is set to true, the settings of recruitment_pft will be used. If the '''ok_recruitment''' flag is set to false, the settings of recruitment_pft will be ignored and the model runs without recruitment. 264 265 Recruitment has been developed, tested and validated for tropical forests. There is no reason why it shouldn't work for other forests. Initial test for temperate regions show that it works there as well. Also forest productivity at higher ages seems relatively sensitive to recruitment. 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. 289 266 290 267 === River routing === … … 292 269 293 270 === Soil maps === 294 ORCHIDEE-CN-CAN runs for two soil maps: zobler (3 soil types) and usda (12 soil types). The usda map will become the default setting in the near future. The code had to be adjusted in sechiba_hydrol_architect.f90 and stomate_windthrow.f90. The soil map can be selected in the run.def by setting the value for '''soiltype_classif''':271 ORCHIDEE-CN-CAN runs for two soil maps: zobler (3 soil types) and usda (12 soil types). The usda map will become the default setting. The code had to be adjusted in sechiba_hydrol_architect.f90 and stomate_windthrow.f90. The soil map can be selected in the run.def by setting the value for '''soiltype_classif''': 295 272 {{{ 296 273 SOILTYPE_CLASSIF= usda … … 303 280 === Single layer vs multi layer energy budget === 304 281 There 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: 305 306 A: use the energy scheme as found in the original enerbil.f90 307 308 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. 282 A - Use the energy scheme as found in the original enerbil.f90 283 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. 309 284 310 285 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 311 312 1 – single layer, using the multi layer energy scheme (i.e. choice B above) 313 314 2 – multi-layer energy budget 315 316 3 – user specific as set in the run.def 317 318 4 – single layer, using the original enerbil scheme (i.e. choice A above) 319 320 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. 321 322 The flags controlled by the multi_layer_control are: 323 324 '''ok_hydrol_arch:''' 325 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. 326 ''' 327 ok_gs_feedback:''' 328 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. 329 330 '''ok_mleb:''' 331 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. 332 333 '''ok_impose_can_structure:''' 334 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. 335 336 '''ok_mleb_history_file:''' 337 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. 286 * Single layer, using the multi layer energy scheme (i.e. choice B above) 287 * Multi-layer energy budget 288 * User specific as set in the run.def 289 * Single layer, using the original enerbil scheme (i.e. choice A above) 290 291 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: 292 * '''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. 293 * '''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. 294 * '''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. 295 * '''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. 296 * '''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. 338 297 339 298 The multi_layer_control set these flags in the following manner: 340 341 1 – single layer, using the multi layer energy scheme 299 * single layer, using the multi layer energy scheme 342 300 {{{ 343 301 ok_hydrol_arch = .TRUE.; … … 347 305 ok_mleb_history_file = .FALSE. 348 306 }}} 349 2 –multi-layer energy budget307 * multi-layer energy budget 350 308 {{{ 351 309 ok_hydrol_arch = .TRUE.; … … 355 313 ok_mleb_history_file = .FALSE. 356 314 }}} 357 3 –user specific as set in the run.def315 * user specific as set in the run.def 358 316 {{{ 359 317 All read from the run.def 360 318 }}} 361 4 –single layer, using the original enerbil scheme319 * single layer, using the original enerbil scheme 362 320 {{{ 363 321 ok_hydrol_arch = .FALSE.; … … 368 326 }}} 369 327 370 371 328 === Specific leaf area === 372 329 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. … … 380 337 SOM_INIT_SURFACE = 1000 381 338 }}} 382 The initial values of carbon for the four SOM pools are used globally. Sensitivity test have shown that the analytic spin-up is not sensitive to the actual size of the initial values. The different system will after a while settle in to there own state (N limited or saturated) in spite of having the same initial state.339 The initial values of carbon for the four SOM pools are used globally. Sensitivity test have shown that the analytic spin-up is not sensitive to the actual size of the initial values. The different systems will after a while settle into their own states (N limited or saturated) in spite of having the same initial state. Convergence appears to be faster if initial values are set. 383 340 384 341 === Start and restart (under development)=== 385 386 342 The table below shows typical configurations to start and restart ORCHIDEE-CN-CAN 387 343 || '''Sechiba''' || || || || '''stomate''' || || || … … 399 355 400 356 The code allows for many more combinations than described above. Some of those configuration could be useful in specific cases but be aware of the following: 401 * if the restart file for sechiba does not come from the same simulation/year as the restart file for stomate, the values for the variables that are stored in both sechiba and stomate will be overwritten by the values stored in the stomate restart file because that file is read later in the initialization phase. Some variables are duplicated because that adds the flexibility to the configuration that can be used to restart the model.357 * If the restart file for sechiba does not come from the same simulation/year as the restart file for stomate, the values for the variables that are stored in both sechiba and stomate will be overwritten by the values stored in the stomate restart file because that file is read later in the initialization phase. Some variables are duplicated because that adds the flexibility to the configuration that can be used to restart the model. 402 358 * When '''read_lai''' is true, '''ok_stomate''' should be false. It may work but it is flawed from a conceptual point of view. read_lai was developed for cases where the model cannot simulate its own canopy. ok_stomate was developed so the model would simulate its own canopy. 403 359 * Combining a sechiba restart from with '''impveg''', '''impsoil''' or '''laimap''' may result in values from the restart file being overwritten because impveg, impsoil and laimap are checked after reading the sechiba restart file. … … 407 363 ORCHIDEE-CN-CAN strengthen the links between sechiba and stomate. As in previous versions, stomate makes use of variables calculated in sechiba but in ORCHIDEE-CAN and ORCHIDEE-CN-CAN, sechiba requires information from stomate to work properly. It is possible to prescribe the canopy structure and thus only run sechiba. Set '''lai_map''' = y, the data for a canopy structure map need to come from an ORCHIDEE-CN-CAN run with stomate. All the required information is stored in the sechiba restart file to enable restarting the model without stomate. 408 364 365 === Wind throw === 366 The calculation of wind storm damage can be activated by setting '''ok_windthrow''' to y in the run.def. This module calculated the critical wind speed of a stand taking stand and soil properties into account. If the stand is managed, the damaged trees are salvaged logged. If the stand is unmanaged the damaged trees are left on-site to decompose. The default setting for ok_windthrow is n. The damaged fractions of the stands are moved to the first age class (if more than 1 age class is used). 367 368 409 369 == Parameterization and Evaluation == 410 411 370 === Workflow === 412 The following outlines the strategy for parameterizing and evaluating the performance of ORCHIDEE-CN-CAN in simulating several key forest ecosystem processes including tree growth dynamics, energy exchange, C-N cycling and plant hydrology. 413 414 The work will likely require several iteration containing all or just a coupled of the following: 1) running the model, 2) tuning key parameters, 3) re-running the model 4) spin-up and 5) evaluating to model, to discern parameter values that allow us to reproduce as closely as possible the global patterns and trends for several key processes. The tests will move across scales starting at pixel scale moving to longitudinal band, European scale and ending at global scale. Although the longitudinal bands are of little use in the evaluation itself they can be considered pre-tests before global tests are run. It is hoped that longitudinal bands would speed up the tests and reduce the computational cost. 415 416 ''CLARIFICATION: Is the reduction of computational cost due to the longitudinal tests finding bugs that would otherwise only appear in global runs?'' 371 The following outlines the strategy for parameterizing and evaluating the performance of ORCHIDEE-CN-CAN in simulating several key forest ecosystem processes including tree growth dynamics, energy exchange, C-N cycling and plant hydrology. The work will likely require several iteration containing all or just a coupled of the following: 372 * running the model; 373 * tuning key parameters; 374 * re-running the model; 375 * spin-up and; 376 * evaluating to model, to discern parameter values that allow us to reproduce as closely as possible the global patterns and trends for several key processes. 377 378 The tests will move across scales starting at pixel scale moving to longitudinal band, European scale and ending at global scale. Although the longitudinal bands are of little use in the evaluation itself they can be considered pre-tests before global tests are run. It is hoped that longitudinal bands would speed up the tests and reduce the computational cost because they could show the incapability of the model to simulate major spatial gradients at a much lower cost compared to global runs. 417 379 418 380 Table 1. Workflow of the parameterization and evaluation of ORCHIDEE-CN-CAN. 419 381 || '''Phase''' || '''Work to be done''' || 420 382 || Prepare and check || Check whether the model runs, the key functionality, and the spin-up are bug free (Table 2). Check whether the scripts, tools and data are available and still working (Table 3). || 421 || Initial evaluation || Run longitudinal spin-up and check order of magnitude in soil carbon pools. Use the same runs to check response gradients to temperature, N-deposition, precipitation and management ( §5.4). ||383 || Initial evaluation || Run longitudinal spin-up and check order of magnitude in soil carbon pools. Use the same runs to check response gradients to temperature, N-deposition, precipitation and management (see Settings for spin-up). || 422 384 || Parameterization || Use FLUXNET and some additional data sources to parameterize the model at the site level (Table 4). || 423 385 || Final evaluation || Run a spin-up + transient simulation over Europe compare the simulation against the spatially explicit data (Table 5). || 424 386 425 426 387 === Apparent bug-free === 427 388 Before starting the work proposed in Table 1 it needs to be confirmed that the model is technically capable of the tasks presented in Table 2. 428 389 429 ''QUESTION: Are we aiming for 500-1000 years with full debug flags on both obelix and irene to increase our confidence? That might be too expensive even at 2 degree resolution for a global run, but we could check.''430 431 390 Table 2. Essential technical capabilities before evaluating ORCHIDEE-CN-CAN. 432 391 || '''Description of the task''' || '''Status''' || 433 || Is the model stable? Can it be run for 500 - 1000 years ? Can it be run for all PFTs? || Recent problems with grasslands ||434 || Is the N-cycle working? Can we run simulations with IMPOSE_CN=n and IMPOSE_CN=y? 392 || Is the model stable? Can it be run for 500 - 1000 years over a few individual pixels? Can it be run for all PFTs? || Recent problems with grasslands || 393 || Is the N-cycle working? Can we run simulations with IMPOSE_CN=n and IMPOSE_CN=y? || OK || 435 394 || Is land cover change working? Can we run simulations with (changing) land cover maps (impose_veg=no)? || OK || 436 395 || Is forest management working? Can we read forest management maps, are the temporal trends in biomass what is expected for unmanaged, high-stand and coppice management? || Still need to run idealized set-ups || … … 438 397 || Does the model run in parallel? || OK || 439 398 || Is the analytical spin-up working? || OK || 440 || Do we have all the driver maps for the years 1600 to 2000 for European simulations? Climate, land cover change, forest management, litter raking, and N-deposition? || 399 || Do we have all the driver maps for the years 1600 to 2000 for European simulations? Climate, land cover change, forest management, litter raking, and N-deposition? || OK || 441 400 || Do we have all the driver maps for the years 1600 to 2000 for global simulations? || Still need litter raking and FM || 442 || Read N-deposition maps through COMP || In progress || 443 401 || Read N-deposition maps through COMP || In progress || 444 402 445 403 === Data availability === 446 Observational data products for model-data comparison can be found at: /home/satellites5/maignan/ORCHIDEE/EVALUATION. 447 *Phenology448 GIMMS (LAI and FPAR3g)449 *Forest structure450 ◦Remote sensing products of biomass (temperate and boreal maps, i.e., Turner)451 ◦Biomass of EU forest from JRC (Europe)452 ◦Global 1-degree Maps of Forest Area, Carbon Stocks, and Biomass, 1950-2010 (ORNL DAAC)453 ◦Avitabile product (Global forest biomass)454 ◦Forest basal area (Europe)455 ◦Canopy height (Global)456 *NPP457 ◦Site-level NPP database Luyssaert et al 2007458 *NEP459 ◦FLUXNET site-level data460 *TER461 ◦FLUXNET site-level data462 *GPP463 ◦FLUXNET site-level data464 ◦EC-based upscaled GPP, i.e., Jung465 *NPP/GPP466 ◦site-level data and regional patterns, i.e., Campioli et al 2015467 *Soil hydrology468 ◦ESA CCI ECV469 ◦measurements from Brazil (ABRACOS product)470 ◦River discharge records from selected gauges (Global coverage)471 *Albedo472 ◦MODIS or GlobAlbedo for albedo473 *Energy (sensible and latent heat)474 ◦GLEAM for evapotranspiration475 ◦EC-based upscaled evapotranspiration, i.e., Jung476 *Tree ring width (not on /home/satellites5/)477 ◦ITRDB478 *LCC479 ◦Luyssaert et al 2014 – FLUXNET changes in Rn, LE, H, G, albedo480 ◦Duveiller et al 2018 – Remote sensing changes in Rn, LE, H+G, albedo481 *NFI482 ◦France, Spain, Germany and Sweden (/home/satellites5/)483 ◦EU-wide data through the VERIFY project?484 485 There are several data tools (ATLAS, Mapper and Jerome’s) to help compare model outputs with observation, which we might be able to use. If we will not be using the available tools for comparison, we need to pre process the observational data products to produce global means, time series, decadal averages of spatial patterns etc. The analyses presented in Naudts et al 2015 are a good starting point for the evaluation of ORCHIDEE-CN-CAN. The following scripts are available and have been tested and re-activated404 Observational data products for model-data comparison can be found at: /home/satellites5/maignan/ORCHIDEE/EVALUATION.[[BR]] 405 1 - Phenology 406 * GIMMS (LAI and FPAR3g) 407 2 - Forest structure 408 * Remote sensing products of biomass (temperate and boreal maps, i.e., Turner) 409 * Biomass of EU forest from JRC (Europe) 410 * Global 1-degree Maps of Forest Area, Carbon Stocks, and Biomass, 1950-2010 (ORNL DAAC) 411 * Avitabile product (Global forest biomass) 412 * Forest basal area (Europe) 413 * Canopy height (Global) 414 3 - NPP 415 * Site-level NPP database Luyssaert et al 2007 416 4 - NEP 417 * FLUXNET site-level data 418 5 - TER 419 * FLUXNET site-level data 420 6 - GPP 421 * FLUXNET site-level data 422 * EC-based upscaled GPP, i.e., Jung 423 7 - NPP/GPP 424 * site-level data and regional patterns, i.e., Campioli et al 2015 425 8 - Soil hydrology 426 * ESA CCI ECV 427 * measurements from Brazil (ABRACOS product) 428 * River discharge records from selected gauges (Global coverage) 429 9 - Albedo 430 * MODIS or GlobAlbedo for albedo 431 10 - Energy (sensible and latent heat) 432 * GLEAM for evapotranspiration 433 * EC-based upscaled evapotranspiration, i.e., Jung 434 11 - Tree ring width (not on /home/satellites5/) 435 * ITRDB 436 12 – LCC 437 * Luyssaert et al 2014 – FLUXNET changes in Rn, LE, H, G, albedo 438 * Duveiller et al 2018 – Remote sensing changes in Rn, LE, H+G, albedo 439 13 – NFI 440 * France, Spain, Germany and Sweden (/home/satellites5/) 441 * EU-wide data through the VERIFY project? 442 443 There are several data tools (ATLAS, Mapper and Jerome’s) to help compare model outputs with observation, which we might be able to use. If we will not be using the available tools for comparison, we need to pre-process the observational data products to produce global means, time series, decadal averages of spatial patterns etc. The analyses presented in Naudts et al 2015 are a good starting point for the evaluation of ORCHIDEE-CN-CAN. The following scripts are available and have been tested and re-activated 486 444 487 445 Table 3. Model evaluations scripts available per November 2018 488 || '''Description''' || '''Status''' || 446 || '''Description''' || '''Status''' || '''Path''' || 489 447 || Extract species-level productivity from French NFI data and compare against simulated productivity – looking to replace the French data by EU-wide data through the VERIFY project || OK || dofoco/dofoco/SCRIPTS/XXX || 490 448 || Extract Jung GPP and compare against spatially explicit simulations for 8 regions in Europe || OK || dofoco/dofoco/ SCRIPTS/XXX || 491 449 || Extract Jung evapotranspiration and compare against spatially explicit simulations for 8 regions in Europe || OK || dofoco/dofoco/ SCRIPTS/XXX || 492 450 || Extract MODIS albedo (NIR & VIS) and compare against spatially explicit simulations for 8 regions in Europe || In progress || dofoco/dofoco/ SCRIPTS/XXX || 493 || Extract height and compare against spatially explicit simulations for 8 regions in Europe || 451 || Extract height and compare against spatially explicit simulations for 8 regions in Europe || OK || dofoco/dofoco/SCRIPTS/XXX || 494 452 || Extract effective LAI and compare against spatially explicit simulations for 8 regions in Europe || OK || dofoco/dofoco/ SCRIPTS/XXX || 495 453 || Extract BA and compare against spatially explicit simulations for 8 regions in Europe || OK || dofoco/dofoco/ SCRIPTS/XXX || … … 500 458 * Start from a spin-up 501 459 * impose_cn = no (i.e., accounting for N-deposition ) 460 * impose_veg = yes (i.e., prescribe the vegetation) 461 * impose_soilt = yes (i.e., prescribe the soil) 502 462 * Forest management = 2 (i.e., accounting for a thin and fell type of forest management) 503 504 ''QUESTION: Do we consider litter raking on site level? Do we consider litter raking for FLUXNET evaluations?'' 463 * litter raking = no 505 464 506 465 European simulations will have the following configuration: … … 508 467 * impose_cn = no (i.e., accounting for N-deposition ) 509 468 * impose_veg = no (i.e., accounting for PFT distribution) 469 * impose_soilt = no (i.e., use soil map) 510 470 * Forest management from map 471 * litter raking = no (except for the transient simulations to construct the control) 511 472 512 473 The following parameterization approach – making use of parameters that were already shown to be sensitive to tuning – is proposed: … … 529 490 || Tree ring width || Self-thinning, recruitment || ITRDB or VERIFY Fig 4 || 530 491 531 532 492 ==== Settings for the FLUXNET comparison ==== 533 The parameterization starts with several 1-pixel test cases coinciding with long-term flux-net sites to test whether the model captures the growth dynamics such as phenology, max LAI, GPP, etc. These tests require a spin-up. The 1-pixel test cases will allow for both parameter tuning and changes in the code to improve the model behavior. The majority of the data represent mature forests, hence, the modelled forests should be mature as well. The model will be run for 80 years, before any output will be compared to the FLUXNET measurements. An iterative process is be planned: 534 535 • 80 years to reach mature forest → parameterize 536 • Re-run the 80 years to reach mature forest with the new parameters → parameterize 537 • Re-run spin-up and 80 year simulation to reach mature forest with the new parameters → parameterize 538 • Continue until satisfied 493 The parameterization starts with several 1-pixel test cases coinciding with long-term flux-net sites to test whether the model captures the growth dynamics such as phenology, max LAI, GPP, etc. These tests require a spin-up. The 1-pixel test cases will allow for both parameter tuning and changes in the code to improve the model behaviour. The majority of the data represent mature forests, hence, the modelled forests should be mature as well. The model will be run for 80 years, before any output will be compared to the FLUXNET measurements. An iterative process is be planned: 494 * 80 years to reach mature forest → parameterize 495 * Re-run the 80 years to reach mature forest with the new parameters → parameterize 496 * Re-run spin-up and 80 year simulation to reach mature forest with the new parameters → parameterize 497 * Continue until satisfied 498 499 The current scripts for FLUXNET evaluation are broken down into three parts. 1) An initial looping over the driver file (1-10 years, depending on the file), 2) 500 years of spinup (regardless of the length of driver file), 3) one final loop over the driver file, for production. Tests for the grassland and cropland sites can easily use the existing setup. Given the temporal evolution of forest structure and their fluxes, testing now needs 80 years from planting after spinup as a production run over the forcing file to avoid trees dying and biasing our results. The FLUXNET script will need to be adjusted to do this. Possible issues with age classes (i.e., changes in the PFT of interest) will be avoided by using a run.def without age classes. 539 500 540 501 Only if we experience too many difficulties with manual tuning (if there are too many non-linearities in the model), we will use the multi-site optimization tool developed by Vlad . When the simulated growth dynamics are satisfying, 140 years long tests will be performed to check cumulative variables such as basal area, tree height, tree diameter, stand density, standing biomass, and harvest. To evaluate net ecosystem exchange of carbon and soil carbon and nitrogen pools a spin-up is required. Note that the spin-up depends on the parameters used in ORCHIDEE and that the sensitivity of parameters in ORCHIDEE depends on the spin-up. There is no easy way to break this dependency. We should avoid to ‘over-tune’ the 1-pixel FLUXNET comparisons. Instead, we will continue evaluating the model over longitudinal bands. 541 542 ''DISCUSSION POINT: The current scripts for FLUXNET evaluation are broken down into three parts. 1) An initial looping over the driver file (1-10 years, depending on the file), 2) 500 years of spinup (regardless of the length of driver file), 3) one final loop over the driver file, for production. I like how the process is described above, and agree that makes a lot of sense for forests. In particular, I think we need 80 years from planting after spinup plus a production run over the forcing file to avoid trees dying and biasing our results. It's not clear how much time it will take to coax the scripts to do this. I think the grassland and cropland sites can easily use the existing setup. We also may have an issue with age classes, as that changes the PFT of interest (but should be straightforward to fix).''543 544 502 545 503 ==== Settings for longitudinal bands ==== … … 558 516 559 517 The European control should be run from the year 1601 to 2015 includes: 560 561 • A spin-up as initial condition to make a European 1° x 1° CONTROL simulation 562 • 64 PFTs (some with 4 age classes) 563 • With forest management 564 • Litter raking 565 • Increasing atmospheric CO2 concentrations read from file 566 • LCC 567 • CRU-NCEP meteorological forcing, cyclic meteorology (1901-1920) until 1900, then use the corresponding year 568 • A dynamic N-cycle (impose_cn=n) 569 • N-deposition, we have N-deposition files from approximately 1860 until present. 570 571 ''DISCUSSION POINT: We are not guaranteed that the European control will be able to be used as a restart for other runs. For example, we expect VERIFY to be at 11 km resolution suing completely different forcing data. Does this change at all how we want to proceed? Or is that a separate issue? I think it makes sense to do the evaluation as stated, and then do what is needed for the other runs separately.'' 518 * A spin-up as initial condition to make a European 1° x 1° CONTROL simulation 519 * 64 PFTs (some with 4 age classes) 520 * With forest management 521 * Litter raking 522 * Increasing atmospheric CO2 concentrations read from file 523 * LCC 524 * CRU-NCEP meteorological forcing, cyclic meteorology (1901-1920) until 1900, then use the corresponding year 525 * A dynamic N-cycle (impose_cn=n) 526 * N-deposition, we have N-deposition files from approximately 1860 until present. 572 527 573 528 Table 5. Observational data products to evaluate European control simulation … … 588 543 ==== Settings for spin-up and re-parameterization ==== 589 544 As a spin-up is costly in both time and computer resources, we need a strategy to avoid wasting these resources. Thus, the spin-up will like the parameterization, be done across scale moving from pixel to global scale. The spin-up will be done in parallel with the parameterization. Often the problems with the spin-up have a technical characters and show up for the pixels with extreme climate conditions. Before launching a longitudinal, regional or global spin-up, we should agree on the model version to use, because structural changes to the code will necessitate re-running the spin-up. The model version to use, will most likely be the version ready once the parameterization at the 1-pixel level is satisfying, and no more changes to the code need be added. 590 591 545 * Identify the variables that are targeted by the spin-up (such as NEP, heterotrophic respiration, decomposition etc). The spin-up will reveal whether parameters affecting these variables need to be tuned. The spin-up itself is also an interesting test case that could be loosely compared against data. 592 * We could compare the spin-ups to maps of soil carbon stocks to check the order of magnitude. Soil carbon maps should only be formally compared with the control run (spin-up + transient simulation) for the year 2000 because that run includes the simulated effects of N-deposition, management, litter raking and land cover change. The more simple configurations of the spin-up do not account for these processes or do not account for the right sequence of processes 546 * We could compare the spin-ups to maps of soil carbon stocks to check the order of magnitude. Soil carbon maps should only be formally compared with the control run (spin-up + transient simulation) for the year 2000 because that run includes the simulated effects of N-deposition, management, litter raking and land cover change. The more simple configurations of the spin-up do not account for these processes or do not account for the right sequence of processes.