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. |
| 10 | L'option !CompactText (=y/n) de la section !UserChoices de la config.card permet d'activer la concaténation des fichiers |
| 11 | textes si le parallélisme est activé. On trouvera alors un unique fichier dans le dépôt ${COMP}/Debug, au lieu de n |
| 12 | fichiers parallèles indicés _000?. Dans cet unique fichier, on aura la liste des n fichiers en première ligne, puis |
| 13 | page après page (séparateur !^L), la sortie du fichier pour chaque processus avec le numéro du processus dans les premières colones. |
| 14 | Par exemple, dans [[BR]] |
| 15 | /dmnfs11/cont003/p86manci/IGCM_OUT/IPSLCM5A/TEST/piControl/PiControl2tIO3/SRF/Debug/PiControl2tIO3_18120101_18120131_out_orchidee sur mercure : |
| 16 | {{{ |
| 17 | out_orchidee_0000 out_orchidee_0001 out_orchidee_0002 |
| 18 | |
| 19 | ^L |
| 20 | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
| 21 | | 0 out_orchidee_0000 |
| 22 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| 23 | 0 nbp_para_nb = 1677 952 223 |
| 24 | 0 RIVER routing is activated : T |
| 25 | [...] |
| 26 | 0 net_co2_flux_monthly (Peta gC/month) = 0.8708003690334370 |
| 27 | ^L |
| 28 | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
| 29 | | 1 out_orchidee_0001 |
| 30 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| 31 | 1 RIVER routing is activated : T |
| 32 | [...] |
| 33 | }}} |
| 34 | |
| 35 | == Comment repartir de zéro après un plantage ? == |
| 36 | |
| 37 | Pour pouvoir relancer un job à zéro il faut : |
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 |
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 |
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]] |
| 91 | Les 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]] |
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 |
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_ |
| 137 | vi 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_ |
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 : |
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 | |
| 225 | 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]] |
| 226 | Dé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 : |
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 : |
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é || |