Version 12 (modified by brocksce, 15 years ago) (diff) |
---|
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
- Introduction
- Vocabulaire
- Fonctionnalités recherchées
- Présentations
- Architecture du job de calcul
- Schéma synoptique de la libIGCM
- Les fichiers d'entrée
- Les fichiers liés au job de calcul
- Les fichiers liés aux composantes
- Installation de la libIGCM
- Préparation d'une configuration avec la libIGCM
- Utilisation
- Documents
- 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).
- Les calendriers suivants sont pris en charge par la librairie date
- 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
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 :
La simulation met à jour au fur et à mesure de son exécution un fichier de suivi appelé run.card :
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?
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 attachment:poster_libIGCM_Branville2008.odp
TODO
Attachments (11)
- job.png (95.9 KB) - added by sdipsl 16 years ago.
-
libIGCM.png
(52.6 KB) -
added by sdipsl 16 years ago.
libIGCM's synoptic schema
- n1.png (1.2 KB) - added by sdipsl 16 years ago.
- n2.png (2.0 KB) - added by sdipsl 16 years ago.
- n3.png (2.0 KB) - added by sdipsl 16 years ago.
- n4.png (1.4 KB) - added by sdipsl 16 years ago.
- n5.png (1.8 KB) - added by sdipsl 16 years ago.
- n6.png (2.1 KB) - added by sdipsl 16 years ago.
- n7.png (1.7 KB) - added by sdipsl 15 years ago.
- n8.png (2.2 KB) - added by brocksce 14 years ago.
- n9.png (2.2 KB) - added by brocksce 14 years ago.
Download all attachments as: .zip