On indique à Eclis quels sont les composantes (modèles) dont les sorties sont produites par XIos en mettant à 1 les clés logiques correspondantes : LRIVIOS, LSFXIOS, LOCEIOS, LICEIOS, LNISIOS

Par ailleurs, on lui désigne par le paramètre IOSNAMREF le fichier xml principal pour XIos (amené à Xios sous le nom iodef.xml)

En général, on souhaite que Xios fonctionne avec un ou plusieurs process serveur, on indique alors le nom du binaire par le paramètre IOSEXE et le nombre de serveurs par NPROC_IOS

Eclis réalise une copie, dans le répertoire de relance, des fichiers désignés par OTHER_FILES ( utilisé pour désigner les autres fichiers xml référencés par le fichier racine) ; il copie ces fichiers dans le répertoire d’exécution en y changeant le mot-clé @IOXDIR@ par le nom du répertoire où Eclis veut que Xios mette les sorties, et ira les chercher.

On peut indiquer comment identifier les listings Xios qu’Eclis gérera, par la variable IOSLISTOUT (exemple de valeur "xios_client*.out xios_server*.out")

Eclis gère les sorties Xios par deux mécanismes : IOS et IOX

• Le mécanisme IOS est historiquement le premier. Il est activé par LIOSOUT=1. Il peut s’appliquer aux deux modes d’utlisation de Xios (avec /sans ’append’). D’abord utilisé pour CMIP6, il y a ensuite été supplanté par un autre mécanisme (IOX=1, cf ci-dessous) . Il reste utilisable (mais pas conjointement avec le mécanisme IOX).

• Le mécanisme IOX est celui développé pour CMIP6. Il est activé par LIOXOUT=1. Il comporte deux variantes, celle dite ’purement incrémentale’ (LIOXSAFE=0) où Xios crée des fichiers pouvant couvrir de très longues durées, et celle dite ’à assemblage’ (LIOXSAFE=1) où Eclis pilote l’assemblage des sorties

Mécanisme IOS

Pendant le step 2, en fin de chaque run modele, les fichers du rundir qui sont listés par "ls IOSOUTPATT" sont déplacés vers le répertoire FTIOSOUT (dont le nom est spécifique de la première date simulée du job).

Pendant le step 3, le contenu de ce répertoire est traité par le script POSTIOS (exemple toolbox/postiox_inc.sh) qui reçoit en argument une série de paramètres de fonctionnement, et qui doit in fine alimenter un fichier indiquant une liste de fichiers à sauvegarder sur machine d’archivage, et un autre indiquant la liste des fichiers qu’il faudra ensuite supprimer (ces deux fichiers de compte-rendus ont des noms forunis en argument d’appel du script).

Ce script peut typiquement réaliser des regroupements de périodes (et peut utiliser comme tampon le répertoire IOXDIR), il peut aussi renommer les fichiers pour que leur nom corresponde à leur contenu (en terme de période couverte, pour le cas ou XIos est utilisé en mode ’append’). C’est le cas du script TOOLBOX/postxios_inc.sh. Le script TOOLBOX/postxios_month.sh correspond lui au cas où on demande à Xios de créer des fichiers mensuels qu’on veut garder mensuels. Il comporte aussi en commentaire la spécification des attendus de tels scripts. Le script TOOLBOX/postxios_year.sh réalise des regroupements annuels de fichier mensuels

Détails
- Pour le nom des fichiers de sortie, les spécifications xml ne doivent pas utiliser la chaîne @IOXDIR@, ni mentionner de répertoire , de manière à ce que le script POSTIOS, qui tourne dans le répertoire d’exécution de la simulation, y trouve les sorties Xios (ou alors, IOSOUPATT doit le prendre en compte)
- La gestion explicite des restarts Xios d’un job à l’autre, qui figure dans le mécanisme IOX (cf infra), n’est pas activée dans ce cas IOS. Cela a sans doute qlq effets de bords quand on fait travailler Xios en mode incrémental (comme découper davantage les fichiers que ce qu’on aurait souhaité)

Mécanisme IOX

IOX - version purement incrémentale (LIOXSAFE=0)

Dans ce cas, c’est Xios qui décide du découpage temporel des fichiers, en fonction des spécifications xml. Et on tire parti du fait que Xios sait compléter des fichiers d’un run du modèle au run suivant (que ce soit dans le même job ou pas), pour créer d’emblée des fichiers pouvant couvrir jusqu’à toute la période de la simulation. Ceci implique de d’introduire un mécanisme qui permet de compléter des fichiers de sortie, éventuellement en allant les chercher sur machine d’archivage (par exemple pour les reprises). Cette récupération éventuelle de fichiers à compléter est réalisée par le script auxiliaire TOOLBOX/giftc.py.

Comme on a souhaité que les fichiers sur hendrix portent des noms qui incluent la période effectivement couverte par les données qu’ils contiennent, il exitse un mécanisme de renommage de ces fichiers, qui est implémenté dans un script désigné par POSTIOX (exemple : toolbox/postxios_inc.sh).

Ce script analyse aussi quels sont les fichiers dits ’complets’, c’est-à-dire que Xios n’est pas susceptible de re-créer par son run suivant, il les déplace depuis IOXOUTDIR=IOXDIR=RELDIR/ftexp/iox vers le répertoire $IOXDIR.$RESDATE qui est sauvegardé pendant le step3 par le script TOOLBOX/pcif.py, et il les liste dans un fichier ’complete_files’ utilisé pour en faire une copie dans IOXKEEPDIR quand LIOXKEEP=1. Le script giftc.py gère aussi la table de correspodance entre les noms ’xios’ et les noms ’hendrix’ des fichiers, laquelle prend la forme d’un fichier texte $RELDIR/iox_index. Ce fichier est utilisé par le script pcif.py qui va en tant que de besoin chercher des fichiers à compléter sur hendrix

En mettant LIOXKEEP à 1 on accumule les fichiers ’complets’ dans IOXKEEPDIR, et on peut activer une phase de contrôle en fin de simulation par le script assemble_and_QC (cf infra - il ne fait alors pas d’assemblage).

Un mécanisme de ’backup’ a été ajouté dans ce cas purement incrémental ; il a pour but d’éviter qu’une longue simulation doive être refaite pour le seul motif qu’un des fichiers couvrant une logue période se retrouverait irrémédiablement corrompu à cause d’un plantage du modèle ou du système. Le principe est d’activer à intervalle régulier le mécanisme d’envoi des fichiers complets même sur les fichiers incomplets. L’intervalle en question est exprimé en mois dans le paramètre IOXSAVEPER. Cette valeur doît être compatible avec la période de sauvegarde des restarts des modèles (la valeur 0 désactive le mécanisme).

Ce mécanisme de backup s’est avéré compliquer la manière de gérer une expérience ; cela comporte la gestion d’un fichier RELDIR/iox_backups listant les dates de backup, et la génèse d’un script TOOLBOX/brelan (auto-documenté) qui sache redémarrer une simulation d’une date de backup. Refaire tourner une partie de simulation seulement s’avére encore plus compliqué. Ces points, plus la charge importante sur la machine d’archivage que représentent les opréations de backup, ont motivé le développemnt de la variante décrite plus loin.

A noter que dans ce cas, Eclis doit aussi gérer les restarts Xios (de nom IOXRESIO=xios_registry.bin), comme les restarts d’un modèle.

IOX - version avec assemblage (LIOXSAFE=1)

Ce cas fonctionne sous l’hypothèse que les fichiers xml sont tels que tous les fichiers de sortie Xios couvrent au maximum la période simulée par un job Eclis, et qu’on va ensuite assembler toute les sorties . La condition est remplie quand un mécanisme (comme dr2xml) fixe (dans les spécifs xml) les ’split_last_date’ de manière adéquate. Cela peut être le cas aussi si ces fichiers xml ne précisent pas de ’split_last_date’ ni de ’split_freq’ (à tester), ou un ’split_freq’ qui corresponde à un sous-multiple de la durée d’un job

Dans ce cas, Eclis fait écrire Xios dans le répertoire IOXOUTDIR=$IOXKEEPDIR/$RESDATE (via @IOXDIR@, cf supra), et lance en fin de run un script TOOLBOX/assemble_and_QC.sh, qui assemble les fichiers de sortie des divers sous-répertoires de IOXKEEPDIR, sauve les résultats sur hendrix (dans un sous-répertoire output_originals de IOXOUTARCH), les post-traite en appelant le script UPOSTPRO, les vérifie en appelant les scripts PREPARE, NCTIME et PNQC, puis sauve les fichiers modifiés sur hendrix

La taille des fichiers après assemblage est piloté par le paramètre ASSEMBLE_MAXSIZE qui représente au choix la taille maximum des sorties, ou le nom d’un fichier donnant, pour chaque couple (variable, table) extrait du nom d’un fichier, la durée maximum de la période couverte par un fchier assemblé.

Les fichiers assemblés sont munis d’une meta-donnée de nom ’tracking_id’ devant (pour certains projets) comporter un identifiant unique de la forme hdl :/$(uuidgen). Le ’handle’ peut être précisé par le paramètre HDL (qui vaut par défaut "21.14100" )

Le script TOOLBOX/assemble_and_QC.sh produit plusieurs listings dans le répertoire RELDIR/listings : un pour lui-même, et un pour chacune des grandes étapes qu’il exécute

Le script TOOLBOX/assemble_and_QC.sh doit parfois être exécuté une nouvelle fois ; pour ça, il est pratique d’utiliser le script TOOLBOX/job_postpros.sh (qui est auto-documenté)

Le répertoire de sorties IOXKEEPDIR n’est pas (pour l’heure) supprimé par assemble_and_QC.sh ni par Eclis, ceci pour sécuriser les résultats bruts de la simulation. Il y a un risque d’encombrer durablement /scratch/work avec de gros volumes

IOX - rappels sur quelques paramètres

• LIOXPUT : (pour le cas LIOX_SAFE=0) le mettre à 0 permet d’inhiber l’envoi des fichiers sur hendrix pendant le run ; pour développements
• LIOXKEEP : (pour le cas LIOX_SAFE=0) : permet de garder dans IOXKEEPDIR une copie des fichiers envoyés sur hendrix ; utile pour activr un contrôle qualité final
• PREPARE : script de contrôle qualité éventuellement lancé en fin de simulation par assemble_and_QC.sh (ex : /scratch/CMIP6/V2/externals/prepare/do_prepare.sh)
• NCTIME : script de contrôle qualité éventuellement lancé en fin de simulation par assemble_and_QC.sh (ex : /scratch/CMIP6/V2/externals/nctime-4.5/nctime_wrapper.sh)
• PNQC : script de contrôle qualité éventuellement lancé en fin de simulation par assemble_and_QC.sh
• HDL (21.14100) : valeur du ’handle’ de la meta-donnée ’tracking_id’ des fichiers de données après assemblage
• LIOXRISKY : le mettre à 1 fait que, après trap de crash, des fichiers Xios incrémentaux potentiellement corrompus ne sont pas effacés (et donc pas remplacés par des backups par la suite)

IOX - quelques variables Eclis (pilotées par Eclis, a priori) :

• IOXDIR (par défaut : RELDIR/ftexp/iox) : répertoire d’écriture de Xios pour le cas LIOXOUT=1 LIOX_SAFE=0
• IOXOUTDIR : répertoire d’écriture pour Xios ; vaut IOXDIR dans le cas LIOX_SAFE=0 (incrémental), et IOXKEEPDIR/$RESDATE dans le cas LIOX_SAFE=1
• IOXKEEPDIR (défaut=/scratch/work/user/outputs/GROUP/EXPID) : répertoire de stockage pérenne des sorties ; n’est alimenté dans le cas LIOX_SAFE=0 que si LIOXKEEP=1