Avertissement : ce texte, valide à l’époque de la sortie de cla version 6.16 d’Eclis, peut être par endroit obsolète, quand il est contredit par cet autre texte

Eclis V6.16 gére des sorties Xios en mode incrémental (append)

Nous sommes convenus de mettre à l’épreuve Xios dans Arpege, Surfex et Trip, pendant le spin-up, dans un mode approchant de celui de la production CMIP6 :

• avec des sorties incrémentales : les runs successifs les complètent au fil de l’eau, et elles sont tronçonnées par des ’fréquences’ de coupure précisées dans la config Xios pour chaque fichier de sortie ou chaque variable de sortie
• et ces sorties seront en sus de type ’timeseries’ (dans la terminologie Xios) , c’est-à-dire des fichiers mono-variables

J’ai pris un peu de temps pour adapter Eclis à ce mode-là, en essayant de lui conserver sa robustesse et sa facilité d’emploi. C’est dispo avec Eclis V6.16, et pas mal testé (mais évidemment, vous saurez trouver des cas tordus). (J’y ai aussi un peu amélioré les reprises sur plantage de l’archivage, en mode archiving=during)

Je vous fais un résumé ci-dessous, en deux gradations : doc utilisateur, doc technique. Merci pour vos retours, grâce auxquels je pourrai peaufiner le texte de la doc en ligne d’Eclis

Doc utilisateur

• Configuration de l’expérience :
  • côté Eclis : l’utilisateur indique LIOXOUT=1 dans les paramètres Eclis
  • côté xml pour Xios (cf exemple ci-dessous) :
    • il précise le mot clé IOXDIR/ dans ses file_defs pour indiquer à Xios qu’il va travailler dans un répertoire dédié pour stocker les fichiers incrémentaux (il le met au début de l’attribut ’ts_prefix’ si travaille en ’time_series’ et sinon, de l’attribut ’name’) ;
    • de préférence, il inclut aussi la chaîne EXPID dans ces attributs ;
    • il fixe aussi les périodes de coupure des fichiers de sortie (attributs ts_split_freq ou split_freq suivant les cas).
  • Eclis décide :
    • du répertoire de manoeuvre sur beaufix de ces fichiers incrémentaux : IOXDIR est traduit en un répertoire sur /scratch/ftdir, qui est accessible depuis le répertoire de relance par le lien symbolique [DIRREL]/ftexp/iox
    • du répertoire hendrix de sauvegarde : GROUP/EXPID/iox/output

• Xios décide de la partie dates ’debut-fin’ des noms de fichiers incrémentaux à partir de la date où il les crée et de la fréquence de coupure, ce qui peut donner une date au-delà de la fin de la simulation. Pour y pallier le principe général est que :
  • les fichiers sont nommés : i) sur beaufix comme Xios l’attend, et ii) sur Hendrix selon leur contenu supposé (on prend la date de fin de run),
  • Eclis se débrouille pour renommer quand il faut et que ca marche dans tous les cas : prolongation d’expérience, recul dans une expérience, plantage dans la phase calcul ou de sauvegarde, mode d’archivage=DURING ou BEFORE ; Ca repose sur un fichier index_xios comprenant les correspondances de nom
  • Tant qu’un fichier n’est pas complet (par rapport à sa période de coupure, cf §1) il n’est pas disponible sur hendrix (exception : quand on prolonge une expé - cf infra) ; ceci parce que la DSI préfère que l’on ne multiplie pas les envois de fichiers évolutifs, pour ne pas charge ’inutilement’ hendrix ; les fichiers pas encore complets sont disponibles sur [DIRREL]/ftexp/iox (en nommage Xios, c’est-à-dire avec date de fin éventuellement plus tardive que le contenu réel)
  • Quand on prolonge une expé, Eclis laisse disponible sur hendrix les fichiers de sortie qui vont être complétés par la prolongation. Il les remplace, au fil de la prolongation, par des fichier complétés (et donc potentiellement renommés quant à leur date de fin) ; donc, fixer des dates de fins d’expés intermédiaires peut éventuellement être utilisé comme un moyen de disposer sur hendrix de fichier intermédiaires
  • Pour reprendre ou prolonger une expé, il est impératif de ne pas avoir modifié dans les fichiers xml la description des fichiers de sortie (file_def), ni bien sûr ré-installé l’’expé.
  • Les scripts delexp et cm_files connaissent l’abbréviation de realm ’X’ pour désigner le ’realm’ (ou répertoire de résulats) des fichiers Xios incrémentaux ; mais EM n’est lui pas encore adapté pour ça
  • Le format des dates générés par Xios dans les noms de fichiers ’timeseries’ est par défaut le plus court possible par rapport à la fréquence de découpagel tempore demandée. C’est ajustable, cf doc de référence de Xios : ts_split_freq_format)
  • A noter qu’on ne peut pas demander à Xios de faire des moyennes sur des périodes plus longues que la durée de chaque lancement de modèle (soit 1 mois avec Eclis)

• Ce mécanisme Eclis de gestion des sorties incrémentales (de mnémonique IOX dans Eclis) est distinct et peut s’ajouter à celui des sorties Xios traitées par IOSOUTPATT (lesquelles ont le mnémonique IOS dans Eclis, et sont supposées être générées comme des fichiers indépendants à chaque mois de simulation ; et elles sont stockées sur hendrix en : GROUP/EXPID/ios/output)

Doc technique

• Pendant le step3, quand un fichier est complet, Eclis le sauve ; s’il s’agit d’une fin d’expé (DATF atteinte) , il rectifie la date de fin dans le nom de fichier, et mémorise le nom connu d’Xios (dans un fichier [DIRREL]/index_xios) ; s’il y a un (ou plusieurs ) fichier sur hendrix portant le meme nom (à la date de fin près), le script d’envoi toolbox/pcif.py les détruit
• Pendant le step1, Eclis (script toolbox/giftc.py) va chercher sur hendrix les fichiers que la simu courante à vocation à compléter (d’après la date de simu et la période des noms de fichiers) et les rapatrie (parce que la simu veut les modifier), mais seulement s’ils n’existent pas localement, sous leur nom Xios ou autre (c(est pour efficacité ; le cas de recul dans une expé est bien géré parce que Xios ré-écrira la partie de donnée re-simulée) . Il ne les supprime pas d’Hendrix, mais ils seront remis plus tard, complétés, ou rectifiés en cas de recul, et potentiellement renommés pourleur date de fin) ; Et il les nomme localement comme Xios l’attend. Donc, on peut jouer avec DATF pour prolonger une expé, et on peut reculer dans une expé

• Sur un plantage du step2, Eclis sauve les fichiers (dans le step3) en rectifiant là aussi la date de fin, et en mémorisant aussi le nom Xios. Il n’y a pas d’effacement d’ioxdir de ces fichiers, mais il y a renommage
• En cas de plantage du step3, les fichiers incrémentaux que ce step n’a parfois pas eu le temps de sauver sur Hendrix seront automatiquement repris en compte au run suivant (et cela prévaut sur aller chercher sur hendrix). Ca permet entre autres qu’un plantage du step2 suivi d’un plantage du step3 soit bien géré
• Le mode ARCHIVING=DURING est toujours opératoire : il n’y a pas de pb à avoir concurrence entre un step3 et les steps 1 et 2 suivants pour les fichiers incrémentaux parce que le step3 n’agit dessus (en les sauvant puis supprimant) que si ces fichiers sont complets (donc n’intéressent pas les steps 1 et 2 suivants), ou si le step2 qui précédait a planté (auquel cas il n’y a pas de step1 et 2 suivant avant relance, manuelle ou auto)
• Un script toolbox/save_iox.sh (à un seul argument : EXPID) permet de sauver ioxdir sur Hendrix en renommant les fichiers comme si l’expé avait fini à DAFC. Il peut servir pour traiter les fichiers d’une expé plantée qu’on ne veut pas prolonger. Il ne peut pas servir pour forcer la copie sur hendrix pendant une simulation (parce qu’il renomme les fichiers localement, ce qui perturberait une simu en cours)
• A la ré-installation d’une simu, les répertoires hendrix et beaufix de sorties incrémentales sont nettoyés de ce qui pouvait rester d’un premier essai ; mais pas de nettoyage lors d’un relan (cf supra)
• Le nettoyage sur beaufix des sorties incrémentales en fin de simu, et donc l’économie de ressources disque sur beaufix, est automatiquement assuré par le schéma supra
• Pour traiter les fichiers incrémentaux, Xios gère un restart de nom ’xios_registry.bin’ (nom identique en entrée et sortie). A part ce détail, Eclis le gère comme les autres restarts. LIOXREST=0 au démarrage
• Eclis a un mécanisme qui, dans le step3, gère les plantages du step2 pour sauvegarder les sorties des mois bien finis. Il complique le script, surtout en mode archiving=during. S’il (ou quand) il n’y avait (aura) plus que des sorties gérées en mode incrémental, on pourra(it) laisser le script pcif.py sauver les fichiers finis lors de son passage suivant (celui qui reprend la simu)

• A noter le besoin de cohérence entre les variables suivantes, au moins jusqu’à une refonte du mécansime de sauvegarde des restarts par Eclis :
  • RESTART_BUFFER_LENGTH : longueur (en mois) de la liste des restarts gardés localement (vaut 12 par défaut) ; doit être suffisamment long par rapport à IOXSAVEPER (cf infra), sauf si on compte seulement sur les sauvegardes de restart
  • SAVE_RESTART_PER : période (appliquée au numéro de mois dans l’année) pour que les restarts modèles soit sauvegardés sur Hendrix (vaut 12 par défaut, soit sauvegarde au 1° janvier seulement)
  • IOXSAVEPER : période de sauvegarde sur hendrix des sorties Xios (qui sont une forme de restart) (vaut 0 par défaut : pas de backup – seuls les fichiers complets sont copiés sur Hendrix) ; elle se combine avec NMONTH pour piloter les moments où cette sauvegarde est réellement faite
  • NMONTH : nombre de mois dans un job
  • INIDATE : date de démarrage de la simulation

• En ce qui concerne les restarts on peut re-démarrer une simulation depuis n’importe quelle année pour l’un des mois de l’année sauvergardé au vu de SAVE_RESTART_PERIOD, ou depuis n’importe quel mois récent dans la limite de RESTART_BUFFER_LENGTH. Donc, quand on redémarre d’un backup, il faut : i) ou que RESTART_BUFFER_LENGTH soit assez long vs MAX, ii) ou se débrouiller pour que les périodicités de SAVE_RESTART_PERIOD d’une part, et de INIDATE, IOXSAVEPER et NMONTH d’autre part se correspondent.

• Exemples de combinaison :
  • INIDATE au 1° janvier, IOXSAVEPER est un multiple de 12, NMONTH divise IOXSAVEPER, SAVE_RESTART_PERIOD divise IOXSAVEPER, RESTART_BUFFER_LENGTH est aussi petit qu’on veut ; on pourra alors toujours repartir du 1° janvier de l’année du plantage
  • idem avec IOXSAVEPER = un multiple de 12 : on peut repartir depuis certains 1° janvier (et certaines sauvegardes de restart ne servent à rien)
  • INIDATE au 1° janvier, IOXSAVEPER est un nombre premier, SAVE_RESTART_PERIOD=12 : les points de reprise sont espacés d’autant d’années que IOXSAVEPER (pour trouver coïncidence entre sauvegardes Xios et sauvegardes de restart)
  • INIDATE n’est pas au 1° janvier : ça se complique sérieusement