. '''Documentation Utilisateur''' [[BR]] ["IGCMG/libIGCM/DocUtilisateur"] ---- . '''Sommaire''' TableOfContents(5) ---- == Fonctionnalités intégrées pour le tag libIGCM v1_2 == ---- == Fonctionnalités intégrées pour le tag libIGCM v1_1 == ---- == Fonctionnalités intégrées pour le tag libIGCM v1_0 (à venir) == ||'''[#F0002 F0002]''' ||'''card,libIGCM_comp''' ||'''Mise en place d'un contrôle de compatibilité card/libIGCM''' || '''DONE''' || ||'''[#F0003 F0003]''' ||'''job''' ||'''Clarification des valeurs de Configuration_!PeriodeState''' || '''DONE''' || ||'''[#F0004 F0004]''' ||'''fichier''' ||'''Les données nécessaires aux configs à jour sur les comptes communs''' || '''DONE''' || ||'''[#F0005 F0005]''' ||'''install''' ||'''Installer run.card et configurer le Job''' || '''DONE''' || ||'''[#F0006 F0006]''' ||'''job,driver''' ||'''Avoir des !PeriodLength et des !WriteFrequency plus souple''' || '''DONE''' || ||'''[#F0008 F0008]''' ||'''job,config.card,driver,libIGCM_sys''' ||'''Simplifier les soumissions multi-procs''' || '''DONE''' || ||'''[#F0008 F0009]''' ||'''libIGCM_sys''' ||'''Variables/Instructions MPI dans libIGCM_sys''' || '''DONE''' || ||'''[#F0010 F0010]''' ||'''card,driver''' ||'''Ajout configuration LMDZ4OR_v2''' || '''DONE''' || ||'''[#F0011 F0011]''' ||'''libIGCM_sys''' ||'''Ajout machine platine''' || '''DONE''' || ||'''[#F0013 F0013]''' ||'''comm''' ||'''Description des configurations sous svn''' || '''DONE''' || ||'''[#F0022 F0022]''' ||'''post''' ||'''Diagnostiques océan''' || '''TO BE COMMITED''' || ---- == Description des fonctionnalités == Ci-après sont décrites les nouvelles fonctionnalités à étudier avec le code suivant: ||'''Fxxxx''' ||'''type''' ||'''Description succinte de la fonctionnalité''' ||'''status''' || ---- #################################################### ||'''F0001''' ||'''job''' ||'''Changement d'organisation des répertoires PARAM et COMP''' ||'''refusé''' || Les fichiers de paramètres sont regroupés dans le répertoire param ce qui implique que 2 composantes ne doivent pas utiliser un même nom de fichier. Faut-il changer cette arborescence en la développant par l'ajout du nom des composantes ? Actuellement , on utilise : . {{{ COMP |-- lim.card |-- lim.driver |-- lmdz.card |-- lmdz.driver |-- oasis.card |-- oasis.driver |-- opa.card |-- opa.driver |-- orchidee.card `-- orchidee.driver PARAM |-- gcm.def |-- geogra.param |-- inice.param |-- namcouple |-- orchidee.def |-- physiq.def |-- run.def `-- thermo.param }}} ---- #################################################### ||'''F0002'''||'''job''' ||'''Mise en place d'un contrôle de compatibilité card/libIGCM''' ||'''accepté''' || Afin de gérer l'évolution de la libIGCM et la compatibilité avec les fichiers cartes (*.card), il faut prévoir d'ajouter dans toutes les cartes la section Compatibility avec l'option libIGCM renseignée du numéro de version de la libIGCM. Le principe est que chaque carte comporte ce renseignement qui sera bloquant si les numéros de version ne coïncident pas. . {{{ [Compatibility] libIGCM=1.0 }}} Suite à une évolution de la libIGCM, l'utilisateur devra : * modifier la valeur de Compatibility_libIGCM avec la nouvelle valeur de la version (modification mineure de libIGCM sans ajouts ou modifications de sections et d'options) * ajouter ou modifier les autres sections et options nécessaires (modification majeure de libIGCM avec ajouts et/ou modifications de sections et d'options) Les numéros de version de la libIGCM seront tagués sur le tronc principal ainsi : * numéro pairs pour les versions stables: 1.0, 1.2, 1.4 * numéro impairs pour les version de développement: 1.1, 1.3, 1.5 ---- #################################################### ||'''F0003''' ||'''job''' ||'''Clarification des valeurs de Configuration_!PeriodeState''' ||'''accepté''' || Pour l'option Configuration_!PeriodeState, créer la valeur "Continue" et remplacer la valeur "Fatal" par "Stopped", pour être plus clair. Le système renseigne au fur et à mesure du déroulement de la simulation via la carte run.card (initialement à "Start"), par les valeurs "Running", "!OnQueue", "Completed", "Stopped". Si la chaîne s'arrète avec la valeur "Stopped" suite à une erreur, l'utilisateur peut faire une relance en modifiant la valeur à "Continue". De même si l'utilisateur souhaite poursuivre une simulation sur une période plus longue, il changera la valeur de l'option Configuration_!PeriodDateEnd et mettra l'option Configuration_!PeriodState à la valeur "Continue". . {{{ # State of Job # User demand: "Continue" # System response: "Running", "OnQueue", "Completed", "Stopped" PeriodState="Start" }}} ---- #################################################### ||'''F0004''' ||'''Fichiers''' ||'''Les données nécessaires aux configs à jour sur les comptes communs''' ||'''accepté''' || Les données sur les comptes communs (MM. Voir http://wiki.ipsl.jussieu.fr/wiki_ipsl/EsciComptes) ---- #################################################### ||'''F0005''' ||'''install''' ||'''Install run.card et le Job''' ||'''accepté''' || ins_job recopie le run.card.init de ${libIGCM} dans le ${SUBMIT_DIR}. Il configure le job en fonction du nom de simulation contenu dans config.card et en fonction de la machine. Il configure les jobs de post-traitements en fonction de la machine. Il exploite l'info !JobClass et !JobNumProcTot de config.card pour configurer le job (en étroite relation avec oasis.driver pour IPSLCM4_v2) (JB,SD,MAF,MM) Quasiment OK, il faudrait tester en config forcé. En lien avec F0008 ---- #################################################### ||'''F0006''' ||'''job,driver''' ||'''Avoir des !PeriodLength et des !WriteFrequency plus souple''' ||'''accepté''' || Gérer les !WriteFrequency 5D, 15D, 30D pour OPA et gérer des !WriteFrequency de 1M avec des !PeriodLength de 1Y par exemple. OPA peut ecrire deux fichiers avec des !WriteFrequency différentes ---> rendre cela le plus souple possible. [[BR]] In Fine faire tourner IPSLCM4_v2 par !PeriodLength de 1Y, ca marche déja manque juste quelques détails pour OPA. (SD) ---- #################################################### ||'''F0007''' ||'''patch''' ||'''Ajout d'un patch libIGCM_post pour l'axe des temps''' ||'''accepté''' || Ce patch doit pouvoir éditer le contenu du tableau time_counter pour avoir un bon axe des temps. ---- #################################################### ||'''F0008''' ||'''job, config.card, driver,libIGCM_sys''' ||'''Simplifier les soumissions multi-procs''' ||'''accepté''' || Régler le problème "MPI_RUN_COMMAND MPI_RUN_OPTIONS" dans AA_job ( MAFo ) : OK pour IPSLCM4_v2 mais vérification/validation de toutes configs (MAFo, AC / MM). En lien direct avec ins_job, config.card et libIGCM_sys. ---- #################################################### ||'''F0009''' ||'''libIGCM_sys''' ||'''Variables/Instructions MPI dans libIGCM_sys''' ||'''accepté''' || Variables d'environnement spécifiques MPI/machines à classer dans libIGCM_sys avec un tableau des valeurs par défaut / explications dans la doc (AC) ---- #################################################### ||'''F0010''' ||'''card, driver''' ||'''Ajout configuration LMDZ4OR_v2''' ||'''accepté''' || Création des jeux de cartes pour LMDZ4OR_v2 et fichiers nécessaires (MM) ---- #################################################### ||'''F0011''' ||'''lib_sys''' ||'''Ajout machine platine''' ||'''accepté''' || Création de la libIGCM_sys pour la machine platine (AC) ---- #################################################### ||'''F0012''' ||'''card, driver''' ||'''Ajout configuration ORCA*LIM''' ||'''accepté''' || Création des jeux de cartes pour ORCA*LIM et fichiers nécessaires (CL) ---- #################################################### ||'''F0013''' ||'''comm''' ||'''Description des configurations sous svn''' ||'''accepté''' || Définir un tableau WIKI des CONFIGs sous libIGCM : Compléter [http://forge.ipsl.jussieu.fr/igcmg/wiki/ConfigSvn cette page] * LMDZ* (toute les configs attachées à LMDZ) * ORCA*LIM * Couplé IPSLCM4_v1_OASIS3 (rev CHILI), LMDZ4OR (rev CHILI), IPSLCM4_v2, LMDZ4INCA_v2, LMDZ4OR_v2, OOL_SEC, OOL_SEC_STO etc .... * IPSL_ESM ---- #################################################### ||'''F0014''' ||'''post''' ||'''!WriteFrequency avec 5D, 10D, 15D, 30D''' ||'''accepté''' || Pouvoir lancer le create_ts pour des !WriteFrequency de 5D, 10D, 15D, 30D pas seulement en modulo mensuel et annuel Nécessaire pour NEMO lorsqu'il tourne en calendrier vrai par période d'integration de 5 jours. En effet dans ce cas là la date de fin ne tombe sur le dernier jour d'un mois qu'une fois par année non bisextile .... ---- #################################################### ||'''F0015''' ||'''post''' ||'''Monitoring à partir des produits TS''' ||'''status''' || Inclure un monitoring performant basé sur les idées suivantes : * Fichier composante.post.card * Plusieurs étapes sont à considérer : 1. Opération ncap . Pour appliquer des opérations sur la variable : PRECIP*86400, TOPS-TOPL 1. Opération ncatted . Pour donner à la nouvelle variable issue du calcul précédent un nom et des unités corrects. 1. Opération ncks . Pour regrouper les grandeurs nécessaires à l'opération de réduction spatial (2D-->1D) avec l'opérateur ncwa suivant. 1. Opération ncwa . Pour calculer les valeurs globales pondérées ou non, pour tout le globe et par hémisphère, avec les extremas sur la période indiquée. 1. Opération ncrcat . Pour concaténer les champs 1D précédemment calculés dans le fichier de la série temporelle. * Deux sections avec une option pour indiquer le recoupement éventuel de variables lors de la création des séries temporelles lorsque celles-ci ne sont pas des variables de coordonnées et donc oubliées par l'opérateur ncks utilisé pour la création des séries temporelles : {{{ [All2DVariables] GatherWithInternal = nav_lon, nav_lat [All3DVariables] GatherWithInternal = nav_lon, nav_lat, deptht }}} * Une section spécifique par variable si des opérations particulières sont nécessaires (recombinaison, calculs, pondération). {{{ [variable] GatherWithInternal = varT GatherWithExternal = (file1, 'varA, varB'), (file2, 'varX, varY, varZ') Operation = variable*varA+varX LongName = "Une nouvelle grandeur" Units = "Unités" WeightingVariable = VarY Average = Global | Global+Hemispheres TrendsFrom = 1:12 }}} * [http://dods.ipsl.jussieu.fr/brocksce/PDCTLV1_monitoring/ Maquette en élaboration] ---- #################################################### ||'''F0016''' ||'''job''' ||'''Contrôle de la présence,recopie de fichiers à des moments précis de la simulation''' ||'''status''' || Gérer un nouveau type de fichier d'input qui demande à être recopié en entrée ou sortie à des moments particuliers de la simulation sachant qu'une gestion dans le fichier driver ne rendrait pas visible ce type de fichier. Solution envisagée : * en ajoutant un troisième argument "période concernée" dans l'option list pour les sections *Files (!InitialStateFiles, !BoundaryFiles, !ParametersFiles, !RestartFiles, !OutputFiles) * et en prévoyant une analyse de la "période concernée" avec une syntaxe de type : * 1D, 5D, 15D, 30D, 1M, 5M, 1Y * 1:100:2 (de la période 1 à la période 100, tous les 2) * 1 à la première période seulement * 2:- (à partir de la deuxième période jusqu'à la fin) * ALL pour toutes les périodes Pour OPA et le fichier dampling.nc crée au premier pas de temps (gestion via le driver), on aura : {{{ [BoundaryFiles] List= () ListNonDel= (${R_BC}/OCE/${config_UserChoices_TagName}/${RESOL_OCE}/LEVITUS_1m_Temperature_Pot_Ice_nomask.nc, ., all), \ ... (${R_BC}/OCE/${config_UserChoices_TagName}/${RESOL_OCE}/runoff_1m_nomask.nc, ., ALL) \ (${R_BC}/OCE/${config_UserChoices_TagName}/${RESOL_OCE}/dampling.nc, ., 2:-) [OutputFiles] List= (${PREFIX_MO}_grid_T.nc, ${R_OUT_OCE_O_M}/${PREFIX}_1M_grid_T.nc, ALL, Post_1M_grid_T),\ ... (${PREFIX_DA}_grid_U.nc, ${R_OUT_OCE_O_D}/${PREFIX}_1D_grid_U.nc, ALL, NONE),\ (${PREFIX_DA}_grid_V.nc, ${R_OUT_OCE_O_D}/${PREFIX}_1D_grid_V.nc, ALL, NONE),\ (${PREFIX_DA}_grid_W.nc, ${R_OUT_OCE_O_D}/${PREFIX}_1D_grid_W.nc, ALL, NONE),\ (${PREFIX_DA}_diaznl.nc, ${R_OUT_OCE_O_D}/${PREFIX}_1D_diaznl.nc, ALL, NONE) \ (${PREFIX_DA}_diaznl.nc, ${R_OUT_OCE_O_D}/dampling.nc, 1, NONE) }}} ---- #################################################### ||'''F0017''' ||'''lib_sys''' ||'''Ajout machine zahir''' ||'''status''' || Ajout de zahir (libIGCM_sys_zahir dans un premier temps) ( ? ) * Difficultés à prévoir sur AIX concernant les expressions régulières (avec awk à revoir) ---- #################################################### ||'''F0018''' ||'''job''' ||'''Redémarrage du job''' ||'''status''' || Tentative de redémarrage du job en cas de plantage ( OM : script autonome ou étape initiale? ) En cas de CPU time exceeded, le PeriodState du run.card est Running, actuellement on le passe OnQueue et on resoumet. Ca pourrait être plus automatique. ---- #################################################### ||'''F0019''' ||'''job''' ||'''Spécificité runs d'ensembles''' ||'''status''' || Stratégie runs d'ensembles + Post-traitement spécifiques (SD. + ?) * A priori seul le config.card change, les comp.card et comp.driver sont identiques * Post traitement spécifique aux ensembles moyenne, variance, enveloppe, min-max ... ---- #################################################### ||'''F0020''' ||'''job''' ||'''Ajout !PeriodLength 3M, 6M''' ||'''status''' || Ajouter d'autres !PeriodLength : par exemple 3 mois et 6 mois ( ? ) ---- #################################################### ||'''F0021''' ||'''post''' ||'''Rebuild sur TX''' ||'''status''' || Rebuild sur les fichiers brutes (machines visées TX, Zahir) (SD,AC,MAF,MM) SX Ok mais trop lent sur brodie; Voir [http://forge.ipsl.jussieu.fr/igcmg/wiki/RebuildPerformances wiki]. Implique refonte total de libIGCM_post et création de libIGCM_sys_brodieTX.ksh ---- #################################################### ||'''F0022''' ||'''post''' ||'''Diagnostiques océan''' ||'''accepté''' || Ajout des diagnostiques complémentaires océaniques dans la chaîne (problème sur mercure, brodie Ok) (SD) ---- #################################################### ||'''F0023''' ||'''post''' ||'''Contrainte 2Go''' ||'''status''' || Time series crées soit par chunk de N années, soit pour rester en dessous de 2Gb, soit sans chunk (SD), soit tableau du nombres d'années par résolution 2D, 3D HF. ---- #################################################### ||'''F0024''' ||'''post''' ||'''Formatage CMOR''' ||'''status''' || Inclure la Cmorisation en fonction des MIP (AMIP, CMIP, PMIP, IPCC) (SD) ---- #################################################### ||'''F0025''' ||'''post''' ||'''Analyse du log du run.card''' ||'''status''' || Exploiter les infos de performance (CPUTIME, SYSTIME, REALTIME) stocker dans run.card (monitorer les centres de calcul en somme).[[BR]] ---- #################################################### ||'''[[Anchor(F0026)]]F0026''' ||'''misc''' ||'''Metafor, Curator''' ||'''status''' || Liens avec les projets Metafor et Curator (gridspecs, NMM, ....). ---- #################################################### ||'''[[Anchor(F0027)]]F0027''' ||'''tech''' ||'''Transfert de fichiers''' ||'''status''' || Inclure les transferts de fichiers résultats entre centres (rsync ou autre ....), ou du moins faciliter ---- #################################################### ||'''[[Anchor(F0028)]]F0028''' ||'''job''' ||'''Accès et exploitation de l'information sur la résolution''' ||'''status''' || gmake devrait pouvoir générer un fichier resol.conf contenant quelque chose comme : ATM(92x72x19)_OCE(182x149x31)_SRF(92x72x19) ce qui permettrait de déterminer à l'avance le volume de sorties à produire et mettre en place un blocage si non gérable. Comme le nombre de grandeurs sauvegardées n'est pas facilement accessible, on pourrait indiquer à l'utilisateur le volume des fichiers écrits (!OutputFiles) après la première période. ---- #################################################### ||'''[[Anchor(F0029)]]F0029''' ||'''comm''' ||'''Sorties avec grandeurs exploitables directement''' ||'''status''' || Le calcul de grandeurs utilisables directement, c'est à dire sans recombinaison postérieure, devrait être encouragé. Cela reduit d'autant les étapes de post-traitement. ---- #################################################### ||'''[[Anchor(F0030)]]F0030''' ||'''comm''' ||'''Présentation de libIGCM''' ||'''status''' || International Congress on Environmental Modelling and Software a lieu en juillet 2008 à Barcelone. Peut-on y présenter libIGCM ? [[BR]] http://www.iemss.org/iemss2008/ [[BR]] ou encore [[BR]] Session on Earth System Modeling: Strategies and Software" at the EGU 2008 [[BR]] http://www.cosis.net/members/meetings/sessions/information.php?p_id=323&s_id=5651 [[BR]] Deadline for submission of abstracts: 14 January 2008 ---- #################################################### ||'''[[Anchor(F0031)]]F0031''' ||'''libIGCM_sys''' ||'''Recopie fichiers basée sur bbFTP''' ||'''status''' || Tester si les commandes de bbFTP peuvent remplacer les scp, rsync. [[BR]] bbFTP est un logiciel optimisé pour le transfert de gros fichiers basé sur un protocol maison (qui n'est pas FTP mais dont l'usage est semblable). [[BR]] http://doc.in2p3.fr/bbftp/ ---- #################################################### ||'''[[Anchor(F0031)]]F0032''' ||'''libIGCM_sys''' ||'''dods_cp''' ||'''status''' || Ajouter à la commande dods_cp (sur les différents centres ) une gestion des droits car les dépôts avec cette commande nécessitent pour l'instant des 'chmod' subtils. Simplifier les différentes libIGCM_sys en conséquence. ---- #################################################### ||'''[[Anchor(Fxxxx)]]Fxxxx''' ||'''type''' ||'''Description succinte de la fonctionnalité''' ||'''status''' || #################################################### #################################################### ---- == Tags posés == === libIGCM_v0_9 === * Tag libIGCM_v0_9 posé le 19 octobre 2007 11:30 {{{ # alias cvs_adm='cvs -d :pserver:adm@cvs.ipsl.jussieu.fr:/home/ioipsl/CVSROOT' cvs_adm rtag libIGCM_v0_9 libIGCM }}}