2023/01/30
Liens utiles:
- le lien gotomeeting pour la visio: https://www.gotomeet.me/EMC3_LMDZ/poihl
- la page des liens utiles: https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/cr-de-reunions/poihl/liens_utiles
Poihl "banalisé"
Généralités:
- Lydia demande des précisions sur le compte fabric sur spirit. C'est bien un compte géré par le groupe et un membre du groupe qui peut rajouter les clés ssh dans le authorized_keys du compte
- rappel: session post-formation à 10h le 31 janvier sur gathertown
- Frédéric informe qu'il y a pas mal de discussions sur ECRAD en ce moment (soit par mail soit sur mattermost). Lui demander d'être rajouté dans la boucle si intéressé
Sujet du jour: consolidation et contrôle qualité
On prévoit une discussion autour des points suivants:
- comment éviter des périodes de moratoire trop longues?
- comment s'approprier les outils du contrôle qualité / trusting?
- travail à mener sur la définition de versions de référence régulières que l'on peut partager: fréquence de ces références, tests à faire pour les valider. Une fréquence de 3 semaines avec un travail en poihl à éplucher le svn log pour décider de la version à prendre?
On commence en fait par discuter d'un nettoyage sur l'espace https://lmdz.lmd.jussieu.fr/pub . Après discussion, le nettoyage est acté, sera effectif dans quelques jours et on décide aussi de passer les fichiers contenus dansr tutorial.tar et tutorial_prod.tar sous svn.
Compte tenu du temps passé sur le nettoyage de /pub, on n'aborde que le 3ème point du contrôle qualité. Pour décider de la validité d'une version de référence se pose la question du genre de validation requis: technique/informatique (est-ce-que la version 'tourne' dans 'tous' les cas?) ou scientifique (est-ce-que la version donne un climat connu / acceptable?). La réponse à cette question conditionne évidemment la fréquence de sortie de ces versions de référence. On considère que les versions de référence que l'on fournira aux demandes des groupes plateforme et ICMC seront des versions validées scientifiquement.
On décide donc d'un processus pour définir des versions de référence validées 'techniquement':
- une semaine avant un poihl "banalisé", on déclare que la HEAD de la trunk est candidate à être la prochaine version de référence
- on déclare un moratoire sur les commissions au code (hors correction de bugs trouvés pendant la phase de validation)
- on fait passer à cette version la batterie de tests de validation (voir ci-dessous)
- une fois les tests réussis et les bugs corrigés, la version 'corrigée' est taggée comme version de référence lors du poihl banalisé
On devrait donc, en gros, pouvoir sortir une version de référence tous les mois environ.
Au cas où on aurait une perte de convergence avec la nouvelle version, il faut alors procéder à une validation scientifique et un éventuel tuning. Dans ce cas:
- on calcule des/les métriques avec cette nouvelle version
- si les valeurs de ces métriques 'dépassent' les seuils de tolérance associées au tuning de la version du modèle, on procède à un re-tuning du modèle
Liste des tests à faire pour validation technique:
- un trusting IPSLCM6 couplé, avec INCA et les traceurs, reprobus (?)
- une suite de validation de différentes physiques pour valider le plus grand nombre possible de paramétrisations (utilisation de l'outil de Lionel)
- un test tutorial_prod (debug, parallèle, xios, cosp)
- un test SPLA
- un test 1D étendu (sur tous les cas définis)
- test isotope ? (plusieurs tournent déjà dans le contrôle qualité journalier)
voir le ticket trac 147, si vous avez un test à rajouter.
Première expérimentation de la procédure au prochain poihl 'banalisé', le 20 février ...