Changes between Version 55 and Version 56 of DevelopmentActivities/ORCHIDEE-DOFOCO

01/06/16 12:27:03 (5 years ago)



  • DevelopmentActivities/ORCHIDEE-DOFOCO

    v55 v56  
    1515- The code crashes in stomate_growth_fun_alloc.f90 where qm_dia is calculated. All values are zero. 
     17=== 06.01.2016 === 
     18- Merged stomate_phenology 
     19- Checked for mass balance closure for carbon and nitrogen 
     20- Re-introduced circ_class_biomass and circ_class_n. 
     21- Used get_printlev (constantes.f90) as a more clean and consistent substitute for the ld_flags that were used for debugging in ORCHIDEE-CAN. 
     22- The code crashes in stomate_growth_fun_alloc.f90 where qm_dia is calculated. All values are zero. 
    1724== ISSUES == 
    1825=== 10.12.2015 === 
    2431- [NOT solved] two identical installations of the revision 2978 do not result in identical output for SRF. The SRF output differed by 10-5 to 10-8 for the C-fluxes for the 4 pixels and 10-6 to 10-9 for the single pixel run. This appears as a minor issue but it suggests that the 1+1 problem has not been solved. Interestingly GPP in stomate is identical. GPP in SRF is among the variables with shows small differences. 
    2532- [NOT solved] the function get_printlev does not work. Only printlev is read and used. printlev_loc is not working. Tried to debug but without success. This function contains about 5 lines of code so finding the problem shouldn't be too difficult. 
     34=== 06.01.2016 === 
     35- [NOT solved] the code still makes use of biomass and circ_class_biomass. Both were kept because in th einitial implementation the labile and reserve pool were not defined at the circumference level. While merging phenology I found my myself working on code that distributed the reserves over the circumference classes. If this is consistently done throughout stomate there is no reason to keep biomass (and ind). This would also overcome the need to sync biomass vs circ_class_biomass and ind vs circ_class_ind. 
     36- [NOT solved] the Nitrogen version of the code makes use of Nsupport when impose_cn is TRUE. The function of the variable seems identical to atm_to_bm (which replaces co2_to_bm and n_to_bm) so Nsupport is no longer used. Confirm whether this is acceptable. 
     37- [NOT solved] The code for the dynamic N-cycle seems to be incomplete (the if-loop only accounts for one case for other cases variables may become undefined). This section was marked with +++CHEC+++.