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: brodie (IDRIS)
• Modèle: SECHIBA seul, avec 11 couches, sans routage
• Forçage: NCC
• 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:

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:

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 ??

• "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.