wiki:DocUtilisateur/UtilisationAvancée

Version 9 (modified by mmaipsl, 15 years ago) (diff)

--

Utilisation avancée

Table des matières

  1. Variables IGCM modifiables dans le job de calcul
  2. get datas from OLD IPSL structure
  3. Change libIGCM variables "on-the-fly"
  4. Variables IGCM utilisables dans les fichiers pilote
  5. Utilisation des bibliothèques
  6. Intégration d'une composante
  7. Ajout d'une résolution
  8. Modification d'un fichier de paramètres avec awk
  9. Modification d'un fichier de paramètres avec sed
Documentation Utilisateur DocUtilisateur Retour au sommaire?

Variables IGCM modifiables dans le job de calcul

Les variables DEBUG_sys, RUN_DIR_PATH, SUBMIT_DIR, DRYRUN, et R_IN peuvent être modifiées en début de Job (fichier Job_JobName), juste avant de sourcer les librairies. 

#D- Set DEBUG_sys to false to disable output calls of function
#D- Default=true
#DEBUG_sys=false
#D- Define running directory
#D- Default=${TMPDIR} ie temporary batch directory
#RUN_DIR_PATH=/workdir4/rech/ces/rces452/BABATEST/TESTPOST
#D- Define submit directory
#D- Default= where you launch qsub
#SUBMIT_DIR=/workdir4/rech/ces/rces452/SCRIPT_V1/modipsl/config/IPSLCM4_v1_OASIS3/EXP01
#D- Turn in dry run mode ? (0,1,2,3)
#D- Default=0
#DRYRUN=3
#D- Define input file root directory
#D- Default=/u/rech/ces/rces452/IGCM
#R_IN=/u/rech/por/rpor111/DATA

En positionnant la variable DRYRUN à une valeur différente de 0 on peut contrôler les actions effectuées par le job et ainsi faire tourner le job dans un mode dit de DRYRUN qu'on peut traduire par un fonctionnement à vide. Les différents niveaux sont décrits dans le tableau ci-dessous avec les actions associées.

Le mode DRYRUN=3 effectue le strict minimum : aucune recopie de fichiers netCDF n'est effectuée, aucune copie d'éxecutable n'est faite, aucune éxecution n'est lancée et on ne dépose aucun fichier résultat. En revanche les mouvements et les traitements/remplissages de namelist sont effectués ainsi que tous les calculs de date. Les mouvements de fichiers sont simulés et les post-traitements sont lancés.

De plus en plus d'actions sont entreprises à mesure que le DRYRUN diminue.

DRYRUN Dates computations
Cp/Exe? param files
Qsub 		sys_Get


 Exe
Chmod

sys_Put_Out
sys_Put_Rest

3 yes no no no
2 yes yes no no
1 yes yes yes no
0 yes yes yes yes

Cette option permet de voir défiler les actions qui auraient été faites et, par exemple, de mettre au point les drivers des composantes (qui par nature vont updater les namelists en cours de run). Le mode DRYRUN permet également de tester les lancements de post-traitements et pourrait être utiliser à terme pour relancer des post-traitements à posteriori.

En utilisant conjointement les variables DRYRUN et RUN_DIR_PATH on peut mettre en place une configuration test dans un répertoire donné. Sur brodie par exemple en positionnant RUN_DIR_PATH=/workdir4/rech/ces/rces452/BABATEST/TESTPOST on tournera dans un répertoire visible depuis la frontale TX !

La variables DEBUG_sys, positionnée par défaut à true, affiche sur la sortie standard les commandes systèmes avant de les exécuter. On peut la positionner à false pour avoir une verbosité moins importante, en particulier au cours des mouvements de fichiers. Si une recopie de fichier ce passe mal un WARNING sera signalé.

Pour pouvoir exécuter le job en intéractif et non pas le soumettre en batch il faut positionner la variable SUBMIT_DIR SUBMIT_DIR=/workdir4/rech/ces/rces452/SCRIPT_V1/modipsl/config/IPSLCM4_v1_OASIS3/EXP01

On peut modifier les chemin d'accès au fichiers d'entrées de plusieurs manières

  • en définissant la variable R_IN dans le job : R_IN=/u/rech/por/rpor111/DATA
  • en définissant dans la section UserChoices du config card une variable R_INIT et R_BC
  • en définissant dans la section UserChoices des cartes des composantes une variable réutilisable.

Exemple pour ce dernier point :

  • dans le fichier lmdz.card on introduit une variable de la façon suivante
  • et on y accède dans la carte par la suite à travers la variable ${lmdz_UserChoices_InputAtm} : 
[UserChoices]
InputAtm=/monchemin/monsentier
...
...
[InitialStateFiles]
List=   (${lmdz_UserChoices_InputAtm}/MyAlbedo.nc, .), \
        (${lmdz_UserChoices_InputAtm}/MyRelief.nc, .), \
        (${lmdz_UserChoices_InputAtm}/MyRugos.nc,  .)

L'arborescence R_IN décrit se divise en deux sous répertoires : BC pour les Boundary Conditions et INIT pour les fichiers qui ne sont nécessaires qu'au premier pas de temps. L'arborescence R_IN se présente par défaut de la manière suivante. 

IGCM
|-- BC
|   |-- ATM
|   |   |-- IPSLCM4_v1 -> IPSLCM4_v1_OASIS3
|   |   `-- IPSLCM4_v1_OASIS3
|   |       |-- IPCC
|   |       |   |-- A1B -> /dmnfs/p86denv/IPCC/A1B
|   |       |   |-- A2 -> /dmnfs/p86denv/IPCC/A2
|   |       |   |-- B1 -> /dmnfs/p86denv/IPCC/B1
|   |       |   |-- CMIP -> /dmnfs/p86denv/IPCC/CMIP
|   |       |   `-- HISTORIQUE -> /dmnfs/p86denv/IPCC/HISTORIQUE
|   |       |-- ISCCP
|   |       |-- LMD14496
|   |       |   |-- A1B -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD14496/A1B
|   |       |   |-- A1FI -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD14496/A1FI
|   |       |   |-- A1T -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD14496/A1T
|   |       |   |-- A2 -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD14496/A2
|   |       |   |-- B1 -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD14496/B1
|   |       |   |-- B2 -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD14496/B2
|   |       |   `-- HISTORIQUE -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD14496/HISTORIQUE
|   |       |-- LMD7245
|   |       `-- LMD9671
|   |           |-- A1B -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD9671/A1B
|   |           |-- A1FI -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD9671/A1FI
|   |           |-- A1T -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD9671/A1T
|   |           |-- A2 -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD9671/A2
|   |           |-- B1 -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD9671/B1
|   |           |-- B2 -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD9671/B2
|   |           `-- HISTORIQUE -> /dmnfs/p86denv/IPCC/IPSL_SO4/ORCA2xLMD9671/HISTORIQUE
|   |-- CPL
|   |   |-- IPSLCM4_v1 -> IPSLCM4_v1_OASIS3
|   |   `-- IPSLCM4_v1_OASIS3
|   |       |-- ORCA2xLMD14496
|   |       |-- ORCA2xLMD4443
|   |       |-- ORCA2xLMD9671
|   |       |-- ORCA4xLMD4443
|   |       `-- ORCA4xLMD7245
|   |-- ICE
|   |   |-- IPSLCM4_v1 -> IPSLCM4_v1_OASIS3
|   |   `-- IPSLCM4_v1_OASIS3
|   |-- OCE
|   |   |-- IPSLCM4_v1 -> IPSLCM4_v1_OASIS3
|   |   `-- IPSLCM4_v1_OASIS3
|   |       |-- ORCA2
|   |       `-- ORCA4
|   `-- SRF
|       |-- IPSLCM4_v1 -> IPSLCM4_v1_OASIS3
|       `-- IPSLCM4_v1_OASIS3
`-- INIT
    |-- ATM
    |   |-- IPSLCM4_v1 -> IPSLCM4_v1_OASIS3
    |   `-- IPSLCM4_v1_OASIS3
    |-- CPL
    |   |-- IPSLCM4_v1
    |   |   |-- ORCA2xLMD9671
    |   |   `-- ORCA4xLMD7245
    |   `-- IPSLCM4_v1_OASIS3
    |       |-- ORCA2xLMD14496
    |       |-- ORCA2xLMD4443
    |       |-- ORCA2xLMD9671
    |       |-- ORCA4xLMD4443
    |       `-- ORCA4xLMD7245
    `-- SRF
        |-- IPSLCM4_v1 -> IPSLCM4_v1_OASIS3
        `-- IPSLCM4_v1_OASIS3

L'arborescence R_OUT est l'arborescence de sauvegarde des résultats. On trouve dans le répertoire R_OUT un répertoire au nom de la configuration, puis un répertoire du nom de l'expérience. Et enfin pour chaque composante, des fichiers bruts, des fichiers post-traités et des fichiers de débug. Le résultat des atlas et du monitoring se trouve au même niveau que les répertoires des composantes.

L'arborescence R_OUT se présente de la manière suivante. Mais un utilisateur avancé peut la modifier à travers la variable R_OUT et à travers les cartes des composantes. Le positionnement des répertoires ATLAS, MONITORING et Analyse n'est pas modifiable. 

IGCM_OUT/
`-- IPSLCM4_v1_OASIS3
    `-- TESTDRY
        |-- ATLAS
        |-- ATM
        |   |-- Analyse
        |   |   |-- SE
        |   |   |-- TS_DA
        |   |   |-- TS_HF
        |   |   `-- TS_MO
        |   |-- Debug
        |   |-- Output
        |   |   |-- DA
        |   |   `-- HF
        |   |   `-- MO
        |   `-- Restart
        |-- CPL
        |   |-- Analyse
        |   |   `-- SE
        |   |-- Debug
        |   |-- Output
        |   |   `-- MO
        |   `-- Restart
        |-- Exe
        |-- ICE
        |   |-- Analyse
        |   |   |-- SE
        |   |   `-- TS_MO
        |   |-- Debug
        |   |-- Output
        |   |   `-- MO
        |   `-- Restart
        |-- MONITORING
        |-- OCE
        |   |-- Analyse
        |   |   |-- SE
        |   |   `-- TS_MO
        |   |-- Debug
        |   |-- Output
        |   |   |-- DA
        |   |   `-- MO
        |   `-- Restart
        |-- Out
        `-- SRF
            |-- Analyse
            |   |-- SE
            |   `-- TS_MO
            |-- Debug
            |-- Output
            |   `-- MO
            `-- Restart

get datas from OLD IPSL structure

You can now re-use your OLD IPSLCM4 data structure to build new post-treatment, MONITORING or what else in new libIGCM output structure by using the script_transformation in attachement in your DMNFS directory (if mercure or gaya). Get the file and use 

script_transformation /u/rech/ces/rces333 SORTIES_CPL_IPSL /u/rech/ces/rces533 IPSLCM4_v2 LA1B450 [ ln | cp | ]

where first parameter is DMNFS PATH for OLD datas and second is the OLD class of configuration. The third and fourth are respectively OUT PATH and Configuration TagName for NEW libIGCM structure (then here in the exemple, datas while be put in /u/rech/ces/rces533/IGCM_OUT/IPSLCM4_v2). And before the last is the OLD/NEW JobName (the same name) and last one is the link/copy Action ( Nothing mean "do nothing", just for test ).

Change libIGCM variables "on-the-fly"

Since revision 120, you can change some libIGCM variables (or some of your configuration) during a run (and not only after the next submission).

How to do that ? you must copy libIGCM.card from ${libIGCM} directory in you run ${SUBMIT_DIR} directory.

Ater modifications of this ${SUBMIT_DIR}/libIGCM.card, variables define inside [UserChanges] will be modified for next Period of libIGCM main loop. Those variables will be updated in the next PeriodEnd stage (see main loop in your job).

Some variables have special treatment in libIGCM_config.ksh : config_UserChoices_DateEnd, config_Post_RebuildFrequency, config_Post_TimeSeriesFrequency, config_Post_SeasonalFrequency. But you can change other important variables as config_UserChoices_PeriodLength and most of all PeriodNb (to adapt your number of loop PBS options and your real execution duration.)

If you want to change other variable, do it with care !

After the first read of libIGCM.card, you should erase or rename it because you don't need to read it again each step. You should change your config.card or job or other cards (depends of your modifications) to have an homogeneous run after next submission.

Variables IGCM utilisables dans les fichiers pilote

Par défaut les variables du shell ont une portée globale, les fichiers pilotes ont donc accès à l'ensemble des variables définies. Cependant le sous ensemble de variables suivant, non exhaustif, est nécessaire au fonctionnement typique d'un fichier pilote :

${config_UserChoices_JobName} Nom du Job et de l'expérience
${config_UserChoices_PeriodLength} Période d'intégration à chaque exécution
${config_ATM_WriteFrequency} Liste des fréquences d'écritures demandées pour l'atmosphère
${config_Restarts_OverRule} y/n est ce que tout le monde démarre de la même simulation
${config_ATM_Restart} y/n est ce que l'atmosphère démarre d'un restart
${DateBegin} Date de début de la simulation
${DateEnd} Date de fin de la simulation
${PeriodDateBegin} Date de début de période que l'on s'apprête à simuler
${PeriodDateEnd} Date de fin de période que l'on s'apprête à simuler
${PeriodLengthInDays} Nombre de jours simulées à la prochaine exécution
${SimulationLengthInDays} Cumul du nombre de jours simulées après la prochaine exécution
${ExperienceLengthInDays} Etendu en jours de l'ensemble de la simulation
${CumulPeriod} Nombre de période déja simulée après la prochaine exécution
${InitYear} Année de DateBegin
${InitDay} Numéro de jour dans l'année de DateBegin
${year} Année en cours
${month} Mois en cours
${FirstInitialize} true/false est ce la première fois que l'on initialise les composantes

Utilisation des bibliothèques

  • libIGCM_debug
  • libIGCM_card
  • libIGCM_date

Intégration d'une composante

Ce paragraphe est en cours de développement. Evidemment les composantes Chimie, Traceur et Carbone constituent d'excellents candidats pour vérifier la solidité et l'architecture de ces nouveaux scripts. Il est assez simple de rajoutez une composante ou de créer une nouvelle configuration. Dans le paragraphe qui suit nous allons prendre comme exemple la mise en place de la configuration LMDZ-INCA (version parallèle). Voici les différentes étapes à suivre :

  • Préparez une architecture de stockage IGCM pour la nouvelle composante (ici la chimie) 
IGCM
|--BC
|   |--CHM
|
|
|--INIT
    |--CHM
        |--AER
        |--CH4
        |--NMHC
        |--NMHC_AER

Cette architecture doit également comporter les autres composantes nécessaire à la création de configuration (ici l'atmosphère et éventuellement la surface pour un couplage lmdz-orchidee-inca). Pour l'instant IGCM (pour lmdz-inca) est stocké sur /dmnfs/p86cozic mais à terme elle sera réunit sur un compte commun ipsl permettant de gérer tous les fichiers d'entrées. De plus il faudra également prévoir d'incorporer les différentes résolutions possibles (AER_9672, AER_9671, CH4_9672, CH4_9671 ...) dans cette architecture.

  • Il faut créer les fichiers carte et pilote de la nouvelle composante : inca.card et inca.driver
    1. le fichier inca.card liste les fichiers d'entrées nécessaires à une simulation
    2. le fichier inca.driver permet de définir des opérations propres à la composante inca lors d'une préparation de run ou en post-traitement. Il peut éventuellement ne contenir que des routines vides 
function CHM_Initialize
function CHM_Update
function CHM_Finalize
  • Il faut modifier le fichier config.card (vous pouvez reprendre n'importe quel fichier config.card et ajoutez ou enlevez ce qui est nécessaire) :
    1. modifier les variables LongName et TagName. Notez que la variable TagName correspond au répertoire dans lequel sera stocké vos sorties de modèle (/dmnfs/.../IGCM_OUT/TagName/JobName)
    2. modifier les variables R_INIT et R_BC qui indiquent où trouver l'architecture de stockage IGCM/
    3. ajouter la nouvelle composante à la rubrique [listOfComponents] 
[listOfComponents]
ATM=(lmdz, LMDZ4)
CHM=(inca, INCA3)

on indique en premier le nom de la composante et en second le nom du répertoire contenant ses sources.

  1. il faut également compléter la rubrique [Executable]. 
[Executable]
ATM=(gcm.e,gcm.e)
CHM=("","")

Inca n'a pas d'éxecutable propre, il utilise celui de lmdz.

  1. il faut ajouter une sous-section pour les restarts de la composante 
#D-- CHM
[CHM]
WriteFrequency="1M"
Restart=n
RestartDate=...
RestartJobName=...
RestartPath=...
OldName=""

/!\ Vous n'avez pas besoin de changer quoique ce soit dans le script de lancement AA_job

Remarque Le modèle inca propose plusieurs configurations à ses utilisateurs, chacune d'entre elles demandant un fichier inca.card différent. Nous sommes actuellement en train de chercher la meilleure solution à proposer :

  • Un seul répertoire d'expérience contenant plusieurs fichiers card : inca.card_AER inca.card_CH4 etc... et l'utilisateur indique dans le fichier config.card qu'elle configuration il choisit 
CHM=(inca_AER,INCA3)
ou
CHM=(inca_CH4,INCA3)
ou ....
  • Plusieurs répertoires d'expériences chacun contenant un jeu complet de cartes pour une configuration.

Ajout d'une résolution

Cette page IGCMG/libIGCM/ExempleAjoutLMD144142 décrit les différentes actions réalisées pour inclure la résolution LMD144142 dans le couplé IPSLCM4_v1_OASIS3.

Modification d'un fichier de paramètres avec awk

La commande awk est très puissante et pourra être utilisée dans un fichier driver pour modifier les paramètres d'un fichier. L'exemple suivant illustre comment modifier les paramètres "teta" d'un fichier et les mettre à leurs valeurs initiales divisées par 2. 

$ cat cat gcm.def_LMD9671 | grep teta
tetagdiv=10800.
tetagrot=18000.
tetatemp=18000.

$ awk '{ if ($0 ~ /teta.*=/) {split($0,a,"=") ; print a[1]"="a[2]/2.0} else print $0}' gcm.def_LMD9671 | grep teta

Modification d'un fichier de paramètres avec sed

La commande sed est également très puissante et pourra être utilisée dans un fichier driver pour modifier les paramètres d'un fichier. L'exemple suivant illustre comment remplacer des "patterns" d'un fichier template par de nouvelles valeurs. Ces nouvelles valeurs pourront être les résultats de fonctions Unix comme date ou whoami mais aussi, par exemple, le résultat d'une fonction interne qui liste des fichiers. 

$ cat gcm.def.template

###################
XXXXXX

###################
AAAAAA

###################
TTTTTT

###################
UUUUUU

###################
HHHHHH

$ cat ./sed_example.ksh
#!/bin/ksh
#
#---------------------------------------------
function PRINT {
for file in $@ ; do
        printf "${file}\\\\n"
done
}

#---------------------------------------------
sed -e "s#XXXXXX#un texte#" \
    -e "s#AAAAAA#$( PRINT *.nc )#" \
    -e "s#TTTTTT#$( date +"%F %T" )#" \
    -e "s#UUUUUU#$( whoami )#" \
    -e "s#HHHHHH#$( hostname -f )#" \
    $1

#---------------------------------------------

$ ls *.nc
file1.nc  file2.nc  file3.nc  file4.nc

$ ./sed_example.ksh gcm.def.template

###################
un texte

###################
file1.nc
file2.nc
file3.nc
file4.nc


###################
2007-11-08 11:15:38

###################
brock

###################
lsce4002.extra.cea.fr

Attachments (1)

  • script_transformation​ (11.3 KB) - added by mmaipsl 15 years ago. Script for transformation of OLD IPSL structure to new libIGCM one. Difference between OASIS 2 and OASIS 3 runs.

Download all attachments as: .zip