| Version 13 (modified by mafoipsl, 15 years ago) (diff) |
|---|
Questions/Réponses?
Table des matières
- 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é ?
- Comment lancer un run guidé (nudge) ?
- Messages d'erreur
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 ?
- 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: ...
# 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 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
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é ?
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}
Comment lancer un run guidé (nudge) ?
Ce paragraphe s'applique aux configurations contenant LMDZ (testé avec LMDZINCA).
- Il faut ajouter un fichier guide.def dans le répertoire PARAM/ de votre répertoire d'expériences
Type de fichier guide.def : ncep=.false. # true si necp , false si ecmwf guide_u= y guide_v= y guide_T= n guide_P= n guide_Q= n ini_anal=.true. tau_min_u=0.0208333 tau_max_u=0.1 tau_min_v=0.0208333 tau_max_v=0.1 tau_min_T=0.0208333 tau_max_T=10
- Il faut modifier le fichier PARAM/run.def pour lui indiquer de prendre en compte guide.def
Ajoutez la ligne : INCLUDEDEF=guide.def
- Il faut modifier la variable ok_guide dans le fichier PARAM/gcm.def
- Dans COMP/lmdz.card :
- Vous devez indiquer les adresses des fichiers de vents avec lesquels vous souhaitez guider votre modèle
[BoundaryFiles]
List= ....\
(/dmnfs/p24data/ECMWF96x72/AN${year}/u_ecmwf_${year}${month}.nc, u.nc)\
(/dmnfs/p24data/ECMWF96x72/AN${year}/v_ecmwf_${year}${month}.nc, v.nc)\
- indiquer dans la liste [ParametersFiles] le fichier guide.def
[ParametersFiles]
List= ....\
(${SUBMIT_DIR}/PARAM/guide.def,.)
- 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)
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é |
