wiki:Modipsl_nouv

Nouveautés dans les outils

Index?/Nouveautés



Comment travailler avec les nouveaux types de config

Since July 2012 modipsl work with a new type of configuration (with EXPERIMENT and GENERAL directories).
The main difference is that each configuration now comes with the possibility to run all experiements defined for all sub-configurations that can be formed using the compiled sources. Extraction of a configuration defines the number of components to download and to compile. How To Use It

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_beta4 :

cd modipsl
mv libIGCM libIGCM_old 
svn co http://forge.ipsl.jussieu.fr/libigcm/svn/tags/libIGCM_v2.0_beta4 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

Nouveautés dans libIGCM_v2.0_beta4

  • correction bug sur la gestion du quota nécessaire pour une simulation
  • Amélioration pour la gestion des fichiers stations (pour LMDZ)

Nouveautés dans libIGCM_v2.0_beta3

  • possibilité d'utiliser un restart stocké avec le pack_restart
  • possibilité d'avoir des packFrequency en mois
  • permet de gérer les simulations d'ensemble de type hindcast/forecast mais nécessite de travailler avec une branche de modipsl. (voir avec Sonia Labetoul ou Sebastien Denvil)

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 tarre le répertoire créé par ce dernier et le sauve dans le répertoire ${R_OUT_EXE} et le préfixe ${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éfixe 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 supplé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 :

  1. construction du modipsl à jour
  2. récupération du premier tar (pour le source du départ)
  3. on dépaque ce tar pour installer le source et la config (utilisation de scrip_recup_model)
  4. suppression du répertoire temporaire
  5. compilation des exécutables
  6. détection du tar suivant (date dans le préfixe)
  7. modification du config.card dans le répertoire de la configuration (date du prochain arrêt). On sauvegarde la date finale originale
  8. lancement du job
  9. et on boucle ces opérations à partir de la seconde étape.
Last modified 11 years ago Last modified on 03/05/13 11:18:40