wiki:Modipsl_exec

Version 23 (modified by acosce, 13 years ago) (diff)

--

Exécution d'une simulation

​Retour au sommaire du mode d'emploi

  1. Exécution d'une simulation
    1. Présentation du répertoire d'expérience
    2. Etapes avant la création du job de simulation
      1. config.card
      2. PeriodLength
      3. répertoire COMP
      4. Options dans lmdz.card
      5. répertoire PARAM
    3. Création du job
    4. Exécution de la simulation
    5. Etat de la simulation en cours
    6. Fin de simulation
  2. FAQ Exécution
    1. Le parallelisme et les fichiers Bands
    2. Comment décripter le fichier Script_Output



NOTE avant la première simulation veillez à créer le fichier ~/.forward contenant votre adresse mail, pour que les mails envoyés en fin de simulation soient bien redirigés vers votre boîte mail.

Présentation du répertoire d'expérience

Dans le répertoire de configuration modipsl/config/nom_config (ex : modipsl/config/IPSLCM5A/) vous trouverez 1 sous répertoire de type EXP00
Ce répertoire contient les fichiers nécessaires pour lancer une simulation :

  • un fichier config.card
  • un répertoire COMP/
  • un répertoire PARAM/
  • un répertoire POST/
  • Le fichier config.card contient la fiche d'identité de votre simulation (nom - dates de début et de fin - calendrier ...). Il contient également les options de démarrage : démarrage depuis les états initiaux (par défaut) ou redémarrage depuis une simulation (à soi ou non).
  • Le répertoire PARAM/ contient les fichiers de paramètres nécessaires aux modèles
  • Le répertoire COMP/ contient deux sortes de fichiers : des cartes (.card) et des drivers (.driver).
    • Les drivers ne sont pas à changer, ils indiquent les opérations à faire pour chaque composantes (modèles) de votre configuration.
    • Les cartes contiennent les informations nécessaires pour chaque composante (les fichiers d'états initiaux, les fichiers de conditions aux limites, les fichiers d'émissions ...) ainsi que les indications sur comment gérer les fichiers sorties des composantes (noms des fichiers que l'on veut conserver, et post-traitement qu'on leur associe.)
  • Le répertoire POST/ contient les fichiers de configuration des monitoring. Par exemple pour le modèle couplé nous trouvons les fichiers pour la glace lim2 et stomate.

Vous trouverez plus d'informations sur les cartes là : ​Doc Utilisateur libIGCM



Etapes avant la création du job de simulation

config.card

Avant de créer un job pour votre simulation vous devez indiquer tous les paramètres nécessaires à cette dernière dans le fichier config.card
Voici les rubriques à modifier : 

JobName=_nom_simul_
ExperimentName=pdControl (mettre le nom de l'expérience selon le vocabulaire CMIP5. pdControl par défaut)
SpaceName=DEVT (mettre DEVT, TEST ou PROD) 
DateBegin=_date_debut_simul_
DateEnd=_date_fin_simul_
PeriodLength= indiquez ici la fréquence de lancement de l'exécutable >>> voir ci-dessous après l'exemple 
JobNumProcTot=_nombre_processeurs

Exemple (10 ans): 

JobName=RUN1
DateBegin=1950-01-01
DateEnd=1959-12-30
PeriodLength=1M
JobNumProcTot=4

note : les rubriques ExperimentName et SpaceName sont optionnelles et n'existent pas pour toutes les configurations.

PeriodLength

PeriodLength correspond à la fréquence des fichiers de sorties de votre modèle. Vous avez le choix entre 1 jour, 5 jours, 1 mois ou 1 an (1D, 5D, 1M ou 1Y). Si vous choisissez 1D cela signifie que au bout d'une année de simulation vous aurez 360 fichiers de sorties. Si vous choisissez 1M vous aurez 12 fichiers de sorties, et si vous choisissez 1Y vous aurez 1 fichier de sortie.
Attention il faut impérativement que PeriodLength ne soit pas supérieur à la durée de votre simulation : c'est à dire pour une simulation de 1 mois ne demandez pas une PeriodLength de 1 an.

répertoire COMP

Comme indiqué ci-dessus le répertoire COMP contient une carte par composante (modèle) de votre configuration. Chacune de ces cartes est divisée en différentes parties :

  • [InitialStateFiles] >>>> indique les fichiers d'état initiaux utilisés pour votre simulation (ex start.nc et startphy.nc pour le modèle lmdz)
  • [BoundaryFiles] >>>> indique les fichiers de conditions aux limites (deux parties List pour les fichiers variant avec le temps, et ListNonDel pour ceux qui ne varient pas)
  • [smoothFiles] >>>> Liste de fichiers rechargés toutes les n-périodes de simulations
  • [ParametersFiles] >>>> liste des fichiers de paramètres pour le modèle (stockés dans EXP00/PARAM/)
  • [RestartFiles] >>>> liste des fichiers de restart pour le redémarrage du modèle : cette liste ne doit pas être modifiée
  • [OutputText] >>>> liste des fichiers texte en sortie du modèle
  • [OutputFiles] >>>> liste des fichiers netcdf en sortie du modèle avec le post-traitement éventuel
  • [Post_...] >>>> description des différentes post-traitements.

A chaque fois la syntaxe utilisée est la suivante :

(path_fichier, fichier)
Elle est équivalente à :
cp path_fichier fichier 

exemple :
ListNonDel= (${R_BC}/ATM/${config_UserChoices_TagName}/${RESOL_ATM}/HISTORIQUE/so4.run1850.cdf, .),\

c'est équivalent à 

cp ${R_BC}/ATM/${config_UserChoices_TagName}/${RESOL_ATM}/HISTORIQUE/so4.run1850.cdf .

ATTENTION : il ne faut pas laisser d'espace après le "\". Si jamais vous laissez un espace la ligne qui suit n'est pas prise en compte.
NOTE : dans les cartes fournies avec les modèles nous utilisons régulièrement les variables ${R_BC} et ${R_INIT}. Par défaut elles sont définies ainsi : 

  R_BC = /dmnfs/cont003/p86ipsl/IGCM/BC
  R_INIT = /dmnfs/cont003/p86ipsl/IGCM/INIT

Toute fois si vous le souhaitez vous pouvez écraser ces définitions en redéfinissant R_BC et R_INIT dans le fichier config.card, ou en indiquant les paths complets des fichiers.
Le répertoire /dmnfs/cont003/p86ipsl/IGCM regroupe tous les fichiers d'input pour les différentes configurations.

Options dans lmdz.card

LMDZ_NbPeriod_adjust=3

LMDZ_NbPeriod_adjust permet de définir combien de PeriodLenght on veut utiliser au début d'une simulation pour créer le fichier Bands qui permet d'ajuster au mieux la parallélisation du code. Si jamais on souhaite utiliser un fichier pré-existant il faut indiquer LMDZ_NbPeriod_adjust=0 et préciser le nom du fichier Bands à utiliser.
Voir ​ici pour une description de l'utilisation des fichiers Bands.
Attention au nombre de proc et à la grille précisés dans ce nom. 

ByPass_hgardfou_teta=n
ByPass_hgardfou_mats=n

# To force higher writing level for aerosol.
# LMDZ_Freq_aero : frequency for writing (in PeriodLength : 10Years = 120) ,
# LMDZ_Length_aero : length of writing (in PeriodLength : 1Year = 12).
# To cancel this option put LMDZ_Length_aero=0
LMDZ_Freq_aero=120
LMDZ_Length_aero=12

# Set COSP activation and Outputs frequency (monthly, daily, HF) = y/n
LMDZ_COSP_OK=n
LMDZ_COSP_monthly=y
LMDZ_COSP_daily=y
LMDZ_COSP_hf=n

# Set NMC Outputs frequency (monthly, daily, HF) = y/n
LMDZ_NMC_monthly=y
LMDZ_NMC_daily=n
LMDZ_NMC_hf=n

répertoire PARAM

Ce répertoire contient les fichiers de paramètres des différents modèles. Reportez vous aux documentations scientifiques de chacun de ces modèles pour en connaître les différentes utilisations.



Création du job

Avant de créer votre job, vérifier le fichier config.card.
La création du job se fait avec la commande : 

cd modipsl/util
./ins_job

Cette commande recherche tous les fichiers config.card existant dans des sous-répertoires de modipsl et crée les job associés (en reprenant la rubrique JobName du fichier config.card). Si jamais un fichier du même nom (Job_nom_simul) existe déjà alors un message d'avertissement apparait et le job n'est pas écrasé. Vous devez l'effacer au préalable pour pouvoir le recréer.

Cette commande crée également run.card.init, squelette du fichier run.card qui contiendra l'état d'avancement de la simulation.

Il crée également les jobs de post-traitement, spécifiques à la machine de post-traitement dans le répertoire : modipsl/libIGCM . Ils s'appellent xxxx.job.

Une fois le job créé (Job_nom_simul) vous devez vérifier les entêtes de vos jobs :

Avant de lancer votre simulation il vous reste une dernière étape : vous devez définir la variable PeriodNb dans votre Job. PeriodNb peut être définie comme le nombre maximal de PeriodLength (dans config.card) pouvant être simulée sur le elapstim_req demandé !
exemple : 

PeriodLength=1M
elapstim_req=20:00:00
PeriodNb=12             >>>> cela signifie que sur les 20 heures de temps CPU demandées on pourra faire tenir 12 mois de simulations


Note: Pour vous faire une idée des temps d'exécution nécessaires vous pouvez trouver un récapitulatif des performances du modèle couplé ​ici



Exécution de la simulation

Avant : Vérifier les dates et les options de démarrage du fichier config.card.

Au CCRT Sur mercure : 

cd modipsl/config/IPSLCM5A/EXP00/
ccc_msub Job_nom_simul sur titane et platine
qsub Job_nom_simul sur mercure(s)

A l'IDRIS 

cd modipsl/config/IPSLCM5A/EXP00/
qsub Job_nom_simul


ATTENTION: par défaut des job d'atlas seront lancés à la fin de votre simulation. Ces jobs s'intitulent REBUILDA, TS et SE. Pour en savoir plus voir ​ici



Etat de la simulation en cours

La variable PeriodState du fichier run.card peut vous aider à connaître l'état de votre simulation : 

Start ou OnQueue : run en attente
Running : run en cours d'exécution
Completed : run fini correctement
Fatal : run fini avec un plantage



Fin de simulation

Lorsque votre simulation est finie deux fichiers sont créés dans votre répertoire d'expérience:

  • run.card
  • Script_Output_JobName

Si la simulation s'est mal déroulée vous aurez un troisième fichier :

  • !JobName_date_out_run_file_error qui contient le journal de sortie de votre simulation

Dans la dernière version de libIGCM ce fichier est contenu dans un répertoire Debug/ créé dans votre répertoire d'expérience. Le fichier run.card indique l'état de votre run à la fin de la simulation. Il contient une variable PeriodState qui vous renseigne 

PeriodState= Completed ( = simulation bien finie) 
PeriodState= Fatal (= problème durant la simulation)

Lorsque votre simulation est bien finie les fichiers de sorties sont stockés au path suivant : 

$DMFDIR/IGCM_OUT/_nom_config_/_SpaceName_/_ExperimentName_/_nom_simul_ 
Avec les sous répertoires suivant : 
ATM CPL ICE OCE SRF SBG Out Exe 
MOD = Restart et Output de la composante (ATM, ICE...) 
Out = journaux de sorties du run 
Exe = exécutables utilisés pour le run

Lorsque votre simulation est bien finie, les post-traitements sont lancés et exécutés sur les frontales.



FAQ Exécution

Le parallelisme et les fichiers Bands

Dans LMDZ si le nombre de points par tâche MPI est distribué de façon uniforme, l'équilibrage de charge n'est pas optimum. Il existe une option adjust (dans lmdz.card) qui permet d'indiquer au code que l'on veut qu'il "ajuste" sa répartition des points. Pour cela lors d'un run on mesure le temps passé dans chaque partie du code et on définit la répartition optimum. Cette nouvelle répartition est stockée alors dans le fichier Bands_res_nbProc.dat (dépend de la configuration – de la machine – de la résolution – du nombre de proc).
Idéalement il faut faire une pré-simulation permettant de créer ce fichier (~ 3 mois de simulation). Puis ensuite utiliser ce fichier pour la simulation "maître". Le fichier est stocké dans le répertoire $DMFDIR/IGCM_OUT/nom_config/.../nom_simul/ATM/Debug/
Voir ​ici pour l'utilisation de adjust et du fichier Bands.

A retenir pour IPSLCM5A : Par défaut, le couplé IPSLCM5A, peut tourner sur un nombre quelconque de processeurs. Il crée lui-même le fichier Bands lors des 3 premiers mois de la simulation puis utilise celui du dernier mois. Il est possible d'utiliser le fichier Bands d'une autre simulation, voir paramétrage dans COMP/lmdz.card.

ATTENTION : Pour être certain d'obtenir les même résultats entre deux simulations il faut annuler l'ajustement et la création des fichiers Bands. Il faut utiliser pour les deux simulations le MÊME fichier Bands.



Comment décripter le fichier Script_Output

A la fin de chaque période de simulation un fichier Script_Output correspondant est créé. Ces fichiers comportent trois parties :

  • copies des fichiers d'input
  • exécution
  • copies des fichiers d'output

Ces trois parties sont délimités ainsi : 

#######################################
#       ANOTHER GREAT SIMULATION      #
#######################################

 1ère partie

#######################################
#      DIR BEFORE RUN EXECUTION       #
#######################################

 2ème partie

#######################################
#       DIR AFTER RUN EXECUTION       #
#######################################

 3ème partie

Si à la fin de votre simulation le fichier ​run.card indique qu'il y a eu un problème vous devez analyser votre fichier Script_Output. Il y a plusieurs solutions :

  • si le fichier s'arrête avant le début de la deuxième partie c'est que soit vous n'avez pas effacé un fichier run.card existant, soit l'un des fichiers d'input que vous demandez n'existe pas.
  • si le fichier s'arrête durant la deuxième partie c'est certainement que vous n'avez pas demandé assez de mémoire ou de temps CPU
  • si le fichier est entier c'est soit qu'il y a une erreur lors de l'exécution, soit qu'il y a un problème lors de la copie des outputs.

Si le message suivant apparaît dans la deuxième partie du fichier, c'est qu'il y a un problème lors de l'exécution. 

========================================================================
EXECUTION of : mpirun -f ./run_file > out_run_file 2>&1
Return code of executable : 1
IGCM_debug_Exit :  EXECUTABLE

!!!!!!!!!!!!!!!!!!!!!!!!!!
!! IGCM_debug_CallStack !!
!------------------------!

!------------------------!
IGCM_sys_Cp : out_run_file xxxxxxxxxxxx_out_run_file_error
========================================================================

Si au contraire vous avez le message suivant 

========================================================================
EXECUTION of : mpirun -f ./run_file > out_run_file 2>&1
========================================================================

Il y a alors deux solutions :

  • dans 90% des cas c'est que le problème s'est produit lors de la copie des outputs.
  • dans les 10% restant c'est que vous êtes passé par un garde fou du modèle et que celui-ci s'est fini proprement mais avant

la fin de la simulation. Dans ce cas là si votre modèle propose un journal de sortie autre que celui de la simulation il faut le consulter. Par exemple, le fichier de sortie de l'océan est stocké sur le serveur de fichiers sous ce nom là : 

IGCM_sys_Put_Out : ocean.output xxxxxxxx/OCE/Debug/xxxxxxxx_ocean.output

Sinon (par exemple pour LMDZ ou INCA) votre journal de sortie est confondu avec celui de la simulation et celui-ci n'a pas eu le temps d'être copié sur l'espace de stockage (explication ICI). Si votre simulation a tourné sur le $SCRATCHDIR vous pouvez le récupérer là, sinon vous devez relancer votre simulation sur le $SCRATCHDIR (par défaut elle est sur le $TMPDIR). Pour cette opération il faut modifier la variable RUN_DIR_PATH voir ICI.