---

Documentation Utilisateur

Auteurs : Sébastien Denvil, Martial Mancip, Patrick Brockmann
Contributions : Anne Cozic, Marie-Alice Foujols

---

Sommaire général libIGCM et FAQ libIGCM/DocUtilisateur/FAQ

Table des matières

1. Introduction
2. Vocabulaire
3. Fonctionnalités recherchées
4. Présentations
5. Architecture du job de calcul
6. Schéma synoptique de la libIGCM
7. Les fichiers d'entrée
8. Les fichiers liés au job de calcul
9. Les fichiers liés aux composantes
10. Installation de la libIGCM
    1. Stratégie
    2. Arborescence des fichiers
    3. Installation spécifique
11. Préparation d'une configuration avec la libIGCM
    1. Configuration IPSLCM4_v2 (recommandée)
    2. Configuration IPSLCM4_v1_OASIS3 (figé)
12. Utilisation
    1. Questions/Réponses?
    2. Utilisation avancée
13. Documents
14. TODO

---

Introduction

La modélisation du Système Terre de l'IPSL comprend aujourd'hui les composantes suivantes : l'Atmosphère, l'Océan, la Glace de Mer, les Surfaces Continentales et un Coupleur. Devant la complexité grandissante du Système Terre à modéliser et l'intégration progressive de nouvelles composantes telle que la composante Chimie et la composante Cycle du Carbone, il est apparu inévitable de repenser l'ancien job de calcul, et au passage les jobs de post-traitement, pour en proposer de nouvelles versions, plus claires et plus flexibles.
Dorénavant, un seul et même job de calcul est proposé pour toutes les configurations, couplées ou forcées. Ceci pour toutes les machines. Pour une configuration déterminée, un utilisateur aura à intervenir, si besoin, sur un nombre limité de fichiers (précisément 2 fichiers par composante et 1 fichier de configuration pour le job de calcul).

Vocabulaire

Définitions des termes utilisés dans ce document.

• Composante = code de calcul (mais pas forcément un exécutable indépendant, par exemple LIM vis à vis de OPA)
• Configuration = ensemble de composantes réglées pour fonctionner ensemble
• fichier carte (extension .card) = fichier texte formé de sections comprenant des options
• fichier pilote (extension .driver) = script shell regroupant des commandes à exécuter à des moments précis de la simulation

Pour info voici la terminologie qui émerge des projets Curator/Flume/Metafor?. Les exemples données ne sont qu'une tentative de mise en correspondance.

• definition - a numerical model that has yet to be configured; a "potential component" : par exemple LMDZ4INCA maintenant
• configuration - a numerical model that has been configured (all of it's options have precise values) : LMDZ4INCA dans 1 an
• composition - a set of configurations linked together; a coupled model; a scientific experiment : IPSLCM4_v1_OASIS3 et/ou les runs FH* ou VV20
• deployment - a specification of how a composition will be run on computers; a scientific experiment capable of producing data : un ensemble SRESA2

Fonctionnalités recherchées

• Unicité du job vis à vis des configurations
  • La structure du job reste identique quelque que soit la configuration utilisée.
• Portabilité des scripts
  • Les jobs sont écrits en K-Shell avec des commandes Unix standards (awk, sed, ...)
• Lisibilité des fichiers card
  • La configuration d'une composante est décrite dans un langage clair et lisible par un humain dans le fichier card. La traduction dans le langage de la composante se fait grâce au fichier driver correspondant.
• Spécificité déportée sur la couches système uniquement
  • L'utilisation de fonctions génériques qui s'appuient sur des couches spécifiques permettent de construire un job indépendant de la plateforme de calcul. Ainsi, seule la librairie système libIGCM_sys est dépendante de la plateforme où s'exécute la simulation.
• Séparation de l'information entre la configuration et ses composantes
  • Les informations nécessaires à la bonne marche de la simulation sont regroupées dans le fichier de configuration (config.card), tandis que les informations relatives au bon fonctionnement des composantes sont accessibles dans les fichiers comp.card et comp.driver.
• Gestion des différents calendriers
  • Les calendriers suivants sont pris en charge par la librairie date
    • 360d : un calendrier de 12 fois 30 jours
    • noleap : un calendrier de 365 jours sans année bissextile
    • leap : un calendrier de 365 jours, 366 jours pour les années bissextiles
    • gregorian : le calendrier vrai (pour les configs qui le supporte, ie ORCHIDEE_OL pour l'instant).
• Désynchronisation des fichiers de Restarts
  • On peut faire démarrer toute les composante à partir des fichiers de restarts d'une même simulation.
  • Ou bien faire démarrer chaque composante de restarts provenant de simulations différentes.
• Mode de débugage
  • Un mode STACK l'ensemble des appels libIGCM est consigné dans un fichier de stack
  • Un mode DRYRUN à plusieurs niveaux permettant de demander au job des actions graduées
  • Le Job peut être joué en intéractif, pas besoin de soumettre en batch
  • La combinaison des ces fonctionnalités offrent une réelle souplesse d'utilisation
• Post-traitements
  • Lancement des post-traitements à des fréquences variables
  • Rebuild, reconstruction des fichiers parallèles sur la machine de son choix
  • Seasonal average (SE), Atlas
  • Annual average (AN)
  • Time series (TS), Monitoring (voir ci dessous)
  • Mise à disposition DODS des post-traitements
• Monitoring
  • Disponible à travers une page html mise à jour au fur et à mesure de la simulation
  • Graphique d'avancement de la simulation, monitoring des perfs via le fichier run.card
• Analyse des performances
  • Le fichier run.card stock les informations relatives aux performances des codes de calcul (CPU time, USER time, ELAPSED time)
  • Cette information peut être utilisée pour monitorer les sauts de performances des centres de calcul
  • Les variables d'environnements FTRACE sont positionnées/commentées dans le Job
  • Les ftrace.out* sont sauvegardés si disponibles

Présentations

• ​Parcourir le dépôt

---

Architecture du job de calcul

PeriodLength (dans config.card) correspond à la durée du bloc jaune sur le schéma.

Schéma synoptique de la libIGCM

Les fichiers d'entrée

Les fichiers d'entrée de chaque composante sont séparés en plusieurs catégories :

• fichiers de Conditions Initiales comme : état0, carte de végétation
  • ils sont récupérés par la fonction IGCM_comp_GetInputInitialStateFiles
• fichiers de Conditions Limites comme les forçages ou un LAI
  • ils sont récupérés par la fonction IGCM_comp_GetInputBoundaryFiles
• fichiers de Paramètres comme les namelist ou le fichier run.def
  • ils sont récupérés par la fonction IGCM_comp_GetInputParametersFiles
• fichiers de Restarts
  • ils sont récupérés par la fonction IGCM_comp_GetInputRestartFiles

Les fichiers liés au job de calcul

Une simulation est contrôlée par 1 fichier de configuration appelé config.card :

• ​Exemple de fichier config.card de la configuration IPSLCM4_v2

La simulation met à jour au fur et à mesure de son exécution un fichier de suivi appelé run.card :

• ​Le fichier initial de suivi de la simulation
• ​Le fichier de suivi d'une simulation en cours

Les fichiers liés aux composantes

Pour chaque composante de la configuration choisie, l'utilisateur récupère, suite à l'exécution de la commande model (modipsl/util/model), 2 fichiers :

• un fichier carte d'extension .card,
• et un fichier pilote d'extension .driver.

​Explorer les fichiers card et driver de la configuration IPSLCM4_v2.

---

Installation de la libIGCM

Stratégie

La libIGCM constitue un module indépendant au sens CVS.

Depuis juillet 2007 c'est à dire depuis la mise en place de modipsl sous svn (Voir ​SVN modipsl), et depuis la configuration ​IPSLCM4_v2, l'ensemble de la libIGCM est récupérée chez l'utilisateur (modipsl/libIGCM) qui a ainsi la maîtrise de l'environnement d'exécution de son expérience.

Arborescence des fichiers

Si la séquence d'installation de modipsl est suivi avec IPSLCM4_v2 comme CONFIGURATION, l'arborescence suivante est créée. Les fichiers cartes et pilotes (*.card et *.driver) des composantes sont visibles dans les répertoires COMP et PARAM.

config
`-- IPSLCM4_v2
    |-- AA_make
    |-- AA_make.ldef
    |-- EXP00
    |   |-- COMP
    |   |   |-- lim.card
    |   |   |-- lim.driver
    |   |   |-- lmdz.card
    |   |   |-- lmdz.driver
    |   |   |-- oasis.card
    |   |   |-- oasis.driver
    |   |   |-- opa.card
    |   |   |-- opa.driver
    |   |   |-- orchidee.card
    |   |   `-- orchidee.driver
    |   |-- PARAM
    |   |   |-- cf_name_table.txt
    |   |   |-- dynami.param_ORCA2xLMD14496
    |   |   |-- dynami.param_ORCA2xLMD9671
    |   |   |-- dynami.param_ORCA4xLMD7245
    |   |   |-- gcm.def_ORCA2xLMD14496
    |   |   |-- gcm.def_ORCA2xLMD9671
    |   |   |-- gcm.def_ORCA4xLMD7245
    |   |   |-- geogra.param
    |   |   |-- inice.param
    |   |   |-- namcouple_ORCA2xLMD14496
    |   |   |-- namcouple_ORCA2xLMD9671
    |   |   |-- namcouple_ORCA4xLMD7245
    |   |   |-- namelist_ORCA2xLMD14496
    |   |   |-- namelist_ORCA2xLMD9671
    |   |   |-- namelist_ORCA4xLMD7245
    |   |   |-- offline.def
    |   |   |-- orchidee.def
    |   |   |-- output.param
    |   |   |-- physiq.def
    |   |   |-- run.def
    |   |   |-- run.param.li
    |   |   |-- thermo.param
    |   |   `-- traceur.def
    |   `-- config.card
    `-- scripts
        |-- BB_make
        `-- BB_make.ldef

Installation spécifique

L'extraction du module libIGCM se fait à partir de la commande svn suivante :

$ svn co http://forge.ipsl.jussieu.fr/libigcm/svn/tags/libIGCM_v1 libIGCM

Vous devrez ensuite éditer le fichier libIGCM_sys/libIGCM_sys_default.ksh, modifier la variable ARCHIVE les fonctions d'appel générique afin d'adapter la librairie à votre système.

---

Préparation d'une configuration avec la libIGCM

Configuration IPSLCM4_v2 (recommandée)

DocUtilisateur/InstallationIPSLCM4v2

Configuration IPSLCM4_v1_OASIS3 (figé)

DocUtilisateur/InstallationIPSLCM4v1OASIS3

---

Utilisation

Questions/Réponses?

libIGCM/DocUtilisateur/FAQ

Utilisation avancée

DocUtilisateur/UtilisationAvancée

---

Documents

• Présentation de la libIGCM à Branville aux Journées de prospective du pôle de modélisation, 19-20 mai 2008
  ​http://dods.ipsl.jussieu.fr/libigcm/documents/poster_libIGCM_Branville2008.odp

---

TODO

DocUtilisateur/TODO