Problem with diag SOIL_P_OX

[jgipsl]

NaN values are found in diagnostic SOIL_P_OX (variable p_O2 in stomate_soilcarbon) after 10years of global offline simulation.

I've started tracking the NaNs but in the mean time, if you have problems with this variable, it can be removed from output files or set prec=8 in field_def_orchidee.xml. Using prec=8 keeps the output in double precision as in the model. Therefor XIOS do not need to make any transformation and NaN values can be written.

[jgipsl]

A 20 years global run, setup FG2 has been done and there was no problem with this variable. Previous bug corrections must have fixed above problem.

[jgipsl]

The error with SOIL_P_OX is seen again using setup SPINUP_ANALYTIC. The error come as soon as the 2nd year, in the end of the year probably because the output is yearly. This is seen in revision 6324 and also 6327.

[jgipsl]

The error can be procuded on following small domain, usine 1MPI:

LIMIT_WEST=-60
LIMIT_NORTH=0
LIMIT_SOUTH=-20
LIMIT_EAST=-40

Using revision 6358, the experiment SPINUP_ANALYTIC using the default set up in CN-CAN (with and without the limits as above) crashes in year 7, tested at irene.

The model crashes, if in mode prod, when XIOS writes SOIL_P_OX as said in the title of the ticket or slightly earlier if using mode debug, because the variable D_s got to high values (floating invalid) in stomate_soilcarbon/nitrogen_dynamics.

I've tracked the bad values, only present at some points (pixel 23 if using the small domain). It comes from evap_bare_lim_ns in diffuco_comb.

Bad evap_bare_lim_ns after diffuco_comb => weird ae_ns in hydrol => weird flux_top => weird rhs => mcl negative => mc negative => tmc negative => swc_pft negative (-3.5) output from hydrol => and then it crashed in nitrogen_dynamics

I've tested 2 solutions/workarounds:

1) After calculation of evap_bare_lim_ns in diffuco_comb, restrain evap_bare_lim_ns in the interval [0,1] as done in hydrol after the calculations.

evap_bare_lim_ns(ji,jst)=MAX(MIN(evap_bare_lim_ns(ji,jst),1.),0.)

2) No code modifications. Set MIN_VEGFRAC=0.001 in run.def. This is the value used in the trunk. The first pixel which crashes has a very small veget fraction and Agnes thought this might be a problem.

In both cases, on the small domain, the model runs successfully. I'm currently testing in global. In both cases as well as the original code, evap_bare_lim_ns becomes higher than 1 at many pixels without crashing the model. It goes as high as ~1000 at some points. But only the original code/setup gives values up to 28000 which crashes the model.

[jgipsl]

After discussion with S. Luysaert, min_vegfrac is set to the same value as in the trunk, done in [6397].

min_vegfrac should not be the reason of the model crashing but it helps in this case the model not to explose.

[jgipsl]

The commit [6465] done on the trunk makes evap_bare_lim_ns stay in the interval [0,1] in diffuco_comb. It is not needed to do evap_bare_lim_ns(ji,jst)=MAX(MIN(evap_bare_lim_ns(ji,jst),1.),0.) anymore in diffuco_comb.

[luyssaert]

The fix committed to the trunk entered ORCHIDEE-CN-CAN in r6470.