Opened 4 years ago

Last modified 14 months ago

#404 accepted defect

Weird veget value for ibare_sechiba

Reported by: maignan Owned by: maignan
Priority: major Milestone: Not scheduled yet
Component: Biogeochemical processes Version: trunc
Keywords: Cc:

Description

In slowproc_veget, we have:

1466	    !! 2. Calculate veget
1467	    !!    If lai of a vegetation type (jv > 1) is small, increase soil part
1468	    !!    stomate-like calculation
1469	    DO ji = 1, kjpindex
1470	       veget(ji,1)=veget_max(ji,1)
1471	       DO jv = 2, nvm
1472	          veget(ji,jv) = veget_max(ji,jv) * ( un - exp( - lai(ji,jv) * ext_coeff_vegetfrac(jv) ) )
1473	       ENDDO
1474	    ENDDO

Because there is no vegetation on bare soil, we should logically rather have:

1470	       veget(ji,1)=0.

In slowproc_checkveget, we further have:

3891	          IF ( jv == ibare_sechiba ) THEN
3892	             IF ( ABS(veget(ji,jv) - veget_max(ji,jv)) > epsilocal ) THEN
3893	                WRITE(str1,'("This occurs on grid box", I8)') ji
3894	                WRITE(str2,'("The difference is ", E14.4)') veget(ji,jv) - veget_max(ji,jv)
3895	                CALL ipslerr_p (3,'slowproc_checkveget', &
3896	                     "veget is not equal to veget_max on bare soil.", str1, str2)
3897	             ENDIF
3898	          ELSE

I really don't understand what is the motivation behind this. I find it prone to bugs when I expect to have veget to be zero for bare soil and sum over all PFTs with this expectation and thus end with erroneous results.

Change History (6)

comment:1 Changed 4 years ago by aducharne

J'ai vérifié dans toutes les routines de sechiba sauf chemistry.f90 (Juliette, tu peux regarder ?)

Tout le semble cohérent avec la définition utilisée.

Seule exception, peut-etre, dans slowproc_interpol, L2295, mais il faut qu'un spécialiste des cartes regarde.

Dans la même routine, je pense que ce qui est codé L3728 et 3731 risque de ne pas marcher si on change pour veget(ji,1) = 0.

CL: hormis le point ci-dessous sur slowproc interpol, je pense que le code fait ce qu'il doit, avec la définition actuelle de veget(ji,1) = veget_max(ji,1). Ce n'est pas intuitif si on voit veget comme la fraction de vegetation, mais tout changer juste avant CMIP6 me semble super dangereux !!! Je vote contre.

comment:2 Changed 4 years ago by lathiere

Vérification faite dans chemistry.f90, pas de problème à relever.

comment:3 Changed 4 years ago by maignan

  • Milestone set to ORCHIDEE 3.0
  • Owner changed from somebody to maignan
  • Status changed from new to accepted

Je suis d'accord pour ne pas faire de modification avant CMIP6.
Quelle est l'autre interprétation de veget si ce n'est la fraction de végétation ?

Dans ORCHIDEE-ICE j'ai changé juste les lignes indiquées et le bilan d'eau au moins est correct.
Je ne suis pas surprise que tout soit cohérent dans l'état actuel sinon ce problème aurait été identifié avant.
La modification proposée permettrait probablement de simplifier le code en cessant de traiter le sol nu à part dans les boucles impliquant veget.

comment:4 Changed 4 years ago by aducharne

Avec l'usage actuel, veget est la fraction "effective" du type de surface donné par le PFT: de la vegetation pour les PFT 2 à 13, et du sol nu pour la PFT1.
Au fond, on pourrait dire que le mauvais terme est PFT sachant qu'il n'y a pas de "plant" dans la PFT1.

comment:5 Changed 2 years ago by maignan

  • Milestone changed from ORCHIDEE 3.0 to ORCHIDEE 4.0

comment:6 Changed 14 months ago by luyssaert

  • Milestone changed from ORCHIDEE 4.0 to Not scheduled yet
Note: See TracTickets for help on using tickets.