- Avancement CNRM-CM6 :
- un binaire Arpege 6.2.3 est figé ;
- une version "6.2.3 plus 2" est en développement, qui comporte une turbulence minimale ; deux simulations T127 (couplé/forcé) de 50 ans sont disponibles ; le masque de Nemo a été changé pour l’Antarctique
- un bug sur upclisfx, concernant la glace de mer, a été corrigé ; les spécificités Aladin ont été intégrées dans les updcli
- Forcages :
- David StM a mis à jour un jeu de fichiers de forcages GHG+constante solaire pour rapprocher la constante solaire de la spécification CMIP6
- Stéphane regardera la mise à jour des GHG (on reste sur la base de valeur globales annuelles)
- Volcans : Martine relancera les producteurs des forcages, pour obtenir les AOD adaptées à notre schéma de rayonnement (même raies qu’à l’IPSL, donc pas de problème en vue)
- Ozone : David envisage de recalculer les coefficients du schema linéaire (opération un peu lourde)
- Land Use : Roland est en phase de test ; changer le Land Use pour la version CNRM-CM n’aurait de vertu que pour homogénéîté avec les runs CNRM-ESM
- XIOS :
- intégration réalisée dans Surfex, branche CM6SFXV8 ; elle comprend un test d’inoccuïté (résultats identiques) sur un cas en grille lat/lon couplé avec Trip
- en compilation Offline, on doit néanmoins désactiver DrHook pour éviter un blocage ; hypothèse : le Dr Hook embarqué dans Surfex est trop ancien
- l’intégration des sources XIOS et de leur compilation par le système de compilation de Surfex Offline est OK sur PC, et en cours de test sur BullX (en version Intel15)
- à l’issue, et après un test en couplé, Stéphane fournira en sus à Jeanne les éléments d’interfacage à Arpege (modifs à MSE et Arpege), pour viser une intégration au 15 août
- une version d’Xios traitant les interpolations verticales est disponible mais reste à tester
- pas de nouvelles sur le bug sur trait de côte dans les interpolations horizontales
- Martine rappelle le besoin de sorties en moyenne zonale et deamnde ce qu’il en est à ce sujet avec Xios
- la flexibilité que donne XIOS sur la fréquence d’échantillonnage de chaque champ séparément (avant moyenne temporelle) soulève des questions, qui nécessitent des investigations complémentaires (non attribuées) :
- quelle fréquence pour quel(s) champ(s) - par exemple, le rayonnement n’est pas mis à jour tous les pas de temps, la température à une évolution assez lente ...
- quelle rupture dans la comparaison des runs introduira(it) une diminution par rapport au rythme actuel (1/6h)
- sur quelles fréquences se basent les diverses références (ex : ERAI a très probablement une fréquence de 6h)
- quel surcoût pour une haute fréquence
- environnement de compilation
- actuellement, on dispose sur Prolix d’Intel15 et Intel16, avec les versions adhoc de NetCDF pour les deux niveaux
- pour CMIP6, on pense pouvoir avoir Intel15 sur beaufix 2 si besoin
- pour la DSI, Intel16 est l’environnement par défaut
- GMAP a testé Intel16, et y trouve un gain (en CPU)
- Arpege 6.2.3 ne tourne pas en Intel16 en optimisation O2, il tourne en optimisation O0, Antoinette compte tester en optimisation O1
- il serait intéressant, au moins pour le moyen terme, que CNRM-CM6 tourne nominalement en Intel16, pour démontrer qu’il est pérenne et qu’on peut espérer le faire tourner sur les machines de Calcul 2019
- en bonus, engranger le gain CPU pour CMIP6 serait intéressant
- Marie-Pierre instruit la possibilité que le Cerfacs travaille à résoudre le bug ; la machine neptune est a priori adaptée
- nous manquons de ressources ingénieur pour ce genre de tâches ; sa priorité devrait être discutée aussi avec les chefs d’équipe
- post-réunion : Antoinette a pu faire tourner en optimisation -O2, pour l’instant au même coût CPU
- Diagnostics à coder pour CMIP6
- la version beta.30 de la Data Request est sortie depuis la dernière réunion
- il se confime qu’AerChemMIP demande des sorties sur l’ensemble des niveaux modèles ; leur volume total, qui est fonction du nombre d’années et de variables de la demande, n’est pas connu lors de la réunion
- les actions notées lors de la précédente réunion restent à mener (par Stéphane) :
- organisation de l’examen de la pertinence et faisabilité pour les variables demandées (avec un premier jet d’attribution nominative de l’examen)
- installation partagée d’outils de la Data Request particularisés pour nos géomètries de modèle, permettant d’estimer les volumes pour une variable
- Matthieu et Marie-Pierre ont mené un examen sur les variables SeaIce ; ils en concluent au besoin d’un grand soin dans l’examen de la définition des variables
- Il faut veiller à permettre d’ajouter des variables (vs la DR) ; un débat a eu lieu sur le besoin d’arbitrage du coût que peut représenter l’ajout d’une variable ’spéciale’ pour toute la production CMIP6, au regard de son intérêt pour un nombre plus ou moins grand de chercheurs du Groupe
- ESGF : pour notre data node, une montée au niveau 2.3.8 du logiciel ESGF a été réalisée fin juin
- Recrutements pour contribuer aux développements techniques (sujet proposé à la dernière réunion) :
- propositions de budget :
- sur Crescendo, le CNRM peut dégager des ressources ; sur Preface,
- Aurore a une queue de crédit ;
- sur Primavera, le CERFACS a déjà un recrutement engagé de Post-Doc et envisage de recruter un ingénieur. Idée de mutualisation Cerfacs/Cnrm sur développement technique paraît pertinente mais reste à discuter en interne Cerfacs.
- pour quelles tâches : Stéphane présente une liste d’actions nécessaires pour CMIP6 ; pour la plupart, il y a un besoin affirmé d’une maîtrise par des personnels permanents ; seuls les tâches des thèmes ’monitoring’ et ’atlas’ semblent appropriées
- propositions de budget :