Voici des notes de la discussion entre Stéphane, Marie-Pierre et moi-même sur le contrôle qualité du 02/02/2016.

On se met d’accord sur les 3 niveaux de contrôle de qualité suivants, le Cerfacs s’engageant à prendre en main l’implémentation des niveaux 2 et 3 dans la chaine CNRM-CM6 :

1. Supervision :

• Définition : s’assurer que les jobs sont toujours en train de tourner en machine, les arrêter si quelquechose se passe mal, et/ou éventuellement les relancer après une analyse du retour de job et action corrective. Si aucun message d’erreur connu n’est identifié, on peut relancer n fois "en aveugle". Si un message d’erreur connu est identifié, l’action dépendra du type d’erreur ; par exemple, si c’est un problème de quota, le job ne sera pas relancé mais un courriel sera envoyé à l’utilisateur.
• Typiquement, la supervision est assurée par des outils de type verif_relan s’exécutant en parallèle de la simulation, lancés en cron.
• Par rapport au script de supervision du Cerfacs, il manquerait dans verif_relan la possibilité de ne tourner qu’un mois avec une configuration modifiée de façon à passer une instabilité (effet papillon) et de revenir à la version nominale le mois d’après.
• Attention, quand on relance un ou des mois antérieurs, il faut bien s’assurer que les nouveaux résultats écrasent les résultats produit avant la relance antérieure.
• On pourrait aussi aller plus loin par exemple, en vérifiant que les fichiers produits ont la bonne taille ; dans ce cas, il y aurait une dépendance entre les actions de supervision et les fichiers de configuration, donc de la "Data request".
• Une partie de la supervision peut être directement intégrée à ECLIS sous forme de plugins.
• Dans ECLIS les scripts commencent par "set -e" ce qui assure que le script plante si une commande se passe mal. Il y a aussi des régions plus tolérantes qui activent une fonction "error" quand quelque chose se passe mal.

2. Monitoring :

• Définition : production de diagnostiques simples et de graphiques en cours de simulation pour s’assurer au premier ordre que les résultats de la simulation sont physiquement corrects.
• Le monitoring pourrait aussi s’assurer que les entrées réellement utilisées par le modèle sont celles qu’on pense utiliser. A implémenter au plus près du coeur du code ; par exemple, vérifier les fichiers d’entrée n’assure pas que le contenu de ces fichiers est réellement utilisé par le code. On pourrait analyser les fichiers de restart modifiés par ARPEGE ou encore mieux un diagnostique produit par le modèle basé directement sur les entrées.
• Peut s’implémenter par plugins ECLIS, pour ce qui est hors modèle.
• Note post-réunion : monitoring ’minimal’ en terme de nombre de variables surveillées à la IPSL, voir : http://webservices.ipsl.fr/monitoring-1.20/tmp/fegg_plot01_GIHlXl_prod/

3. Controle qualité des données (CQD ou DQC pour "Data QC") :

• Définition : analyse plus détaillée assurant la qualité scientifique des résultats de la simulation
• Le 1er niveau de CQD correspond à l’utilisation d’un outil qui devrait être fourni par le WGCM Infrastructure Panel (WIP) de CMIP6 qui analyse automatiquement les données produites et générerait des flags de type "OK", "suspect", "out of range". Ce type d’outil a été utilisé par les Data Centers (BADC et DKRZ) dans CMIP5 avant l’attribution d’un DOI. Pour CMIP6, ces outils devrait être utilisés par les groupes avant le transfert des données vers les Data Centers. Sophie et Marie-Pierre s’informent auprès de Guillaume Levavasseur sur l’état d’avancement de ces outils dans CMIP6. Voir aussi ce qui se fait à l’IPSL et mutualiser les développements. Ce 2 niveau de CQD devrait se faire en aval des données quasi-cmorisées produites par XIOS avant ou après ajout des metadata. (Pour le DKRZ, ce 2e niveau comprend 3 sous-niveaux, voir https://redmine.dkrz.de/projects/cmip5-qc/wiki ; voir aussi http://www.dkrz.de/daten-en/data-services/Datapublication/quality-assurance-of-data)
• La production et l’analyse visuelle d’un atlas est un deuxième niveau de CQD
• Un 3e niveau indispensable est l’analyse détaillée des résultats qui doit être faite par un scientifique. Ce niveau devrait être passé avant la publication des données. Au sein du groupe CNRM-Cerfacs, un scientifique responsable devrait être identifié pour chaque MIP.