Elle apporte :

• la possibilité de réaliser des simulations en mode ’peu incrémental’ (ou ’année par anné’ : LIOXSAFE=1) même sans invoquer la Data request et dr2xml
• réactivation de la fonctionnalité de cyclage sans spin-ups (forcage ’SCYC’, pour OMIP)
• des améliorations dans les post-traitements (cas LIOXSAFE=1) pour CMIP6 (script assemble_and_QC.sh) :
  • ajout du script toolbox/job_postpro.sh pour re-post-traiter des sorties via ce script (voir plus bas,)
  • correction à la corrections des standard_names et du branch_time
  • utilisation des variables d’environnement DontSaveList et DontSaveDir (les variables listées dans le fichier DontSaveList ne sont pas archivées, mais déplacées vers le répertoire DontSaveDir
  • s’assurer que tous les fichiers ont bien été assemblés

( seule une partie des corrections avaient déja intégrées par un patch dans la V6.37)

Pour toutes les simulations CMIP6 qui n’ont pas encore donné lieu à bon à publier, il convient de re-post-traiter les données avec ce script de re-traitement senesi/eclis/V6.38/toolbox/job_postpro.sh (ou en /scrtach/CMIP6/V2/eclis_V6.38). En fonction des arguments fournis

Si vos données sont encore sur /scratch, ce script refait l’assemblage des fichiers annuels (un argument permet, si on le met à 0, d’économiser le cout de ré-assemblage), puis

• sauve les données assemblées sur hendrix (répertoire output_originals), puis
• corrige des meta-données, et
• sauve les données corrigées sur hendrix (répertoire output)

Si vos données ne sont plus sur scratch :

• il les récupère depuis hendrix,et
• fait les corrections de meta-données, puis
• sauve les sorties corrigées sur hendrix (répertoire output_postprocessed)

On évite ainsi dans tous les cas d’écraser les données assemblées par les données ayant en sus subi des modifications de meta-données (mais il vous appartiendra de nettoyer les données redondantes sur hendrix)

Le job lancé envoie par mail un CR en fin de traitement, mais seulement si tout s’est bien passé. S’il a réalise un assemblage, il a aussi supprimé les données du répertoire ’assembled’ sur scratch (ré-générable à partir des données annuelles). Pour l’effacement des données annuelles sur scratch, la politique n’est pas encore figée. Vous pourrez utiliser l’outil /cnrm/est/COMMON/CMIP6/get pour descendre les données sur /cnrm/cmip6 et vérifier leur contenu, puis émettre le bon à publier (cf CR de réunion CMIP6_Tech).

Dans le cas contraire (pas de mail de bonne fin), des listings des différentes étapes sont disponibles dans le répertoire qui est indiqué au lancement du script (plus un listing général , au nom en assemble_and_QC*) ; les plus intéressants, dans les cas d’erreur, sont ceux de nctime et de PrePARE, qui peuvent indiquer des trous dans les données dans les cas les pires. Cela pourrait vous amener à refaire certaines années, et/ou à consigner dans le bon à publier quelles sont les couples table-variable à ne pas publier. Dans ce dernier cas , pour finaliser l’envoi des données sur hendrix, vous devrez, dans le job de postpro modifier la ligne "QC_is_blocking=0"

A noter que ce script pourrait idéalement encore évoluer :

• pour ajouter une meta-donnée décrivant les jeux de forçages que nous avons utilisés, mais je n’ai pas encore le contenu de l’info à y mettre
• pour activer un contrôle des données produites (statistiques des valeurs des champs), mais sa mise au point, pour une version qui "passe à l’échelle", est laborieuse ; il s’ensuit que supprimer toutes données annuelles du /scratch est encore risqué

Nous n’attendrons pas ces évolutions

Enfin, pour les simus qui ont déja donné lieu à bon à publier, un examen au cas par cas est nécessaire