Présents : Stéphane, Constantin, Matthieu, Aurore, David SMt, Sophie T,Laurent, Romain, Roland, David S., Pierre, Marie-Pierre

• Avancement CNRM-CM6_BR (Aurore)
  • Aurore : Un run de 40 ans NEMO-GELATO-(ARPEGE pre-6.2.3) avec XIOS2 pour NEMO et GELATO. Réalisé Prolix (intel 15)
  • Rythme de production : 7-8h/jour.
  • Pas de rééquilibrage de charge effectué par rapport à Beaufix (seulement du nombre de nœuds)
  • Pre6.2.3 = binaire d’Antoinette sur Prolix.
  • Options d’OASIS (conservatif global) : va « plomber » le ¼ de degré. Le BSC a reporté le même problème. La solution de masques terre-mer correspondant Surfex/Nemo ne sera pas retenue pour CMIP6. L’équipe OASIS doit corriger ces pbs avec le conservatif.
  • David SMt : Simulations jumelles Arpege avec aérosols interactifs. Version stable. Pas d’écart constaté.
• Stratégie de runs CMIP6 :
  • Pour le HR on table sur : 1000 Nemo, 1000 Arpege => 50 nœuds
  • 1800 nœuds par machine
  • Ressources disponibles pour CMIP6 : 3% des ressources en moyenne, 5%-10% en crête. D’où plusieurs simulations en même temps.
  • Sur 9 nœuds => 10 LR ou 2 HR
  • HR sur 50 nœuds => 5SYPD, sur 30 nœuds => 3 SYPD

• XIOS2 (Stéphane)
  • XIOS dans Arpege Surfex : fait
  • Interpolation horizontale testée avec grille d’origine Gaussienne ou Lambert. Encore des pbs de limites de masques.
  • Interpolation verticale : promise pour la semaine dernière (on est confiant)
  • Performances : en T127, surcoût XIOS d’environ 10 % (runs courts donc fort poids de l’initialisation). En T359 à peu près neutre sur runs courts. Avec 1 proc dédié XIOS (ce qui peut consommer jusqu’à 1 nœud). David Smt se propose pour étudier des configurations Arpege utilisant un nombre entier de noeuds moins ’quelques’ procs (1 Trip + 1 à 3 Xios)
  • Lucia ne donne que des stats par composante, ne distingue pas XIOS, donc pas utile pour les perfs XIOS.
  • David SMt note qu’il serait intéressant de garder les ranges Min/Max tels que produits (et imprimés) par fullpos .
  • Si on désactive fullpos (LFPOS=false) ça ne tourne pas. La désactivation partielle est OK (N1POS=0)
  • Question de la « décumulation » :
    • Avant : les cumuls sortis par Surfex en fullpos étaient décumulés en postprocessing pour calcul de diags intégrés.
    • Avec XIOS, il y a un surcout du à la livraison au pas de temps du modèle des variables
    • XIOS n’a pas de fonctionnalité de décumulation. Demande remontée à la XIOS-team.
    • On précise à XIOS la fréquence d’échantillonnage et la plage temporelle sur laquelle on moyenne.
    • Pas une solution de passer à XIOS un champ déjà moyenné (par principe XIOS gère lui-même le calcul des moyennes).
    • Dans XIOS, les champs sont livrés à tous les pas de temps indépendamment de la fréquence d’échantillonnage demandée. Stéphane a codé une sur-couche de « filtrage » qui permet de ne post-traiter et de ne fournir à XIOS qu’aux fréquences demandées.
  • En cours/ A faire :
    • perfs runs long
    • phasage sur branche Surfex de Bertrand (CM6SFXv8)
    • Livraison MSE à Antoinette
    • Organisation commune des fichiers de config XIOS (corresp. nom de variable modèle/cmip, description des fichiers, description des variables)
    • Tests en couplé

• drq2xml (Stéphane)
  • Outil qui génère automatiquement à partir de la Data Request, les fichiers de config des outputs (iodef.xml)
  • Partagé avec IPSL. L’utilisation d’un table de synonymes modèle-dépendant sera nécessaire.
  • En l’état de prototype. Fonctionne.
  • Fonctionnalité d’XIOS des time series en mode « append » nécessaire pour s’approcher du format CMOR monovar/longue période.
  • Nécessite de revoir la gestion des sorties par ECLIS (on ne peut plus rester sur du mois/mois pour l’archivage) pour tirer partie de cette fonctionnalité.
  • Implique aussi de revoir les plugins ESM. 
  • Pour cela les fichiers doivent rester sur scratch le temps qu’on atteigne la fin de période visée (discussion sur la conservation ou non du principe d’un volume maximal de 2 Go par fichier de sortie).
  • Soulève les questions de place sur le SCRATCH. A voir avec la DSI.
  • Mode append d’XIOS : Fonctionnalité de synchronisation XIOS garantissant l’intégrité du fichier même si le processus d’append est interrompu. De même XIOS sait gérer la reprise d’un simu en reprenant en arrière : XIOS écrase la partie de données surnuméraire.
  • Fonctionnalité XIOS de bascule fichiers multivars/monovar : On peut donner une description multi-variables dans l’iodef.xml et une clef permet de basculer sur du mono variable. Pratique pour gérer les 2 types de productions : CMIP monovar et simus maison plus courtes multivar. Autre possibilité : adopter le monovar pour tout type d’exercice et tarer avant archivage sur hendrix pour économiser sur les inodes dans le cas de multiples petites simulations.

• CR réunion début juin IS-ENES (Stéphane)
  • Les outils ESGF ont été refondus dont les nouvelles procédures de publication. Pas encore de mise en commun programmée.
  • Data Request : Martin Juckes ne peut pas annoncer de date de livraison (dû au retard des MIPs à finaliser leur liste d’outputs)
  • Certaines variables demandées ne sont toujours pas décrites
  • Les volumes estimés sont donnés en NetCDF4
  • Les données publiées seront munies d’un PID pour la citation.
  • L’IPSL développe un service d’errata sur les bases CMIP6 => centralisation des signalements d’erreurs. Pas encore tranché : envoi systématique des errata aux utilisateurs qui ont downloadé les jeux ou pas ?
  • Contrôle qualité : le DKRZ a refondu son package (finalisé en décembre). Déjà fonctionnel sur les données CMIP5 et CORDEX. Pas d’articulation avec la Data Request a priori. Contact Stephan Kinderman
  • CMOR3.1.0 vient d’être livré
  • CEDA-CC développé par Martin Juckes, mais après la Data Request ….
  • Dans la data resquest pas bcp de plages de validité. Question posée à la CMOR-team. (Réponse depuis : les plages n’ont pas évolué dans CMOR depuis CMIP5, mais le développeur est preneur de nouvelles plages)
  • Il faudra publier en même temps les données et les résultats des QC. On ne sait pas où en est cette assertion….
  • Outil ISPL Synda pour la réplication des données par les sites ESGF principaux. Permet aussi la réplication à l’échelle d’un labo, une personne.
  • QC : le CERFACS s’assure auprès du DKRZ et CEDA de la stabilité des outils (du moins sur leur structure) puis commence le maquettage de l’intégration dans ECLIS.

• ESGF (Laurent)
  • Mise en place nouveau groupe de travail CDNOT (CMIP Datanode Operations Team) dont Sébastien Denvil est le chairman. Eric Gerbier et Laurent représentent le groupe CNRM-CERFACS. Un DMP (Data Management Plan) va sortir. 28 instituts membres de ce groupe pour le moment.
  • 15 nœuds seulement ont redémarré à ce jour..Au CNRM : Nouvelle baie supplémentaire et ajout extension de disques de 1.4 Pb en cours.
  • Coup dur avec le départ de l’IPSL de Nicolas Carenton (co-développeur du package ESGF)
  • Formation d’un réseau des RSSI des centres (ESGF Software Security Team) : E. Gerbier y représentera le CNRM-CERFACS.

• Environnements Prolix/beaufix
  • Intel 15 ok.
  • Compilé en Intel 16 Arpège plante, même en T127
  • Stéphane interroge la DSI et GMAP sur les choix de long terme

• DataRequest (Stéphane)
  • Il faut relancer l’examen des diagnostics demandés
  • Il faut repartir de la dernière version 1.beta.29 de la DR
  • SIMIP : à voir avec David et/ou Matthieu. Vérifier qu’on ait tous les diags demandés en sortie de Gelato les champs.
  • Stéphane installera une version commune de la Data Request et des outils qui permettent d’estimer le volume occupé par une variable pour un ensemble de MIPs par (e.g.) :

drq –m CFMIP,AerChelMIP –p3 –printvars –printLinesMax 2000 | grep ‘rsut’

• Updcli/Updozo (David StM)
  • Refonte : Maintenant gestion dans code Arpege sous GmkPack
  • Plus que 2 versions : updclisfx, updcliarp, ozone incluse, aérosols inclus. Updozo n’existe plus.
  • Pour Aladin on ne lit pas les clim d’aérosols de la même façon. Spécificité à intégrer (Pierre/David SMt)

• Prochaine réunion : 19 juillet. Roland propose de réfléchir, lors de cette réunion, à une « mutualisation » ou « un « complémentarité » des embauches CRESCENDO/PRIMAVERA pour aider la partie technique infrastructre, production. A discuter avec Laurent Terray et Sophie Valcke.