wiki:libIGCM/DocUtilisateur/FAQ

Version 12 (modified by mafoipsl, 13 years ago) (diff)

--

Questions/Réponses?

Table des matières

  1. Comment repartir de zéro après un plantage ?
  2. Comment continuer une simulation ?
  3. Comment changer le nombre de processeurs/taches
  4. Comment choisir une execution en mode parallèle ou séquentiel ?
  5. Où se trouve la sortie du dernier job d'une série ?
  6. Comment renommer l'intégralité d'une expérience ?
  7. Comment ajouter ou utiliser des "Patchs" sur les sorties histoires avant les post-traitements ?
  8. Comment relancer les post-traitements à partir de la "frontale" ?
  9. Comment relancer les post-traitements à partir de la machine de calcul ?
  10. Comment avoir les SE pour le coupleur CPL
  11. Quels sont les principes de base pour relancer un job planté ?
  12. Comment lancer un run guidé (nudge) ?
  13. Messages d'erreur
Documentation Utilisateur DocUtilisateur Retour au sommaire?


Comment repartir de zéro après un plantage ?

Pour pouvoir relancer un job à zéro il faut :

  1. effacer le fichier run.card
  2. effacer le fichier stack si il est créé
  3. effacer le répertoire temporaire créé sur le scratchdir (pour mercure)
  4. 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)

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 :
rhodes: rm /u/rech/psl/rpsl003/IGCM_OUT/IPSLCM4_v1_OASIS3/VC20/Out/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 :
    1. OldPrefix doit correspondre à la dernière date calculée dans le run que vous voulez prolonger
    2. PeriodDateBegin doit correspondre à la nouvelle date calculée (vous pouvez la retrouver dans le dernier fichier Scrip_output du run)
    3. 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 ?

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.
  • 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 :

  1. nettoyer à la main le répertoire d'archive,
  2. celui de travail et
  3. 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 :

  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 :
 cd ${R_SAVE}
 find . -name "*198602*"
 find . -name "*198602*" -print -exec rm -f '{}' \;

/!\ Attention :

  1. la seconde commande est destructive ! à manipuler avec beaucoup de prudence.
  2. 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.
  1. 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.

  1. 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).

  1. 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
  1. Il faut modifier le fichier PARAM/run.def pour lui indiquer de prendre en compte guide.def
Ajoutez la ligne :
INCLUDEDEF=guide.def
  1. Il faut modifier la variable ok_guide dans le fichier PARAM/gcm.def
  2. Dans COMP/lmdz.card :
    1. 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)\
  1. indiquer dans la liste [ParametersFiles] le fichier guide.def
[ParametersFiles]
List= ....\
      (${SUBMIT_DIR}/PARAM/guide.def,.)
  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)

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 : $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. 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é