Run the model with impose_CN=FALSE

[aresovsky]

Check to make sure the model runs successfully with impose_CN set to "false." Currently (as of 10/1/17), all of our test simulations are done with impose_CN=true. Document/fix any issues/bugs/mass balance errors resulting from switching off impose_CN. Any bugs should be fixed. The model should run successfully with either impose_CN=true or impose_CN=false.

[luyssaert]

While working on this issue ticket #335 and #337 were opened and fixed. At present the code crashes in year two with a very large negative biomass. The negative biomasses are caused in stomate_phenology.f90 around line 1039 where cn_leaf_use is calculated. cn_leaf_use is around -10e4. The calculation of cn_leaf_use makes use of fcn_root. This parameter was used as a scalar but in fact is vector with nvm dimensions (fcn_root is pft-dependent). This fixed the problem with the large negative values but resulted in a mass balance error in the same block of code.

Phenological growth is supported by the labile carbon pool. The labile carbon is allocated to the leaves and roots. If there is not enough nitrogen, the leaf and root biomass is reduced to respect the C/N ratio. If the leaf and root pool is reduced, the reduction should be added back into the labile pool. This fixed the mass balance closure problem for C in phenology with impose_cn = n.

The model now crashes in year 4 with a mass balance error for N in the soil nitrogen dynamics. We got this bug before. It was then related to negative n mineralization that was not correctly accounted for. The current code tries to capture and remedy negative n_mineralization in stomate_litter.f90 but those checks overlooked one line of code and that is the line that is causing the negative mineralization. Ideally the negative mineralization should be cured in stomate_litter.f90. For the moment it seem simpler to do so in stomate_soilcarbon.f90.

To make sure the mass balance in soilcarbon is closed the module was reduced to just the mass balance check at the beginning and at the end with nod code in between. That worked. The nitrogen dynamics code was then added process by process. The calculation of the mass balance checked was restructured to ensure that the components of the n-cycle were not set to zero within the routine because the components are written to the history files at the end of the routine. In the first approach only zeros were written to the history files. In addition the values for input were overwritten reducing the input to one day per year rather than a daily input. Furthermore, there was an error in the mass balance check for emission (values for the different n-species would overwrite each other rather than getting accumulated). All these issues were fixed and the model was tested for a single pixel with all PFTs for both impose_cn = y and impose_cn = n. The model could run for 35 years without a crash.

In the previous test mineralisation was set to zero. When using the values calculated in stomate_litter.f90 the model crashes on a mass balance error. The way mineralization is accounted for in soil_n_min was correct but the way mineralization, immob and soil_n_min were accounted for in the mass balance check contained some double counting. The problem was rooted in the fact that negative mineralization was accounted for up front (subtracted from soil_n_min) whereas this was not done for positive mineralization. Later in the code mineralisation and immob were added to soil_n_min. In case mineralization was negative, this was the second time it was accounted for. This issue has been fixed. Mineralization, both negative and positive are accounted for up front.

The code was cleaned, compiles in production-mode and tested for impose_cn = y and impose_cn = n. The code ran for 25 years without crashing for a single pixel containing all PFTs. All the above changes are committed in r4087.

[luyssaert]

The ticket was re-opened because this tasks needs to be redone for the merge with the trunk.

[aresovsky]

As of revision 4569, the model can run with IMPOSE_CN=y or IMPOSE_CN=n and results are in line with expectations. Some of the other information in this ticket is duplicated in ticket 332.