= __Exécution d'une simulation__ = '''[wiki:platform/documentation_2012 Index]/[wiki:Modipsl_exec Exécution]''' [[PageOutline]] [[BR]][[BR]] '''NOTE''' avant la première simulation veillez à créer le fichier ~/.forward contenant votre adresse mail, pour que les mails envoyés en fin de simulation soient bien redirigés vers votre boîte mail. [[BR]] == Présentation du répertoire modipsl/config/XXX == Il existe deux types de répertoire modipsl/config/XXX * Ceux qui contiennent un répertoire EXPERIMENT et un répertoire GENERAL : il va falloir créer le répertoire d'expérience. C'est le cas pour tout les configuration avec suffix _v5. * Ceux qui ne contiennent pas de répertoires EXPERIMENT et GENERAL. A la place, il y aura une ou plusieurs répertoires d'expériences déjà prête. Vous auriez pas besoin de créer le répertoire d'expérience. Reportez vous directement au paragraphe [wiki:Modipsl_exec#Présentationdurépertoiredexpérience Présentation du répertoire d'expérience]. == Création du répertoire d'expérience == Avec un seul exécutable, par exemple celui de IPSLCM5_v5, vous pouvez lancer différents type de configurations "IPSLCM5_v5", mais aussi "LMDZOR" ou "LMDZ". Donc pour chaque configuration de modèle extrait vous trouverez un répertoire EXPERIMENT qui contiendra les différentes configurations que vous pouvez lancer avec l'exécutable créé. Pour préparer votre répertoire d'expérience vous devez choisir un expérience dans un sous-répertoire de EXPERIMENTS. Copier le config.card depuis cette répertoire dans modipsl/config/XXX/config.card. Modifiez le config.card comme vous le souhaitez au moins pour le nom du job, !JobName. Appliquer ensuite le commend ../../util/ins_job. Cette commande permet la création d'un répertoire d'expérience du nom du job. Le config.card sera replace dans le nouveau répertoire. Voici un exemple où on a extrait le couplé IPSLCM5_v5 et on voulait faire un expérience forcé LMDZOR de type clim : {{{ cd modipsl/config/IPSLCM5_V5 cp EXPERIENCE/LMDZOR/clim/config.card . vi config.card => Modifiez JobName, DateBegin, nombre de proc etc. ../../util/ins_job }}} Une fois le répertoire est créé, se déplacer dedans et continuer à travailler comme si c'était un répertoire "tout prête". C'est par exemple possible de refaire le job en re-appliquant ins_job dans le répertoire d'expérience, par exemple si vous changiez le nombre de processus dans config.card. Mais si vous souhaitez re-faire le job, il faut d'abord effacer le job existant car ins_job ne va jamais écraser un job existant. C'est possible de créer plusieurs répertoire d'expérience côte à côte. Chaque fois, avant utiliser ins_job, il faut copier un nouveau config.card et le modifier. Un répertoire déjà crée ne sera jamais écrasé. Il faut toujours choisir un nouveau !JobName dans config.card, sinon ins_job ne fera rien. == Présentation du répertoire d'expérience == Dans le répertoire de configuration '''modipsl/config/nom_config''' (ex : '''modipsl/config/IPSLCM5A/''') vous trouverez 1 sous répertoire de type EXP00 [[BR]] Ce répertoire contient les fichiers nécessaires pour lancer une simulation : - un fichier config.card - un répertoire COMP/ - un répertoire PARAM/ - un répertoire POST/ * 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).[[BR]] * Le répertoire PARAM/ contient les fichiers de paramètres nécessaires aux modèles[[BR]] * 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 contiennent les informations nécessaires pour chaque composante (les fichiers d'états initiaux, les fichiers de conditions aux limites, les fichiers d'émissions ...) ainsi que les indications sur comment gérer les fichiers sorties des composantes (noms des fichiers que l'on veut conserver, et post-traitement qu'on leur associe.) [[BR]] * Le répertoire POST/ contient les fichiers de configuration des monitoring. Par exemple pour le modèle couplé nous trouvons les fichiers pour la glace lim2 et stomate. [[BR]] Vous trouverez plus d'informations sur les cartes là : [http://forge.ipsl.jussieu.fr/libigcm/wiki/DocUtilisateur Doc Utilisateur libIGCM] [[BR]][[BR]] == 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 [[BR]] Voici les rubriques à modifier : {{{ JobName=_nom_simul_ ExperimentName=pdControl (mettre le nom de l'expérience selon le vocabulaire CMIP5. pdControl par défaut) SpaceName=DEVT (mettre DEVT, TEST ou PROD) 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 }}} '''note : ''' les rubriques !ExperimentName et !SpaceName sont optionnelles et n'existent pas pour toutes les configurations. === !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. [[BR]] '''Attention''' il faut impérativement que !PeriodLength ne soit pas 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. [[BR]] === La rubrique Post-traitement de config.card === Les paramètres de cette rubrique sont décrits [wiki:Modipsl_post#Lespost-traitementsdansconfig.card ici] === 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)` * `[smoothFiles] >>>> Liste de fichiers rechargés toutes les n-périodes de simulations ` * `[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 : ''(path_fichier, fichier)'' [[BR]] Elle est équivalente à : [[BR]] ''cp path_fichier fichier'' [[BR]] {{{ exemple : ListNonDel= (${R_BC}/ATM/${config_UserChoices_TagName}/${RESOL_ATM}/HISTORIQUE/so4.run1850.cdf, .),\ c'est équivalent à cp ${R_BC}/ATM/${config_UserChoices_TagName}/${RESOL_ATM}/HISTORIQUE/so4.run1850.cdf . }}} '''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. [[BR]] '''NOTE''' : dans les cartes fournies avec les modèles nous utilisons régulièrement les variables ${R_BC} et ${R_INIT}. Par défaut elles sont définies ainsi : {{{ R_BC = /ccc/work/cont003/dsm/p86ipsl/IGCM/BC R_INIT = /ccc/work/cont003/dsm/p86ipsl/IGCM/INIT }}} Toutefois si vous le souhaitez vous pouvez écraser ces définitions en redéfinissant R_BC et R_INIT dans le fichier config.card, ou en indiquant les paths complets des fichiers. [[BR]] Le répertoire /ccc/work/cont003/dsm/p86ipsl/IGCM regroupe tous les fichiers d'input pour les différentes configurations. [[BR]] === Options dans lmdz.card === {{{ LMDZ_NbPeriod_adjust=3 }}} LMDZ_NbPeriod_adjust permet de définir combien de !PeriodLenght on veut utiliser au début d'une simulation pour créer le fichier Bands qui permet d'ajuster au mieux la parallélisation du code. Si jamais on souhaite utiliser un fichier pré-existant il faut indiquer LMDZ_NbPeriod_adjust=0 et préciser le nom du fichier Bands à utiliser. [[BR]] Voir [wiki:Modipsl_execFAQ#LeparallelismeetlesfichiersBands ici] pour une description de l'utilisation des fichiers Bands. [[BR]] '''Attention''' au nombre de proc et à la grille précisés dans ce nom. {{{ ByPass_hgardfou_teta=n ByPass_hgardfou_mats=n }}} {{{ # To force higher writing level for aerosol. # LMDZ_Freq_aero : frequency for writing (in PeriodLength : 10Years = 120) , # LMDZ_Length_aero : length of writing (in PeriodLength : 1Year = 12). # To cancel this option put LMDZ_Length_aero=0 LMDZ_Freq_aero=120 LMDZ_Length_aero=12 }}} {{{ # Set COSP activation and Outputs frequency (monthly, daily, HF) = y/n LMDZ_COSP_OK=n LMDZ_COSP_monthly=y LMDZ_COSP_daily=y LMDZ_COSP_hf=n }}} {{{ # Set NMC Outputs frequency (monthly, daily, HF) = y/n LMDZ_NMC_monthly=y LMDZ_NMC_daily=n LMDZ_NMC_hf=n }}} === 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. [[BR]][[BR]] == Création du job == Avant de créer votre job, vérifier le fichier config.card. [[BR]] La création du job se fait avec la commande : {{{ 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. [[BR]] Cette commande crée également run.card.init, squelette du fichier run.card qui contiendra l'état d'avancement de la simulation. Il crée également les jobs de post-traitement, spécifiques à la machine de post-traitement dans le répertoire : modipsl/libIGCM . Ils s'appellent xxxx.job. Une fois le job créé (Job_nom_simul) vous devez vérifier les entêtes de vos jobs : * [wiki:Modipsl_mercure#ModificationsàapporterdansunJob spécificités mercure] * [wiki:Modipsl_brodie#ModificationsàapporterdansunJob spécificités brodie] * [wiki:Modipsl_titane#ModifierlalimitedetempsCPU spécificités titane] * [wiki:Modipsl_curie#AvantdelancerunJob spécificités Curie] 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 dans le temps réels demandé dans l'entête du Job (la variable '''elapstim_req''' sur titane et '''wall_clock_limit''' sur vargas). Le temps de transfère des fichiers est inclue dans le temps réel. [[BR]] exemple : {{{ PeriodLength=1M elapstim_req=20:00:00 # wall_clock_limit sur vargas PeriodNb=12 >>>> cela signifie que sur les 20 heures de temps CPU demandées on pourra faire tenir 12 mois de simulations }}} [[BR]] '''Note''': Pour vous faire une idée des temps d'exécution nécessaires vous pouvez trouver un récapitulatif des performances du modèle couplé [wiki:PerformancesIPSLCM5A ici] [[BR]] [[BR]][[BR]] == Exécution de la simulation == Avant de soumettre votre job vérifiez une dernière fois les dates et les options de démarrage du fichier config.card. [[BR]] '''Méthodes de soumission suivant les machines :''' * [wiki:Modipsl_mercure#Soumissiondujob Mercure] * [wiki:Modipsl_titane#SoumissionduJob Titane] * [wiki:Modipsl_brodie#SoumissionduJob Brodie] * [wiki:Modipsl_vargas#CommandesdegestiondeJobs Vargas] * [wiki:Modipsl_curie#Commandesdegestiondejob Curie] [[BR]] '''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 [https://forge.ipsl.jussieu.fr/igcmg/wiki/Modipsl_post ici] [[BR]][[BR]] == 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 }}} [[BR]][[BR]] == 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 un répertoire Debug/ est créé. Il contient les fichiers de debug pour chaque composante du modèle : Par exemple {{{ - xxxx_gcm.def (fichier paramètres de lmdz) - xxxx_out_gcm.e_error (sorties texte de lmdz et inca) - xxxx_run.def (fichier paramètres de lmdz) - xxxx_out_orchidee (sortie texte de orchidee) - xxxx_traceur.def (fichier paramètres de lmdz) - xxxx_orchidee.def (fichier paramètres de lmdz) - xxxx_physiq.def (fichier paramètres de lmdz) }}} 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 : {{{ $CCCSTORE/IGCM_OUT/_nom_config_/_SpaceName_/_ExperimentName_/_nom_simul_ Avec les sous répertoires suivant : RESTART DEBUG ATM CPL ICE OCE SRF SBG Out Exe ATM/Output CPL/Output etc... = sorties netcdf des différentes composantes RESTART = tar des restarts de toutes les composantes par fréquence de pack DEBUG = tar des fichiers texte debug de toutes les composantes 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 sur les frontales. [[BR]][[BR]] == Quels fichiers de sorties sont produits? == Dans config.card, vous pouvez gérer la fréquence de sorties de vos fichiers. Par défaut vous avez : * pour l'atmosphère : {{{ [ATM] WriteFrequency="1M 1D HF" }}} c'est à dire des fichiers mensuels (1 valeur par mois) rangés dans ATM/Ouput/MO, des fichiers journaliers rangés par mois (28,30 ou 31 valeurs) dans ATM/Output/DA et des fichiers haute fréquence (4 valeurs par jour) rangés dans ATM/Ouput/HF. * pour l'océan et le coupleur : {{{ [OCE] WriteFrequency="1M 1D" }}} c'est à dire des fichiers mensuels (1 valeur par mois) rangés dans OCE/Ouput/MO (CPL/Output/MO) et des fichiers journaliers rangés par mois (28, 30 ou 31 valeurs) dans OCE/Output/DA (CPL/Output/DA) * pour la glace de mer, les surfaces continentales et la biogéochimie continentale : {{{ WriteFrequency="1M" }}} c'est à dire des fichiers mensuels rangés dans ICE/Ouput/MO, SRF/Output/MO et SBG/Output/MO Que peut-on demander ? * Vous pouvez enlever une fréquence que vous ne souhaitez pas : HF pour ATM par exemple. * Pour ajouter une fréquence, il faut rajouter le fichier généré dans le fichier COMP.card, rajouter le traitement des paramètres de gestion de cette fréquence dans COMP.driver. * Pour modifier le niveau de sorties de LMDZ, les paramètres lev_histf sont à modifier dans le fichier PARAM/physiq.def_L39 (ou _L19 si vous êtes avec 19 niveaux). Par défaut : * lev_histhf=2 * lev_histday=2 * lev_histmth=2 * Pour modifier les sorties de NEMO, vous pouvez ajouter ou supprimer des variables dans le fichier PARAM/iodef.xml. * A faire dans la partie 2 : output files definition pour supprimer des variables. * A faire dans la partie 2 pour ajouter des variables * suffisant pour des variables déjà décrites dans la partie 1 : definition of all existing variables * en modifiant le code NEMO sinon. * Pour modifier le niveau de sortie d'Orchidee, les paramètres SECHIBA_HISTLEVEL et STOMATE_HISTLEVEL sont à modifier dans PARAM/orchidee.def. Par défaut : * SECHIBA_HISTLEVEL = 5 * STOMATE_HISTLEVEL=10 == Simulations d'ensemble == Cette fonctionnalité est en cours de développement. === Comment les préparer? === * il faut un fichier ensemble.card qui contient : * type d'ensemble activé * ensemble par restart/perturbation : * nom de l'ensemble * nombre de membres * les dates de départ * le nom du programme qui modifiera les fichiers de restart pour y introduire un bruit blanc. Exemple : * ensemble paramétrique : les paramètres et leurs valeurs * il faut lancer ins_job en précisant l'expérience à dupliquer en ensemble === Comment les lancer? === * il faut utiliser le fichier créé avec l'ensemble des jobs à soumettre === Comment les surveiller? === [[BR]][[BR]] ---- = __FAQ__ = * [wiki:Modipsl_execFAQ#CommentdécrypterlefichierScript_Output Comment décrypter le fichier Script_Output ?] * [wiki:Modipsl_execFAQ#Écraserunesimulation Comment écraser une simulation ?] * [wiki:Modipsl_execFAQ#Continuerunesimulation Comment continuer une simulation ?] * [wiki:Modipsl_execFAQ#Démarrerdepuisuneautresimulation Comment utiliser les fichiers de restart d'une autre simulation ?] * [wiki:Modipsl_execFAQ#Commentpréparerunenouvelleexpérience Comment préparer une nouvelle expérience ?] * [wiki:Modipsl_execFAQ#Commentvérifierquelessortiessontcomplètes Comment repérer qu'il manque un fichier dans les sorties, comment repérer que les tailles de fichiers ne sont pas identiques pour tous les mois des différentes années ? ] * [wiki:Modipsl_execFAQ#Commentboucheruntroucadrelancerunesimulationpourrefairelesfichiersdunmoiscomplet Comment boucher un trou cad relancer une simulation pour refaire les fichiers d'un mois complet?] * [wiki:Modipsl_execFAQ#Commentrelancerunesimulationàlidentiquepourrécupérerquelquesfichiersdesortiedisparus Comment relancer une simulation à l'identique pour récupérer quelques fichiers de sortie disparus ?] * [wiki:Modipsl_execFAQ#commentrepérerlessimusàrefaireéventuellementlorsqueleCCRTprévientquunebandeestirrécupérableetlistentlesfichiersperdus comment repérer les simus à refaire éventuellement lorsque le CCRT prévient qu'une bande est irrécupérable et listent les fichiers perdus ?] * [wiki:Modipsl_execFAQ#PourquoijetrouvelemotcléFataldanslefichierrun.card Pourquoi je trouve le mot clé Fatal dans le fichier run.card ?] * [wiki:Modipsl_execFAQ#CommentrefaireunmoisdunesimulationquiatournésurDMFDIRenstockantlesrésultatssurSTORE Comment refaire un mois d'une simulation qui a tourné sur DMFDIR en stockant les résultats sur CCCSTORE ? ] * [wiki:PerformancesIPSLCM5A Temps d’exécution du couplé IPSLCM5A] * [wiki:Modipsl_execFAQ#LeparallelismeetlesfichiersBands Le parallélisme et les fichiers Bands] * [wiki:Modipsl_execFAQ#CréationdelétatinitialpourLMDZOR Création de l'état initial pour LMDZOR] * [wiki:LMDZOR_v4#UsingIPSLcoupledmodeloutput Comment créer l'état inital pour LMDZ avec les SST du couplé IPSLCM5A] * [wiki:Modipsl_execFAQ#Passagedunesimulationcoupléeàunesimulationforcée Passage d'une simulation couplée à une simulation forcé] * [wiki:Modipsl_execFAQ#CommentdésactiverSTOMATEdansIPSLCM5ouLMDZOR Comment désactiver Stomate dans IPSLCM5 ou LMDZOR ?] * [wiki:Modipsl_execFAQ#Commentlancerunrunguidénudge Comment utiliser le mode guidé (nudge) de LMDZ ?] * [wiki:Modipsl_execFAQ#Commentregarderlesfichierssurdods Comment utiliser les services dods ?]