26 | | === Age classes (r6614) === |
27 | | Age classes were introduced to better handle heterogeneity at the landscape level. The feature allows us to distinguish between different successional stages of the same PFT (e.g., a newly grown forest vs. a mature forest). Age classes are independent of the number of diameter classes. Using age classes adds a lot of details to both the biophysics and the biogeochemistry following natural disturbances, forest management and land cover change. If half of a grassland is afforested with a PFT that already exists in the pixel, previous versions of ORCHIDEE will combine this newly forest land and the existing forest in a single PFT. This will result in, for example, a low albedo, a high roughness, and other properties. When age classes are used, the newly afforested and the existing forest will end up in separate PFTs. One will have a high albedo, the other a low albedo, and other properties may differ significantly as well. In CAN with age classes, PFTs are only merged if the youngest age class for a PFT already has biomass. |
| 26 | === Age classes === |
| 27 | Describes r6614. Age classes were introduced to better handle heterogeneity at the landscape level. The feature allows us to distinguish between different successional stages of the same PFT (e.g., a newly grown forest vs. a mature forest). Age classes are independent of the number of diameter classes. Using age classes adds a lot of details to both the biophysics and the biogeochemistry following natural disturbances, forest management and land cover change. If half of a grassland is afforested with a PFT that already exists in the pixel, previous versions of ORCHIDEE will combine this newly forest land and the existing forest in a single PFT. This will result in, for example, a low albedo, a high roughness, and other properties. When age classes are used, the newly afforested and the existing forest will end up in separate PFTs. One will have a high albedo, the other a low albedo, and other properties may differ significantly as well. In CAN with age classes, PFTs are only merged if the youngest age class for a PFT already has biomass. |
80 | | === Albedo (r6614) === |
81 | | ORCHIDEE trunk 4 makes use of a two stream radiative transfer scheme through the canopy, extended to multiple canopy levels (https://doi.org/10.5194/gmd-2016-280). 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), calculating an effective LAI based on the solar angle. Light from collimated (black sky) and diffuse (white sky) sources are used, and both are weighted equally as information about this partitioning is not yet available in forcing data. In ORCHIDEE trunk 4 the same scheme is used to simulate the reflected, transmitted and absorbed light, of which the absorbed light as a function of canopy level is passed to the photosynthesis routines and used in place of the exponential LAI layering found in older versions of the TRUNK (see the section Photosynthesis). 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 trunk 4 cannot revert to previous approaches for calculating albedo. |
| 80 | === Albedo === |
| 81 | Describes r6614. ORCHIDEE trunk 4 makes use of a two stream radiative transfer scheme through the canopy, extended to multiple canopy levels (https://doi.org/10.5194/gmd-2016-280). 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), calculating an effective LAI based on the solar angle. Light from collimated (black sky) and diffuse (white sky) sources are used, and both are weighted equally as information about this partitioning is not yet available in forcing data. In ORCHIDEE trunk 4 the same scheme is used to simulate the reflected, transmitted and absorbed light, of which the absorbed light as a function of canopy level is passed to the photosynthesis routines and used in place of the exponential LAI layering found in older versions of the TRUNK (see the section Photosynthesis). 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 trunk 4 cannot revert to previous approaches for calculating albedo. |
87 | | === Albedo (background) (r6614) === |
88 | | If covered by snow, the background albedo is calculated in the VIS and NIR wavelengths by the snow module and accounts for snow age and snow density. If not covered by snow, the background albedo is not simulated but prescribed by the parameters '''bgd_reflectance(:,ivis)''' and '''bgd_reflectance(:,inir)'''. If the background is partly covered by snow, the snow albedo and the background albedo are merged, which allows snow to settle under the canopy, reflecting 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 trunk 4 has two options to prescribe the background albedo: |
| 87 | === Albedo (background) === |
| 88 | Describes r6614. If covered by snow, the background albedo is calculated in the VIS and NIR wavelengths by the snow module and accounts for snow age and snow density. If not covered by snow, the background albedo is not simulated but prescribed by the parameters '''bgd_reflectance(:,ivis)''' and '''bgd_reflectance(:,inir)'''. If the background is partly covered by snow, the snow albedo and the background albedo are merged, which allows snow to settle under the canopy, reflecting 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 trunk 4 has two options to prescribe the background albedo: |
93 | | === Albedo (snow) (r6614) === |
94 | | The snow albedo could be either prescribed (the value of '''fixed_snow_albedo''' should then be set in the run.def and will be read in src_parameters/constantes_var.f90) or calculated following Chalita and Treut (1994) '''ok_snow_albedo_clm3 = n ''' or calculated following CLM3 '''ok_snow_albedo_clm3 = y''' (recommended). The difference between the latter two methods has not been tested yet. The CLM method was implemented in ORCHIDEE-CN-CAN and has been tested in combination with the other changes to the albedo calculations. The Chalita and Treut method was added in parallel to the ORCHIDEE trunk 3.0. When merging both versions, we ended up with two option. |
95 | | |
96 | | |
97 | | === Allocation (r6742) === |
98 | | ORCHIDEE trunk 4 uses the allometric allocation as developed in O-CN. In ORCHIDEE trunk 4 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 (incl. the pseudo sugar loading), the allocation scheme remained rather similar between the 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. This sensitivity is important at the start and the end of the growing seasons when temperatures may be low. 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 a lot/too much. This dampening was observed in ORCHIDEE-CN and ORCHIDEE-CN-CAN. IN ORCHIDEE-CNP the temperature relationship was removed (hence NPP and GPP are strictly coupled) because the interannual variability became unrealistic. |
| 93 | === Albedo (snow) === |
| 94 | Describes r6614. The snow albedo could be either prescribed (the value of '''fixed_snow_albedo''' should then be set in the run.def and will be read in src_parameters/constantes_var.f90) or calculated following Chalita and Treut (1994) '''ok_snow_albedo_clm3 = n ''' or calculated following CLM3 '''ok_snow_albedo_clm3 = y''' (recommended). The difference between the latter two methods has not been tested yet. The CLM method was implemented in ORCHIDEE-CN-CAN and has been tested in combination with the other changes to the albedo calculations. The Chalita and Treut method was added in parallel to the ORCHIDEE trunk 3.0. When merging both versions, we ended up with two option. |
| 95 | |
| 96 | |
| 97 | === Allocation === |
| 98 | Describes r6742. ORCHIDEE trunk 4 uses the allometric allocation as developed in O-CN. In ORCHIDEE trunk 4 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 (incl. the pseudo sugar loading), the allocation scheme remained rather similar between the 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. This sensitivity is important at the start and the end of the growing seasons when temperatures may be low. 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 a lot/too much. This dampening was observed in ORCHIDEE-CN and ORCHIDEE-CN-CAN. IN ORCHIDEE-CNP the temperature relationship was removed (hence NPP and GPP are strictly coupled) because the interannual variability became unrealistic. |
105 | | === Anthropogenic species change (r6614) === |
106 | | 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 trunk 4. Set '''ok_change_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. A example of such a configuration can be found in config/ORCHIDEE_OL/OOL_SEC_STO_FG5. 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 species changes. If the forest is unmanaged (fm=1), the code assumes that nature will determine the species rather than humans. Anthropogenic species change has not been developed to work together with land cover change. For the moment it is one or the other. When testing this functionality read_species_change_map and/or read_desired_fm_map could be set to n. The new forest management strategy can then be simply prescribed by setting the parameter '''fm_change_force''' to one of the four fm strategies. Likewise the new species can be prescribed by setting the parameter '''species_change_force''' to the desired PFT number. |
107 | | |
108 | | |
109 | | === Bare soil (r6783) === |
110 | | 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 veget_max_1 + sum(veget_max_i - veget_i) with i from 2 to the number of PFTs. When a deciduous PFT sheds its leaves, the gaps in the forest will thus contribute to the 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 PFT1 deserts as the background albedo of forest gaps. In ORCHIDEE v2.1 the background albedo has been reparameterized and this issue may have been largely resolved now if '''alb_bg_modis''' = y ([https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/TrunkFunctionality4#Albedobackgroundr6614 more details]). From many points of view a dynamic bare soil fraction is strange, e.g., bare soil has its own water column so when moving the forest gaps from to forest to PFT1 the soil water content, soil carbon content, litter layer, etc all changes temporary. If '''ok_bare_soil_new''' is set to TRUE, canopy gaps no longer contribute to the bare soil. 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 but the calculation of bare soil evaporation underneath a canopy would be problematic. For that reason ok_bare_soil_new is recommended only to be used with the multi-layer energy budget (when run with more than 1 layer). The multi-layer energy budget accounts for within canopy turbulence and can therefore deal with evaporation from beneath a canopy. At present the settings for ok_bare_soil_new are included in the energy_control flag ([https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/TrunkFunctionality4#Singlevsmultilayerenergybudgetr6614 more details]). The default settings of ORCHIDEE 4.0 combine the new albedo scheme with the single layer energy budget (enerbil) and '''ok_bare_soil_new''' = n. |
111 | | |
112 | | |
113 | | === Bark beetles (r6614) === |
114 | | The bark beetle module was developed such that it interacts with the windthrow module. If you want to activate it use the flag OK_PEST=y in the run.def. To specify which PFT may be affected by bark beetles use BEETLE_PFT_xxx= TRUE where XXX is the pft you interested in. Note that for the moment bark beetles in ORCHIDEE is parameterized only to work with Picea abies. |
115 | | |
116 | | |
117 | | === C13 (r6614) === |
118 | | 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. Following changes to the recalculation of GPP under plant water stress the calculation of Ci is no longer accurate. This may have broken the functionality to calculate C13. Needs to be tested. |
119 | | |
120 | | |
121 | | === Configurations (r6614) === |
122 | | The model comes with the following well-tested configurations (config/ORCHIDEE_OL). Well-tested means that these configuration have been tested on different servers and some are part of the trusting: |
| 105 | === Anthropogenic species change === |
| 106 | Describes r6614. 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 trunk 4. Set '''ok_change_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. A example of such a configuration can be found in config/ORCHIDEE_OL/OOL_SEC_STO_FG5. 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 species changes. If the forest is unmanaged (fm=1), the code assumes that nature will determine the species rather than humans. Anthropogenic species change has not been developed to work together with land cover change. For the moment it is one or the other. When testing this functionality read_species_change_map and/or read_desired_fm_map could be set to n. The new forest management strategy can then be simply prescribed by setting the parameter '''fm_change_force''' to one of the four fm strategies. Likewise the new species can be prescribed by setting the parameter '''species_change_force''' to the desired PFT number. |
| 107 | |
| 108 | |
| 109 | === Bare soil === |
| 110 | Describes r6783. 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 veget_max_1 + sum(veget_max_i - veget_i) with i from 2 to the number of PFTs. When a deciduous PFT sheds its leaves, the gaps in the forest will thus contribute to the 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 PFT1 deserts as the background albedo of forest gaps. In ORCHIDEE v2.1 the background albedo has been reparameterized and this issue may have been largely resolved now if '''alb_bg_modis''' = y ([https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/TrunkFunctionality4#Albedobackgroundr6614 more details]). From many points of view a dynamic bare soil fraction is strange, e.g., bare soil has its own water column so when moving the forest gaps from to forest to PFT1 the soil water content, soil carbon content, litter layer, etc all changes temporary. If '''ok_bare_soil_new''' is set to TRUE, canopy gaps no longer contribute to the bare soil. 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 but the calculation of bare soil evaporation underneath a canopy would be problematic. For that reason ok_bare_soil_new is recommended only to be used with the multi-layer energy budget (when run with more than 1 layer). The multi-layer energy budget accounts for within canopy turbulence and can therefore deal with evaporation from beneath a canopy. At present the settings for ok_bare_soil_new are included in the energy_control flag ([https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/TrunkFunctionality4#Singlevsmultilayerenergybudgetr6614 more details]). The default settings of ORCHIDEE 4.0 combine the new albedo scheme with the single layer energy budget (enerbil) and '''ok_bare_soil_new''' = n. |
| 111 | |
| 112 | |
| 113 | === Bark beetles === |
| 114 | Describes r6614. The bark beetle module was developed such that it interacts with the windthrow module. If you want to activate it use the flag OK_PEST=y in the run.def. To specify which PFT may be affected by bark beetles use BEETLE_PFT_xxx= TRUE where XXX is the pft you interested in. Note that for the moment bark beetles in ORCHIDEE is parameterized only to work with Picea abies. |
| 115 | |
| 116 | === C13 === |
| 117 | Describes r6614. 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. Following changes to the recalculation of GPP under plant water stress the calculation of Ci is no longer accurate. This may have broken the functionality to calculate C13. Needs to be tested. |
| 118 | |
| 119 | |
| 120 | === Configurations === |
| 121 | Describes r6614. The model comes with the following well-tested configurations (config/ORCHIDEE_OL). Well-tested means that these configuration have been tested on different servers and some are part of the trusting: |
139 | | === Consistency checks (r6614) === |
140 | | The code distinguishes between three options to check for mass and surface conservation. 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 trunk 4 will also check for the conservation of veget_max and frac_nobio. 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. |
| 138 | === Consistency checks === |
| 139 | Describes r6614. The code distinguishes between three options to check for mass and surface conservation. 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 trunk 4 will also check for the conservation of veget_max and frac_nobio. 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. |
146 | | === Croplands (r6614) === |
147 | | Makes use of crop_planting and crop_harvest in the module sapiens_agriculture. Harvest goes into harvest_pool (just like wood) and its decomposition is accounted for in the fluxes from the product use pool. |
148 | | |
149 | | |
150 | | === CWRR vs Choinel (r6614) === |
151 | | Following ORCHIDEE trunk 3, the Choinel code is no longer available in ORCHIDEE trunk 4. The hydrological schemes were not touched during the development of ORCHIDEE trunk 4. The hydraulic architecture in ORCHIDEE trunk 4 relies on CWRR. |
152 | | |
153 | | |
154 | | === Diameter classes (r6614) === |
155 | | 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. |
| 145 | === Croplands === |
| 146 | Describes r6614. Makes use of crop_planting and crop_harvest in the module sapiens_agriculture. Harvest goes into harvest_pool (just like wood) and its decomposition is accounted for in the fluxes from the product use pool. |
| 147 | |
| 148 | |
| 149 | === CWRR vs Choinel === |
| 150 | Describes r6614. Following ORCHIDEE trunk 3, the Choinel code is no longer available in ORCHIDEE trunk 4. The hydrological schemes were not touched during the development of ORCHIDEE trunk 4. The hydraulic architecture in ORCHIDEE trunk 4 relies on CWRR. |
| 151 | |
| 152 | |
| 153 | === Diameter classes === |
| 154 | Describes r6614. 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. |
168 | | === Forced clear cut (r6614) === |
169 | | '''FORCED_CLEAR_CUT''' is a flag used to force ORCHIDEE trunk 4 to clearcut a forest after one year of simulation. This flag is set to TRUE in order to start a new stand at the beginning of the FIN step in ENSEMBLE runs. It helps us to control the stand age at the end of the HIST step. If you want to use this flag for other purposes, do not forget that a clearcut means that the majority of the living biomass is removed (circ_class_biomass for sapwood and heartwood), but the other pools are transferred in the litter pool (leaf, branches, fruit, fine root). Note that if '''FORCED_CLEAR_CUT''' is used, the model will clearcut at the end of every year in that run. The typical set-up should be: 300 years of spin-up with '''FORCED_CLEAR_CUT''' set to FALSE, 1 year with '''FORCED_CLEAR_CUT''' set to TRUE, a simulation with the length similar to the age of the forest with '''FORCED_CLEAR_CUT''' set to FALSE. |
170 | | |
171 | | |
172 | | === Forest management and management changes (r6614) === |
173 | | 70% of the global forests are managed, which contradicts 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 of ORCHIDEE-FM, i.e., the allocation rule of Deleuze and Dhote that allocates carbon to different diameter classes based on the basal area of the tree, and relative-density index (RDI)-based management which enforces thinning and harvest operations based on the current tree density and the self-thinning density, were retained. |
| 167 | === Forced clear cut === |
| 168 | Describes r6614. '''FORCED_CLEAR_CUT''' is a flag used to force ORCHIDEE trunk 4 to clearcut a forest after one year of simulation. This flag is set to TRUE in order to start a new stand at the beginning of the FIN step in ENSEMBLE runs. It helps us to control the stand age at the end of the HIST step. If you want to use this flag for other purposes, do not forget that a clearcut means that the majority of the living biomass is removed (circ_class_biomass for sapwood and heartwood), but the other pools are transferred in the litter pool (leaf, branches, fruit, fine root). Note that if '''FORCED_CLEAR_CUT''' is used, the model will clearcut at the end of every year in that run. The typical set-up should be: 300 years of spin-up with '''FORCED_CLEAR_CUT''' set to FALSE, 1 year with '''FORCED_CLEAR_CUT''' set to TRUE, a simulation with the length similar to the age of the forest with '''FORCED_CLEAR_CUT''' set to FALSE. |
| 169 | |
| 170 | |
| 171 | === Forest management and management changes === |
| 172 | Describes r6614. 70% of the global forests are managed, which contradicts 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 of ORCHIDEE-FM, i.e., the allocation rule of Deleuze and Dhote that allocates carbon to different diameter classes based on the basal area of the tree, and relative-density index (RDI)-based management which enforces thinning and harvest operations based on the current tree density and the self-thinning density, were retained. |
200 | | === Harvest (r6614) === |
201 | | All biomass harvest is recorded in a harvest variable '''harvest_pool''', this variable also stores the mass and dimensions of the harvest/mortality (absolute numbers thus accounting for the pixel area!). Related variables were introduced: '''harvest_type''', '''harvest_cut''', and '''harvest_area'''. 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 were replaced by 2, 17 and 50 years which is closer to the reality for Europe. For most parts of the world a 100 year wood pool is very optimistic. |
202 | | |
203 | | |
204 | | === Leaf area index map (r6614) === |
205 | | Four flags have been identified that control the model behavior in terms of lai: '''ok_stomate''', '''ok_pheno''', '''impveg''' and '''read_lai'''. There is a 5th implicit flag which is whether restart files are used or not. If a restart file is used, the lai values will come from the sechiba restart file which is read at t=48. Given that each flag can take two values, we have 32 configurations in total. Out of these 32 configurations 10 are defined of which about 5 to 7 seem to be intended (for more details see '''Start and restart - Table 1'''). Many of the remaining 22 settings are inconsistent (i.e. running stomate to calculate a lai and reading an lai_map to prescribe lai), duplicate other settings, or would require further developments to work properly. Furthermore, the current code does not stop or warn when inconsistent settings are selected. The table (see Start and restart) proposes a scheme with 2 flags which can run with our without restart files, thus resulting in 8 different ways to control the lai in sechiba or the initial lai in stomate. The remaining 2 combinations are inconsistent and will stop the model. |
| 199 | === Harvest === |
| 200 | Describes r6614. All biomass harvest is recorded in a harvest variable '''harvest_pool''', this variable also stores the mass and dimensions of the harvest/mortality (absolute numbers thus accounting for the pixel area!). Related variables were introduced: '''harvest_type''', '''harvest_cut''', and '''harvest_area'''. 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 were replaced by 2, 17 and 50 years which is closer to the reality for Europe. For most parts of the world a 100 year wood pool is very optimistic. |
| 201 | |
| 202 | |
| 203 | === Leaf area index map === |
| 204 | Describes r6614. Four flags have been identified that control the model behavior in terms of lai: '''ok_stomate''', '''ok_pheno''', '''impveg''' and '''read_lai'''. There is a 5th implicit flag which is whether restart files are used or not. If a restart file is used, the lai values will come from the sechiba restart file which is read at t=48. Given that each flag can take two values, we have 32 configurations in total. Out of these 32 configurations 10 are defined of which about 5 to 7 seem to be intended (for more details see '''Start and restart - Table 1'''). Many of the remaining 22 settings are inconsistent (i.e. running stomate to calculate a lai and reading an lai_map to prescribe lai), duplicate other settings, or would require further developments to work properly. Furthermore, the current code does not stop or warn when inconsistent settings are selected. The table (see Start and restart) proposes a scheme with 2 flags which can run with our without restart files, thus resulting in 8 different ways to control the lai in sechiba or the initial lai in stomate. The remaining 2 combinations are inconsistent and will stop the model. |
212 | | === Land cover change (with age classes) (r6614) === |
213 | | Land cover change now accounts for age classes. It is controlled by '''veget_update'''. Set '''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. Furthermore, land cover change also deals with the change of biological land uses to non biological land uses (of which the most important change is probably urbanization). If urbanization happens, all the carbon an nitrogen are stored in a series of variables '''burried_xxx''' where xxx stands for a different pool, e.g., litter, soil, .... Burried_xxx are cumulative variables thus increasing over time . There is a place holder in sapiens_lcchange.90 to also develop the release of the buried carbon and nitrogen following de-urbanization (see ticket #616). The series of the burried_xxx variables are not yet written to an output file but this could be easily added (they are already defined in the xml files). |
| 211 | === Land cover change (with age classes) === |
| 212 | Describes r6614. Land cover change now accounts for age classes. It is controlled by '''veget_update'''. Set '''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. Furthermore, land cover change also deals with the change of biological land uses to non biological land uses (of which the most important change is probably urbanization). If urbanization happens, all the carbon an nitrogen are stored in a series of variables '''burried_xxx''' where xxx stands for a different pool, e.g., litter, soil, .... Burried_xxx are cumulative variables thus increasing over time . There is a place holder in sapiens_lcchange.90 to also develop the release of the buried carbon and nitrogen following de-urbanization (see ticket #616). The series of the burried_xxx variables are not yet written to an output file but this could be easily added (they are already defined in the xml files). |
219 | | === Litter decomposition (r6614) === |
220 | | 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. |
| 218 | === Litter decomposition === |
| 219 | Describes r6614. 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. |
233 | | === Litter raking (r6614) === |
234 | | 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 trunk 4 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. An example of to set up the model to make use of the historical litter raking maps can be found in config/ORCHIDEE_OL/OOL_SEC_STO_FG4 |
235 | | |
236 | | |
237 | | === Litter resistance to evaporation (r6783) === |
238 | | The default for the flag '''do_rsoil''' has changed to TRUE. When set to TRUE the flag reduces the bare soil evaporation because it accounts for the moisture content of the litter layer (Sellers et al., 1992). The presence of litter always acts as an extra barrier (resistance) to bare soil evaporation. If the litter layer dries out the resistance will even further increase. As in previous version, ORCHIDEE 4 calculates the bare soil fraction as PFT1 + SUM(veget_max_i - veget_i) where i goes from 2 to the number of PFTs. veget is now calculated by using Pgap which resulted in more bare soil, the extra resistance from litter helps to keep to evapotranspiration in check. |
239 | | |
240 | | |
241 | | === Mortality (r6614) === |
242 | | ORCHIDEE trunk 4 distinguishes 2 types of natural mortality: (1) explicitly considering mortality from disturbances and self-thinning, and (2) implicitly considering background mortality. Ideally, approach (1) should be further developed such that all underlying agents driving background mortality are represented in the model (i.e., gap-scale mortality, pests, disease, windthrow, etc.) such that it can replace approach (2). Two options of background mortality may be chosen: constant background mortality and dynamic background mortality. To use the first option, set the flag '''constant_mortality''' = y. The background mortality of a forests is calculated as a constant, prescribed fraction. In trunk 4, this fraction is given by '''residence_time''' (see also forest management). Otherwise set '''constant_mortality''' = n, the dynamic background mortality of a forest is a function of its net primary production (npp). If npp decreases, mortality will increase Both options have been developed but only '''constant_mortality''' = y has been tested in ORCHIDEE trunk 4. |
| 232 | === Litter raking === |
| 233 | Describes r6614. 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 trunk 4 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. An example of to set up the model to make use of the historical litter raking maps can be found in config/ORCHIDEE_OL/OOL_SEC_STO_FG4 |
| 234 | |
| 235 | |
| 236 | === Litter resistance to evaporation === |
| 237 | Describes r6783. The default for the flag '''do_rsoil''' has changed to TRUE. When set to TRUE the flag reduces the bare soil evaporation because it accounts for the moisture content of the litter layer (Sellers et al., 1992). The presence of litter always acts as an extra barrier (resistance) to bare soil evaporation. If the litter layer dries out the resistance will even further increase. As in previous version, ORCHIDEE 4 calculates the bare soil fraction as PFT1 + SUM(veget_max_i - veget_i) where i goes from 2 to the number of PFTs. veget is now calculated by using Pgap which resulted in more bare soil, the extra resistance from litter helps to keep to evapotranspiration in check. |
| 238 | |
| 239 | |
| 240 | === Mortality === |
| 241 | Describes r6614. ORCHIDEE trunk 4 distinguishes 2 types of natural mortality: (1) explicitly considering mortality from disturbances and self-thinning, and (2) implicitly considering background mortality. Ideally, approach (1) should be further developed such that all underlying agents driving background mortality are represented in the model (i.e., gap-scale mortality, pests, disease, windthrow, etc.) such that it can replace approach (2). Two options of background mortality may be chosen: constant background mortality and dynamic background mortality. To use the first option, set the flag '''constant_mortality''' = y. The background mortality of a forests is calculated as a constant, prescribed fraction. In trunk 4, this fraction is given by '''residence_time''' (see also forest management). Otherwise set '''constant_mortality''' = n, the dynamic background mortality of a forest is a function of its net primary production (npp). If npp decreases, mortality will increase Both options have been developed but only '''constant_mortality''' = y has been tested in ORCHIDEE trunk 4. |
249 | | === Nitrogen cycle (r6614) === |
250 | | ORCHIDEE trunk 4 strictly follows ORCHIDEE trunk 3 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. |
| 248 | === Nitrogen cycle === |
| 249 | Describes r6614. ORCHIDEE trunk 4 strictly follows ORCHIDEE trunk 3 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. |
291 | | === Phenology (r6614) === |
292 | | The pft-specific parameter '''always_init''' controls whether the phenology depends on the reserves (set to .FALSE.) or is forced (set to .TRUE.). Note that a forced phenology (thus always_init = .TRUE.) has no ecophysiological basis, it is a numerical approach to stabilize the vegetation cover. A stable vegetation cover is particularly welcome in coupled simulations but likely hides real vegetation dynamics (especially under future climate conditions) or problems in other routines or parameter settings. If a PFT keeps dying in an area where it is currently present, this would hint at a problem with the current model/parameters. If a PFT keeps dying under future conditions, it may be a real response (depending on the PFT). If forced phenology is used, plants will develop an initial canopy in phenology irrespective of whether the plant had sufficient carbon and nitrogen reserves and for evergreen species irrespective of whether the canopy was viable at all. This setting basically overcomes a mortality event at the expense of taking up carbon and nitrogen from the atmosphere. When used in combination with impose_cn = n, an inconsistency is introduced: impose_cn = n reflect the desire to close the nitrogen cycle, always_init = y opens a backdoor in the nitrogen cycle. |
| 290 | === Phenology === |
| 291 | Describes r6614. The pft-specific parameter '''always_init''' controls whether the phenology depends on the reserves (set to .FALSE.) or is forced (set to .TRUE.). Note that a forced phenology (thus always_init = .TRUE.) has no ecophysiological basis, it is a numerical approach to stabilize the vegetation cover. A stable vegetation cover is particularly welcome in coupled simulations but likely hides real vegetation dynamics (especially under future climate conditions) or problems in other routines or parameter settings. If a PFT keeps dying in an area where it is currently present, this would hint at a problem with the current model/parameters. If a PFT keeps dying under future conditions, it may be a real response (depending on the PFT). If forced phenology is used, plants will develop an initial canopy in phenology irrespective of whether the plant had sufficient carbon and nitrogen reserves and for evergreen species irrespective of whether the canopy was viable at all. This setting basically overcomes a mortality event at the expense of taking up carbon and nitrogen from the atmosphere. When used in combination with impose_cn = n, an inconsistency is introduced: impose_cn = n reflect the desire to close the nitrogen cycle, always_init = y opens a backdoor in the nitrogen cycle. |
297 | | === Photosynthesis (r6614) === |
298 | | Photosynthesis is calculated as in ORCHIDEE trunk 4, and ORCHIDEE trunk 3 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 trunk 4 used nlevels_photo = 10. Contrary to previous trunk versions of ORCHIDEE where each canopy layer contained 0.5 units of LAI, in ORCHIDEE trunk 4, each canopy layer will have the same depth (in m) but will contain a different amount of LAI because tree canopies are assumed spherical. |
299 | | |
300 | | |
301 | | === Plant water stress (r6614) === |
302 | | With ORCHIDEE trunk 4 there are two option to calculate waters stress: |
| 296 | === Photosynthesis === |
| 297 | Describes r6614. Photosynthesis is calculated as in ORCHIDEE trunk 4, and ORCHIDEE trunk 3 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 trunk 4 used nlevels_photo = 10. Contrary to previous trunk versions of ORCHIDEE where each canopy layer contained 0.5 units of LAI, in ORCHIDEE trunk 4, each canopy layer will have the same depth (in m) but will contain a different amount of LAI because tree canopies are assumed spherical. |
| 298 | |
| 299 | |
| 300 | === Plant water stress === |
| 301 | Describes r6614. With ORCHIDEE trunk 4 there are two option to calculate waters stress: |
309 | | === Prescribe initial vegetation (r6614) === |
310 | | 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 are 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 diameter was chosen because it is easy to (mentally) visualize the prescribed vegetation. In the run.def '''dia_init_min''' and '''dia_init_max''' need to be prescribed. Typical values are 1 to 3 cm. If more than one diameter class is used, '''dia_init_max ''' needs to larger than '''dia_init_min'''. The larger the difference between the min and max, the more vegetation layers the canopy will be composed from. Grasses are prescribed by the parameters '''height_init_min''' and '''height_init_max''' because we have no diameter-height relationship for grasses. Note that '''height_init_min''' and '''height_init_max''' are the same. The fact that we have two values is a left over from previous versions of stomate_prescribe.f90 (see ticket #688). |
| 308 | === Prescribe initial vegetation === |
| 309 | Describes r6614. 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 are 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 diameter was chosen because it is easy to (mentally) visualize the prescribed vegetation. In the run.def '''dia_init_min''' and '''dia_init_max''' need to be prescribed. Typical values are 1 to 3 cm. If more than one diameter class is used, '''dia_init_max ''' needs to larger than '''dia_init_min'''. The larger the difference between the min and max, the more vegetation layers the canopy will be composed from. Grasses are prescribed by the parameters '''height_init_min''' and '''height_init_max''' because we have no diameter-height relationship for grasses. Note that '''height_init_min''' and '''height_init_max''' are the same. The fact that we have two values is a left over from previous versions of stomate_prescribe.f90 (see ticket #688). |
318 | | === Pseudo sugar loading (r6614) === |
319 | | The model code does not control the C/N ratio of the labile pool hence, even if there is a strong N-limitation, the model can accumulate lots of carbon in the labile pool. The first CN-version was indeed doing this as the plant could easily store several 1000 gC m-2. As this was considered unrealistic, the excess C in the labile pool was burned-off by some excess respiration. Although this luxury/wastage respiration has been suggested in the literature (see Amthor et al 2000 and Chamber et al 2004) it is not confirmed by many observations. It was therefore decided to control the size of the labile pool. The model already had an estimate of the optimal pool size of the labile and carbres pools. If the plant has more labile carbon than the optimal, GPP is downregulated because too much sugars in the leaves will increase the viscosity and hamper the sapflow in the phloem. The viscosity can be decreased again by closing the stomata and transpiring less of the sapflow in the xylem. By closing the stomata, GPP will be downregulated (Holtta et al 2017 doi:10.1093/treephys/tpx011). Because ORCHIDEE has no sapflow, turgor and viscosity yet, we used a simple ratio to downregulate NUE. Hence, the feature was called '''pseudo sugar loading''' to make clear this is not the real thing yet. |
| 317 | === Pseudo sugar loading === |
| 318 | Describes r6614. The model code does not control the C/N ratio of the labile pool hence, even if there is a strong N-limitation, the model can accumulate lots of carbon in the labile pool. The first CN-version was indeed doing this as the plant could easily store several 1000 gC m-2. As this was considered unrealistic, the excess C in the labile pool was burned-off by some excess respiration. Although this luxury/wastage respiration has been suggested in the literature (see Amthor et al 2000 and Chamber et al 2004) it is not confirmed by many observations. It was therefore decided to control the size of the labile pool. The model already had an estimate of the optimal pool size of the labile and carbres pools. If the plant has more labile carbon than the optimal, GPP is downregulated because too much sugars in the leaves will increase the viscosity and hamper the sapflow in the phloem. The viscosity can be decreased again by closing the stomata and transpiring less of the sapflow in the xylem. By closing the stomata, GPP will be downregulated (Holtta et al 2017 doi:10.1093/treephys/tpx011). Because ORCHIDEE has no sapflow, turgor and viscosity yet, we used a simple ratio to downregulate NUE. Hence, the feature was called '''pseudo sugar loading''' to make clear this is not the real thing yet. |
332 | | === River routing (r6614) === |
333 | | This functionality works has not been evaluated yet for ORCHIDEE trunk 4, although it technically runs. Unless rivers are your main interest, set '''river_routing''' to n. The functionality still has problem when combined with the zoomed grids because pixels far away from the zoom become so big that some rivers can no longer reach the sea. Stand alone applications of ORCHIDEE trunk 4 with river routing being activated require that the whole watershed in include in the simulation domain. If not the model will crash right at the start. |
334 | | |
335 | | |
336 | | === run.def (r6614) === |
337 | | The format of the run.def has been modified to use the same structure for both coupled and off-line runs. The run.def is split between its driver settings (written in run.def), general items which control the ORCHIDEE model (in the orchidee.def file), and PFT-dependent parameters (in the orchidee_pft.def file). A script is now included with the config/ORCHIDEE_OL directory called MAKE_RUN_DEF. This scripts generates different orchidee_pfts.def files. Default model configurations (and thus different orchidee.def files) can be found in config/ORCHIDEE_OL. |
| 331 | === River routing === |
| 332 | Describes r6614. This functionality works has not been evaluated yet for ORCHIDEE trunk 4, although it technically runs. Unless rivers are your main interest, set '''river_routing''' to n. The functionality still has problem when combined with the zoomed grids because pixels far away from the zoom become so big that some rivers can no longer reach the sea. Stand alone applications of ORCHIDEE trunk 4 with river routing being activated require that the whole watershed in include in the simulation domain. If not the model will crash right at the start. |
| 333 | |
| 334 | |
| 335 | === run.def === |
| 336 | Describes r6614. The format of the run.def has been modified to use the same structure for both coupled and off-line runs. The run.def is split between its driver settings (written in run.def), general items which control the ORCHIDEE model (in the orchidee.def file), and PFT-dependent parameters (in the orchidee_pft.def file). A script is now included with the config/ORCHIDEE_OL directory called MAKE_RUN_DEF. This scripts generates different orchidee_pfts.def files. Default model configurations (and thus different orchidee.def files) can be found in config/ORCHIDEE_OL. |
355 | | === Single vs multi layer energy budget (r6614) === |
356 | | 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. In this can, however, be done by two different methods that in theory should give the exact same results: |
| 354 | === Single vs multi layer energy budget === |
| 355 | Describes r6614. 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. In this can, however, be done by two different methods that in theory should give the exact same results: |
383 | | === Specific leaf area (r6614) === |
384 | | Similar to ORCHIDEE 3.0, ORCHIDEE trunk 4 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. Nevertheless, the effect of this flag is much more limited than one could expect based on the perceived importance of sla. |
385 | | |
386 | | |
387 | | === Spin-up (r6614) === |
388 | | The analytical spin-up works with ORCHIDEE trunk 4. To ensure growth at the onset of the analytic spin-up for all PFTs initial values are needed for the SOM pools, and that is irrespective of whether IMPOSE_CN is y or n. The initial pools are set in stomate_io.f90, and they can be specified in the run.def by: |
| 382 | === Specific leaf area === |
| 383 | Describes r6614. Similar to ORCHIDEE 3.0, ORCHIDEE trunk 4 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. Nevertheless, the effect of this flag is much more limited than one could expect based on the perceived importance of sla. |
| 384 | |
| 385 | |
| 386 | === Spin-up === |
| 387 | Describes r6614. The analytical spin-up works with ORCHIDEE trunk 4. To ensure growth at the onset of the analytic spin-up for all PFTs initial values are needed for the SOM pools, and that is irrespective of whether IMPOSE_CN is y or n. The initial pools are set in stomate_io.f90, and they can be specified in the run.def by: |
420 | | === Sechiba vs stomate (r6614) === |
421 | | In ORCHIDEE trunk 4 the links between sechiba and stomate have been strengthened compared to previous ORCHIDEE trunks. As in previous versions, stomate makes use of variables calculated in sechiba but in ORCHIDEE trunk 4, 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 trunk 4 run with stomate. All the required information is stored in the sechiba restart file to enable restarting the model without stomate. |
422 | | |
423 | | === Tree ring width (r6721) === |
424 | | Tree ring width is always calculated and is not controlled by any flags or additional parameters. The basal area increment is central in the allocation scheme when making use of the Deleuze and Dhote rule to account for within stand competition between trees with different dimensions. It is saved to the output variable CCDELTABA (mm2 day-1). Basal area increment can be used to calculate the tree ring width when assuming that the cross-section of a tree trunk is circular. The output variable CCTRW represents the radial increase of individual trees for each circumference class (mm day-1). Since CCTRW is simply sqrt(ba_later/pi) - sqrt(ba_beginning/pi), it reconstructs trees from zero at year 1 removing the effect of BA_init. An implication of this approach is that the value at the first time step does not only include the growth calculated in stomate_growth_fun_all but also the basal area that was prescribed in stomate_prescribe.f90. The contribution of the initial tree dimensions prescribed in stomate_prescribe becomes more important if bigger trees are prescribed. Both CCDELTABA and CCTRW are written to stomate_4dim.nc. |
425 | | |
426 | | === Vertical discretization soil carbon (r6721) === |
427 | | To be completed. |
428 | | |
429 | | === Wind throw (r6614) === |
430 | | The calculation of wind storm damage can be activated by setting '''ok_windthrow''' to y in the orchidee.def. This module calculates 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 replanted and moved to the first age class (if more than 1 age class is used). |
| 419 | === Sechiba vs stomate === |
| 420 | Describes r6614. In ORCHIDEE trunk 4 the links between sechiba and stomate have been strengthened compared to previous ORCHIDEE trunks. As in previous versions, stomate makes use of variables calculated in sechiba but in ORCHIDEE trunk 4, 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 trunk 4 run with stomate. All the required information is stored in the sechiba restart file to enable restarting the model without stomate. |
| 421 | |
| 422 | === Tree ring width === |
| 423 | Describes r6721. Tree ring width is always calculated and is not controlled by any flags or additional parameters. The basal area increment is central in the allocation scheme when making use of the Deleuze and Dhote rule to account for within stand competition between trees with different dimensions. It is saved to the output variable CCDELTABA (mm2 day-1). Basal area increment can be used to calculate the tree ring width when assuming that the cross-section of a tree trunk is circular. The output variable CCTRW represents the radial increase of individual trees for each circumference class (mm day-1). Since CCTRW is simply sqrt(ba_later/pi) - sqrt(ba_beginning/pi), it reconstructs trees from zero at year 1 removing the effect of BA_init. An implication of this approach is that the value at the first time step does not only include the growth calculated in stomate_growth_fun_all but also the basal area that was prescribed in stomate_prescribe.f90. The contribution of the initial tree dimensions prescribed in stomate_prescribe becomes more important if bigger trees are prescribed. Both CCDELTABA and CCTRW are written to stomate_4dim.nc. |
| 424 | |
| 425 | === Vertical discretization soil carbon === |
| 426 | Describes r6721. To be completed. |
| 427 | |
| 428 | === Wind throw === |
| 429 | Describes r6614. The calculation of wind storm damage can be activated by setting '''ok_windthrow''' to y in the orchidee.def. This module calculates 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 replanted and moved to the first age class (if more than 1 age class is used). |