Couplé OCC17

Arpege

Problèmes divers:

Bug1: Arret Arpege

***** LFIOUV - KREP= -9, KNUMER= 81, LDNOMM= T, CDSTTO='OLD', LDERFA= T, LDIMST= T, KNIMES= 1, KNBARP=     8 KNBARI=     0
***** LFIOUV - STATUS 'OLD' MAIS LE FICHIER N'EXISTE PAS, UNITE 81       *****
ABOR2 CALLED
***** LFIOUV - STATUS 'OLD' MAIS LE FICHIER N'EXISTE PAS, UNITE 81       *****
ABORT!!   ***** LFIOUV - STATUS 'OLD' MAIS LE FICHIER N'EXISTE PAS, UNITE 81       *****

En fait, Arpege essaie de lire le fichier sur le HOME.

Solution: il NE FAUT PAS faire de lien symbolique dans les fichiers d'entree mais des copies. Sinon, mpirun est tout perturbe. D'autre part, la premiere instruction a faire dans un programme MPI, c'est MPI_Init. Tout ce qui est fait avant (donc l'ouverture des fichiers qu'il ne trouve pas) est MAL. Donc, on ajoute MPI_Init a hauteur de la routine sumpini.F90

Bug 2: Valeurs erronees d'albedo
dans Arpege

La clefs LMCC02 n'est plus operante. Du coup, les points englaces (selon le fichier de climatologie) sont consideres comme points terre dans updcpl et gardent les valeurs qui sont definies dans updcli.

Solution: on ajoute une clef LMCC02 dans updcli

Couplage des courants:

On implémente le couplage des courants de surface (modifications faites par Jean-François Guérémy sur Arpege 3) et on teste le modèle sur un mois avec des champs nuls. Les sorties doivent être rigoureusement les même qu'avant la modification des codes:

On continue en effectuant maintenant le couplage des courants sur un an, départ de Lévitus au repos.

Au bout d'un an de run, voici les différences entre run avec et run sans couplage des courants:

Sur la grille d'OPA, les vecteurs sont représentés dans un repère local (dans Arpege, c'est un repère géographique). Il faut donc changer de repère (rotation) lorsqu'on passe d'une grille à l'autre. C'est fait dans OPA lors de la réception des champs de vent, mais pas dans Arpege pour les courants.
On utilise donc la routine d'Oasis rotations.f90 en modifiant la namcouple comme suit:

BICUBIC LR VECTOR_I LATLON 10 SOVOCEAN pour le courant zonal

BICUBIC LR VECTOR_J LATLON 10 SOUOCEAN pour le courant méridien

On essaie de valider l'interpolation. On se sert pour cela de deux champs analytiques. Un champ constant (U=1, V=1) et un champ variant en sinus de la longitude.
On ne valide que l'interpolation de la norme du vecteur. En effet, la validation de la conservation de l'angle nécessiterait de créer un champ de départ (sur la grille ORCA) en tenant compte de la rotation du repère local. Si un tel champ test existe, merci de me l'envoyer.
On trace la différence entre la norme sur la grille analytique et la norme obtenue après passage dans l'interpolateur, rapportée à la norme sur la grille analytique. C'est ce résultat qui est décliné dans les liens décrivant les 2 problèmes rencontrés:

Problème 1: Celui-ci apparaît lors de la visualisation des interpolations du champs constant : la rotation crée une erreur à la ligne de recouvrement du pôle:
Interpolation Bicubique sans rotation de vecteur
Interpolation Bicubique avec rotation de vecteur C'est mieux avec les bons (?!) fichiers d'angles des grilles U et V : Interpolation Bicubique avec rotation de vecteur
L'interpolation choisie ne semble pas en cause. L'interpolation CONSERV fait apparaître d'autres problèmes: Interpolation Conserv

Problème2 : Avec des champs différents sur les grilles U et V, un autre problème se pose: après la rotation, Oasis interpole le champ de la grille V sur la grille U, d'où dégradation du champ aux Tropiques. Mais cette dégradation est minime et inférieure à celle provoquée par le recours au plus proches voisins pour l'interpolation BICUBIC aux côtes. On peut faire un EXTRAP, mais celui-ci ne marche pas pour la composante V dans le cas d'une rotation (on retombe sur des plus proches voisins après la première interpolation de la grille U vers V).
Interpolation Bicubique sans rotation de vecteur
Interpolation Bicubique avec rotation de vecteur
Interpolation Bicubique sans rotation de vecteur plus extrap
Interpolation Bicubique avec rotation de vecteur plus extrap

Solution envisagée: refaire un MOZAIC un mozaic pour les grilles U et V. Voilà le résultat si on utilise le mozaic de la grille T ... catastrophique à cause du shift d'un demi point de grille. Reste que l'estimation de ce que donnerais un nouveau mozaic sur U et V (en prenant deux composantes sur la grille T) n'est guère plus brillant que notre BICUBIC ...

Les fichiers d'angles pour les grilles U et V sont disponibles sur le site: tar.gz

Petit détail: sur l'Arctique, il y a de la glace. Est-ce que ça a un sens de passer à l'atmosphère des courants océaniques quand ceux-ci ne sont pas vus par l'atmosphère ?
Solution: passer aussi la vitesse de la glace ... et pondérer par la surface englacée.

Résultat: quasiment pas d'impact mais c'est plus correct d'un point de vue formel (pour ce qu'on en sait !)

-------------------------------------------------------

Version multiprocesseur Kali:

Etat des lieux:
sur PC, version qui tourne sur 2 PC, ou 1PC et plusieurs process, mais pas sur plus de 2 PCs. (/home/evian/eric/ArpegePC/kali)
sur kali, version qui tourne en multiproc en version t63 et t159 (/home/maisonna/Arpege/4_4/compile.sh). Reste un bug dans SAFO en t159.

scan2mdm.F90 modifiée pour les Norvégiens semble marcher ! (/home/maisonna/Arpege/4_4/sources_completes/libtest)

Reste à faire:
tester la version stratosphérique