Questions/Réponses
Table des matières
- Compression du nombre de fichiers
- Comment repartir de zéro après un plantage ?
- Comment continuer une simulation ?
- Comment changer le nombre de processeurs/taches
- Comment choisir une execution en mode parallèle ou séquentiel ?
- Où se trouve la sortie du dernier job d'une série ?
- Comment renommer l'intégralité d'une expérience ?
- Comment ajouter ou utiliser des "Patchs" sur les sorties histoires avant les post-traitements ?
- Comment relancer les post-traitements à partir de la "frontale" ?
- Comment relancer les post-traitements à partir de la machine de calcul ?
- Comment avoir les SE pour le coupleur CPL
- Quels sont les principes de base pour relancer un job planté ?
- Messages d'erreur
Compression du nombre de fichiers
concaténation des outputs
à partir de libIGCM rev 429, on peut diminuer le nombre de fichiers texte sauvés pour une simulations.
L'option CompactText (=y/n) de la section UserChoices de la config.card permet d'activer la concaténation des fichiers
textes si le parallélisme est activé. On trouvera alors un unique fichier dans le dépôt ${COMP}/Debug, au lieu de n
fichiers parallèles indicés _000?. Dans cet unique fichier, on aura la liste des n fichiers en première ligne, puis
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.
Par exemple, dans
/dmnfs11/cont003/p86manci/IGCM_OUT/IPSLCM5A/TEST/piControl/PiControl2tIO3/SRF/Debug/PiControl2tIO3_18120101_18120131_out_orchidee sur mercure :
out_orchidee_0000 out_orchidee_0001 out_orchidee_0002 ^L _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | 0 out_orchidee_0000 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 0 nbp_para_nb = 1677 952 223 0 RIVER routing is activated : T [...] 0 net_co2_flux_monthly (Peta gC/month) = 0.8708003690334370 ^L _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | 1 out_orchidee_0001 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 RIVER routing is activated : T [...]
Comment repartir de zéro après un plantage ?
Pour pouvoir relancer un job à zéro il faut :
- effacer le fichier run.card
- effacer le fichier stack si il est créé
- effacer le répertoire temporaire créé sur le scratchdir (pour mercure)
- 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)
Comment continuer une simulation ?
Pour continuer un run au delà des dates existantes, il faut :
- Changer la variable DateEnd dans config.card
- Supprimer le fichier stack :
brodie: rm stack
- Changer la variable PeriodState dans run.card (=OnQueue). Sans cela le job se finit en mettant :
- dans le fichier run.card PeriodState= Fatal
- dans la sortie de Job (Script_Output_...) IGCM_debug_Exit : IGCM_config_PeriodStart Error PeriodState : Completed
- 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 :
- OldPrefix doit correspondre à la dernière date calculée dans le run que vous voulez prolonger
- PeriodDateBegin doit correspondre à la nouvelle date calculée (vous pouvez la retrouver dans le dernier fichier Scrip_output du run)
- PeriodDateEnd doit correspondre à la nouvelle date de fin
Comment changer le nombre de processeurs/taches
- 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.
Comment choisir une execution en mode parallèle ou séquentiel ?
- A l'Idris il faut utiliser la classe multi si on est en parallèle. C'est le fonctionnement par défaut.
- 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.
Où se trouve la sortie du dernier job d'une série ?
- 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}
Comment renommer l'intégralité d'une expérience ?
Note préalable : un job libIGCM/move-and-rename.job permet à présent de faire l'intégralité des opérations
suivantes automatiquement.
Sont utilisation est :
- il faut le recopier dans votre ${SUBMIT_DIR}
- modifier si besoin les champs NEW_SpaceName, NEW_ExperimentName (si ils existent dans votre config.card)
- ensuite modifier le champ NEW_JobName qui donnera le nouveau nom du job, des stockages, des REBUILDs, du MONITORING ...
- enfin indiquer le chemin de votre SUBMIT_DIR
Vous pouvez le soumettre sur votre frontale ou l'exécuter en interactif. Il vous demandera alors de valider les suppressions en confirmation (ATTENTION avant validation).
- Exemple donné pour gaya, idem pour mercure en modifiant le path du rename (~p86denv/CMOR_IPCC-AR4_SCRIPTS/rename)
- 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
rlogin gaya cd IGCM_OUT/IPSLCM4_v2 mv OLD_NAME NewName cd NewName find . -name "*OLD_NAME*" -print -exec ~rces452/rename OLD_NAME NewName {} \;
Comment ajouter ou utiliser des "Patchs" sur les sorties histoires avant les post-traitements ?
Les scripts de Patch servent à corriger les problèmes dans les fichiers histoires, pendant la création des post-traitements.
- Ces scripts sont stockés dans le répertoire libIGCM_post. Dans la version trunk actuelle (en date du 2009-03-23), on a :
- IGCM_Patch_20070220_histcom_time_axis.ksh : sert à transformer le nom du premier axe de temps "t_ave_0086400" en "time_counter"
- IGCM_Patch_20090317_histcom__Fillvalue.ksh : sert à remplacer pour toutes les variables l'attribut _Fillvalue en missing_value
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?
- Pour utiliser ces paths, nous avons implémenté un mécanisme analysant la liste "Patch" dans la composante.card.
Par exemple pour un traitement de sechiba_history.nc :[OutputFiles] List= (sechiba_history.nc, ${R_OUT_SRF_O_M}/${PREFIX}_1M_sechiba_history.nc, Post_1M_sechiba_history) [Post_1M_sechiba_history] Patches = (Patch_20070220_histcom_time_axis, Patch_20090317_histcom__Fillvalue) GatherWithInternal = (lon, lat, veget, time_counter, Areas) TimeSeriesVars = (lai, maxvegetfrac, vegetfrac, [...], drainage)
On appelle donc les deux patchs IGCM_Patch_20070220_histcom_time_axis.ksh et IGCM_Patch_20090317_histcom__Fillvalue.ksh
avant des construire les fichiers SE et TS, uniquement pour tous les fichiers sechiba_history.nc. - Pour créer vos nouveaux patchs, il vous suffit de respecter la nomenclature (IGCM_Patch_ + date + nom_du_patch + .ksh )
et de le placer dans le même répertoire modipsl/libIGCM/libIGCM_Post.
Comment relancer les post-traitements à partir de la "frontale" ?
- 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).
- 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:"
- 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.
- 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.
- 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.
- A adapter à votre cas, et à votre arborescence, bien entendu !
# On prépare le terrain cd ; mkdir -p POST/PDCTLV5 ; cd POST/PDCTLV5 # On prépare un jeu de cartes de référence qui servira pour toute les expériences couplées. # 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. cp -r /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/config/IPSLCM4_v2/PDCTLV5/COMP ../COMPONENT_IPSLCM4_v2 # rcp -r brodie: ... cesium : scp -pr mercure:... # Pour IPSLCM5, il faut recopier ainsi les 2 répertoires COMP et POST. # Notre référence pour les cartes. Ainsi si l'on souhaite ajouter une variable pour 10 simulations, inutile d'éditer 10 fichiers. ln -s ../COMPONENT_IPSLCM4_v2 COMP # LES 2 COMMANDES CI DESSUS NE SONT A FAIRE QU'UNE FOIS PAR CONFIGURATION A PRIORI. # On ramène le config.card de l'expérience que l'on veut post-traiter : cp /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/config/IPSLCM4_v2/PDCTLV5/config.card . # rcp brodie: ... vi config.card # renseigner DateBegin et DateEnd pour vos séries temporelles (create_ts) # renseigner DateEnd et SeasonalFrequency pour les moyennes saisonnières (create_se). # Une seule série sera faite à la fois, la dernière. DateBegin n'est pas utilisé par create_se. # Par exemple avec : DateEnd=1929-12-30 SeasonalFrequency=10Y la série _SE_1920_1929_ cp /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/config/IPSLCM4_v2/PDCTLV5/run.card . # rcp brodie: ... # On ramène les jobs de post-traitements depuis la libIGCM : cp /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/libIGCM/create_ts.job . # rcp brodie: ... cp /work/p86denv/PARA_SX8_ORCA2xLMD9671/SVN/modipsl/libIGCM/create_se.job . # rcp brodie: ... # On configure create_ts.job : 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. # attention à bien remplir le répertoire libIGCM /path/to/your/libIGCM # qsub create_ts.job # llsubmit on ulam
Comment relancer les post-traitements à partir de la machine de calcul ?
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.
- Dans le job SI VOUS COMPTEZ FAIRE QSUB :
DRYRUN=3 # passage post-traitement seulement !PeriodNb=1 # 1 seule période la dernière si vous comptez faire qsub #PBS -l 00:10:00 # réduire les temps CPU demandé si vous comptez faire qsub
- Dans le job SI VOUS COMPTEZ FAIRE DE L'INTERACTIF SUR TX : ksh ./Job_TOTO :
DRYRUN=3 # passage post-traitement seulement RUN_DIR_PATH=/path/to/your/workdir # Le répertoire où va tourner le "mini-run" (crée si besoin) SUBMIT_DIR=$( pwd ) # Le répertoire où se situe le job Job_TOTO
- 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 :
touch PARAM/Bands_96x71x19_-1prc.dat
- 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 :
- Dans le fichier config.card, désactiver le rebuild offline. Mettre :
RebuildFrequency=NONE
- Dans le fichier run.card :
- Pour faire une execution à blanc d'une période : revenir 1 période en arrière (CumulPeriod) et mettre PeriodState à OnQueue ou Running:
#last PREFIX OldPrefix= HOL20_18691130 #Compute date of loop == .suivi PeriodDateBegin= 1869-12-01 PeriodDateEnd= 1869-12-30 CumulPeriod= 120 # State of Job "Start", "Running", "OnQueue", "Completed" PeriodState= OnQueue
- Pour faire une execution à blanc d'une période : revenir 1 période en arrière (CumulPeriod) et mettre PeriodState à OnQueue ou Running:
Toutes ces variables doivent être modifiées pour une relance correcte.
- 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 :
PostState = Start TimeSeriesRunning= n TimeSeriesCompleted= 18601230 SeasonalRunning=n SeasonalCompleted=
Comment avoir les SE pour le coupleur CPL
Il faut relancer les post-traitements en lançant create_se.job comme décrit dans la réponse à cette question-ci après avoir changé NONE en Post_cpl_oce_xxx dans le fichier oasis.card ainsi :
[OutputFiles] -List= (cpl_oce_tau.nc, ${R_OUT_CPL_O_M}/${PREFIX}_cpl_oce_tau.nc, NONE),\ - (cpl_oce_flx.nc, ${R_OUT_CPL_O_M}/${PREFIX}_cpl_oce_flx.nc, NONE),\ - (cpl_oce_sst.nc, ${R_OUT_CPL_O_M}/${PREFIX}_cpl_oce_sst.nc, NONE) +List= (cpl_oce_tau.nc, ${R_OUT_CPL_O_M}/${PREFIX}_cpl_oce_tau.nc, Post_cpl_oce_tau),\ + (cpl_oce_flx.nc, ${R_OUT_CPL_O_M}/${PREFIX}_cpl_oce_flx.nc, Post_cpl_oce_flx),\ + (cpl_oce_sst.nc, ${R_OUT_CPL_O_M}/${PREFIX}_cpl_oce_sst.nc, Post_cpl_oce_sst)
Quels sont les principes de base pour relancer un job planté ?
Note préalable : un job libIGCM/clean_month.job permet à présent de faire l'intégralité des opérations
suivantes automatiquement (sauf la resoumission du job).
Sont utilisation est simple (juste à exécuter dans votre ${SUBMIT_DIR})
et il vous demande de valider les suppressions en confirmation (ATTENTION avant validation).
On doit pour l'instant :
- nettoyer à la main le répertoire d'archive,
- celui de travail et
- modifié le run.card dans le répertoire de soumission.
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.
Détails des trois étapes :
- 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 :
cd ${R_SAVE} find . -name "*198602*" find . -name "*198602*" -print -exec rm -f '{}' \;
/!\ Attention :
- la seconde commande est destructive ! Ã manipuler avec beaucoup de prudence.
- 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.
- Suivant les machines et l'état de la variable RUN_DIR_PATH, il faut nettoyer le répertoire de travail :
- Supprimer les fichiers de la racine du RUN_DIR_PATH
cd ${RUN_DIR_PATH} find . -type f -maxdepth 1 find . -type f -maxdepth 1 -print -exec rm -f '{}' \;
/!\ Attention : la seconde commande est destructive ! Ã manipuler avec beaucoup de prudence.
- 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.
cd ${R_OUT_SCR} find . -name "*198602*" find . -name "*198602*" -print -exec rm -f '{}' \;
/!\ Attention : la seconde commande est destructive ! Ã manipuler avec beaucoup de prudence.
- Modifier PeriodState dans le run.card et le placer soit à Running, soit à OnQueue.
Enfin une bonne idée est de ressoumettre le job avec la sortie numérotée correctement :
qsub -o Script_Output_${JobName}.${CumulPeriod} Job_${JobName}
Messages d'erreur
Message d'erreur | Remède |
IGCM_debug_Exit : IGCM_config_PeriodStart Error PeriodState : Fatal | Pour repartir du début, supprimer le fichier run.card. Voir paragraphe 6 |
IGCM_debug_Exit : IGCM_config_PeriodStart Error PeriodState : Completed | Pour continuer une simulation, modifier le fichier run.card. Voir paragraphe 7 |
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 |
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 |
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 |
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. |
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é |