Changes between Version 17 and Version 18 of libIGCM/DocUtilisateur/FAQ


Ignore:
Timestamp:
03/14/11 09:52:39 (11 years ago)
Author:
mmaipsl
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • libIGCM/DocUtilisateur/FAQ

    v17 v18  
    1 = Questions/Réponses = 
    2 [[PageOutline(2,Table des matières,inline)]] 
     1= Questions/Réponses = 
     2[[PageOutline(2,Table des matières,inline)]] 
    33'''Documentation Utilisateur''' [[wiki:DocUtilisateur Retour au sommaire]] 
    44 
    55---- 
    6  
    7 == Comment repartir de zéro après un plantage ? == 
    8  
    9 Pour pouvoir relancer un job à zéro il faut : 
     6== Compression du nombre de fichiers == 
     7 
     8=== concaténation des outputs === 
     9à partir de libIGCM rev 429, on peut diminuer le nombre de fichiers texte sauvés pour une simulations. 
     10L'option !CompactText (=y/n) de la section !UserChoices de la config.card permet d'activer la concaténation des fichiers 
     11textes si le parallélisme est activé. On trouvera alors un unique fichier dans le dépôt ${COMP}/Debug, au lieu de n 
     12fichiers parallèles indicés _000?. Dans cet unique fichier, on aura la liste des n fichiers en première ligne, puis 
     13page après page (séparateur !^L), la sortie du fichier pour chaque processus avec le numéro du processus dans les premières colones. 
     14Par exemple, dans [[BR]] 
     15/dmnfs11/cont003/p86manci/IGCM_OUT/IPSLCM5A/TEST/piControl/PiControl2tIO3/SRF/Debug/PiControl2tIO3_18120101_18120131_out_orchidee sur mercure :  
     16{{{ 
     17out_orchidee_0000 out_orchidee_0001 out_orchidee_0002 
     18 
     19^L 
     20_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  
     21|  0   out_orchidee_0000 
     22- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
     230 nbp_para_nb =  1677  952  223 
     240 RIVER routing is activated :   T 
     25[...] 
     260 net_co2_flux_monthly (Peta gC/month)  =   0.8708003690334370 
     27^L 
     28_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  
     29|  1   out_orchidee_0001 
     30- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
     311 RIVER routing is activated :   T 
     32[...] 
     33}}}  
     34 
     35== Comment repartir de zéro après un plantage ? == 
     36 
     37Pour pouvoir relancer un job à zéro il faut : 
    1038 1. effacer le fichier run.card 
    11  1. effacer le fichier stack si il est créé 
    12  1. effacer le répertoire temporaire créé sur le scratchdir (pour mercure) 
    13  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 ulam à l'IDRIS) 
     39 1. effacer le fichier stack si il est créé 
     40 1. effacer le répertoire temporaire créé sur le scratchdir (pour mercure) 
     41 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 ulam à l'IDRIS) 
    1442 
    1543== Comment continuer une simulation ? == 
    16 Pour continuer un run au delà des dates existantes, il faut : 
     44Pour continuer un run au delà des dates existantes, il faut : 
    1745 * Changer la variable !DateEnd dans config.card 
    1846 * Supprimer le fichier stack :  
     
    2351  * dans le fichier run.card !PeriodState= Fatal 
    2452  * dans la sortie de Job (Script_Output_...) IGCM_debug_Exit :  IGCM_config_!PeriodStart Error !PeriodState :  Completed 
    25  * Si nécessaire, vérifier dans run.card ce qui a du se faire tout seul au début de l'exécution de la période de simulation suivante : 
    26   1. !OldPrefix doit correspondre à la dernière date calculée dans le run que vous voulez prolonger 
    27   1. !PeriodDateBegin doit correspondre à la nouvelle date calculée (vous pouvez la retrouver dans le dernier fichier Scrip_output du run) 
    28   1. !PeriodDateEnd doit correspondre à la nouvelle date de fin 
     53 * Si nécessaire, vérifier dans run.card ce qui a du se faire tout seul au début de l'exécution de la période de simulation suivante : 
     54  1. !OldPrefix doit correspondre à la dernière date calculée dans le run que vous voulez prolonger 
     55  1. !PeriodDateBegin doit correspondre à la nouvelle date calculée (vous pouvez la retrouver dans le dernier fichier Scrip_output du run) 
     56  1. !PeriodDateEnd doit correspondre à la nouvelle date de fin 
    2957 
    3058== Comment changer le nombre de processeurs/taches == 
    31  * 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. 
    32  
    33 == Comment choisir une execution en mode parallèle ou séquentiel ? == 
    34  * A l'Idris il faut utiliser la classe multi si on est en parallèle. C'est le fonctionnement par défaut. 
    35  * 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. 
    36  
    37 == Où se trouve la sortie du dernier job d'une série ? == 
    38  * 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} 
    39  
    40 == Comment renommer l'intégralité d'une expérience ? == 
    41 '''Note préalable : un job libIGCM/move-and-rename.job permet à présent de faire l'intégralité des opérations  
     59 * 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. 
     60 
     61== Comment choisir une execution en mode parallèle ou séquentiel ? == 
     62 * A l'Idris il faut utiliser la classe multi si on est en parallèle. C'est le fonctionnement par défaut. 
     63 * 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. 
     64 
     65== Où se trouve la sortie du dernier job d'une série ? == 
     66 * 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} 
     67 
     68== Comment renommer l'intégralité d'une expérience ? == 
     69'''Note préalable : un job libIGCM/move-and-rename.job permet à présent de faire l'intégralité des opérations  
    4270suivantes automatiquement.'''[[BR]] 
    4371Sont utilisation est : 
     
    4674 1. ensuite modifier le champ NEW_JobName qui donnera le nouveau nom du job, des stockages, des REBUILDs, du MONITORING ... 
    4775 1. enfin indiquer le chemin de votre SUBMIT_DIR 
    48 Vous pouvez le soumettre sur votre frontale ou l'exécuter en interactif.  
     76Vous pouvez le soumettre sur votre frontale ou l'exécuter en interactif.  
    4977Il vous demandera alors de valider les suppressions en confirmation (ATTENTION avant validation). 
    5078 
    51  * Exemple donné pour gaya, idem pour mercure en modifiant le path du rename (~p86denv/CMOR_IPCC-AR4_SCRIPTS/rename) 
    52  * 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 
     79 * Exemple donné pour gaya, idem pour mercure en modifiant le path du rename (~p86denv/CMOR_IPCC-AR4_SCRIPTS/rename) 
     80 * 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 
    5381 
    5482{{{ 
     
    6189 
    6290== Comment ajouter ou utiliser des "Patchs" sur les sorties histoires avant les post-traitements ? == 
    63 Les scripts de Patch servent à corriger les problèmes dans les fichiers histoires, pendant la création des post-traitements. 
    64  * Ces scripts sont stockés dans le répertoire libIGCM_post. Dans la version trunk actuelle (en date du 2009-03-23), on a : 
    65    * IGCM_Patch_20070220_histcom_time_axis.ksh : sert à transformer le nom du premier axe de temps "t_ave_0086400" en "time_counter" 
    66    * IGCM_Patch_20090317_histcom!__Fillvalue.ksh : sert à remplacer pour toutes les variables l'attribut _Fillvalue en missing_value [[BR]] 
    67      pour assurer la compatibilité avec les anciennes version de ferret (avant la  6.0). Il ne sert que pour des post-traitements sur rhodes. Inutile sur ulam aussi? 
    68  * Pour utiliser ces paths, nous avons implémenté un mécanisme analysant la liste "Patch" dans la composante.card. [[BR]] 
     91Les scripts de Patch servent à corriger les problèmes dans les fichiers histoires, pendant la création des post-traitements. 
     92 * Ces scripts sont stockés dans le répertoire libIGCM_post. Dans la version trunk actuelle (en date du 2009-03-23), on a : 
     93   * IGCM_Patch_20070220_histcom_time_axis.ksh : sert à transformer le nom du premier axe de temps "t_ave_0086400" en "time_counter" 
     94   * IGCM_Patch_20090317_histcom!__Fillvalue.ksh : sert à remplacer pour toutes les variables l'attribut _Fillvalue en missing_value [[BR]] 
     95     pour assurer la compatibilité avec les anciennes version de ferret (avant la  6.0). Il ne sert que pour des post-traitements sur rhodes. Inutile sur ulam aussi? 
     96 * Pour utiliser ces paths, nous avons implémenté un mécanisme analysant la liste "Patch" dans la composante.card. [[BR]] 
    6997   Par exemple pour un traitement de sechiba_history.nc : 
    7098   {{{ 
     
    79107   On appelle donc les deux patchs IGCM_Patch_20070220_histcom_time_axis.ksh et IGCM_Patch_20090317_histcom!__Fillvalue.ksh [[BR]]  
    80108   avant des construire les fichiers SE et TS, uniquement pour tous les fichiers sechiba_history.nc. 
    81  * Pour créer vos nouveaux patchs, il vous suffit de respecter la nomenclature (IGCM_Patch_ + date + nom_du_patch + .ksh )  [[BR]] 
    82    et de le placer dans le même répertoire modipsl/libIGCM/libIGCM_Post. 
    83  
    84 == Comment relancer les post-traitements à partir de la "frontale" ? == 
    85  * 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). 
    86  * L'exemple suivant est donné sur mercure TX7, l'analogie est directe pour ulam ; concernant ulam remplacer les "cp [-r]" par des "rcp [-r] brodie:" 
    87  * L'idée est de créer à sa racine (HOME) un répertoire contenant les cartes de référence de chaque composante (lmdz.card ...), puis de ramener dans un répertoire dédié les config.card des simulations que l'on souhaite post-traiter après coup. 
    88  * Supposons que l'expérience à post-traiter ait été extraite 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. 
    89  * 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éées. 
    90  * A adapter à votre cas, et à votre arborescence, bien entendu ! 
    91  
    92 {{{ 
    93 # On prépare le terrain 
     109 * Pour créer vos nouveaux patchs, il vous suffit de respecter la nomenclature (IGCM_Patch_ + date + nom_du_patch + .ksh )  [[BR]] 
     110   et de le placer dans le même répertoire modipsl/libIGCM/libIGCM_Post. 
     111 
     112== Comment relancer les post-traitements à partir de la "frontale" ? == 
     113 * 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). 
     114 * L'exemple suivant est donné sur mercure TX7, l'analogie est directe pour ulam ; concernant ulam remplacer les "cp [-r]" par des "rcp [-r] brodie:" 
     115 * L'idée est de créer à sa racine (HOME) un répertoire contenant les cartes de référence de chaque composante (lmdz.card ...), puis de ramener dans un répertoire dédié les config.card des simulations que l'on souhaite post-traiter après coup. 
     116 * Supposons que l'expérience à post-traiter ait été extraite 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. 
     117 * 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éées. 
     118 * A adapter à votre cas, et à votre arborescence, bien entendu ! 
     119 
     120{{{ 
     121# On prépare le terrain 
    94122cd ; mkdir -p POST/PDCTLV5 ; cd POST/PDCTLV5 
    95123 
    96 # On prépare un jeu de cartes de référence qui servira pour toute les expériences couplées. 
    97 # C'est au sein des jeux de cartes que l'on définit les variables qui feront l'objet de time series et les fichiers qui feront l'objet de moyennes saisonnières. 
     124# On prépare un jeu de cartes de référence qui servira pour toute les expériences couplées. 
     125# C'est au sein des jeux de cartes que l'on définit les variables qui feront l'objet de time series et les fichiers qui feront l'objet de moyennes saisonnières. 
    98126cp -r /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/config/IPSLCM4_v2/PDCTLV5/COMP ../COMPONENT_IPSLCM4_v2 # rcp -r brodie: ... cesium : scp -pr mercure:...  
    99127 
    100 # Pour IPSLCM5, il faut recopier ainsi les 2 répertoires COMP et POST. 
    101  
    102 # Notre référence pour les cartes. Ainsi si l'on souhaite ajouter une variable pour 10 simulations, inutile d'éditer 10 fichiers. 
     128# Pour IPSLCM5, il faut recopier ainsi les 2 répertoires COMP et POST. 
     129 
     130# Notre référence pour les cartes. Ainsi si l'on souhaite ajouter une variable pour 10 simulations, inutile d'éditer 10 fichiers. 
    103131ln -s ../COMPONENT_IPSLCM4_v2 COMP 
    104132 
    105133# LES 2 COMMANDES CI DESSUS NE SONT A FAIRE QU'UNE FOIS PAR CONFIGURATION A PRIORI. 
    106134 
    107 # On ramène le config.card de l'expérience que l'on veut post-traiter : 
     135# On ramène le config.card de l'expérience que l'on veut post-traiter : 
    108136cp /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/config/IPSLCM4_v2/PDCTLV5/config.card . # rcp brodie: ... 
    109 vi config.card # renseigner DateBegin et DateEnd pour vos séries temporelles (create_ts) 
    110                # renseigner DateEnd et SeasonalFrequency pour les moyennes saisonnières (create_se).  
    111                # Une seule série sera faite à la fois, la dernière. DateBegin n'est pas utilisé par create_se. 
    112                # Par exemple avec : DateEnd=1929-12-30 SeasonalFrequency=10Y la série _SE_1920_1929_ 
     137vi config.card # renseigner DateBegin et DateEnd pour vos séries temporelles (create_ts) 
     138               # renseigner DateEnd et SeasonalFrequency pour les moyennes saisonnières (create_se).  
     139               # Une seule série sera faite à la fois, la dernière. DateBegin n'est pas utilisé par create_se. 
     140               # Par exemple avec : DateEnd=1929-12-30 SeasonalFrequency=10Y la série _SE_1920_1929_ 
    113141cp /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/config/IPSLCM4_v2/PDCTLV5/run.card . # rcp brodie: ... 
    114142 
    115 # On ramène les jobs de post-traitements depuis la libIGCM : 
     143# On ramène les jobs de post-traitements depuis la libIGCM : 
    116144cp /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/libIGCM/create_ts.job . # rcp brodie: ... 
    117145cp /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/libIGCM/create_se.job . # rcp brodie: ... 
    118146 
    119147# On configure create_ts.job :  
    120 vi create_ts.job  # en tout début de script ajouter CompletedFlag=10201230 si vous voulez poursuivre des séries temporelles existantes au dela de 10201230. 
    121                   # attention à bien remplir le répertoire libIGCM /path/to/your/libIGCM  
     148vi create_ts.job  # en tout début de script ajouter CompletedFlag=10201230 si vous voulez poursuivre des séries temporelles existantes au dela de 10201230. 
     149                  # attention à bien remplir le répertoire libIGCM /path/to/your/libIGCM  
    122150# 
    123151qsub create_ts.job # llsubmit on ulam  
    124152}}} 
    125153 
    126 == Comment relancer les post-traitements à partir de la machine de calcul ? == 
    127 Cette 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. 
     154== Comment relancer les post-traitements à partir de la machine de calcul ? == 
     155Cette 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. 
    128156 * Dans le job SI VOUS COMPTEZ FAIRE QSUB : 
    129157{{{ 
    130158  DRYRUN=3         # passage post-traitement seulement 
    131   !PeriodNb=1      # 1 seule période la dernière   si vous comptez faire qsub 
    132   #PBS -l 00:10:00 # réduire les temps CPU demandé si vous comptez faire qsub 
     159  !PeriodNb=1      # 1 seule période la dernière   si vous comptez faire qsub 
     160  #PBS -l 00:10:00 # réduire les temps CPU demandé si vous comptez faire qsub 
    133161}}} 
    134162 * Dans le job SI VOUS COMPTEZ FAIRE DE L'INTERACTIF SUR TX : ksh ./Job_TOTO : 
    135163{{{ 
    136164  DRYRUN=3                           # passage post-traitement seulement 
    137   RUN_DIR_PATH=/path/to/your/workdir # Le répertoire où va tourner le "mini-run" (crée si besoin) 
    138   SUBMIT_DIR=$( pwd )                # Le répertoire où se situe le job Job_TOTO 
    139 }}} 
    140    * Dans ce cas, il faut aussi créer un fichier de ce type : Bands_96x71x19_-1prc.dat ou Bands_144x142x19_-1prc.dat. Un simple touch suffit : 
     165  RUN_DIR_PATH=/path/to/your/workdir # Le répertoire où va tourner le "mini-run" (crée si besoin) 
     166  SUBMIT_DIR=$( pwd )                # Le répertoire où se situe le job Job_TOTO 
     167}}} 
     168   * Dans ce cas, il faut aussi créer un fichier de ce type : Bands_96x71x19_-1prc.dat ou Bands_144x142x19_-1prc.dat. Un simple touch suffit : 
    141169{{{ 
    142170  touch PARAM/Bands_96x71x19_-1prc.dat 
    143171}}} 
    144  * Dans le fichier config.card, désactiver le rebuild offline. Mettre : 
     172 * Dans le fichier config.card, désactiver le rebuild offline. Mettre : 
    145173{{{ 
    146174RebuildFrequency=NONE 
    147175}}} 
    148176 * Dans le fichier run.card : 
    149   * Pour faire une execution à blanc d'une période : revenir 1 période en arrière (!CumulPeriod) et mettre !PeriodState à !OnQueue ou Running: 
     177  * Pour faire une execution à blanc d'une période : revenir 1 période en arrière (!CumulPeriod) et mettre !PeriodState à !OnQueue ou Running: 
    150178{{{ 
    151179 #last PREFIX 
     
    158186 PeriodState= OnQueue 
    159187}}} 
    160 Toutes ces variables doivent être modifiées pour une relance correcte. 
    161   * 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 : 
     188Toutes ces variables doivent être modifiées pour une relance correcte. 
     189  * 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 : 
    162190{{{ 
    163191PostState = Start 
     
    170198== Comment avoir les SE pour le coupleur CPL == 
    171199 
    172 Il 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 : 
     200Il 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 : 
    173201 
    174202{{{ 
     
    183211}}} 
    184212 
    185 == Quels sont les principes de base pour relancer un job planté ? == 
    186 '''Note préalable : un job libIGCM/clean_month.job permet à présent de faire l'intégralité des opérations  
     213== Quels sont les principes de base pour relancer un job planté ? == 
     214'''Note préalable : un job libIGCM/clean_month.job permet à présent de faire l'intégralité des opérations  
    187215suivantes automatiquement (sauf la resoumission du job).[[BR]] 
    188 Sont utilisation est simple (juste à exécuter dans votre ${SUBMIT_DIR}) [[BR]] 
     216Sont utilisation est simple (juste à exécuter dans votre ${SUBMIT_DIR}) [[BR]] 
    189217et il vous demande de valider les suppressions en confirmation (ATTENTION avant validation).''' 
    190218 
    191219 
    192220On doit pour l'instant : 
    193  1. nettoyer à la main le répertoire d'archive, 
     221 1. nettoyer à la main le répertoire d'archive, 
    194222 1. celui de travail et 
    195  1. modifié le run.card dans le répertoire de soumission. 
    196  
    197 Ces trois étapes sont nécessaires car de nombreux fichiers sont sauvés en lecture-seules et ne pourront être écrasé lors de la relance du job. [[BR]] 
    198 Détails des trois étapes : 
    199  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 : 
     223 1. modifié le run.card dans le répertoire de soumission. 
     224 
     225Ces trois étapes sont nécessaires car de nombreux fichiers sont sauvés en lecture-seules et ne pourront être écrasé lors de la relance du job. [[BR]] 
     226Détails des trois étapes : 
     227 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 : 
    200228 
    201229{{{ 
     
    205233}}} 
    206234/!\ Attention : 
    207   a. la seconde commande est destructive ! à manipuler avec beaucoup de prudence. 
    208   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. 
    209  1. Suivant les machines et l'état de la variable RUN_DIR_PATH, il faut nettoyer le répertoire de travail : 
     235  a. la seconde commande est destructive ! à manipuler avec beaucoup de prudence. 
     236  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. 
     237 1. Suivant les machines et l'état de la variable RUN_DIR_PATH, il faut nettoyer le répertoire de travail : 
    210238  * Supprimer les fichiers de la racine du RUN_DIR_PATH 
    211239 
     
    215243 find . -type f -maxdepth 1 -print -exec rm -f '{}' \; 
    216244}}} 
    217 /!\ Attention : la seconde commande est destructive ! à manipuler avec beaucoup de prudence. 
    218   * 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. 
     245/!\ Attention : la seconde commande est destructive ! à manipuler avec beaucoup de prudence. 
     246  * 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. 
    219247 
    220248{{{ 
     
    223251 find . -name "*198602*" -print -exec rm -f '{}' \; 
    224252}}} 
    225 /!\ Attention : la seconde commande est destructive ! à manipuler avec beaucoup de prudence. 
    226  1. Modifier !PeriodState dans le run.card et le placer soit à Running, soit à !OnQueue. 
    227 Enfin une bonne idée est de ressoumettre le job avec la sortie numérotée correctement : 
     253/!\ Attention : la seconde commande est destructive ! à manipuler avec beaucoup de prudence. 
     254 1. Modifier !PeriodState dans le run.card et le placer soit à Running, soit à !OnQueue. 
     255Enfin une bonne idée est de ressoumettre le job avec la sortie numérotée correctement : 
    228256 
    229257{{{ 
     
    231259}}} 
    232260 
    233 == Comment lancer un run guidé (nudge) ? == 
    234 Ce paragraphe s'applique aux configurations contenant LMDZ (testé avec LMDZINCA). 
    235  1. Il faut ajouter un fichier guide.def dans le répertoire PARAM/ de votre répertoire d'expériences 
     261== Comment lancer un run guidé (nudge) ? == 
     262Ce paragraphe s'applique aux configurations contenant LMDZ (testé avec LMDZINCA). 
     263 1. Il faut ajouter un fichier guide.def dans le répertoire PARAM/ de votre répertoire d'expériences 
    236264 
    237265{{{ 
     
    259287 1. Il faut modifier la variable ok_guide dans le fichier PARAM/gcm.def 
    260288 1. Dans COMP/lmdz.card : 
    261   a. Vous devez indiquer les adresses des fichiers de vents avec lesquels vous souhaitez guider votre modèle 
     289  a. Vous devez indiquer les adresses des fichiers de vents avec lesquels vous souhaitez guider votre modèle 
    262290 
    263291{{{ 
     
    274302      (${SUBMIT_DIR}/PARAM/guide.def,.) 
    275303}}} 
    276  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) 
     304 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) 
    277305 
    278306== Messages d'erreur == 
    279 || '''Message d'erreur''' ||''' Remède''' || 
    280 || IGCM_debug_Exit :  IGCM_config_!PeriodStart Error !PeriodState :  Fatal || Pour repartir du début, supprimer le fichier run.card. Voir paragraphe  6 || 
     307|| '''Message d'erreur''' ||''' Remède''' || 
     308|| IGCM_debug_Exit :  IGCM_config_!PeriodStart Error !PeriodState :  Fatal || Pour repartir du début, supprimer le fichier run.card. Voir paragraphe  6 || 
    281309|| IGCM_debug_Exit : IGCM_config_!PeriodStart Error !PeriodState : Completed || Pour continuer une simulation, modifier le fichier run.card. Voir paragraphe 7 || 
    282 || IGCM_debug_Exit :  IGCM_config_!PeriodStart RErun an old job. || Vous tournez une simulation qui a déjà tourné. Arrive en général quand on a oublié de changer le nom du job !JobName dans config.card || 
    283 || sur rhodes : $WORKDIR/IGCM_OUT/*/....out : A la fin : 08/21 16:29:10 Exceeds the processor limit value of 2 processors, using 3 processors. || Attendre le post_traitement suivant ou soumettre à la main le post-traitement || 
    284 || sur rhodes/ulam : $WORKDIR/IGCM_OUT/*/create_TS....out : --Debug1--> Time Series Job allready running exit || Il y a eu un post-traitement qui s'est mal fini sur rhodes/ulam. Brodie : remettre à la main dans run.card !TimeSeriesRunning= n et attendre le post_traitement suivant || 
    285 || IGCM_debug_Exit :  IGCM_config_!PeriodStart RErun an old job. Because of readonly permissions, you can't RErun a job when saved files are still in the ARCHIVE directory. You must deleted those files, or the whole /dmnfs/p86maf/IGCM_OUT/IPSLCM4_v1_OASIS3/HH20D tree. IGCM_debug_Verif_Exit : Something wrong append. EXIT THE JOB. || Penser à mettre DRYRUN=3 pour relancer les post-traitements. || 
    286 ||IGCM_card_!DefineVariableFromOption![111]: Section: not found    IGCM_debug_Exit : ...card is not compatible with libIGCM version 1.0 || Vérifiez que toutes vos cartes (*.card) contiennent bien la section [compatiblity] et que celle ci correspond à la version de libIGCM que vous avez récupéré || 
     310|| IGCM_debug_Exit :  IGCM_config_!PeriodStart RErun an old job. || Vous tournez une simulation qui a déjà tourné. Arrive en général quand on a oublié de changer le nom du job !JobName dans config.card || 
     311|| sur rhodes : $WORKDIR/IGCM_OUT/*/....out : A la fin : 08/21 16:29:10 Exceeds the processor limit value of 2 processors, using 3 processors. || Attendre le post_traitement suivant ou soumettre à la main le post-traitement || 
     312|| sur rhodes/ulam : $WORKDIR/IGCM_OUT/*/create_TS....out : --Debug1--> Time Series Job allready running exit || Il y a eu un post-traitement qui s'est mal fini sur rhodes/ulam. Brodie : remettre à la main dans run.card !TimeSeriesRunning= n et attendre le post_traitement suivant || 
     313|| IGCM_debug_Exit :  IGCM_config_!PeriodStart RErun an old job. Because of readonly permissions, you can't RErun a job when saved files are still in the ARCHIVE directory. You must deleted those files, or the whole /dmnfs/p86maf/IGCM_OUT/IPSLCM4_v1_OASIS3/HH20D tree. IGCM_debug_Verif_Exit : Something wrong append. EXIT THE JOB. || Penser à mettre DRYRUN=3 pour relancer les post-traitements. || 
     314||IGCM_card_!DefineVariableFromOption![111]: Section: not found    IGCM_debug_Exit : ...card is not compatible with libIGCM version 1.0 || Vérifiez que toutes vos cartes (*.card) contiennent bien la section [compatiblity] et que celle ci correspond à la version de libIGCM que vous avez récupéré ||