wiki:DevelopmentActivities/MergeHydro/Matthieu_notes_on_merge

See first notes in Doc_ORC_merge_21-06-2011.doc​.

Matthieu notes for the merge

TESTS DE LA VERSION MERGE-HYDRO

Simulation sur le bassin de l'Amazone et du Mississippi

Configuration:

  • Machine: vargas (IDRIS), parallèle
  • Modèle: SECHIBA sans STOMATE, avec routage
  • Forçage: NCC 1°x1°
  • Période temporelle simulée: 1975-2000

Un bug est survenu dès le début de la simulation sur l'Amazonie quand on met le check_CWRR à TRUE. Le découpage de la précipitation au sol (precisol) entre les 3 différents tiles (precisol_ns) ne se fait pas bien. Precisol_ns est toujours inférieur à precisol.

commentaire de Martial : après vérification, ce problème de SPLIT precisol_ns survient aussi dans la version de Matthieu (avec autre forçage - WG 4° global, sur deux jours).
Nous avons donc discuté avec Matthieu pour analyser les convolutions/déconvolutions des corr_veg_soil / soiltile dans hydrol.

Pour information: Le test du découpage en question se situe entre les lignes 3942 et 3979. Le découpage se situe entre les lignes 3827 et 3837.

Pour l'instant je ne vois pas ce qui pose problème. Rq: Je m'étonne que l'on fasse intervenir ae_ns (évaporation du sol nu par tile) dans le test qui vérifie le découpage de la precip au sol.

24/01/2012

  • Problème de SPLIT precisol_ns corrigé.
  • Quelques bugs à corriger quand on active le routage:
    • mettre getin au lieu de getin_p dans CALL getin_p('RIVER_DESC', river_file) et CALL getin_p('RIVER_DESC_FILE', river_file_name)
    • 31/01/2012: initaliser à FALSE le logique err_basin_number

01/02/2012 Essai sur 15ans d'une simulation SECHIBA+routage (sans floodplains ni irrigation)

  • Le modèle tourne bien, avec tous les flags de vérification activés (waterbal, flags pour vérifier la construction des bassins versants ...)
  • Problème de sous-estimation de l'évapotranspiration totale. En ordre de grandeur, voici les valeurs en moyennes sur le bassin amazonien de l'ET et de ses composantes (en mm/an):
    • evap: 500
    • interception loss: 350
    • transpir: 10
    • evapnu: 140
  • Pour comparaison, voici les valeurs des mêmes variables pour une simulation que j'avais faite avec "ma" version d'ORCHIDEE lors de mon postdoc au LOCEAN (c.a.d. version avant le mergehydro). Rq: même forçage (NCC) pour les 2 simuls:
    • evap: 1030
    • interception loss: 440
    • transpir: 460
    • evapnu: 130
  • L'évap est donc sous-estimée dans la version actuelle du mergehydro (evap "observée" de l'ordre de 1200 mm/an) à cause d'une transpiration quasi-inexistante.
  • Le problème se situe au niveau du calcul des vbeta2, vbeta23 et vbeta3.

Pour aller plus loin, j'ai fait 2 simulations sur 5 jours au pas de temps de 30min. Elles sont toutes deux issues de la même version (mergehydro). Seul le calcul des vbetas diffèrent entre les 2 simuls.

Résultats donnés à Manaus. Voir figure: https://forge.ipsl.jussieu.fr/orchidee/attachment/wiki/Branches/MergeHydro/diag_transpir.png

Légende:

  • "Merghy svn": avec le calcul original des vbetas dans la version mergehydro
  • "Merghy Tristan": avec le calcul des vbetas d'après Tristan d'Orgeval dans la version mergehydro

A priori, les 2 calculs sont sensés représenter un même concept. Mais ils divergent à mon sens:

  • "Merghy svn": à chaque fois que le flux intégré de l'interception est > à qsintveg, la transpiration est déclenchée. Mais ce cas arrive très rarement voire jamais dans cet exemple. Voir dernier graphe de cette figure:https://forge.ipsl.jussieu.fr/orchidee/attachment/wiki/Branches/MergeHydro/diag_transpir2.png

Le beta de l'interception est calculé sur la partie mouillée de la feuille. Mais celui de la transpiration n'est plus calculé sur la partie restante de la feuille. Pourquoi ?? La première partie du calcul du vbeta3 est commentée!

  • "Merghy Tristan": à chaque fois que le flux maximal au niveau de la feuille n'est pas satisfait par le flux d'interception, la transpiration est déclenchée (c'est bien ce que l'on voit quand on compare les courbes bleues des 2 premiers graphes). Le beta de l'interception est calculé sur toute la feuille.
  • Conclusion: n'est-ce-pas une erreur de commenter la première partie de calcul du vbeta3 de la version svn? Du coup, cela expliquerait pourquoi on ne fait pratiquement plus de transpiration !!: 
            !vbeta3(ji,jv) = veget(ji,jv) * (un - zqsvegrap(ji)) * humrel(ji,jv) * &  
            !     (un / (un + speed * q_cdrag(ji) * (rveg_pft(jv)*(rveget(ji,jv) + rstruct(ji,jv)))))
            vbeta3(ji,jv) = vbeta3(ji,jv) + MIN( vbeta23(ji,jv), &
                 veget(ji,jv) * zqsvegrap(ji) * humrel(ji,jv) * &
                 (un / (un + speed * q_cdrag(ji) * (rveg_pft(jv)*(rveget(ji,jv) + rstruct(ji,jv))))))

02/02/2012

  • Test en décommentant la première partie du calcul du vbeta3 de la version svn: 
                vbeta3(ji,jv) = veget(ji,jv) * (un - zqsvegrap(ji)) * humrel(ji,jv) * &  
                 (un / (un + speed * q_cdrag(ji) * (rveg_pft(jv)*(rveget(ji,jv) + rstruct(ji,jv)))))
            vbeta3(ji,jv) = vbeta3(ji,jv) + MIN( vbeta23(ji,jv), &
                 veget(ji,jv) * zqsvegrap(ji) * humrel(ji,jv) * &
                 (un / (un + speed * q_cdrag(ji) * (rveg_pft(jv)*(rveget(ji,jv) + rstruct(ji,jv))))))

Figure des résultats: https://forge.ipsl.jussieu.fr/orchidee/attachment/wiki/Branches/MergeHydro/diag_transpir1_ok.png
Légende:

  • "Merghy svn": avec le calcul original des vbetas dans la version mergehydro
  • "Merghy Tristan": avec le calcul des vbetas d'après Tristan d'Orgeval dans la version mergehydro
  • "Merghy svn ok": avec le calcul original des vbetas dans la version mergehydro en décommentant la première partie du calcul du vbeta3

La figure montre bien que l'on récupère une transpiration (courbe rouge) "proche" de celle que l'on avait avec le calcul de Tristan (courbe bleue). Le commentaire était bien un bug. Je commite cela. Rq: la partition interception/transpiration est un peu différente au pas de temps du modèle entre les deux calculs. L'ET totale est, au final, quasi la même...

07/02/2012

  • Simulation sur Manaus pour comparer l'interception loss/transpiration.

Figure des résultats: https://forge.ipsl.jussieu.fr/orchidee/attachment/wiki/Branches/MergeHydro/com_beta3_shutt_mergehydro.png
Légende:

  • "Merghy Tristan": avec le calcul des vbetas d'après Tristan d'Orgeval dans la version mergehydro
  • "Merghy svn ok": avec le calcul original des vbetas dans la version mergehydro
  • "REGYNA": avec ma version d'ORCHIDEE utilisée pour mon post-doc au LOCEAN (incluant le calcul des vbetas d'après Tristan d'Orgeval)

08/02/2012

  • Simulation sur le bassin amazonien avec routage+floodplains+swamps activés (ainsi que tous les flags d'hydrol et routing). Forçage NCC.
    • Arrêt de la simulation suite au test dans hydrol_soil_flux: 'Problem in the water balance, qflux computation'
  • Interprétations (Matthieu Guimberteau+Aurélien Campoy+Martial Mancip):

Ce test vérifie si le flux en haut de la colonne de sol calculé à deux instants différents (qflux00 et temp) est conservé après le schéma de diffusion. Dans notre simulation, qflux00<temp. 

          qflux00(ji,jst) = mask_soiltile(ji,jst) * &
               & (MIN(tmcs(ji,jst),tmc(ji,jst))-tmcint(ji)+SUM(rootsink(ji,:,jst))+dr_ns(ji,jst)-returnflow_soil(ji))

Rq: dans le code, returnflow_soil est nul. Le returnflow est mis dans reinfiltration_soil. 

          returnflow_soil(ji) = zero
          reinfiltration_soil(ji) = (returnflow(ji) + reinfiltration(ji))/vegtot(ji)
          irrigation_soil(ji) = irrigation(ji)/vegtot(ji)

       temp(ji) =  qflux(ji,1,ins) + (dz(2,ins)/huit) &
            &  * (trois* (mc(ji,1,ins)-mcint(ji,1)) + (mc(ji,2,ins)-mcint(ji,2))) &
            &  + rootsink(ji,1,ins)

La raison pour laquelle nous sommes dans ce cas est la suivante: nous sommes dans la situation où toute la colonne de sol est saturée: tmc>tmcs. Or, une précaution a été prise dans le calcul de qflux00. On y calcule la variation d'eau dans la colonne de sol entre le contenu en eau au début du pas de temps borné par la saturation, et celle à la fin du pas de temps. Dans le calcul de temp, cette précaution n'est pas prise d'où une différence que l'on peut avoir entre qflux00 et temp lorsque tout le contenu en eau du sol dépasse la saturation.

  • Analyse du code (Matthieu Guimberteau+Aurélien Campoy):

Suite à ce problème, la question que l'on se pose est la suivante: pourquoi se retrouve-t-on dans une telle situation où tmc>tmcs?
Cette situation se produit dans notre cas quand on active les plaines d'inondations et par conséquent la réinfiltration de l'eau de ces plaines dans le sol. Dans la version merghydro, l'eau qui se réinfiltre depuis les plaines d'inondation (reinfiltration_soil) est rajoutée à la première couche de sol qui peut se retrouver alors au-dessus de la saturation. La subroutine hydrol_soil_smooth répartit l'excès d'eau dans les autres couches plus profondes si possible. Si toutes les couches se retrouvent saturées, l'excès d'eau restant est stockée dans la première couche et part en priorité en évaporation. Mais il semble que dans notre cas, l'évaporation ne soit pas suffisante pour ramener l'humidité sous la saturation.

  • Propositions de modifications (Matthieu Guimberteau+Aurélien Campoy):

On peut donc re-réfléchir à la façon dont on rajoute au sol l'eau provenant des plaines d'inondation (donc du routage). Nous avons pensé qu'il serait plus judicieux que l'excès d'eau reparte en ruissellement de surface si le sol ne peut pas la stocker. Or, depuis la thèse de Tristan d'Orgeval, l'infiltration d'un front saturé est décomposé « en calculant le temps que met chaque couche successive à se saturer et la quantité de ruissellement produite pendant ce temps. » Nous avons trouvé judicieux de rajouter l'eau des plaines d'inondation qui s'infiltre à la variable water2infilt, c'est à dire l'eau (precisol) qui reste à infiltrer dans le sol. De cette manière, si c'est possible, cette quantité d'eau s'infiltre et sature progressivement les couches du sol sinon elle ruisselle évitant de faire appel à la subroutine hydrol_soil_smooth.

  • Simulation identique à la précédente mais en intégrant dans le code les modifications proposées.
  • Simulation réalisée avec succès sur 15 ans avec tous les flags activés. Les ordres de grandeurs des composantes du cycle de l'eau semblent correctes.

14/05/2012

Résultats de comparaison des résultats sur le bassin de l'Amazone:

  • entre l'ancienne version hydro et la nouvelle
  • activation de STOMATE => quel effet sur l'hydrologie?
  • avec des observations, estimations...

Présentation: ​http://www.sisyphe.upmc.fr/~guimberteau/docs/1205_tests_mergehydro.pdf

21/05/2012

Résultats de comparaison avec la version hydrologique 2 couches Choisnel (avec hydrolc_flood ajoutée (modification commitée))

​http://www.sisyphe.upmc.fr/~guimberteau/docs/1205_tests_mergehydro_2.pdf

23/05/2012

Détails des corrections de bugs commitées:

​https://forge.ipsl.jussieu.fr/orchidee/attachment/wiki/Branches/MergeHydro/Matthieu_notes_on_merge/commit_23052012.pdf

Last modified 12 years ago Last modified on 2012-05-23T18:06:56+02:00

Attachments (2)

Download all attachments as: .zip