wiki:DevelopmentActivities/CMIP6/DevelopmentsCMIP6/hydric_stress

Version 17 (modified by pmaugis, 2 years ago) (diff)

maj thèse Samir Meridja

Stress hydriques dans ORCHIDEE : synthèse des problemes actuels

Les différents stress hydriques du modèle

Ci dessous un résumé par Nicolas Viovy (relativement ancien: 2009) des stress hydriques calculés dans ORC :

  • Pour la photosynthèse/transpiration: HUMREL

On calcule tout d'abord un stress comme la convolution de l'eau du sol dans chaque couche avec le profil racinaire (exponentiel) dont le coefficient varie avec le PFT. On normalise par le résidu de l'exponentiel au "fond" du sol pour que la somme fasse 1. Ensuite on applique une deuxieme fonction waterlim=MIN(stress*2,1) qui vaut donc 1 lorsque ce stress est supérieur à 0.5 et qui décroit jusqu'à 0 lorsque le stress passe de 0.5 à 0. cela permet de simuler le fait qu'il n'y a pas de fermeture stomatique tant que le sol reste modérément humide et décroit ensuite rapidement. Autre chose: en condition de sol sec, lorsqu'il pleut même assez faiblement, mais suffisemment pour humidifier les couches de surface, les plantes ouvrent leurs stomates et les referment dès que l'eau en surface est reasséché. Dans l'hydro Choinesl c'étati assez simple puisqu'il suffisait de calculer le stress pour la couche de surface et de fond et de prendre le minimum des deux. C'est un peu plus compliqué avec le modèle à 11 couches... (a implémenter?)

  • Pour la decomposition du carbone sol: shumdiag

La aussi on convolue l'eau du sol avec une exponentielle pour simuler le fait que la densité de carbone décroit avec la profondeur. Par contre il n'y a pas la d'effet de seuil comme pour la photosynthèse. La fonction de réponse de la decomposition est une courbe en cloche minimale au WP et maximum au FC. Par contre elle décroit ensuite quand on va de la capacité au champs vers la saturation du fait du passage d'une décomposition aérobie à une décomposition anaérobie. Dans le 2 couche cela n'était pas possible à simuler par contre ca doit être possible avec le 11 couches. Il faudrait la aussi voir comment l'utiliser.

  • Pour la phénologie: vegstress

On utilise un seuil ou une dérivée d'acrroisement de l'eau du sol. Le stress est à calculer en utilisant la convolution de l'eau du sol avec le profil racinaire mais sans prendre en compte l'effet seuil du "waterlim"

  • Pour les feux:

Il y a l'humidité de la litière qui est calculée pour définir la fréquence de feux de LPJ. Il s'agit de prendre en compte l'humidité des première couches de sol (profondeur à définir).

Problemes identifiés du stress pour la photosynthèse / transpiration

Agnes après investigation de Hydrol, puis discussion avec Nicolas Viovy et Vuichard a pointé plusieurs incohérences et potentiels bugs. Ci dessous, quelques échanges d'emails concernant les problèmes soulevés:

  • Résumé du problem par Nicolas Vuichard avec commentaires additionnels de Nicolas Viovy et Agnes+Mathieu

Le stress hydrique est calculé comme décrit dans la figure 6 du doc d'Agnès http://forge.ipsl.jussieu.fr/orchidee/raw-attachment/wiki/Documentation/UserGuide/eqs_hydrol.pdf. Cette fonction est non continue au point de flétrissement et sature à 1 avant d'arriver à la capacité au champ (elle vaut 1 à partir de la moitié de la teneur en eau à saturation). Cette fonction est non linéaire du fait de l'utilisation d'une racine carrée. Cette fonction est calculée par couche, et une convolution de cette fonction avec le profil racinaire est réalisée pour calculer un stress sur l'ensemble de la colonne de sol, tel que vu par l'ensemble des racines. On a besoin de 3 fonctions de stress dans ORCHIDEE:

  • une pour la photosynthèse/transpiration (humrel);
  • une pour la phénologie et autres processus en rapport avec la végétation (nommé aussi humrel dans stomate, mais qui correspond à la variable vegstress côté sechiba, je l'appelle vegstress par la suite)
  • une autre pour la décomposition de la matière organique (shumdiag)

Les deux premières doivent être convoluées avec le profil racinaire, la dernière non.

  • Nicolas Viovy: Oui à ceci près que pour la décomposition, dans l'avenir, quand on aura une discrétisation verticale du carbone sol il faudra la convoluer avec celle ci. Mais pour l'instant le profil racinaire peut aussi être considéré comme un proxy de la densité de carbone du sol et que donc dans un premier temps on pourrait alors pour shumdiag utiliser aussi la convolution avec le profil racinaire (ce qui est fait actuellement dans le 2 couches). Et donc dans les fait on aurait humrel=shumdiag Sachant qu'il vuat mieux garder les 2 puisque à terme il devraient devenir différents !

Ce que l'on souhaite, je pense, pour vegstress, c'est une fonction qui varie linéairement de 0 à 1 entre le point de flétrissement (wp) et la capacité au champ (fc).

Etes-vous d'accord pour que humrel soit une fonction qui varie linéairement de 0 à 1 sur le domaine [wp; (wp+fc)/2] ?

  • Agnes: Oui, si on corrige pour [wp; wp+(fc-wp)/2] (je crois)

A noter qu'on trouve aussi de la littérature indiquant que humrel atteint 1 à wp + 0.75 ou 0.8 de (fc-wp) mais ce serait super d'en profiter pour faire dépendre fc et wp de la texture.

Dernière question concernant humrel: Pour l'instant, le "seuillage" à 1 sur la moitié du domaine de validité de la fonction est effectivement fait 2 fois: une fois dans diffuco à partir du stress moyen intégré sur la colonne de sol et une fois dans hydrol lors du calcul du stress pour chacune des couches de sol. Sachant qu'il ne faut en garder qu'un, où applique-t-on le seuillage ? Sur la fonction définie pour chacune des couches (us_tmp) dans hydrol ou sur le stress intégré sur la colonne de sol (c'est à dire vegstress). De ce que je perçois, appliquer le seuillage en amont sur chacune des couches aboutit à un stress plus fort qui si on l'applique sur la fonction intégrée sur la colonne de sol.

  • Nicolas Viovy: En y réfléchissant, je pense qu'il vaudrait peut être mieux appliquer la fonction sur le humrel intégré. Il faudrait que je refasse un peu de biblio la dessus pour voir le sens exact de cette formule d'un point de vu physio mais de ce que je me rappelle c'est quand même une réponse globale de la plante qui commence à fermer ces stomates quand son potentiel hydrique devient "critique" (i.e risque de cavitation). Dans ce cas je pense que ça n'a pas trop de sens de l'appliquer à chaque niveau du sol car ce n'est pas une réponse racinaire. C'est un peu plus compliqué car si il n'y a pas de mécanisme qui permette à la plante de réguler son débit au niveau racinaire instantané, sur une échelle plus longue de quelques jours il y a en réalité un effet indirect via le développement du réseau racinaire qui va se densifier la ou il y a de l'eau et se raréfier la ou il n'y en a pas, donc ça va jouer effectivement sur l'eau puisée à chaque niveau ce qui était d'ailleurs peut être la raison d'être de l'intégration de la fonction de stress au niveau de chaque niveau de ce que j'ai cru comprendre de notre discussion Agnès ?). Mais dans la mesure ou pour l'instant on n'a pas de représentation dynamique du profil racinaire, ça n'a pas trop de sens de le considérer non ?
  • Agnes: Est-ce que ça a à voir avec water_lim? (ou vegstress est encore modifié)

En tout cas, il me semble qu'il faut garder la coherence entre us et humrel, qui doit etre la somme des us, pour que bilan d'eau et d’énergie restent cohérents.

  • Réponse Nicolas: pour répondre à ton dernier point oui ça a bien rapport avec le water_lim et donc la question de Nicolas était de savoir si on garde le calcul qui est fait dans hydrol ou le stress calculé à chaque niveau (us d'après ce que j'ai compris) qui varie linerairement entre [wp; (wp+fc)/2] et dans ce cas il faut supprimer le calcul de water_lim qui est remplacé directement par humrel soit us varie simplement linéairement entre wp et wp+fc et on maintient le waterlim... dans tous les cas humrel reste la somme des us. Par contre je réalise que dans ce cas ça ne pose pas de problème lorsque ok_co2 est activé puisque le calcul de waterlim qui prend en compte l'effet seuil est pris en compte dans diffuco_trans_co2 et donc sur la transpiration. Par contre ça pose un problème si ok_co2 n'est pas activé car dans ce cas diffuco_trans ne proend pas en compte ça ! il faudrait alors le rajouter dans diffuco_trans....
  • Complément d'information sur la parti "Diffuco" par Agnes et Mathieu:

Voici la ligne qui relie humrel et water_lim dans diffuco_trans_co2, sachant que water_lim intervient pour définir vc2, vj2, et Rd (mais pas fvpd):

Calculates the water limitation factor. water_lim(:) = MAX( min_sechiba, MIN( humrel(:,jv)/0.5, un ))

Si on n'aime pas trop les manières compliquées d'écrire un truc simple, on peut réécrire la ligne ci-dessus comme:

water_lim(:) = MAX( min_sechiba, MIN( humrel(:,jv)*2., un ))

Ce que cette ligne implique, c'est que water_lim=1 dès que humrel>0.5, ce qui, dans le cas particulier d'un profil d'humidité constant dessiné dans ma note, se produit tout le temps dès que mc> mcw.

Sinon, si l'on veut faire des corrections, je pense qu'elles doivent être faite directement dans hydrol au niveau de us, dont la somme humrel est transmise à diffuco. Pour que les rootsink soient cohérents avec la transpiration, on a besoin que le stress "global" humrel soit la somme exacte des us (cf subroutine hydrol_split_soil).

  • Information complémentaires (par Mathieu): Thèse de Samir Meridja avec Alain Perrier en 2013.

Voir en attaché un passage de la thèse traitant du problème: these_meridja_STRESS.pdf or complete version on HAL

Problème identifié du stress pour la photosynthèse en lien avec le gel du sol

  1. Maignan, le 18/09/2016
  1. Ducharne le 20/09/16

Je n'ai pas trouvé de problème dans l'examen du code hydrol.f90 relatif aux variables humrel et humrelv. Sachant que le stress semble être trop fort selon les diagnostics produits par Vlad ici https://orchidas.lsce.ipsl.fr/dev/freeze.php, je relève les points de la discussion précédente : N. Vuichard mentionne que la fonction de stress appliquée à chaque couche (solution actuelle retenue) donne un stress plus fort que la fonction de stress appliquée sur la colonne. N. Viovy pense que ça a moins de sens d'appliquer un stress par niveau (c'est également mon avis). Il faudrait donc appliquer la fonction de stress à vegstress comme c'était fait précédemment dans diffuco_trans_co2 avec water_lim (ce calcul peut être fait dans hydrol).

Perso, j'ai un peu de mal à comprendre la solution proposée, c'est possible d'avoir qq équations ? Mais sur le principe, je n'ai rien contre si ça garantit bien que l'on ne peut pas prendre plus d'eau dans une couche que ce qu'elle contient.

  1. Vuichard 20/09/16

J'étais aussi en faveur d'une fonction de stress 'intégrée', mais quand on a repris cela avec Agnès, on a tout de même été sensible à l'argument avancé par Agnès, à savoir ne pas prendre plus d'eau que ce qu'une couche contient (voir en particulier ces lignes de code: https://forge.ipsl.jussieu.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/hydrol.f90#L6274).

A noter aussi qu'il pourrait être utile de "relaxer" la pente très raide du stress hydrique, comme dans Baker et al. 2008 dans SiB3.

  1. Maignan, le 20/09/2016

Oui, ton document montre bien que le stress est devenu plus fort en passant de Choisnel à CWRR.

Je note au passage un bug sur vegstress : dans hydrol_diag_soil on somme les vegstressv sur les jst sans les avoir pondérés précédemment par mask_soiltile. Si vous confirmez, je peux faire le ticket et le commit correspondants. On peut ensuite déjà rajouter vegstress et water_lim dans les diagnostiques pour comparer à humrel.

Bien vu. Si possible, appliquer le mask_soiltile au meme endroit que pour humrel, en step 1 de hydrol_diag_soil

Ce n'est pas vraiment un bug dans le sens où on a ces lignes de code (https://forge.ipsl.jussieu.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/hydrol.f90#L4684), mais c'est sûr que tout cela est ultra bugogène. On a en tête de reprendre toutes ces variables (vegstress, humrel,...) qui sont définies par PFT et par soiltile, alors que dans le code chaque PFT ne peut émarger qu'à un seul soitile. En d'autres termes, on peut se passer de la dimension 'soiltile' pour ces variables, ce qui simplifierait grandement le code.

Tu as raison, pas de bug. Je suis d'accord aussi pour la suppression de la dimension soiltile.

Attachments (1)

Download all attachments as: .zip