wiki:Modipsl_post

Version 32 (modified by acosce, 11 years ago) (diff)

--

Les post-traitements avec libIGCM

Index?/Post-traitements



Les post-traitements dans config.card

Dans config.card on indique les types de post-traitements que l'on souhaite et à quelle fréquence on va les réaliser.

#========================================================================
#D-- Post -
[Post]
#D- Do we rebuild parallel output, this flag determines
#D- frequency of rebuild submission (use NONE for DRYRUN=3)
RebuildFrequency=1Y
#D- Do we rebuild parallel output from archive (use NONE to use SCRATCHDIR as buffer)
RebuildFromArchive=NONE
#D- If you want to produce time series, this flag determines
#D- frequency of post-processing submission (NONE if you don't want)
TimeSeriesFrequency=10Y
#D- If you want to produce seasonal average, this flag determines
#D- the period of this average (NONE if you don't want)
SeasonalFrequency=10Y
#D- Offset for seasonal average first start dates ; same unit as SeasonalFrequency
#D- Usefull if you do not want to consider the first X simulation's years
SeasonalFrequencyOffset=0
#D- 
PackFrequency=1Y
#========================================================================

Si l'on ne veut pas de post-traitement il faut indiquer NONE pour les fréquences TimeSeriesFrequency et SeasonalFrequency.



Rebuilds

  • rebuild est un utilitaire qui permet de recombiner plusieurs fichiers créés par un programme parallèle (sous-domaines) en un seul.
  • rebuild est disponible avec IOIPSL. Voir http://forge.ipsl.jussieu.fr/igcmg/browser/IOIPSL/trunk/tools (il est donc distribué avec les différentes configuration via modipsl)
  • rebuild est installé sur les frontales de l'IDRIS et du CCRT dans les comptes communs. Il est appelé automatiquement à la fréquence RebuildFrequency et représente la toute première étape des post-traitements.
  • Il est impossible d'annuler les rebuilds, si l'on indique NONE pour RebuildFrequency cela lancera la reconstruction des fichiers sur la machine de calcul au lieu de la frontale ou de la machine de post-traitement.
  • RebuildFrequency=1Y indique la fréquence de lancement des travaux REBUILDA. A noter: si JobType=DEV, le paramètre est forcé la valeur de PeriodLength. Attention : RebuildFrequency n'accepte pas comme valeur des multiples de month (6M par exemple)
  • RebuildFromArchive=true indique que les fichiers seront stockés dans leur état initial (par sous-domaine), sur la machine de stockage. Le job REBUILDA commencera par aller les chercher sur le serveur de fichiers, avant de les assembler (rebuild), de leur appliquer les Patchs demandés puis de les stocker dans le répertoire usuel COMP/Output/MO ou COMP/Output/DA pour les fichiers mensuels ou journaliers de la composante COMP (OCE, ICE, ATM, SRF, ...). A noter c'est lui qui enchaine les autres post-traitements lancés par les jobs create_ts.job et create_se.job.

Choix de RebuildFrequency et RebuildFromArchive

Lorsque l'on indique RebuildFrequency = none la reconstruction des fichiers se fait au fur et à mesure de la simulation entre deux appels à gcm (--> perte de temps de calcul et mauvaise utilisation des queues parallèles). Il faut donc déporter la reconstruction sur une queue scalaire (mono sur titane). Ainsi la simulation continue de tourner pendant que le rebuild se fait en parallèle sur une autre queue. Le problème c'est que dans ce cas là on lance un job de rebuild chaque mois, et si tout le monde fait ça la queue scalaire se retrouve submergée. Il faut donc demander une fréquence de reconstruction qui soit plus "large" que le periodLength défini dans le config.card. Par exemple demander que les reconstructions se fassent une fois par an --> 1 job de lancé au lieu de 12.
Il existe ensuite deux façons de gérer le stockage des fichiers en attente de reconstruction :

  • on les stocke sur le dmfdir et on va les chercher à la fin de l'année --> Solution qu'il faut utiliser à l'idris : rebuildFromArchive=true
  • on les stocke sur le scratchdir et ils sont donc disponibles pour le rebuild ---> Solution qu'il faut utiliser au ccrt. Par contre il faut faire attention que le nombre de fichiers stockés ne dépassent pas le quota du scratchdir.



La concaténation des sorties "PACK"

Au CCRT et au TGCC les sorties des modèles sont concaténées avant d'être stockées sur le storedir. La fréquence de concaténation est définie par le paramètre PackFrequency, si celui-ci n'est pas déclaré alors on utilise la fréquence de rebuild RebuildFrequency.
Cette étape de packing est réalisée par les job PACKOUTPUT, PACKRESTART, PACKDEBUG lancés après le job de Rebuild.



Comment sont traités les différents types de fichiers d'output ?

Tous les fichiers listés ci-dessous sont archivés ou concaténés avec la même fréquence (PackFrequency)

  • Restart : ils sont archivés avec la commande tar dans un répertoire JobName/RESTART/
  • Output : ils sont concaténés par type de fichier (histmth, histday ...) avec la commande ncrcat dans les différents répertoires JobName/_comp_/Output/
  • Debug : ils sont sont archivés avec la commande tar dans un répertoire JobName/DEBUG/. Sauf les fichiers Bands créés avec l'option Adjust qui sont stockés lors de la création dans le répertoire JobName/ATM/Debug/

Certains fichiers sont stockés dans leur état initial :

  • Analyse : ils sont copiés dans JobName/_comp_/Analyse sur le cccstore
  • MONITORING : ils sont copiés dans JobName/MONITORING sur le cccwork
  • Atlas : ils sont copiés dans JobName/Atlas sur le cccwork



Time Series

Une Time Serie est un fichier, qui contient une seule variable sur toute la longueur d'une simulation (!ChunckJob2D = NONE) ou sur une période plus courte pour les variables 3D (!ChunckJob3D = 50Y) .

  • Leur fréquence d'écriture est définie dans le fichier config.card : TimeSeriesFrequency=10Y indique que les séries temporelles seront lancées tous les 10 ans.
  • Elles sont décrites dans les fichiers COMP/*.card par les options !TimeSeriesVars2D et !TimeSeriesVars3D.

Exemple pour lmdz :

45	[OutputFiles]
46	List=   (histmth.nc,      ${R_OUT_ATM_O_M}/${PREFIX}_1M_histmth.nc,      Post_1M_histmth), \
...
53	[Post_1M_histmth]
54	Patches= (Patch_20091030_histcom_time_axis)
55	GatherWithInternal = (lon, lat, presnivs, time_counter, aire)
56	TimeSeriesVars2D = (bils, cldh, ... )
57	ChunckJob2D = NONE
58	TimeSeriesVars3D = ()
59	ChunckJob3D = NONE
  • Chaque fichier de sortie (section [OutputFiles]) est associé à un post-traitement : Post_1M_histmth dans l'exemple.
  • post_1M_histmth est une section (débutant par "[Post_1M_histmth]")
  • Cette section contient les variables : Patches= , GatherWithInternal = , !TimeSeriesVars2D = , !ChunckJob2D , !TimeSeriesVars3D et !ChunckJob3D
  • Patches= (Patch_20091030_histcom_time_axis) Il s'agit du Patch qui sera appliqué sur le fichier avant son stockage sur le serveur de fichiers. Ils sont visibles au niveau de : libIGCM_post On peut avoir plusieurs Patch appliqués l'un après l'autre.
  • GatherWithInternal = (lon, lat, presnivs, time_counter, aire) Il s'agit des variables qui sont extraites du fichier initial et rangées avec la variable de la Time Serie.

Les Time Series sont rangées sur le serveur de fichiers dans les répertoires IGCM_OUT/IPSLCM5A/DEVT/pdControl/MyExp/ATM/Analyse/TS_MO pour celles qui sont issues des fichiers mensuelles. TS_DA pour celles qui sont issues des fichiers journaliers.

A noter : Il y a un job de Time Series 2D et un job par Time Series 3D sur les frontales. Pour le couplé IPSLCM5A , il y en donc 5 actuellement.



Monitoring

  • Le monitoring vous permet de suivre la progression d'une simulation en machine et de surveiller l'évolution temporelle de grandeurs clés.
  • En suivant fréquement le déroulement de vos simulations, vous pourrez détecter non seulement des anomalies d'exécution mais aussi évaluer l'influence de vos modifications. Aussi n'hésitez pas à placer le monitoring de votre simulation dans les onglets de votre navigateur. Si jamais certaines grandeurs clés évoluent de façon anormale, peut-être vous faudra-t-il envisager d'arrêter votre simulation. Vous économiserez ainsi beaucoup d'heures de calculs sur votre projet de recherche.
  • Les grandeurs clés tracées dans le monitoring sont calculées à partir des variables des Time Series. Vous pouvez ajouter ou modifier des grandeurs à surveiller en éditant les fichiers de configuration des monitoring qui sont proposés par défaut pour chaque composante. La documentation sur les calculs effectués dans le monitoring est disponible à partir de http://wiki.ipsl.jussieu.fr/IGCMG/Outils/ferret/Monitoring
  • Voici un example de monitoring du couplé IPSLCM5A sur 10 ans. Le premier onglet nommé Analysis Cards présente une synthèse des informations sur les dates et les temps d'exécution obtenus à exploitant des fichiers config.card et run.card. Le deuxième onglet nommé Monitoring Board présente un tableau de monitoring de grandeurs avec la possibilité de sélectionner une ou plusieurs composantes.

  • Pour chaque expérience, le monitoring est stocké dans le répertoire MONITORING suivant la nomenclature IGCM_OUT/IPSLCM5A/DEVT/pdControl/MyExp/MONITORING.
  • Le monitoring est déclenché automatiquement après la création des Time Series. Voir figure sur la chaîne de calcul.

Inter Monitoring



Moyennes Saisonnières

  • Les fichiers SE ou moyennes saisonnières contiennent des moyennes pour chaque mois de l'année (janv, fev...) sur une fréquence définie dans le fichier config.card
    • SeasonalFrequency=10Y Les moyennes saisonnières (des mois de janvier, février,...) seront lancées tous les 10 ans.
    • SeasonalFrequencyOffset=0 Les premières années seront sautées avant de commencer à calculer les moyennes saisonnières.
  • Les fichiers SE ou moyennes saisonnières sont lancées automatiquement à la fréquence SeasonalFrequency=10Y (en faisant attention à SeasonalFrequencyOffset=0) lorsqu'il y a autre choses que NONE dans le dernier paramètre du fichier dans la section '[OutputFiles]'.
  • Tous les fichiers avec un Post demandé sont alors moyennés avec la commande ncra avant d'être stockés dans le répertoire : IGCM_OUT/IPSLCM5A/DEVT/pdControl/MyExp/ATM/Analyse/SE 1 fichier par SeasonalFrequency=10Y



Les Atlas

  • Les atlas sont le résultat d'un post-traitement qui va créer une collection de tracés présentés dans une arborescence web. Chaque figure est disponible sous forme d'images et de fichiers pdf. Les cartes ou tracés sont réalisés avec le logiciel ferret et l'utilisation des bibliothèques de scripts ferret FAST et ATLAS. Plus d'information peuvent trouvées sur l'usage de ferret et de ces bibliothèques à partir de http://wiki.ipsl.jussieu.fr/IGCMG/Outils/ferret
  • Voici un exemple d'atlas du couplé IPSLCM5A disponible sur dods : ATM
  • Il y a au moins 8 répertoires avec les atlas pour le couplé. Ils sont basés sur des fichiers atlas_composante.cfg. On peut les voir directement sur les serveurs de fichiers dans le répertoire : IGCM_OUT/IPSLCM5A/DEVT/pdControl/MyExp/ATLAS.
  • Les bibliothèques de scripts fast/atlas sont installée sur les comptes communs.

FAQ

Attachments (2)

Download all attachments as: .zip