Scripts créés pour l'ipsl_pack - Archivage des fichiers Output

Idée de base :
Nous allons regrouper les fichiers stockés dans les répertoires Output à l'aide de la commande ncrcat.

Problématique :

1- connaître la taille du pack
2- créer les listes des fichiers à packer

Déterminer la taille d'un "pack"

/home/cont003/p86cozic/SCRIPTS_DEM/find_size_pack_4.job

• $1 = une config_card créée par create_config_card_2.job
• $2 = le path d'un fichier information_dmnfs

Pour cette première approche j'utilise le fichier information_dmnfs_2011-09-21 créé par le ccrt et indiquant pour chaque fichier (présent sur le dmnfs au 21 septembre 2011) sa taille. Il faudra réfléchir ensuite pour savoir si on demande au ccrt de refaire cette capture du dmnfs au moment de la copie sur l'espace tampon, où si on développe une version du code travaillant sur l'architecture directement.

Déroulement du script :

• lecture dans config_card (créé par le script create_config_card_2) de
  • JobName
  • PATH_SIMUL
  • DateBegin
  • DateEnd
• à partir du fichier information_dmnfs on cherche la liste des paths des fichiers stockés dans les répertoires Output de cette simulation >> création d'un fichier $SCRATCHDIR/tmp_$JobName/info_Output.txt
• à partir de info_Output.txt on retrouve tous types de fichiers de sorties (1D_histday.nc, 1M_histmth.nc etc...) Cette liste est stockées dans $SCRATCHDIR/tmp_$JobName/info_name_file.txt
• pour chaque type de fichier (dans info_name_file.txt) on crée la liste des paths de ces fichiers là et on la classe par ordre alphabétique. 1ère colonne : taille du fichier, 2ième colonne : path du fichier.
• On suppose une fréquence de pack de 20 ans et une taille de pack comprise entre 20 et 70 Go. A partir de la fréquence de pack on calcul les dates des différents pack et pour chaque type de fichiers on stocke la liste et la taille des fichiers qui serait compris dans chaque pack.
• A ce stade là on a pour chaque type de fichier et pour chaque période de pack la taille qu'aurait ce pack. Soit la taille du pack est bien comprise entre 20 et 70Go et on conserve une fréquence de 20 ans, soit elle est plus petite ou plus grande et à l'aide d'une règle de 3 on calcule la fréquence idéale.
• La nouvelle fréquence de pack sera la plus petite de toutes celles calculées pour tous les types de fichiers et toutes les périodes.

Remarques / Questions

• on cherche la fréquence idéale pour les packs en testant 10 périodes. On passe ainsi en revue 100 ans de simulations (20x10). Est-ce suffisant ?
• on laisse de côté mesh_mask qui est un cas particulier. Ne pas oublier de le traiter ultérieurement.
• si il n'y a qu'une seule période pack de traitée (donc pour les simulations < 20 ans) on calcule d'abord combien d'années comprend cette période avant de regarder si la taille convient et d'éventuellement calculer une fréquence idéale.
• Faut-il continuer à travailler avec information_dmnfs ?

Création des listes de fichiers à packer

/home/cont003/p86cozic/SCRIPTS_DEM/write_liste_pack.job

• $1 = une config_card créée par create_config_card_2.job
• $2 = le path d'un fichier information_dmnfs

Maintenant que l'on connaît la fréquence idéale pour un pack on peut créer les listes de fichiers par type d'output pour passer en argument à ncrcat.

• Les listes sont créées en reprenant la boucle principale du script permettant de calculer la fréquence du pack.
• Par défaut toutes les listes sont nommées $SCRATCHDIR/tmp_$JobName/ncrcat_${type_file}_${date_debut_pack}_${date_fin_pack}.list.
• On recherche les trous potentiels dans la simulation
  • on liste les années comprises entre DateBegin et DateEnd >> liste_date.txt
  • on vérifie la simulation pour savoir si les sorties sont annuelles ou mensuelles.
    • si elles sont mensuelles on complète la liste des dates avec pour chaque années tous les mois (1900 devient 190001, 190002, ...., 190011, 190012)
    • si elles sont annuelles on complète la liste des dates avec uniquement les mois de janvier (1900, 1901, deviennent 190001, 190101 etc...)
  • pour chaque fichier de chaque type de fichier Output on extrait la date de début de sa période à laquelle on retranche son jour (histday_19000101_19000131.nc donne 190001, histday_19000101_19001231.nc donne 190001)
  • on compare nos deux listes pour connaître les mois / années manquante. Et pour chacune on transforme le fichier ncrcat_.list contentant cette date en fichier tar_.list.

Remarques / Questions

• Ces fichiers de liste contiennent actuellement l'arborescence sur le dmnfs. Et elles sont créées à partir du fichier information_dmnfs.
• Est-il possible pour une même simulation d'avoir des fichiers annuels et mensuels ? Ce cas pour l'instant n'est pas traité
• 4 points sur ncrcat :
  • gestion du grand nombre d'entrée. Possible en utilisant le pipe ou xargs Lire : ​http://nco.sourceforge.net/nco.html#Large-Numbers-of-Files. On pourra plutôt utiliser le pipe via un :$ cat filelist.txt | ncrcat
  • sorties hétérogènes sur le nombre de variables présentes Soit 2 fichiers à concaténer.
    • a) si f1.nc a plus de variables que f2.nc alors ncrcat détecte une erreur.
    • b) si inverse f1.nc a moins de variables que f2.nc alors ncrcat f1.nc f2.nc fait le travail mais uniquement sur la liste des variables du premier fichier.
  • vérification du ncrcat en interne Relance aujourd'hui: Lire ​http://sourceforge.net/projects/nco/forums/forum/9829/topic/4824185
  • ncrcat ou cdo -cat d'ailleurs pour faire le boulot ? Il me semble qu'on ne peut utiliser cdo qui ne conserve pas les metadata initiale. Mais il faut conserver cette justification.

Consolidation (A faire)

• Vérifier qu'un tar est bien complet
• Vérifier qu'un pack est bien complet
• Si le pack s'arrête pendant la phase de pack et tar, comment savoir d'où repartir (Idée : création d'un listing sur ce qui doit être fait au final et voir ce qui est déjà fait)
• Si le pack s'arrête pendant la phase de calcul de la fréquence ou d'écriture des listes ? Repartons à zéro ?

Fonctionnement du pack

• le CCRT copie un dmnfs sur l'espace tampon
• si l'on décide de traiter avec le pack toutes les simulations sous IGCM_OUT, pas besoin de faire de commande ccc_archive avec ipsl_pack comme option
• On passe l'ipsl_pack sur le répertoire IGCM_OUT d'un utilisateur : il packe ce qu'il peut et efface au fur et à mesure les données de l'espace tampon
• on conserve une trace des listes ncrcat et tar pour indiquer à l'utilisateur comment son compte est packé
• si certaines simulations sont trop petites (test sur quelques jours par exemple) elles ne sont pas packées et on les laisse sur l'espace tampon
• le ccrt passe ensuite ses propres chaînes (ccc_archive et tar par défaut) sur toutes les données restantes sur l'espace tampon