CR de réunion CMIP6_Tech du 6/3/2016

• prochaine réunion le 12 avril 14h en salle 151
• Les CR de ces réunions sont dorénavant disponibles sur le site http://www.umr-cnrm.fr/cm/ (autorisation d’écriture d’articles sur ce site à demander éventuellement à L. Franchistéguy)
• CNRM-CM6 :
  • Le fonctionnement du mode couplé est stabilisé, avec un choix homogène d’options de compilationet de librairies pour toutes les composantes. Sous Eclis, un plugin "intel15_mpi5" permet d’avoir l’environnement d’exécution adhoc
  • le problème d’interpolation dans le couplage est bien lié à un ordre des coins inadapté dans le fichier de grille ; reste à vérifier ue rétablir le bon ordre suffit.
  • Physique : une dérive en eau importante est due à un bug LIM3, qui ’perd’ la neige sur ocean libre
  • les plantages en HR semblent résolus par l’activation d’une clé qui permet de stabiliser un des schémas physiques (calcul de l’eau condensée)

• XIOS et Arpege+Surfex
  • l’adaptation à la V8 de Surfex est codée mais reste à tester ; le cas des diagnostics que SUrfex ne sort qu’en version cumulée est à étudier, car incompatible avec une hypothèse d’XIOS : qu’il gère cumuls et moyennes
  • la 1° version interfacée à Arpege ’exposera’ à XIOS, depuis la routine aplpar, les diagnostics sortis pour CMIP5 ;
  • l’objectif est une disponibilité sous 15 jours
  • les champs de la chimie seront à ajouter ’en suivant’
  • un groupe de travail a été monté avec l’IPSL pour la configuration des diagnostics à produire par les simulations CMIP6 à partir de la Data Request, avec XIOS ;
  • Stéphane y a proposé un prototype de génération automatique des fichiers xml qu’il a développé, et qui permet d’envisager, avec les autres fonctionnalités d’XIOS, de se passer de Cmorisation en indiquant à XIOS tous les attributs NectCDF à coder comme meta-données ; cette phase-là, qui ne maniuple que des attributs CF ou CMIP6, est indépendante des modèles concernés, en supposant qu’une ’strate’ de définitions XIOS doit de toute façon assurer la correspondannce entre terminologie spécifique du modèle et terminologie ’officielle’
  • les fonctionnalités XIOS encore manquantes pour CMIP6 y ont été listées, et seront a priori prises en compte ; cela concerne en particulier une focntion de Cmor : le contrôle des valeurs de champs par rapport à des bornes, stockées dans la Data Request, et qui dépendent de la variable et de la fréquence concernées (mais hélas, à ce stade, ne dépendent pas de l’expérience) ; les valeurs hors bornes pourront au choix générer un avertissement ou un plantage de la simulation ; on covient que, même dans le cas de simulations de production, il peut être opportun de travailler en mode ’plantage’ si un effet papillon permettait de remédier aux valeurs hors bornes ; au demeurant, le dispositif ’avec plantage’ permet une boucle de réaction rapide dans les simulations de mise au point, si tant est que chaque utilistauer a suffisamment la main sur les valeurs des bornes (et controle le choix avertissement/plantage au niveau de chaque variable) ; un outil de synthèse des avertissements semble nécessaire
  • La compression éventuelle à appliquer aux sorties (éventuellement en mode post-traitement) pour obtenir des fichiers de type ’NetCDF-4 classic’ reste encore à étudier.

• Controle qualité :
  • Les acteurs travaillant pour le WIP, ici le DKRZ, développent un chaine de controle qualité des données à publier pour CMIP6, dont les résultats pourraient être rendus nécessaires pour publier les données ;
  • ce développement ne sera guère disponible qu’en fin d’été, malgré une demande pour disposer d’unb prototype au plus tôt ; l’intégration d’un controle qualité dans notre chaine de production est donc a priori à différer jusqu’à cette livraison
  • les résultats du contrôle qualité effectué par le DKRZ sur nos données CMIP5 devrait être exploités pour commencer à traiter dans CNRM-CM les avertissements qu’il a levés ; ces résultats sont disponibles en http://www.ipcc-data.org/sim/gcm_monthly/AR5/Reference-Archive.html ; pour notre piCOntrol, par ex, voir en http://cera-www.dkrz.de/WDCC/CMIP5/QCResult.jsp?experiment=cmip5/output1/CNRM-CERFACS/CNRM-CM5/piControl
  • il faudra aussi exercer, sur les sorties de CNRM-CM6, en mode ’offline’, les controles qualité utilisés par le Cerfacs pour le projet SPECS, dès qu’un prototype assez avancé de CM6 sera disponible ; Marie-Pierre et SOphie enquêteront aussi sur le devenir des résultats de contrôle de SPECS
  • le groupe de travail IPSL-CNRM sur XIOS et CMIP6 compte aussi vérifier que les données générées par XIOS passent, structurellement, les controles de conformité de CMIP6, dès qu’un outil de controle sera validé par le WIP

• Monitoring : un ’coding sprint’ est en cours (CREFACS + CNRM + IPSL) qui concerne l’utilisation de CLiMAF pour des atlas et du monitoring de résultats océaniques ; à suivre

• Prolix : il serait intéressant de profiter de Prolix2 pour faire avancer la validation du couplé HR plus rapidement ; les préalables sont une installation des composantes de CNRM-CM et une optimisation ;
  • hors réunion : pour Arpege, Antoinette installera très rapidement la (seule) version 6.2.2 d’Arpege compilée en ’intel15_mpi5’ ;
  • hors réunion : pour Nemo, Matthieu installera la version 3.6
  • David et Stéphane installeront respectivement updozo et updcli ;
  • les gestionnaires habituels de données communes les installeront sur le scratch/work ; une page sur le site CM décrira leurs localisations et servira à leur sauvegarde périodique (manuelle) ; cette page sera gérée par l’ensembled e ces gestionnaires de données
  • l’optimisation concerne les paramètres de géométrie et NPROMA ; les intéressés (Fabrice, Eric M.) sont absents et devront être consultés ;
  • par ailleurs, Sophie V. se propose pour faire avancer une simulation HR, une fois ces pré-requis assurés

• ESGF :
  • global : la fédération a redémarré ; le président du comité exécutif a diffusé une lettre à ce sujet ; une bonne partie des noeud dits Tier1 est opérationnelle et 50% de l’archive globale CMIP5 a été republiée à ce jour au sein de la fédération.
  • local :
    • le logiciel de notre datanode a été à nouveau ré-installé, un test de publication est positif ; la re-publication en masse va re-démarrer ; la publication de données nouvelles passera après
    • le COCI réclame pour début avril une ré-évaluation des volumes à gérer fin 2017 ; la réévaluation demandée pourra être fournie sous forme d’intervalle (2 Po +- 0.5 Po par exemple) ; elle repose sur une mise à jour de la Data Request conernant AerCHemMip ; il faut relancer Martin Juckes sur ce point