2021/10/18

Poihl 'banalisé'
(dans le sens où ce n'est ni un poihl "physique" ni un poihl "architecture du code"

Le poihl de la semaine prochaine sera un poihl 'physique' 

Pour rappel:
Le lien gotomeeting est https://www.gotomeet.me/EMC3_LMDZ/poihl

La page du tour de table virtuel est ici
https://pad.colibris-outilslibres.org/p/TourdeTablePoihl

Infos générales et propositions de travail en groupe:

• Etienne nous informe que R. Roehrig a lancé une annonce officialisant le nouveau format standard 1D. Les cas ArmCu et RICO devraient s'y conformer avant la fin 2021 pour un exercice d'intercomparaison qui se tiendrait en 2022. Ceci implique:
• des changements dans le code LMDZ (dyn1D: lecture des forçage et des options supplémentaires)
• des nouveaux scripts de post-traitement pour se conformer à la norme CF. En l'état actuel, on sort 3 types de fichiers: les bruts (histday), une version V0 utilisée par HiTune et autres scripts et la version V1 se conformant au format standard officiel
• Frédéric a un plantage sur des sorties qu'il aimerait qu'on résolve en groupe
• AIRS: test en cours (important de faire les retours au poihl sur les sujets initiés au poihl) 
• question de Ehouarn sur le traitement des valeurs négatives de traceurs (plantage/remise à zéro?)
         la réponse passe par une clarification du schéma leapfrog dans la dynamique pour régler  l'advection des traceurs
                  ⇒ proposition de travail
• proposition de points pour un prochain poihl: Martin Ménégoz aimerait discuter de la bimodalité des précipitations mais pas avant début novembre

"Suite de la discussion sur tutorial_prod":
Adriana nous informe des avancées de ses travaux de rénovation de tutorial_prod et de questions qu'elle se pose:

• rajout de commentaires dans les scripts (install_lmdz.sh et ceux de tutorial_prod)
• ménage dans les *.def tout en en gardant un bon nombre. Par défaut, on veut une simulation proche de CMIP6
• travail à prévoir avec Frédérique sur les *aer.def
• il faut pouvoir tourner par défaut avec l'ozone stratosphérique et les aérosols troposphériques (avec un vrai fichier de climato)
• question: comment concilier une version d'ORCHIDEE nécessitant une compilation avec XIOS et des sorties IOIPSL pour LMDZ (utilisées pour le tuning par exemple)? Dans l'état actuel du code, la compilation de LMDZ avec XIOS implique que les sorties se font avec XIOS...
• une solution serait de modifier le code LMDz pour que, même si compilé avec XIOS, les sorties utilisent IOIPSL
• une autre solution, vu que les sorties IOIPSL et XIOS sont basées sur les mêmes principes de niveaux de sortie, serait de développer un script de traduction des config/output.def vers les file_def*.xml appropriés
• pour commencer on pourrait déjà créer des file_def*.xml simple pour créer les fichiers utiles au tuning avec XIOS

Tour de table virtuel: