Changes between Version 25 and Version 26 of DevelopmentActivities/ORCHIDEE-DOFOCO


Ignore:
Timestamp:
2012-10-25T09:23:12+02:00 (10 years ago)
Author:
luyssaert
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DevelopmentActivities/ORCHIDEE-DOFOCO

    v25 v26  
    3434        * stomate_io.f90 
    3535        * stomate_constants.f90 
    36         * stomate_data.f90 
    37         * stomate_prescribe.f90 
     36        * stomate_data.f90 (commented - CHECK for grass) 
     37        * stomate_prescribe.f90 (rewritten and tested - CHECK for grass) 
    3838        * sechiba.f90 
    3939        * diffuco.f90  
     
    4242== TO DO == 
    4343 
    44         POSSIBLE TICKETS 
    45         * Stomate_prescribe calculates the number of individuals. Immediately after doing so, it checks whether the total crown areas equals veget_max (the definition of veget_max), however, it is unlikely that this condition will be satisfied. Subsequently the code calculates ind as a function of veget_max. It would be a lot more elegant if this solution could be calculated right away. Check if an analytical solution can be found. 
    46   
    47         INITIALIZE & CONSISTENCY 
     44        STRUCTURE 
     45        * Make separate subroutine for resource-based allocation and allometric allocation 
     46        * Define all allometric relationships in a single subroutine to increase consistency of the model 
     47      
     48        ISSUES 
    4849        * Calculate rue_longterm in stomate_season.f90 
    4950        * In Sonke's code ! fraction of GPP which is lost as growth respiration is defined as REAL(r_std), SAVE :: frac_growthresp in 1.9.5.2 it is defined as a PARAMETER -> check stomate_constantes. 
    5051        * Check the values of limit_cn 
    51  
    52         LABILE & RESERVE POOL 
    5352        * Check where lab_fac comes from in stomate_resp.f90 
    5453        * Check negative NPP spikes (side effect of issues with the labile and reserve pool?) 
    55  
    56         RUE 
    57         * Lai is optimised for mean annual radiation use efficiency and the C costs for producing the canopy. The cost-benefit ratio is optimised when the marginal gain / marginal cost = 1 Investing 1gC in the canopy comes at a total cost that is composed by the C required for the canopy in addition to the roots and the sapwood to support the canopy. The total cost (C) is thus calculated as C: LAI * ( (1/tau_leaf)/sla + (one_year/tau_root)*LF/sla + (one_year/tau_sap)*height/(sla*KF)). The marginal cost for one unit of LAI is then dC/dLAI : (1/tau_leaf)/sla + (1/tau_root)*LF/sla + (1/tau_sap)*height/(sla*KF). Where, tau_leaf is given by ::leaflife_tab in years, tau-root by ::tau_root_d in days and tau_sap by ::tau_sap in days. LF is unitless, KF is expressed in meters and sla in m2.gC-1. The unit of dC/dLAI is thus gC.m-2 but all turnover times need to be expressed on an annual scale. Investing 1gC in the canopy enables the plant to assimilate more carbon. The gain (G) can be approximated by using the 'radiation use efficiency' as follows: RUE * one_year ( 1. - exp (-0.5 * LAI )). Where, 0.5 is the extinction factor that accounts for the fact the lower parts of the canopy receive less light. Note that RUE has a particular definition and is calculated as the ratio of GPP over the fraction of radiation absorbed by the canopy. Hence the unit of RUE is gC.m-2.day-1. The marginal gain of one unit of LAI is dG/dLAI: 0.5 * one_year * RUE exp (-0.5 * LAI). Subsequently, the optimal LAI is estimated as LAI_opt = -2. * log(2*(dC/dt)/RUE*one_year) ??Why was it not considered a cost when the leaves life longer than one year i.e. MIN(1.,leaflife_tab) in the original code - THINK ABOUT THIS!! 
     54        * The optimal LAI is estimated as LAI_opt = -2. * log(2*(dC/dt)/RUE*one_year) ??Why was it not considered a cost when the leaves life longer than one year i.e. MIN(1.,leaflife_tab) in the original code - THINK ABOUT THIS!! 
    5855        * Check what will happen if Cl_target is reached? Seems that the current routines keeps allocating C to the canopy.   
    59          
    60         REST 
    6156        * Check the values of GPP and NPP (much lower with the new scheme) 
    62         * Add the calculated height to the history files (done but needs to be checked) 
    6357        * Check whether a spin-up works 
    6458        * Check cn_sapl in stomate_lcchange.f90 (compare to OCN) 
     
    7367        * TEST 2: The old allocation scheme (flag STOMATE_FUNCTIONAL_ALLOCATION = n) in the adjusted 1.9.5.2 (rev 712) code was run for: (1) one pixel (52-53N, 6-7E), (2) 2 years, (3) without restart file, (4) with NCC forcing and (5) for all forest PFTs on a single pixel. The configuration can be found at home/users/sluys/MY_DEBUG/config/ORCHIDEE_OL/MYDEBUG2. 
    7468        * TEST 3: The new allocation scheme (flag STOMATE_FUNCTIONAL_ALLOCATION = y) in the adjusted 1.9.5.2 (rev 712) code was run for: (1) one pixel (52-53N, 6-7E), (2) 10 years, (3) without restart file, (4) with NCC forcing and (5) for all forest PFTs on a single pixel. The configuration can be found at home/users/sluys/MMY_DEBUG/config/ORCHIDEE_OL/MYDEBUG3. 
    75  
    76         * Conclusion TEST 1 vs TEST 2: the outcome was different (OL2/MYDEBUG1/output.txt) but should have been the same. Checked ediff for config.card, stomate.card, sechiba.card, orchidee_ol.card, driver.def, stomate.def and sechiba.def: no differences except for the job name. On day 1 all variables are similat except for CO2FLUX (although the fluxes listed in the history files are the same!) 
    77         * Conclusion TEST 3: the new allocation is stable over 10 years for PFT's 2 to 8. PFT 9 dies after 3 years but keeps its heartwood biomass for several more years (100 g C m-2). For all PFT's, NPP shows some very negative spikes for a single day (-10 gC m-2). Leaf_M and Root_M decreases with time for several PFT's. 
    78         * Conclusion TEST 2 vs TEST 3: new allocation has substantial less NPP due to substantial higher Ra. Ra of the old scheme is very low (25%) compared to the new scheme which is closer to (40%). 
    7969 
    8070[[BR]]