| | 11 | |
| | 12 | === August 4th, 2016 === |
| | 13 | * The solution to the problem with '''thermosoil_cond_pft''' was committed in r3699. |
| | 14 | * More on the '''negative soil carbon values''' |
| | 15 | Albert has continued to track back the problem of negative carbon soil coming from unrealistic low temperatures. The problem is linked to the use of the veget_max_bg variable which is present in thermosoil(c).f90 and stomate_permafrost_soilcarbon.f90. There is no such variable in the TRUNK. |
| | 16 | |
| | 17 | It is defined as: |
| | 18 | {{{ |
| | 19 | veget_max_bg(:,2:nvm) = veget_max(:,2:nvm) |
| | 20 | veget_max_bg(:,1) = MAX((un - SUM(veget_max(:,2:nvm), 2)), zero) |
| | 21 | }}} |
| | 22 | |
| | 23 | and used notably in thermosoil_coef where soilflx is computed. |
| | 24 | |
| | 25 | The problem is that this variable basically get rid of frac_nobio, putting it into the bare soil fraction. So this is completely incoherent with all enerbil/explicisnow/... that use only veget_max. |
| | 26 | |
| | 27 | We may not have seen this problem before because we had no pixels with frac_nobio, however the TRENDY maps have pixels with frac_nobio (Ye, you changed revision number when your problem appeared but you also used a new PFT map which maybe has pixels with frac_nobio?) |
| | 28 | |
| | 29 | Does someone know where this veget_max_bg originates from? |
| | 30 | |
| | 31 | My idea is that we have to remove it, use veget_max and treat pixels with frac_nobio properly. |
| | 32 | |
| | 33 | Albert is doing such tests, to see if we can go on with the TRENDY spinup. |
