Run-off : une histoire de bug

Olivier Marti – juin 2017

Principe du calcul des poids

La méthode MOSAIC

Le calcul des poids de run-off part des poids utilisés pour interpoler les flux de chaleur et d’eau de l’atmosphère à l’océan. Pour ce calcul, j’utilise un petit programme fait maison appelé MOSAIC. MOSAIC calcule la surface commune entre une maille d’atmosphère et une maille d’océan (Figure 1). Le poids est le ratio entre la surface commune et la surface de la maille atmosphère. Le flux d’une maille atmosphère est donc affecté à toutes les mailles océan en dessous, en proportion de la surface intersectée. La méthode est con-servative. Le fichier poids est un ensemble de liens. Un lien est constitué d’une adresse d’origine (numéro de la maille d’atmosphère), d’une adresse cible (numéro de la maille d’océan), et d’un poids .

Figure 1 : méthode de calcul de l’intersection entre les mailles océans et atmosphère. Chaque maille est un polygone défini par huits points : points u, v et f.

Le trait de côte

Une fois ces poids calculés entre les grilles atmosphère et océan, on interpole le masque océanique vers la grille atmosphérique. Le masque océan vaut 1 sur l’océan et 0 sur les points masqués. On obtient donc la fraction d’océan dans une maille atmosphère, qui est utilisée par LMDZ pour définir sa géographie. La géométrie de la côte est donc parfaite-ment identique dans les deux modèles, ce qui permet la conservation des flux même à la côte. Les poids de run-off

La construction des poids pour le run-off se fait en plusieurs étapes.

1. Limitation à la côte

On détermine tout d’abord les points côtiers. Pour l’atmosphère, ce sont les points qui ont une sous-surface océanique non nulle. Pour l’océan, les points qui ont un voisin masqué.

Les liens qui relient des points non côtiers sont supprimés.

2. Normalisation

On procède ensuite à une normalisation des poids restant pour que tout le flux d’une maille atmosphère arrive bien dans une maille d’océan.

3. Extension

ORCHIDEE construit son schéma de routage à partir d’un fichier de rivière à résolution élevé. Ce fichier contient implicitement une côte, et ORCHIDEE va router l’eau jusqu’à cette côte. Dans LMDZ-ORCHIDEE, le trait de côte est celui de ORCA. Certains estuaires profonds comme l’Amazone ou l’Amour ne sont pas représentés. Dans ces estuaires, ORCHIDEE ne route pas l’eau jusqu’à un point côtier. Il faut donc traiter ces soucis. Lors-qu’un point LMDZ est proche de la côte (paramètre dist_atm=400 km), on cherche le point côtier le plus proche, et on crée des liens d’interpolation qui vont de cette maille vers les points océans qui sont sous cette maille côtière. Une phase de normalisation permet la conservation.

La conservation globale

Il reste des points de l’atmosphère qui sont loin de la côte, et dont le run-off n’est routé nul part. Et il y a sur le continent des points de run-off endoréiques comme le Lac Tchad par exemple. Il faut fermer le bilan en eau du modèle, et empêcher ainsi une dérive du niveau marin. On utilise pour cela une fonctionnalité d’OASIS : la conservation globale d’un champ. OASIS calcule l’intégrale du flux sur la grille d’origine (atmosphère) et sur la grille de destination (océan). Il calcule la différence, et corrige ensuite le flux sur la grille de des-tination. La correction est soit additive (ajout d’une valeur uniforme), soit multiplicative (multiplication du champ par une constante). IPSLCM6 utilise une correction additive.

Cette correction globale empêche de diagnostiquer de façon simple les erreurs sur les poids : la conservation est toujours respectées …

Les différentes versions, et leurs bugs

Version 1

IPSLCM5 utilisait le coupleur OASIS 3. Cette version du coupleur ne gère pas de façon native l’orientation sud-nord de la grille LMDZ. Il y a en conséquence des manips dans MOSAIC pour retourner la grille, et générer des fichiers de poids acceptés par OASIS.

IPSLCM6 utilise la version OASIS-MCT qui est plus versatile. Il a fallu revenir en arrière. Un paramètre supplémentaire dans MOSAIC permet de gérer le besoin de retourner la grille. On utilise une valeur différente pour générer des poids pour le ‘vieux’ IPSLCM5 utili-sé par les paléoclimatologues et pour IPSLCM6.

Le bug

Il y avait une erreur dans MOSAIC, et un masque atmosphère était resté dans la mauvaise orientation sud-nord. On appliquait un faux masque terre-océan (inversé nord-sud). Cela masquait certaines rivières, dont l’Amazone.

Version 2

Pour la version 2, on corrige le sens du masque.

Le bug

Pour calculer les poids du run-off, il faut commencer par relire les poids des flux atmos-phère vers océan. Il y avait un bug de lecture dans cette version du code : les poids étaient à zéro. Cependant la phase d’extension fonctionne normalement. On arrive à ce paradoxe : les points à l’intérieur de la terre sont routés vers l’océan, mais pas les points côtiers (Figure 2). L’Amazone est donc correctement routée, mais pas le Nil par exemple !. Figure 2 : points atmosphère dont le run-off est routé directement à la mer. A gauche pour la ver-sion 1, à droite pour la version 2. Les versions 3 et 4 ont les mêmes points routés que la version 1.

Version 3

La version 3 n’a, pour l’instant, pas de bug connu. Les points atmosphères routés vers la mer sont les mêmes que pour la version 1.

A partir de la version 3, on introduit des nouveaux diagnostics dans le monitoring du mo-dèle. En intégrant le run-off sur les points océans sauf les points côtiers, on a une ap-proximation du terme de correction globale apporté par OASIS. On constate qu’il est faible, de l’ordre de 0.03 Sv. Ce terme est à surveiller lors des évolutions du modèle.

Version 4

La simulation préindustrielle CM6010.2-LR-piCtrl-01 se plante à cause d’un débit de run-off très élevé à l’embouchure du McKenzie?. La salinité de surface devient très faible, le Kz de l’océan devient très faible, la couche de surface part en surf et les schémas devien-nent instables. Dans certaines configurations de côte, et selon la façon dont les deux grilles se superpo-sent, il peut arriver que le run-off d’un point atmosphère soit routé vers un seul point océan, avec donc un flux qui peut être fort. Il a donc été décidé d’étaler le run-off sur une bande côtière (dist_oce=150 km). La mé-thode consistant à partir des poids des flux atmosphériques a été abandonnée. La nou-velle méthode fonctionne avec les étapes suivantes :

1. Détermination des bandes côtières

Un point atmosphère est susceptible d’être routé vers la mer s’il est a une distance à la côte inférieure à dist_atm=400 km. La distance à la côte est déterminé en calculant la distance entre le centre de la maille et le point océanique (point T) le plus proche.

Un point océan est susceptible de recevoir du run-off s’il est à moins de dist_oce=150 km de la côte (Figure 3). Voir plus haut la détermination des points cô-tiers océan).

2. Création des liens

Un point atmosphère de la bande côtière est routé vers un point océan de la bande côtière si leur distance est inférieur à dist_atm+dist_oce=550 km.

3. Normalisation

Une fois tous les liens créés, il y a une phase de normalisation pour assurer la conservation.

Diagnostic

Le run-off étant dispersé sur l’océan, le calcul du terme du correction globale de la version 3 n’est plus adapté. On diagnostique ce terme de correction en monitorant le run-off sur un point au milieu de l’océan Pacifique. Figure 3 : points océans recevant du run-off direct d’un point atmosphère. A gauche pour la version 1, à droite pour la version 4. Les versions 2 et 3 sont identiques à la version 1. Figure 4 : points atmosphériques routés (verts) et points océaniques recevant du routage (rouges) pour la version 4 des poids de run-off.