Changes between Version 109 and Version 110 of DevelopmentActivities/ORCHIDEE-DOFOCO

Timestamp:

2016-11-20T19:39:53+01:00 (7 years ago)

Author:

luyssaert

Comment:

--

DevelopmentActivities/ORCHIDEE-DOFOCO

@@ -37 +37 @@
 - Revision 3710 includes an updated stomate scheme. This revision features an optional hack which takes all carbon required for autotrophic respiration from the atmosphere. It was found that this allows most PFTs to grow (mostly) normally. The relevant changes are contained in stomate_growth_fun_all.f90.   The model runs for 102 years with no crashes. 
 - [NOT solved] History variables BM_ALLOC_RES_c and BM_ALLOC_RES_n are written with invalid data. C and N in the reserve pools are contained in the variable RESERVE_M_c and RESERVE_M_n.
-- [NOT solved] Some PFTs still have abnormalities in their long-term growth and decay patterns; After 100 simulation years, PFTs 18 and 22 (Broadleaved Summergreen Temperate age class 01, Needleleaf Evergreen Boreal age class 01) both contain a sharp spike in atm_to_bm-N. This spike should coincide with a sudden increase in individual tree density, but this does not seem to be the case. PFT 28 (Broadleaved Summergreen Boreal age class 03) shows jumps in mean tree diameter that coincide with sudden drops in individual tree density. This behavior is unexpected for unmanaged tree stands. See attached pdfs for data.
+- [NOT solved] Some PFTs still have abnormalities in their long-term growth and decay patterns; After 100 simulation years, PFTs 18 and 22 (Broadleaved Summergreen Temperate age class 01, Needleleaf Evergreen Boreal age class 01) both contain a sharp spike in atm_to_bm-N. This spike should coincide with a sudden increase in individual tree density, but this does not seem to be the case. PFT 28 (Broadleaved Summergreen Boreal age class 03) shows jumps in mean tree diameter that coincide with sudden drops in individual tree density. This behaviour is unexpected for unmanaged tree stands. See attached pdfs for data.
 
 === 21.07.2016 ===
@@ -47 +47 @@
 - Revision 3634 has no new functionality.
 - Several mass balance problems were fixed for the option impose_cn = y
-- [NOT solved] Alex could run the model for 34 years without any problems on obelix. Sebastiaan could run the model for 7 years on Curie and got a crash in year 8 in stomate_growth_fun_alloc.f90. The model crashes in allocation because the biomass is zero and the code tries to divide by zero which does not work. This is a conceptual problem. The allocation scheme needs biomass to decide how to allocate biomass. Hence, the scheme should never be called if biomass is zero. In allocation some of the if-statements use the veget_max criterion for consistency with the other routines. We could simply replace this by a biomass criterion but then we loose consistency with the other routines and more importantly we simply hide the bug. The real problem is that we have pfts for which veget_max is greater than zero but biomass is zero. This should never occur in allocation because allocation is right after prescribe and in-between there is no mortality. If veget_max is greater than zero and biomass equals zero, prescribe should add biomass to that pixel. This is a long story to say that the real problem is in prescribe and not in allocation. How it is possible that and apparent empty PFT (biomass = 0) with a veget_max>0 does not receive new biomass in prescribe. Given that we did not have this problem in the C-only version it is probably good to start looking in the lines of code where N is dealt with. 
+- [ticket #288] Alex could run the model for 34 years without any problems on obelix. Sebastiaan could run the model for 7 years on Curie and got a crash in year 8 in stomate_growth_fun_alloc.f90. The model crashes in allocation because the biomass is zero and the code tries to divide by zero which does not work. This is a conceptual problem. The allocation scheme needs biomass to decide how to allocate biomass. Hence, the scheme should never be called if biomass is zero. In allocation some of the if-statements use the veget_max criterion for consistency with the other routines. We could simply replace this by a biomass criterion but then we loose consistency with the other routines and more importantly we simply hide the bug. The real problem is that we have pfts for which veget_max is greater than zero but biomass is zero. This should never occur in allocation because allocation is right after prescribe and in-between there is no mortality. If veget_max is greater than zero and biomass equals zero, prescribe should add biomass to that pixel. This is a long story to say that the real problem is in prescribe and not in allocation. How it is possible that and apparent empty PFT (biomass = 0) with a veget_max>0 does not receive new biomass in prescribe. Given that we did not have this problem in the C-only version it is probably good to start looking in the lines of code where N is dealt with. 
 
 
@@ -62 +62 @@
 - Revision 3442 has a more or less complete version of stomate (LCC is still missing but this routine does not affect the parameterisation of the model).
 - [solved] Most PFTs (except the crops) don't grow but don't die either (an issue with N-availability?)
-- The mass balance has been closed for all the activated stomate routines (for FOREST_MANAGED_FORCED = 1 or 2). 
-- [NOT solved] Need to test mass balance closure for FOREST_MANAGED_FORCED  = 3 (Coppice) and FOREST_MANAGED_FORCED  = 4 (Short Rotation Coppice). 
-- [NOT solved] Need to re-activate the independent mass balance check for stomate and write it to the history file (request from IPSL)
+- The mass balance has been closed for all the activated stomate routines (for FOREST_MANAGED_FORCED = 1 or 2).  
+- [ticket #267] Need to re-activate the independent mass balance check for stomate and write it to the history file (request from IPSL)
 
 === 12.05.2016 ===
@@ -78 +77 @@
 === 29.04.2016 ===
 - Revision 3397. Added two-way albedo
-- [NOT solved] problems with 'snow_frac', feeding into values for the snow albedo greater than 1, and crashes shortly afterwards. Variable that is causing the problem appears to be 'frac_snow_veg',  in the subroutine 'albedo_two_stream'. This is a variable that is calculated in 'calculate_snow_albedo' subroutine and passed up to 'albedo_two_stream', and from there to condveg. The only place that it is calculated is 'calculate_snow_albedo'. In this particular model run it is zero for all PFTs. However in a later loop over all PFTs (within 'albedo_two_stream') the value of 'frac_snow_veg' strangely deviates from zero, which causes incremental  increases in the albedo, until eventually the model crashes. When I define a local variable for this PFT loop, 'frac_snow_veg_loc' (just within 'albedo_two_stream') the model does not crash. This is rather a clumsy solution, but it is strange that 'frac_snow_veg' does not retain its value during the loop.
+- [ticket #287] problems with 'snow_frac', feeding into values for the snow albedo greater than 1, and crashes shortly afterwards. Variable that is causing the problem appears to be 'frac_snow_veg',  in the subroutine 'albedo_two_stream'. This is a variable that is calculated in 'calculate_snow_albedo' subroutine and passed up to 'albedo_two_stream', and from there to condveg. The only place that it is calculated is 'calculate_snow_albedo'. In this particular model run it is zero for all PFTs. However in a later loop over all PFTs (within 'albedo_two_stream') the value of 'frac_snow_veg' strangely deviates from zero, which causes incremental  increases in the albedo, until eventually the model crashes. When I define a local variable for this PFT loop, 'frac_snow_veg_loc' (just within 'albedo_two_stream') the model does not crash. This is rather a clumsy solution, but it is strange that 'frac_snow_veg' does not retain its value during the loop.
 
 === 22.04.2016 ===
@@ -104 +103 @@
 === 18.02.2016 ===
 - Merged the laieff code and made the link between stomate and sechiba
-- [NOT solved] LAI is still passed around. According to the DOFOCO philosophy it should be calculated from biomass when needed. This should be checked. Difficulty is that the option to read the LAI map needs to be maintained. Probably best to convert LAI in biomass and pass biomass raound in line with the rest of the code.
-- [NOT solved] veget is now calculated from laieff. It needs to be checked whether this is always the case. Not sure about that.
-- [NOT solved] canopy structure is declared in sechiba and calculated in stomate. The output files are also written in stomate so for the moment it has not been tested whether it is correctly passed to sechiba.
+- [ticket #285 and #286] LAI is still passed around. According to the DOFOCO philosophy it should be calculated from biomass when needed. This should be checked. Difficulty is that the option to read the LAI map needs to be maintained. Probably best to convert LAI in biomass and pass biomass raound in line with the rest of the code.
+- [ticket #262] veget is now calculated from laieff. It needs to be checked whether this is always the case. Not sure about that.
+- [solved] canopy structure is declared in sechiba and calculated in stomate. The output files are also written in stomate so for the moment it has not been tested whether it is correctly passed to sechiba.
 
 === 03.02.2016 ===
@@ -112 +111 @@
 - [solved] No nitrogen allocation for deciduous trees
 - [solved] Added a patch for allow_initpheno in stomate_phenology to make the model work with turnover. This patch should be removed as soon as turnover is activated. The patch is marked with +++PATCH+++
-- [NOT solved] We end up with rather large residuals in ordinary allocation. This is something new and unwanted. The code itself should be OK so most likely this is the result of a bug somewhere else in the code (no idea where) or a problem due to the parameter settings. The numerical approximation makes use of ::s and ::step. That is probably where the problem is really happening. A temporary fix was implemented.
-- [NOT solved] The code runs with ncirc=3 but the output needs to be adjusted to reflect the different diameter classes.
+- [ticket #284] We end up with rather large residuals in ordinary allocation. This is something new and unwanted. The code itself should be OK so most likely this is the result of a bug somewhere else in the code (no idea where) or a problem due to the parameter settings. The numerical approximation makes use of ::s and ::step. That is probably where the problem is really happening. A temporary fix was implemented.
+- [ticket #283] The code runs with ncirc=3 but the output needs to be adjusted to reflect the different diameter classes.
 - [solved] Phenology now uses a battery of variables: allow_phenology, begin_leaves, senescence, ... these variables can be in conflict with each other. The code could be simplified and made more robust by merging all this information is a single variable,for example; pheno_status. The value of that variable could be iallowpheno, ibeginleaf, igrowth, isenescent, idormancy. That way the plant can only have one condition at a time and inconsistencies would no longer be possible.
-- [NOT solved] Phenology seems to work but is far from realistic.
+- [ticket #282] Phenology seems to work but is far from realistic.
 
 === 03.02.2016 ===