wiki:Modipsl_exec

Context Navigation

Version 36 (modified by acosce, 13 years ago) (diff)
--

Exécution d'une simulation

Index/Exécution

Exécution d'une simulation
FAQ

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 de soumettre votre job vérifiez une dernière fois les dates et les options de démarrage du fichier config.card.
Méthodes de soumission suivant les machines :

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.

Quels fichiers de sorties sont produits?

Dans config.card, vous pouvez gérer la fréquence de sorties de vos fichiers. Par défaut vous avez :

pour l'atmosphère :
```
[ATM]
WriteFrequency="1M 1D HF"
```

c'est à dire des fichiers mensuels (1 valeur par mois) rangés dans ATM/Ouput/MO, des fichiers journaliers rangés par mois (28,30 ou 31 valeurs) dans ATM/Output/DA et des fichiers haute fréquence (4 valeurs par jour) rangés dans ATM/Ouput/HF.

pour l'océan et le coupleur :
```
[OCE]
WriteFrequency="1M 1D"
```

c'est à dire des fichiers mensuels (1 valeur par mois) rangés dans OCE/Ouput/MO (CPL/Output/MO) et des fichiers journaliers rangés par mois (28, 30 ou 31 valeurs) dans OCE/Output/DA (CPL/Output/DA)

pour la glace de mer, les surfaces continentales et la biogéochimie continentale :
```
WriteFrequency="1M"
```

c'est à dire des fichiers mensuels rangés dans ICE/Ouput/MO, SRF/Output/MO et SBG/Output/MO

Que peut-on demander ?

Vous pouvez enlever une fréquence que vous ne souhaitez pas : HF pour ATM par exemple.
Pour ajouter une fréquence, il faut rajouter le fichier généré dans le fichier COMP.card, rajouter le traitement des paramètres de gestion de cette fréquence dans COMP.driver.
Pour modifier le niveau de sorties de LMDZ, les paramètres lev_histf sont à modifier dans le fichier PARAM/physiq.def_L39 (ou _L19 si vous êtes avec 19 niveaux). Par défaut :
- lev_histhf=2
- lev_histday=2
- lev_histmth=2
Pour modifier les sorties de NEMO, vous pouvez ajouter ou supprimer des variables dans le fichier PARAM/iodef.xml.
- A faire dans la partie 2 : output files definition pour supprimer des variables.
- A faire dans la partie 2 pour ajouter des variables
  - suffisant pour des variables déjà décrites dans la partie 1 : definition of all existing variables
  - en modifiant le code NEMO sinon.
Pour modifier le niveau de sortie d'Orchidee, les paramètres SECHIBA_HISTLEVEL et STOMATE_HISTLEVEL sont à modifier dans PARAM/orchidee.def. Par défaut :
- SECHIBA_HISTLEVEL = 5
- STOMATE_HISTLEVEL=10

FAQ

Download in other formats:

Plain Text