wiki:ModipslBeginner

Version 83 (modified by mafoipsl, 15 years ago) (diff)

--

MODIPSL for beginner

(Auteurs : Anne Cozic, Marie-Alice Foujols)
Dernière mise à jour : 08/12/2009


  1. MODIPSL for beginner
    1. Environnements de calculs
      1. IDRIS
      2. CCRT
    2. Extraire modipsl
      1. Mode utilisateur
      2. Mode administrateur
      3. Pour en savoir plus sur SVN
    3. Présentation des répertoires de modipsl
    4. Liste des configurations disponibles via modipsl
    5. Travailler avec une configuration choisie
      1. Extraction
        1. Mots de passe
      2. FCM
      3. Compilation
        1. A qui signaler quand cela ne marche pas?
        2. Options de compilations de LMDZ
      4. Lancer une simulation
        1. Cas general
          1. Présentation du répertoire d'expérience
          2. Etapes avant la création du job de simulation
          3. Création du job
          4. Exécution de la simulation
          5. Le parallelisme et les fichiers Bands
        2. Cas particuliers LMDZ-ORCHIDEE et LMDZ-INCA
          1. Répertoires d'expérience
          2. Création de l'état initial pour LMDZOR
      5. Etat de la simulation en cours
      6. Fin de simulation
        1. Comment lire le fichier ScriptOutput
        2. Comment sont stockés les fichiers de sorties du modèle
        3. Comment regarder les fichiers sur dods
      7. Execution
        1. Relancer une simulation
        2. Poursuivre une simulation
      8. Les post-traitements avec libIGCM
        1. Quels sont les paramètres de lancement des post-traitement?
        2. Où tournent les post-traitements?
        3. Comment vérifier que les post-traitements sont bien passés?
        4. Comment relancer les post-traitements?
        5. Qu'est-ce que rebuild?
        6. Qu'est-ce qu'une Time Series?
        7. Comment ajouter une variable dans les Time Series?
        8. Qu'est-ce qu'un monitoring?
        9. Comment ajouter une figure dans les monitoring?
        10. Qu'est-ce qu'un moyenne saisonnière?
        11. Où voir les atlas?
    6. Questions/Réponses? des autres documentations

MODIPSL pour les débutants

MODIPSL est l'interface d'accès aux modèles de l'IPSL. Cette page résume ce qu'un nouvel utilisateur de MODIPSL doit connaître.
Cette page veut rassembler les informations pour les nouveaux utilisateurs et pointer vers les pages plus complètes de chaque configuration ou de chaque outil quand nécessaire.
N'hésitez pas à consulter la présentation du cours "modipsl" ​ppt (ou ​pdf). Les transparents 24 à 48 reprennent avec des schémas une grande partie des informations qui vous seront données ci-dessous.



Environnements de calculs

IDRIS

​http://www.idris.fr/

Mémo des choses à faire sur un nouveau login à l'IDRIS pour pouvoir préparer et lancer une simulation :

  • PATH sur brodie : ajouter l'accès à svn et fcm : 
    PATH=$PATH:/TXlocal/pub/svn/svn-1.3.1/bin:/home/rech/psl/rpsl035/fcm/bin
  • $WORKDIR sur ulam est très vaste mais non sauvegardé. C'est là que les post-traitements tourneront in fine.
  • $WORKDIR sur brodie peut être étendu largement (50 Go pour le groupe par exemple). Le demander à l'assistance. Pour vérifier l'occupation et la taille : 
    quota_u -w
  • sur ulam, il faut éviter les bavardages affichés lors de la connexion. Vérifier depuis brodie que la commande : rsh ulam pwd renvoie juste une ligne avec le HOME.
  • Il faut faire marcher les transferts brodie/gaya par mfget/mfput. Pour cela utiliser la commande Ftuas sur ulam (permet de faire connaitre le mot de passe gaya à brodie et à toutes les machines).
  • Pour que le stockage sur le serveur dods.idris fonctionne, il faut faire marcher la commande rsh gaya pwd sur ulam. Pour cela remplir le fichier gaya:~/.rhosts (et lui donner les accès rw-------) avec : 
    ulam.idris.fr
ulam
brodie.idris.fr
brodie
  • Pour les accès dods, il faut lancer de plus une commande mfdods sur gaya. Cela crée le lien (24h après la première fois) visible là : ​http://dods.idris.fr/monlogin.
  • Pour donner les accès à tous (755 ou drwxr-xr-x) au WORKDIR de brodie, il faut demander à l'assistance IDRIS pour le niveau /u/rech/grp.

CCRT


Mémo des choses à faire sur un nouveau login au CCRT pour pouvoir préparer et lancer une simulation :

  • PATH sur mercure/platine : ajouter l'accès à fcm : 
    PATH=$PATH:/home/cont003/p86ipsl/fcm/bin  # MERCURE only



Extraire modipsl

Mode utilisateur

svn co http://forge.ipsl.jussieu.fr/igcmg/svn/modipsl/trunk modipsl

Pour vous simplifiez la vie et éviter de retaper cette ligne de commande à chaque nouvelle extraction de modipsl, nous vous conseillons de vous créer un alias : 

alias svn_ano='svn co http://forge.ipsl.jussieu.fr/igcmg/svn/modipsl/trunk modipsl'

La commande d'extraction devient alors juste 

svn_ano

Attention sur vargas (IDRIS) il faut explicitement demander l'accès à svn : module load subversion

Mode administrateur

svn co svn+ssh://yourlogin@forge.ipsl.jussieu.fr/ipsl/forge/projets/igcmg/svn/modipsl/trunk modipsl

D'autres commandes en bas de cette page : ​http://forge.ipsl.jussieu.fr/igcmg/wiki/WikiStart

Pour en savoir plus sur SVN



Présentation des répertoires de modipsl

Après avoir extrait Modipsl vous avez un répertoire contenant 7 sous-répertoires :

  • bin/
  • config/
  • doc/
  • lib/
  • modeles/
  • tmp/
  • util/

Tous ces répertoires sont vides excepté le répertoire doc/ contenant le texte de la licence CECILL (license sous laquelle sont placés les modèles de l'IPSL) et le répertoire util/ qui contient les scripts nécessaire à une installation complète de n'importe quelle configuration disponible des modèles de l'IPSL. 

mod.def         >>>>>> Définition pour chaque configuration de leurs composantes et de leurs tags
model           >>>>>> Extraction des modèles validés disponibles
ins_make        >>>>>> Installation et configuration des Makefiles 
ins_job         >>>>>> Installation et configuration des scripts de lancement

Voir le transparent 26 de la présentation suivante ppt



Liste des configurations disponibles via modipsl

Via modipsl vous pouvez avoir accès à un grand nombre de configurations regroupant différents modèles de l'IPSL. Pour connaître cette liste il vous suffit dans le répertoire util/ de passer la commande suivante : 

cd modipsl/util
./model -h

Pour avoir plus d'informations sur une configuration en particulier (modèles utilisés, versions CVS ou SVN utilisées ...) il faut passer la commande 

./model -h nom_de_la_config

Exemple avec LMDZ4OR_v2 : 

>> ./model -h LMDZ4OR_v2

>> model : LMDZ4OR_v2
 
LMDZ4OR_v2 configuration with parallel LMDZ4 and ORCHIDEE
working configuration
Official beta release
IOIPSL/src svn tags/v2_1_1
LMDZ4 tag LMDZ4_V3_1
ORCHIDEE tag orchidee_1_9_1
LMDZ4OR_v2 svn trunk
libIGCM HEAD
 
model manager email address : blabla@blabla
 
Component 1 : IOIPSL/tags/v2_1_1/src
Tag       1 : HEAD
System    1 : svn
Server    1 : http://forge.ipsl.jussieu.fr/igcmg/svn
Directory 1 : IOIPSL/src
Local Dir 1 : modeles
Component 2 : ORCHIDEE
Tag       2 : orchidee_1_9_1
System    2 : cvs
Server    2 : sechiba@cvs.ipsl.jussieu.fr:/home/ssipsl/CVSREP
Directory 2 : .
Local Dir 2 : modeles
Component 3 : LMDZ4
Tag       3 : LMDZ4_V3_1
System    3 : cvs
Server    3 : lmdzbrowse@cvs.lmd.jussieu.fr:/home/cvsroot
Directory 3 : .
Local Dir 3 : modeles
Component 4 : CONFIG/trunk/LMDZ4OR_v2
Tag       4 : HEAD
System    4 : svn
Server    4 : http://forge.ipsl.jussieu.fr/igcmg/svn
Directory 4 : LMDZ4OR_v2
Local Dir 4 : config
Component 5 : libIGCM
Tag       5 : ?
System    5 : cvs
Server    5 : anonymous@cvs.ipsl.jussieu.fr:/home/ioipsl/CVSROOT
Directory 5 : .
Local Dir 5 : .

La première partie les modèles utilisés dans la configuration ainsi que leurs numéros de version sur CVS ou SVN. Ensuite est donnée l'adresse e-mail du responsable de cette configuration, puis tous les paths des composantes.



Travailler avec une configuration choisie

Dans ce paragraphe nous prendrons comme exemple le modèle couplé IPSLCM4_v2. Les autres configurations utilisant le nouveau modipsl (IPSL_ESM_V1, LMDZ4OR_v2, LMDZINCA_v2, LMDZORINCA) suivent le même principe. Quand des cas particuliers existent nous vous les indiquerons.


Extraction

cd modipsl/util
./model -h               >>>> indique toutes les configurations dispo
./model IPSLCM4_v2       >>>> on choisi d'extraire la configuration IPSLCM4_v2

Lors de cette extraction plusieurs logins et mots de passe vous seront demandés. Pour les récupérer adressez vous au responsable de la configuration (voir ci-dessus model manager email address)
Cette commande récupère sur CVS et/ou SVN les différents modèles composant la configuration demandée. Les sources de ces modèles sont installées dans le répertoire modipsl/modeles/. Pour notre exemple vous obtenez les répertoires suivants :

  • modipsl/modeles/IOIPSL/
  • modipsl/modeles/LMDZ4/
  • modipsl/modeles/OPA/
  • modipsl/modeles/ORCHIDEE/
  • modipsl/modeles/UTIL/

Modipsl installe également ce que l'on appelle une configuration. Elle est dans le répertoire modipsl/config/ (ici modipsl/config/IPSLCM4_v2/).
Cette configuration vous permettra de compiler l'ensemble des modèles, puis de lancer une simulation.


Mots de passe

Pour connaitre les mots de passe d'extraction s'adresser au model manager email address. Il est indiqué lors de la commande 

 ./model -h IPSLCM4_v2


FCM

Certains modèles de l'IPSL utilisent l'outils ​FCM pour gérer la création de leur makefile (modèle LMDZ, modèle INCA ...). FCM n'est pas accessible par défaut sur les machines de calcul. Il est disponible sur les machines de l'IDRIS et du CCRT et vous devez l'ajouter à votre PATH : 

sur mercure
PATH=~p86ipsl/fcm/bin:$PATH
sur brodie
PATH=/home/rech/psl/rpsl035/fcm/bin:$PATH
sur vargas
PATH=/homegpfs/rech/psl/rpsl035/FCM/bin/fcm:$PATH


Compilation

Avant la première compilation des différents modèles de votre configuration vous devez créer les makefiles adaptés à la machine sur laquelle vous travaillez. 

cd modipsl/util
./ins_make

La commande ins_make permet de créer un makefile pour la config. Dans notre exemple modipsl/config/IPSLCM4_v2/Makefile. Ce Makefile contrôle tous les makefiles des différents modèles utilisés.Une fois qu'il est créé vous n'avez pas besoin de le regéner (sauf changement de machine ou d'emplacement de modipsl dans votre architecture).
Vous pouvez ensuite lancer la compilation (résolution par défaut soit ORCA2 et LMDZ 96x95x19) : 

cd modipsl/config/IPSLCM4_v2/
sxgmake

Suivant la configuration sur laquelle vous travaillez le Makefile peut vous proposer différentes résolutions. Pour les connaître vous devez regarder les différentes target dans le fichier Makefile. Pour IPSLCM4_v2 ce sont les suivantes :

  • ORCA2xLMD4443
  • ORCA2xLMD444315
  • ORCA2xLMD444311
  • ORCA2xLMD7245
  • ORCA2lgmxLMD7245
  • ORCA2xLMD9671
  • ORCA2xLMD9695
  • ORCA2lgmxLMD9671
  • ORCA2xLMD14496
  • ORCA2xLMD144142

Lorsque vous savez quelle résolution vous désirez vous pouvez alors lancer la compilation : 

cd modipsl/config/IPSLCM4_v2/
sxgmake resolution_desirée

par exemple 

sxgmake ORCA2xLMD144142

Petit truc : A la fin de la compilation le makefile crée un fichier .resol qui contiendra la résolution de la dernière compilation. Une fois ce fichier créé vous pouvez ensuite relancer les compilations juste avec la commande sxgmake vous n'êtes plus obligé de préciser la résolution.


A qui signaler quand cela ne marche pas?

Si il y a un problème de compilation vous pouvez vous adresser au model manager. Il est indiqué lors de la commande 

 ./model -h IPSLCM4_v2


Options de compilations de LMDZ

Dans le cas des configurations _WORK (IPSLCM5_WORK, LMDZ_WORK...) ou des configurations IPSL_ESM_v2 et LMDZINCA_v3 les options de compilations du modèle LMDZ ont changé : 

makelmdz_fcm [options] -m arch exec
[-h]                       : manuel abrégé
[-d [[IMx]JMx]LM]          : IM, JM, LM sont les dims en x, y, z (def: $dim)
[-p PHYS]                  : compilation avec la physique libf/phyPHYS, (def: lmd)
[-prod / -dev / -debug]    : compilation en mode production (default) / developpement / debug .
[-c false/MPI1/MPI2]       : couplé océan : MPI1/MPI2/false (def: false)
[-v false/true]            : avec ou sans végétation (def: false)
[-chimie INCA/false]       : avec ou sans model de chimie INCA (def: false)
[-parallel none/mpi/omp/mpi_omp] : parallelisation (default: none) : mpi, openmp ou mixte mpi_openmp
[-g GRI]                   : conf. grille dans dyn3d/GRI_xy.h  (def: reg inclue un zoom)
[-io IO]                   : choix d'une librairie I/O, experts (def: ioipsl)
[-include INCLUDES]        : variables supplementaires pour include
[-cpp CPP_KEY]             : cle cpp supplementaires
[-adjnt]                   : adjoint, a remettre en route ...
[-filtre NOMFILTRE]        : prend le filtre dans libf/NOMFILTRE (def: filtrez)
[-link LINKS]              : liens optionels avec d'autres librairies
[-fcm_path path]           : chemin pour fcm (def: le chemin est suppose deja exister dans le PATH)
 -arch nom_arch            : nom de l'architecture cible
 exec                      : exécutable généré


Lancer une simulation

Cas general

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

Dans le répertoire modipsl/config/IPSLCM4_v2/ vous trouverez 1 sous répertoires 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/

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). Voir plus d'informations sur les redémarrages ​pour le couplé IPSLCM4_v2
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 elles contiennent les informations nécessaires pour chaque composantes (les fichiers d'états initiaux, les fichiers de conditions aux limites, les fichiers d'émissions ...) ainsi que comment gérer les fichiers sorties des composantes (noms des fichiers que l'on veut conserver, et post-traitement qu'on leur associe)
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_
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

!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 plus 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)
  • [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 : 

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

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

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.

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 : vérifier le fichier config.card. 

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.

Après : vérifier le fichier Job_nom_simul

N'oubliez pas de modifier les variables elapstim_req et memsz_job en entête de job si nécessaire (voir documentation sur les machines de calculs du CCRT ou les variables cputim_job et memsz_job sur les machines de l'IDRIS). 

#PBS -l memsz_job=6.0gb       # limite memoire
#PBS -l elapstim_req=00:30:00 # limite en temps elapsed

Remarque : Pour connaître les temps autorisés sur les différentes queues de la machine vous pouvez utiliser la commande class au CCRT ou news class à l'IDRIS.
Par défaut la simulation tournera sur le disque tmpdir de la machine. Si vous voulez qu'elle ait lieu sur le scratchir, vous devez modifier la variable RUN_DIR_PATH dans le fichier Job_nom_simul 

RUN_DIR_PATH=$SCRATCHDIR

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 vous pouvez faire passer 12 mois de simulations durant 20h de temps CPU



Exécution de la simulation

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

Au CCRT 

cd modipsl/config/IPSLCM4_v2/EXP00/
ccc_msub Job_nom_simul

A l'IDRIS 

cd modipsl/config/IPSLCM4_v2/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 PostTraitementLibIGCM?

Le parallelisme et les fichiers Bands

Par défaut, le couplé IPSLCM5_v2, peut tourner sur un nombre quelconqiue 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.

Par défaut, pour le couplé IPSLCM4_v2 le nombre de processeurs demandé est le suivant :

IPSLCM4_v2 Nb de processeurs total Nb de processeurs pour LMDZ/ORCHIDEE Nb de processeurs pour OPA et OASIS Fichier utilisé par LMDZ
ORCA2xLMD9671 4 3 1 Bands_96x71x19_3prc.dat

Il est possible de demander le nombre de processeurs suivants pour les résolutions citées.

IPSLCM4_v2 Nb de processeurs total Nb de processeurs pour LMDZ/ORCHIDEE Nb de processeurs pour OPA et OASIS Fichier utilisé par LMDZ
ORCA2xLMD14496 6 5 1 Bands_144x96x19_5prc.dat
ORCA2xLMD144142 6 5 1 Bands_144x142x19_5prc.dat
ORCA2xLMD144142 8 7 1 Bands_144x142x19_7prc.dat

Pour changer le nombre de processeurs utilisés et prendre une des valeurs du tableau précédent (4, 6, 6 ou 8), il faut modifier le parametre JobNumProcTot dans le fichier config.card, juste avant de lancer la commande ins_job. On peut également le changer ultérieurement en modifiant dans le fichier Job_nom_simul le parametre BATCH_NUM_PROC_TOT=

Si vous voulez mettre un nombre de processeurs autre que ceux de la liste, le fichier Bands n'existe pas. Il faut alors modifier les cards pour ne pas aller le chercher et éventuellement modifier LMDZ pour qu'il crée le fichier. Voir : IPSLCM4_v2_PAR. Ce fichier Bands permet d'optimiser votre simulation, mais n'est pas indispensable: votre simulation sera juste un peu plus lente sans lui.

Cas particuliers LMDZ-ORCHIDEE et LMDZ-INCA

Répertoires d'expérience
  • Pour LMDZ4OR_v2 le répertoire d'expérience se nomme LMDZOR
  • Pour LMDZINCA_v2 il y a un répertoire d'expérience par configuration de INCA : EXP_AER, EXP_CH4, EXP_NMHC ....

Plus d'information sur les configs avec le modèle INCA ​ICI

Création de l'état initial pour LMDZOR

Si vous n'avez pas de fichier d'états initiaux pour le modèle couplé celui-ci les crée automatiquement. Ce qui n'est pas le cas pour les configurations LMDZ4OR_v2 et LMDZINCA_v2. Dans ces deux cas vous trouverez un répertoire CREATE/ en plus de votre répertoire d'expérience. Nous allons prendre pour exemple la config LMDZ-ORCHIDEE.
Le répertoire CREATE/ est composé de :

  • un fichier config.card
  • un fichier config.card_Interannuel
  • un sous répertoire COMP/
  • un sous répertoire PARAM/

L'utilisateur peut décider soit de créer un état initial pour un run climato c'est à dire qu'il utilisera pour chaque année de simulation le même fichier de conditions aux limites. Soit de créer un état initial pour un run nudgé c'est à dire qu'à chaque année de simulation correspondra un fichier de conditions aux limites différents prenant en compte les données de sst et de glaces de mer (sic). Nous allons voir maintenant comment procéder dans ces deux cas :

  • RUN CLIMATO

Dans ce cas vous laissez les fichiers tels que vous les avez extraits. 

cd modipsl/config/LMDZ4OR_v2/CREATE/
ls                                >>>> verification des fichiers dans le répertoire CREATE/ (cf ci-dessus) 
cd ../../../util
./ins_job                         >>>> creation du job Job_ELC-$RESOL ($RESOL = la resolution de votre simulation, ex LMD9671) dans le répertoire CREATE/
cd ../config/LMDZ4OR_v2/CREATE
ccc_msub Job_ELC-$RESOL              >>>> soumission du job tel quel

L'état initial ainsi créé sera dans le répertoire $DMFDIR/IGCM_OUT/LMDZ4OR_v2/ELC-$RESOL/ 

ls $DMFDIR/IGCM_OUT/LMDZ4OR_v2/ELC-LMD9671/ATM/Restart/
ELC-LMD9671_19791230_limit.nc   ELC-LMD9671_19791230_start.nc ELC-LMD9671_19791230_startphy.nc

Ensuite avant de lancer votre simulation vous devez vérifier que le fichier modipsl/config/LMDZ4OR_v2/LMDZOR/COMP/lmdz.card renvoie bien vers ces fichiers 

[InitialStateFiles]
List=   (${R_OUT}/${config_UserChoices_TagName}/${CREATE}/ATM/Restart/${CREATE}_19791230_start.nc, start.nc) \
        (${R_OUT}/${config_UserChoices_TagName}/${CREATE}/ATM/Restart/${CREATE}_19791230_startphy.nc, startphy.nc)
[...]
[BoundaryFiles]
ListNonDel= (${R_OUT}/${config_UserChoices_TagName}/${CREATE}/ATM/Restart/${CREATE}_19791230_limit.nc, limit.nc) \
[...]


  • RUN NUDGE

Dans ce cas là vous devez utiliser les fichiers suffixés AMIP. Ils permettent de créer les fichiers aux limites pour les années 1956 à 2005 en utilisant les données AMIP6. 

cd modipsl/config/LMDZ4OR_v2/CREATE
mv config.card_Interannuel config.card
mv COMP/lmdz.card_Interannuel COMP/lmdz.card
cd ../../../util
./ins_job                             >>>> creation du Job Job_ELI-$RESOL
cd ../config/LMDZ4OR_v2/CREATE
ccc_msub Job_ELI-$RESOL

L'état initial ainsi créé sera dans le répertoire $DMFDIR/IGCM_OUT/LMDz4OR_v2/ELI-$RESOL/. Contrairement au cas climato vous obtenez 50 trios "start.nc, startphy.nc et limit.nc" 

ls $DMFDIR/IGCM_OUT/LMDz4OR_v2/ELI-LMD9671/ATM/Restart/
ELI-LMD9671_19561230_limit.nc   ELI-LMD9671_19561230_start.nc   ELI-LMD9671_19561230_startphy.nc 
(...)
ELI-LMD9671_20051230_limit.nc   ELI-LMD9671_20051230_start.nc   ELI-LMD9671_20051230_startphy.nc

Pour votre simulation vous devrez comme précédemment indiquer les path de start et startphy dans le fichier lmdz.card. Mais attention cette fois ci pour le fichier de conditions aux limites il faudra l'indiquer dans la section List et non pas ListNonDel de BoundaryFiles. 

[InitialStateFiles]
List=  (${R_OUT}/${config_UserChoices_TagName}/${CREATE}/ATM/Restart/${CREATE}_${year}1230_start.nc, start.nc) \
       (${R_OUT}/${config_UserChoices_TagName}/${CREATE}/ATM/Restart/${CREATE}_${year}1230_startphy.nc, startphy.nc)
[...]
[BoundaryFiles]
List=(${R_OUT}/${config_UserChoices_TagName}/${CREATE}/ATM/Restart/${CREATE}_${year}1230_limit.nc, limit.nc)


Remarque : Si vous souhaitez utiliser d'autres jeux de données que les données AMIP vous devez modifier le fichier modipsl/config/LMDZ4OR_v2/CREATE/lmdz.card

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_gcm.e_error qui contient le journal de sortie de votre simulation

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/IPSLCM4_v2/_nom_simul_ 
Avec les sous répertoires suivant : 
ATM CPL ICE OCE SRF 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. En savoir plus sur les post-traitements : PostTraitementLibIGCM?

Comment lire le fichier ScriptOutput

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

C'est trois parties sont délimités ainsi : 

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

 1ère partie

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

 2ième partie

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

 3ième partie

Si à la fin de votre simulation le fichier run.card indique qu'il y a eu un problème vous devez lire 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 effacer 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 -np 4 -max_np 4 ./lmdz.x > out_lmdz.x 2>&1
Return code of executable : 1
IGCM_debug_Exit :  EXECUTABLE

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

!------------------------!
IGCM_sys_Cp : out_lmdz.x /workdir2/rech/psl/rpsl592/PRINCE/modipsl/config/LMDZ4OR_v2/LMDZOR/LMDZOR01_19800201_19800230_out_lmdz.x_error
========================================================================

Si au contraire vous avez le message suivant 

========================================================================
EXECUTION of : mpirun -np 4 -max_np 4 ./lmdz.x > out_lmdz.x 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. 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.

Comment sont stockés les fichiers de sorties du modèle

Les sorties de la simulation sont stockées sur le disque de stockage de la machine. Le DMFDIR pour le CCRT, et GAYA pour l'IDRIS.
Modipsl permet de créer une architecture de stockage commune à toutes les configurations de modèles : IGCM_OUT. Cette architecture est ordonnancée de la manière suivante : 

IGCM_OUT/nom_config/nom_experience/repertoires_composantes/

Exemple pour le modèle couplé IPSLCM4_v2 :
IGCM_OUT/IPSLCM4_v2/MonExp/
       - ATM/
       - SURF/
       - ICE/
       - OCE/

Chaque répertoire de composante contient lui-même deux sous-répertoires : Restart/ et Output/ qui comme leurs noms l'indiquent contiennent pour l'un les fichiers de restart et pour l'autre les fichiers d'output de la simulation. En plus de ces deux répertoires il y en a un troisième Debug/ qui contient éventuellement les fichiers textes liés à la simulations (*.def, fichier Bands ...)
En plus de ces répertoires propres aux composantes il y a deux répertoires Exe/ et Out/ contentant pour le premier les copies des exécutables de la simulation, et pour le second une copie des journaux de sorties de la simulation.



Comment regarder les fichiers sur dods

  • A l'IDRIS, il faut aller sur le web à l'adresse : ​http://dodsp.idris.fr/ et choisir son login, sa configuration, sa simulation puis enfin la composante (Output ou Analyse) ou les atlas ou encore le monitoring.
  • Au CCRT, il faut aller sur le web à l'adresse : ​http://dods.extra.cea.fr/data/ et choisir son login, da configuration, sa simulation...
  • Une fois trouvé un fichier netcdf (suffixe .nc), on peut le récupérer en clickant dessus ou l'analyser avec les fonctionalités DODS. Pour cela il faut à son adresse ajouter cgi-bin/nph-dods juste avant son login. Plus d'informations là : ​http://dods.ipsl.jussieu.fr/

Execution

Relancer une simulation

  1. Pour repartir du début, vous devez effacer dans votre répertoire d'expérience les fichiers stack_error (si existant) et run.card.
  2. Vous devez effacer le répertoire $DMFDIR/IGCM_OUT/IPSLCM4_v2/_nom_simul_
  3. Si vous aviez changé la variable RUN_DIR_PATH vous devez également effacer le répertoire correspondant à votre simulation sur votre scratchdir.
  4. Relancer le job



Poursuivre une simulation

Dans le fichier run.card vous devez :

  • vérifier que les variables PeriodDateBegin et PeriodDateEnd correspondent bien à votre prochaine période de simulation
  • indiquer PeriodState = OnQueue
  • Dans le Job vous devez modifier le numéro du fichier de sortie pour qu'il ne se plante pas en cherchant à remplacer un fichier Script_Ouptut existant. Par défaut c'est Script_Output_NomJob.1, vous pouvez le changer par Script_Output_NomJob.CumulPeriod (vous trouverez CumulPeriod dans run.card)




Les post-traitements avec libIGCM

Cette page donne quelques informations sur les post-traitements du couplé IPSLCM5.

Les post-traitements sont des opérations systématiquement lancées en fin de simulation sur les frontales. Il s'agit des rebuild ou assemblage des fichiers créés par sous-domaines par les applications parallèles (LMDZ et ORCHIDEE dans le cas du couplé IPSLCM5. Ils concernent également les fichiers concernés par des Patchs ou modifications systématiques avant stockage (axe des temps, masque terre/océan, ...). Il s'agit des séries temporelles (qui lancent les monitoring) et des moyennes saisonnières (qui lancent les atlas).

Quels sont les paramètres de lancement des post-traitement?

Dans le fichier ​config.card, les variables qui gèrent les post-traitements sont dans la section Post :: 

82	#D-- Post -
83	[Post]
84	#D- Do we rebuild parallel output, this flag determines
85	#D- frequency of rebuild submission (use NONE for DRYRUN=3)
86	RebuildFrequency=1Y
87	#D- Do we rebuild parallel output from archive
88	RebuildFromArchive=true
89	#D- If you want to produce time series, this flag determines
90	#D- frequency of post-processing submission
91	TimeSeriesFrequency=10Y
92	#D- If you want to produce seasonal average, this flag determines
93	#D- the period of this average
94	SeasonalFrequency=10Y
95	#D- Offset for seasonal average first start dates ; same unit as SeasonalFrequency
96	#D- Usefull if you do not want to consider the first X simulation's years
97	SeasonalFrequencyOffset=0
  • RebuildFrequency=1Y indique la fréquence de lancement des travaux REBUILDA. A noter: si JobType=DEV, le paramètre est forcé la valeur de PeriodLength
  • RebuildFromArchive=true indique que les fichiers seront stockés dans leur état initial (par sous-domaine), sur la machine de stockage. Le job REBUILDA commencera par aller les chercher sur le serveur de fichier, avant de les assembler (rebuild), de leur appliquer les Patchs demandés puis de les stocker dans le répertoire usuel COMP/Output/MO ou COMP/Output/DA pour les fichiers mensuels ou journaliers de la composante COMP (OCE, ICE, ATM, SRF, ...).
  • TimeSeriesFrequency=10Y Les séries temporelles seront lancées tous les 10 ans.
  • SeasonalFrequency=10Y Les moyennes saisonnières (des mois de janvier, février,...) seront lancées tous les 10 ans.
  • SeasonalFrequencyOffset=0 Les premières années seront sautées avant de commencer à calculer les moyennes saisonnières.

Où tournent les post-traitements?

Les post-traitements tournent généralement sur les frontales des calculateurs. Il s'agit de travaux systématiques de traitement de fichiers qui n'ont pas leur place sur les calculateurs. Peu d'optimisation, peu de parallélisation massive, ... Sur chaque centre, les machines de calcul ont leur frontale privilégiée.

Centre Calculateur Frontale
CCRT mercure SX8 frontale TX7 mercure
CCRT mercure SX9 cesium
CCRT platine frontale platine
IDRIS brodie ulam
IDRIS vargas ulam

Comment vérifier que les post-traitements sont bien passés?

  • sur ulam, les sorties des post-traitements sont là : $WORKDIR/IGCM_OUT/IPSLCM5/Ma_simulation
  • sur la frontale TX7, ils sont là : $SCRATCHDIR/IGCM_OUT/IPSLCM5/Ma_simulation
  • sur cesium, ils sont là : $SCRATCHDIR/IGCM_OUT/IPSLCM5/Ma_simulation
  • sur la frontale de platine, ils sont là : SCRATCHDIR/IGCM_OUT/IPSLCM5/Ma_simulation

A noter : Les commandes de mise sur dods sont faites à la fin du job de monitoring ou à la fin de chaque atlas.

Comment relancer les post-traitements?

Il existe 2 méthodes pour relancer les post-traitements : relancer le job de rebuild ou relancer le dernier mois de la simu avec DRYRUN=3.

Comment faire est déjà décrit là : ​depuis la frontale et ​depuis le calculateur

Qu'est-ce que rebuild?

  • rebuild est un utilitaire qui permet de recombiner plusieurs fichiers créés par un programme parallèle (sous-domaines) en un seul.
  • rebuild est disponible avec IOIPSL. Voir ​http://forge.ipsl.jussieu.fr/igcmg/browser/IOIPSL/trunk/tools
  • rebuild est installé sur les frontales de l'IDRIS et du CCRT dans les comptes communs. Il est appelé automatiquement à la fréquence RebuildFrequency et représente la toute première étape des post-traitements.

Qu'est-ce qu'une Time Series?

Une Time Serie est un nouveau fichier, qui contient une seule variable sur toute la longueur d'une simulation (!ChunckJob2D = NONE) . Elles sont décrites dans les fichiers COMP/*.card derrière les paramètres !TimeSeriesVars2D et !TimeSeriesVars3D. Les 3D étant très volumineuses, peuvent être produites par période de !ChunckJob3D = 50Y années.

Exemple pour lmdz : 

45	[OutputFiles]
46	List=   (histmth.nc,      ${R_OUT_ATM_O_M}/${PREFIX}_1M_histmth.nc,      Post_1M_histmth), \
...
53	[Post_1M_histmth]
54	Patches= (Patch_20091030_histcom_time_axis)
55	GatherWithInternal = (lon, lat, presnivs, time_counter, aire)
56	TimeSeriesVars2D = (bils, cldh, ... )
57	ChunckJob2D = NONE
58	TimeSeriesVars3D = ()
59	ChunckJob3D = NONE
  • Chaque fichier de sortie (section [OutputFiles]) est associé à un post-traitement : Post_1M_histmth dans l'exemple.
  • post_1M_histmth est une section (débutant par "[Post_1M_histmth]")
  • Cette section contient les variables : Patches= , GatherWithInternal = , !TimeSeriesVars2D = , !ChunckJob2D , !TimeSeriesVars3D et !ChunckJob3D
  • Patches= (Patch_20091030_histcom_time_axis) Il s'agit du Patch qui sera appliqué sur le fichier avant son stockage sur le serveur de fichiers. Ils sont visibles au niveau de : ​libIGCM_post On peut avoir plusieurs Patch appliqués l'un après l'autre.
  • GatherWithInternal = (lon, lat, presnivs, time_counter, aire) Il s'agit des variables qui sont extraites du fichier initial et rangées avec la variable de la Time Serie.

Les Time Series sont rangées sur le serveur de fichiers dans les répertoires IGCM_OUT/IPSLCM5/ATM/Analyse/TS_MO pour celles qui sont issues des fichiers mensuelles. TS_DA pour celles qui sont issues des fichiers journaliers.

A noter : Il y a un job de Time Series 2D et un job par Time Series 3D sur les frontales. Pour le couplé, il y en donc 5 actuellement.

Comment ajouter une variable dans les Time Series?

Pour ajouter une nouvelle Time Serie il suffit d'ajouter son nom à la série de variables existantes, en prenant soin de la mettre avec les variables similaires : 2D ou 3D.

Qu'est-ce qu'un monitoring?

Voici un exemple de Monitoring du couplé IPSLCM5 : ​3 ans

Le monitoring d'une simulation est composé de plusieurs courbes produites à partir de variables des Time Series. Il contient également une première page détaillant les dates de passage en machine de la simulation. Cette page permet de suivre la progression d'une simulation en machine.

Le monitoring est lancé automatiquement à la fin des Time Series.

Comment ajouter une figure dans les monitoring?

Les monitoring sont paramétrés là: ~compte_commun/atlas/ Par exemple pour LMDZ : monitoring01_lmdz_LMD9695.cfg

Il est possible de modifier un monitoring en créant un répertoire POST locale à la configuration, en recopiant un fichier .cfg et en le modifant à sa convenance. Il y a 2 exemples dans le couplé. Voir ​post-traitements spécifiques

Qu'est-ce qu'un moyenne saisonnière?

Les fichiers SE ou moyennes saisonnières sont lancées automatiquement à la fréquence SeasonalFrequency=10Y (en faisant attention à SeasonalFrequencyOffset=0) lorsqu'il y a autre choses que NONE dans le dernier paramètre du fichier dans la section '[OutputFiles]'. Tous les fichiers avec un Post demandé sont alors moyennés avec la commande ncra avant d'être stockés dans le répertoire : IGCM_OUT/IPSLCM5/ATM/Analyse/SE 1 fichier par SeasonalFrequency=10Y

Où voir les atlas?

Voici un exemple d'atlas du couplé IPSLCM5 : ​ATM

Il y a au moins 8 répertoires avec les atlas pour le couplé.

Les atlas sont des outils mis à disposition sous les comptes communs. Voir ~compte_commun/atlas/ Ils sont basés sur des fichiers atlas_composante.cfg. utilisant les outils fast/atlas. Voir : ​http://dods.ipsl.jussieu.fr/fast/

Questions/Réponses? des autres documentations