Changes between Version 221 and Version 222 of DevelopmentActivities/ORCHIDEE-DOFOCO


Ignore:
Timestamp:
2019-11-22T13:32:57+01:00 (5 years ago)
Author:
mmcgrath
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • DevelopmentActivities/ORCHIDEE-DOFOCO

    v221 v222  
    22[[PageOutline]] 
    33 
    4 ORCHIDEE-CN-CAN is a combination of three code bases: the trunk as it is in 2019, 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. 
     4ORCHIDEE-CN-CAN is a combination of three code bases: the trunk as it is in 2019, 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. Consider the model as two parts: 1) core processes that effect fluxes and pools on the per square meter level, and 2) perirpheric processes that involve everything else.  In this picture, the functionality that is not yet included depends on core processes like vegetation growth, soil hydrology or the energy budget, but it does not affect these processes at the pixel level. 
    55* The available functionality is described in more detail below 
    66* Missing functionalities compared to the trunk: DGVM, IPCC woodharvest, prescribed LAI, and fire disturbances  
    77* Missing functionalities compared to ORCHIDEE-CN: none  
    88* Missing functionalities compared to ORCHIDEE-CAN: none 
    9 * Better functionalities than those available in the trunk, ORCHIDEE-CN or ORCHIDEE-CN-CAN: spitfire for fire disturbances and gross land cover changes 
     9* Better functionalities than those available in the trunk, ORCHIDEE-CN or ORCHIDEE-CN-CAN: other branches have used an improved fire module (Spitfire) for fire disturbances and gross land cover changes, and we could consider adding those to Tag 4.0 
    1010* 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, mass balance and quality control functions … it is expected that lots of testing will be required to come to a satisfying result with LMDzOR-CN-CAN. 
    1111 
    … …  
    7878 
    7979== Functionalities (alphabetical order) == 
     80 
    8081=== Age classes === 
    81 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 signficiantly as well.  
     82Age 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 when an older age class is killed. 
    8283 
    8384Age classes are defined as separate PFTs.  Different age classes of the same PFT could therefore be, in principle, 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 for the whole simulation, but for each PFT it can be decided whether age classes are used or not. In other words, if the user chooses four age classes for the simulation, each PFT can have either 1 or 4 age classes.  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 creating 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, although ORCHIDEE-CAN does make extensive use of "CYCLE" statements to avoid calculations where no biomass is present. 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. 
    8485 
    85 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 considerably easier. 
     86It does not make sense to use age classes for runs ignoring land cover change.  Age classes can be used for site level simulations that involve land cover change.  Only use age classes if you really need them (e.g., land cover change), as not using age classes will make post processing of the simulation results considerably easier. 
    8687 
    8788The 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:  
    … …  
    133134 
    134135=== Albedo (general) === 
    135 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. 
     136ORCHIDEE-CN-CAN 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 avaialble in forcing data.  In ORCHIDEE-CN-CAN 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 expontential 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-CN-CAN cannot revert to previous approaches for calculating albedo. 
    136137  
    137 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. 
    138  
    139 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).  
     138The 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, both the visible (VIS) and near-infrared (NIR) spectra 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. 
     139 
     140When snow 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 Albedo (background)).  
    140141 
    141142=== Albedo (background) === 
    142 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: 
     143If 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'''. 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-CN-CAN has two options to prescribe the background albedo: 
    143144* 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. 
    144145* 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. 
    … …  
    317318 
    318319=== River routing === 
    319 The river routing code was not touched during the development of ORCHIDEE-CN-CAN. This functionality has not been tested yet for ORCHIDEE-CN-CAN. Unless rivers are your main interest, set '''river_routing''' to n.  
     320The river routing code was not touched during the development of ORCHIDEE-CN-CAN. This functionality has not been evaluated yet for ORCHIDEE-CN-CAN, although it technically runs. Unless rivers are your main interest, set '''river_routing''' to n.  
     321 
     322=== run.def === 
     323The 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 some driver settings (written in run.def), a bunch of general items which control the ORCHIDEE model (in the orchidee.def file), and PFT-dependent parameters (in the orchidee_pft.def file). 
     324 
     325A script is now included with the config/ORCHIDEE_OL directory called MAKE_RUN_DEF.  This will generate 
    320326 
    321327=== Soil maps ===