Changes between Version 1 and Version 2 of libIGCM/DocUtilisateur/FAQ


Ignore:
Timestamp:
07/24/08 13:21:31 (16 years ago)
Author:
sdipsl
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • libIGCM/DocUtilisateur/FAQ

    v1 v2  
    1  . 
    2 ---- 
    3  . '''Documentation Utilisateur''' [[BR]]  
    4 Date 
    5 ["DocUtilisateur"] 
    6  
    7  . 
    8 ---- 
    9  . '''Sommaire'''  
    10 TableOfContents(5) 
    11 === Questions/Réponses === 
    12  
    13 ==== Comment repartir de zéro après un plantage ? ==== 
     1'''Documentation Utilisateur'''  [wiki:DocUtilisateur] 
     2[[PageOutline(2,Table des matières,inline)]] 
     3 
     4= Questions/Réponses = 
     5 
     6== Comment repartir de zéro après un plantage ? == 
    147Pour pouvoir relancer un job à zéro il faut : 
    158 1. effacer le fichier run.card 
    … …  
    1811 1. effacer le répertoire de sortie $DMFDIR/IGCM_OUT/IPSLCM4_v1_OASIS3/LO1 (pour mercure) ou $HOMEGAYA/IGCM_OUT/IPSLCM4_v1_OASIS3/LO1 (sur rhodes à l'IDRIS) 
    1912 
    20 ==== Comment continuer une simulation ? ==== 
     13== Comment continuer une simulation ? == 
    2114Pour continuer un run au delà des dates existantes, il faut : 
    2215 * Changer la variable !DateEnd dans config.card 
    … …  
    2821  1. !OldPrefix doit correspondre à la dernière date calculée dans le run que vous voulez prolonger 
    2922  1. !PeriodDateBegin doit correspondre à la nouvelle date calculée (vous pouvez la retrouver dans le dernier fichier Scrip_output du run) 
    30  
    3123  1. !PeriodDateEnd doit correspondre à la nouvelle date de fin 
    32 ==== Comment changer le nombre de processeurs/taches ==== 
     24 
     25== Comment changer le nombre de processeurs/taches == 
    3326 * Par défaut AA_job lance une exécution en parallèle sur un total de !JobNumProcTot tâches avec les options fournies par !JobRunOptions. Changer le nombre de processeurs avant de lancer la commande ins_job. Eviter de changer !JobRunOptions. Ces options sont dans le fichier config.card. 
    3427 
    35 ==== Comment choisir une execution en mode parallèle ou séquentiel ? ==== 
     28== Comment choisir une execution en mode parallèle ou séquentiel ? == 
    3629 * A l'Idris il faut utiliser la classe multi si on est en parallèle. C'est le fonctionnement par défaut. 
    3730 * Depuis août 2007, le passage séquentiel/parallèle se fait automatiquement dans AA_job. Attention néanmoins à modifier la compilation qui est parallèle par défaut pour LMDZ et Orchidee dans les configurations récentes. Option -DCPP_PARA. 
    3831 
    39 ==== Où se trouve la sortie du dernier job d'une série ? ==== 
     32== Où se trouve la sortie du dernier job d'une série ? == 
    4033 * La dernière sortie de job, correspondant à la simulation des dernières périodes avant !DateEnd n'est pas rangée sur les serveurs de fichiers. On peut la trouver dans le répertoire de soumission : ${SUBMIT_DIR} 
    4134 
    42 ==== Comment renommer l'intégralité d'une expérience ? ==== 
     35== Comment renommer l'intégralité d'une expérience ? == 
    4336 * Exemple donné pour gaya, idem pour mercure en modifiant le path du rename (~p86denv/CMOR_SCRIPTS/rename) 
    4437 * Je rappelle au passage que les noms d'expérience ne doivent pas contenir d'underscore. Si c'est le cas, ces expériences ne peuvent figurer dans la page mc2 : http://mc2.ipsl.jussieu.fr/PHP/testing.php?exp=PDCTLV1&resolution=false 
    45  {{{ 
     38{{{ 
    4639rlogin gaya 
    4740cd IGCM_OUT/IPSLCM4_v2 
    … …  
    5144}}} 
    5245 
    53 ==== Comment relancer les post-traitements à partir de la "frontale" ? ==== 
     46== Comment relancer les post-traitements à partir de la "frontale" ? == 
    5447 * En utilisant le mode !StandAlone des scripts create_ts.job (création de time series) et create_se.job (création de moyenne saisonnières). 
    5548 * L'exemple suivant est donné sur mercure TX7, l'analogie est directe pour brodie TX7 ; concernant rhodes remplacé les "cp [-r]" par des "rcp [-r] brodie:" 
    … …  
    5750 * Supposons que l'expérience a post-traité ait été extrait dans /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl et qu'il s'agit de la configuration IPSLCM4_v2. L'expérience en question s'appelle par exemple PDCTLV5. 
    5851 * En mode !StandAlone on peut rajouter à loisir des variables dans les *.card, seules les séries temporelles qui n'existent pas sur le serveur de fichiers sont créees. 
    59  {{{ 
     52{{{ 
    6053# On prépare le terrain 
    6154cd ; mkdir -p POST/PDCTLV5 ; cd POST/PDCTLV5 
    … …  
    7972# On ramène les jobs de post-traitements depuis la libIGCM : 
    8073cp /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/libIGCM/create_ts.job . 
    81 #cp /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/libIGCM/create_se.job . 
     74cp /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/libIGCM/create_se.job . 
    8275 
    8376# On configure create_ts.job :  
    … …  
    8780}}} 
    8881 
    89 ==== Comment relancer les post-traitements à partir de la machine de calcul ? ==== 
     82== Comment relancer les post-traitements à partir de la machine de calcul ? == 
    9083Cette façon de faire permet de tester des nouveaux post-traitements en phase d'inclusion dans la chaine ou bien de refaire tourner des post-traitements. Pour cela il faut utiliser la variable DRYRUN du job, la positionner à 3 pour ne passer que dans certaines étapes du job et relancer le job pour la dernière période. 
    9184 * Dans le job SI VOUS COMPTEZ FAIRE QSUB : 
    92  {{{ 
    93   DRYRUN=3                                                              # passage post-traitement seulement 
    94   !PeriodNb=1 # 1 seule période la dernière                  # si vous comptez faire qsub 
    95   #PBS -l 01:00:00 # réduire les temps CPU demandé  # si vous comptez faire qsub 
     85 
     86{{{ 
     87  DRYRUN=3         # passage post-traitement seulement 
     88  !PeriodNb=1      # 1 seule période la dernière   si vous comptez faire qsub 
     89  #PBS -l 01:00:00 # réduire les temps CPU demandé si vous comptez faire qsub 
    9690}}} 
    9791 * Dans le job SI VOUS COMPTEZ FAIRE DE L'INTERACTIF SUR TX OU BIEN SX : ./Job_TOTO : 
    98  {{{ 
     92{{{ 
    9993  DRYRUN=3                                                                                                                                   # passage post-traitement seulement 
    10094  RUN_DIR_PATH=/workdir4/rech/ces/rces452/BABATEST/TESTPOST                                   # Le répertoire où va tourner le "mini-run" (crée si besoin) 
    … …  
    10397 * Dans le fichier run.card : 
    10498  * Pour faire une execution à blanc d'une période : revenir 1 période en arrière (!CumulPeriod) et mettre !PeriodState à !OnQueue ou Running: 
    105   {{{ 
     99{{{ 
    106100 #last PREFIX 
    107101 OldPrefix= HOL20_18691130 
    … …  
    112106 # State of Job "Start", "Running", "OnQueue", "Completed" 
    113107 PeriodState= OnQueue 
    114  }}} 
    115   Toutes ces variables doivent être modifiées pour une relance correcte. 
     108}}} 
     109Toutes ces variables doivent être modifiées pour une relance correcte. 
    116110  * Pour les post-traitements eux-mêmes, réinitialiser !PostState et indiquer qu'il faut relancer les post-traitements en mettant les variables !XxRunning à n. Mettre également la date de fin des séries temporelles déjà réalisées. Par exemple : 
    117   {{{ 
     111{{{ 
    118112PostState = Start 
    119113TimeSeriesRunning= n 
    … …  
    123117}}} 
    124118 
    125 ==== Comment avoir les SE pour le coupleur CPL ==== 
     119== Comment avoir les SE pour le coupleur CPL == 
    126120 
    127121Il faut relancer les post-traitements en lançant create_se.job comme décrit dans la réponse à cette  [http://wiki.ipsl.jussieu.fr/wiki_ipsl/IGCMG/libIGCM/DocUtilisateur/FAQ#head-0d4f6c4387459cf1300a1ffb23786e4c0b0a793a question-ci] après avoir changé NONE en Post_cpl_oce_xxx dans le fichier oasis.card ainsi : 
    … …  
    137131}}} 
    138132 
    139 ==== Quels sont les principes de base pour relancer un job planté ? ==== 
     133== Quels sont les principes de base pour relancer un job planté ? == 
    140134On doit pour l'instant : 
    141135 1. nettoyer à la main le répertoire d'archive, 
    … …  
    146140Détails des trois étapes : 
    147141 1. Pour le répertoire d'archive ${R_SAVE} (donné dans le Script_Output_$jobname), on fait pour un job planté en février (02) 1986 : 
    148  {{{ 
     142{{{ 
    149143 cd ${R_SAVE} 
    150144 find . -name "*198602*" 
    151145 find . -name "*198602*" -print -exec rm -f '{}' \; 
    152146}}} 
    153  /!\ Attention : 
     147/!\ Attention : 
    154148  a. la seconde commande est destructive ! à manipuler avec beaucoup de prudence. 
    155149  a. brodie ne voit pas directement ses répertoires d'archive (situés sur gaya), il faut donc se connecter sur ce dernier serveur pour faire le nettoyage. 
    156150 1. Suivant les machines et l'état de la variable RUN_DIR_PATH, il faut nettoyer le répertoire de travail : 
    157151  * Supprimer les fichiers de la racine du RUN_DIR_PATH 
    158   {{{ 
     152{{{ 
    159153 cd ${RUN_DIR_PATH} 
    160154 find . -type f -maxdepth 1 
    161155 find . -type f -maxdepth 1 -print -exec rm -f '{}' \; 
    162   }}} 
    163   /!\ Attention : la seconde commande est destructive ! à manipuler avec beaucoup de prudence. 
     156}}} 
     157/!\ Attention : la seconde commande est destructive ! à manipuler avec beaucoup de prudence. 
    164158  * Supprimer les derniers fichiers créés dans les sous-répertoires de sauvegarde temporaire, comme pour les répertoires d'archivage. Ceci n'est plus nécessaire. La double copie n'étant plus active pour le moment. 
    165   {{{ 
    166   cd ${R_OUT_SCR} 
     159{{{ 
     160 cd ${R_OUT_SCR} 
    167161 find . -name "*198602*" 
    168162 find . -name "*198602*" -print -exec rm -f '{}' \; 
    169   }}} 
    170   /!\ Attention : la seconde commande est destructive ! à manipuler avec beaucoup de prudence. 
     163}}} 
     164/!\ Attention : la seconde commande est destructive ! à manipuler avec beaucoup de prudence. 
    171165 1. Modifier !PeriodState dans le run.card et le placer soit à Running, soit à !OnQueue. 
    172166Enfin une bonne idée est de ressoumettre le job avec la sortie numérotée correctement : 
    … …  
    175169}}} 
    176170 
    177 ==== Comment lancer un run guidé (nudge) ? ==== 
     171== Comment lancer un run guidé (nudge) ? == 
    178172Ce paragraphe s'applique aux configurations contenant LMDZ (testé avec LMDZINCA). 
    179173 1. Il faut ajouter un fichier guide.def dans le répertoire PARAM/ de votre répertoire d'expériences 
    180  {{{ 
     174{{{ 
    181175Type de fichier guide.def : 
    182176ncep=.false. # true si necp , false si ecmwf 
    … …  
    193187tau_min_T=0.0208333 
    194188tau_max_T=10 
    195  }}} 
     189}}} 
    196190 1. Il faut modifier le fichier PARAM/run.def pour lui indiquer de prendre en compte guide.def 
    197  {{{ 
     191{{{ 
    198192Ajoutez la ligne : 
    199193INCLUDEDEF=guide.def 
    200  }}} 
     194}}} 
    201195 1. Il faut modifier la variable ok_guide dans le fichier PARAM/gcm.def 
    202  
    203196 1. Dans COMP/lmdz.card : 
    204197  a. Vous devez indiquer les adresses des fichiers de vents avec lesquels vous souhaitez guider votre modèle 
    205   {{{ 
     198{{{ 
    206199[BoundaryFiles] 
    207200List= ....\ 
    208201      (/dmnfs/p24data/ECMWF96x72/AN${year}/u_ecmwf_${year}${month}.nc, u.nc)\ 
    209202      (/dmnfs/p24data/ECMWF96x72/AN${year}/v_ecmwf_${year}${month}.nc, v.nc)\ 
    210   }}} 
     203}}} 
    211204  a. indiquer dans la liste [!ParametersFiles] le fichier guide.def 
    212   {{{ 
     205{{{ 
    213206[ParametersFiles] 
    214207List= ....\ 
    215208      (${SUBMIT_DIR}/PARAM/guide.def,.) 
    216   }}} 
     209}}} 
    217210 1. Vous devez indiquer dans config.card le bon calendrier (leap pour prendre en compte les années bisextiles ou noleap pour ne pas en tenir compte) 
    218211 
    219 === Messages d'erreur === 
     212== Messages d'erreur == 
    220213|| '''Message d'erreur''' ||''' Remède''' || 
    221214|| IGCM_debug_Exit :  IGCM_config_!PeriodStart Error !PeriodState :  Fatal || Pour repartir du début, supprimer le fichier run.card. Voir paragraphe  6 ||