Version 4 (modified by mmaipsl, 12 years ago) (diff) |
---|
Nouveautés dans les outils
Comment changer la version de libIGCM
- Nécessaire, par exemple, suite au changement d'archivage au CCRT (passage DMFDIR -> CCCSTOREDIR/CCCWORKDIR)
- Quand un nouveau tag libIGCM est sorti et qu'il a été recommandé de le prendre
D'abord enlever l'ancien libIGCM et extraire le nouveau tag, ici le tag libIGCM_v2.0_beta2 :
cd modipsl mv libIGCM libIGCM_old svn co http://forge.ipsl.jussieu.fr/libigcm/svn/tags/libIGCM_v2.0_beta2 libIGCM
Ensuite se deplacer dans le repertoire d'experience, effacer (ou sauvegarder) les vieux jobs et refaire les nouveaux jobs avec ins_job. MYCONFIG pourrait être IPSLCM5A ou LMDZOR_v4 par exemple :
cd ..../config/MYCONFIG/MYEXP mv Job_MYEXP OLDJOB # sauvegarder l'ancien Job ../../../util/ins_job # modifier Job_MYEXP : NbPeriod, mémoire, ... comme déjà fait dans OLDJOB
=> Particularité suite au changement de système d'archivage au CCRT, ajouter dans config.card PackFrequency=1Y. Lire aussi l'exposé https://forge.ipsl.jussieu.fr/igcmg/attachment/wiki/ModipslBeginner1/CCRT_TGCC_expose_2012_04_03.pdf
Sauvegarde automatique des sources
Cette fonctionnalité est pour l'instant désactivé dans libIGCM.
La sauvegarde en cours de production
Le nouveau script libIGCM SaveSourceModifications.job est lancé sur la frontale de la machine de calcul, via la fonction IGCM_config_SaveSourceModifications de libIGCM_config.ksh, au début de la simulation et lorsque la date de l'un des exécutable a changé.
Ceci n'est pas vraiment optimal car en théorie, on devrait testé à chaque itération si l'un des paramètres de la configuration a été modifié (par un checksum sur les fichiers initialement téléchargés par exemple).
Le script SaveSourceModifications.job est donc exécuté sur la frontale (qui a un accès à l'arborescence modipsl et donc aux sources des modèles et à la configuration). Il exécute l'outil de différence ${MODIPSL}/util/script_diff_model. Puis il tar le répertoire créé par ce dernier et le sauve dans le répertoire ${R_OUT_EXE} et le préfix ${config_UserChoices_JobName}_${DatesPeriod} et le nom ${MODIPSL_SAVE_NAME}_certified.tar ou ${MODIPSL_SAVE_NAME}_NOTcertified.tar si le dernier fichier modifié est plus ancien que la dernière date de modification des exécutables dans le job. En effet cette condition entraîne que les données ont pu réellement être produites à partir des modifications enregistrer. Si un fichier source ou un fichier de paramètre a été modifié entre temps, on a pas cette certitude (et donc la certification de la sauvegarde des sources).
Le fonctionnement interne de la sauvegarde des sources
Pour aller un peu plus loin dans l'explication du mécanisme de sauvegarde, on décrit ici les deux utilitaires script_diff_model et script_log_analyse.
Cet outils permettent d'analyser et de fabriquer une copie de l'arborescence modipsl avec toutes les diffs de sources gérés sous CVS ou Subversion par élément téléchargé dans la configuration dans mod.def.
Le script script_log_analyse sert à analyser la dernière configuration récupérée avec la commande model (ie il interprète la dernière configuration sauvée dans le fichier util/log). Il suffit pour l'utiliser de renseigner la variable ${MODIPSL}. Il construit alors une série de tableaux en mémoire (décrit dans le script) donnant les informations nécessaires et suffisantes pour récupérer la bonne version de la composante ou de l'outil, via l'un des deux gestionnaires de révision.
Le script script_diff_model créé un répertoire temporaire de sauvegarde des différences de source (le préfix modipsl_save_diff avec la date de son exécution et représenté par la variable ${MODIPSL_SAVE}). Après avoir exécuter l'outil script_log_analyse décrit précédemment, il parcourt toutes les composantes et outils téléchargés avec la commande model initiale et appelle les outils de diff du gestionnaire de version de la composante pour sauver l'ensemble des différences entre la composante initiale et son état actuel. Il permet aussi de sauver tous les sources suplémentaires dont l'extension est listée dans la variable SUFFIXES :
# Code source suffixe for new file detection SUFFIXES='\(f90\|F90\|f\|F\|h\|h90\|hh\|c\|cc\|inc\|fcm\|path\|cfg\|card\|driver\|def\|def_.*\|txt\|xml\|ksh\|tex\)'
On sauvegarde alors à priori toute modification effectuée depuis la récupération de la composante, jusqu'au lancement de l'exécutable.
La récupération des sources sauvegardés
Le script script_recup_model de modipsl/util permet de récupérer à la main chacun des tarballs sauvegardés avec les données au cours de la production. Il n'y a pour l'instant pas de récupération automatique d'un scénario complet. (Je donne à la fin de ce paragraphe quelques spécifications pour construire un tel job.)
Pour utiliser ce script, placez-vous dans un modipsl vide récent. Il vous faut récupérer une arborescence sauvegardée par script_diff_model et probablement la dépaqueter dans un répertoire temporaire (à supprimer à la fin). Puis simplement exécuter ce script avec le chemin vers ce répertoire temporaire. Le script fait alors les appels checkout (demande de mot de passe possible) comme l'avait fait la commande model - avec les bonnes révisions - et remet en place les fichiers sources ou de paramètres crées entre la récupération initiale et la sauvegarde dans le job.
Pour construire le job de récupération systématique des sources lors d'un scénario complet, les actions à construire sont les suivantes :
- construction du modipsl à jour
- récupération du premier tar (pour le source du départ)
- on dépaque ce tar pour installer le source et la config (utilisation de scrip_recup_model)
- suppression du répertoire temporaire
- compilation des exécutables
- détection du tar suivant (date dans le préfix)
- modification du config.card dans le répertoire de la configuration (date du prochain arrêt). On sauvegarde la date finale originale
- lancement du job
- et on boucle ces opérations à partir de la seconde étape.