This is a page which can contain reports from other specific meetings about ORCHIDEE

---

Réunion 04/07/2013 : Bilan réunion Couplage ORCHIDEE - ATM via OASIS

Présents : Jan Polcher, Marc Stéfanon, Yann Meurdesoif, Arnaud Caubel, Anne Cozic, Philppe Peylin, Josefine Ghattas

Objectif : D'analyser l'intérêt pour le groupe ORC d'un potentiel couplage ORC-LMDz via OASIS et/ou de l'utilisation de OASIS pour faire des simulation en mode forcé.

Marc à présenté l'état du couplage ORCHIDEE-WRF via OASIS-MCT (la dernière version d'OASIS); nous avons ensuite discuté des bénéfices et inconvénients d'une approche avec OASIS. Voir ici ​la présentation de Marc.

• Potentiel avantages d'OASIS:
  • Tout d'abord OASIS permet de lancer deux exécutable (ORCH et le modèle d'atmosphère), ce qui permettrait à terme de "de-synchroniser" les modèles et donc d'avoir ORC qui fait certain calculs après avoir retourné au modèle d'atmosphère les champs du bilan d'eau et d'énergie. Yann mentionne que cela n'a de réel intérêt que si le cout calcul de ORC est significatif par rapport a celui de l'atmosphère
  • Si l'on considère 3 modèles (ORC, ATM, OCEAN) alors OASIS peut simplifier les couplages 2 à 2 sans avoir à passer par le modèle d'atmosphère pour envoyer le routage de l'eau à l'océan.
  • Si l'on envisage des grilles de résolutions différentes entre l'atmosphère et ORC, alors OASIS permettra de gérer plus facilement les interpolations à chaque pas de temps.
  • Parallélisation: Pour le moment ORC est parallélisé avec une subdivision selon un ensemble de points continu en longitude (c'est a dire par bande couvrant ou non toutes les longitudes mais pas par domaine rectangulaire). OASIS a permit le couplage ORC-WRF par bloc rectangulaire ce qui correspondait au découpage dans WRF. Néanmoins Yann mentionne que l'on peut aussi envisager le découpage par bloc carré avec un couplage direct (quelques changements a faire dans ORC.)

• Potentiels inconvénient d'OASIS:
  • Les performances informatiques restent à vérifier. Jan a fait des premiers tests en mode forcé avec OASIS ou avec l'ancien driver qui donnent des résultats similaire. Néanmoins ce test inclus des modification du driver dans OASIS (sur la lecture des forçages en particulier) ce qui impacte probablement les performances globales. Il faudrait donc refaire des tests avec "driver" identiques.
  • Yann mentionne que la parallélisation OMP, vers laquelle on se dirige, n'est pas encore possible avec OASIS-MCT
  • Les simulations avec OASIS nécessitent de porter OASIS sur chaque machine (et le compiler) ce qui peut être "lourd" et surtout nécessite des ressources
  • Il est clair que pour LMDZ, le couplage "directe" ORC-LMDZ restera un mode de fonctionnement pour le futur proche (raisons de type contextuelles); Cela implique donc le maintient éventuel de deux voix de couplage.

• Stratégie collective et réflexions générales:
  • Jan et Marc vont poursuivre leur effort WRF-ORC via OASIS; Il essayeront de mieux caractériser les performance du coupleur vis a vis d'un couplage IDENTIQUE mais directe.
  • On a mentionné le problème des "ressources" qui restent limitées et donc la difficulté de maintenir deux système de couplage pour le groupe ORC.
  • On envisage dans un premier temps d'avoir en parallèle: i) WRF-ORC avec OASIS porté par LMD-Palaiseau, ii) Un couplage directe LMDz-ORC qui va intégrer XIOS et qui essaye de garder un oeil sur les développement du coté OASIS-WRF-ORC
  • Un problème soulevé concerne aussi les outils LIBIGCM: Quel est la stratégie du pôle de modélisation et du pole régional vis a vis de ces outils et de leur application éventuelle pour le modèle régionale et leur maintenance. Ce point sera relayé au Pôle de Modélisation.
  • Pour les aspect DRIVER et simulations forcées: Il est important d'essayer d'avoir a terme une seule approche! Dans un premiers temps il serait idéal que les développements de Jan sur la réécriture du Driver pour l'utilisation d'OASIS en forcé bénéficient au Driver standard! Ce point est à rediscuter pratiquement !
  • Yann pourrait éventuellement consacré un peu de temps sur une tache ciblé permettant de mieux comparer les deux approches.
  • On prévoit de murir la réflexion et de refaire un point à l'automne..
  • Commentaires de Jan :
    • Il est motivé pour mesure plus précisément la performance du driver prototype qui couple avec OASIS. Il demandera des conseils de Yann sur comment mesurer cela correctement
    • Il voudrait bien avec l'aide de quelqu'un (à définir) réfléchir à ce qui peut être porté du prototype à dim2_driver pour améliorer les performances. Cela sera plutôt pour Septembre

---