wiki:Modipsl_post

Version 20 (modified by acosce, 12 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 derrière les paramètres !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

  • Voici un exemple de Monitoring du couplé IPSLCM5A : 10 ans
  • On peut les voir directement sur les serveurs de fichiers dans le répertoire : IGCM_OUT/IPSLCM5A/DEVT/pdControl/MyExp/MONITORING.
  • Le monitoring d'une simulation est composé de plusieurs courbes produites à partir de variables des Time Series. Il contient également une première page détaillant les dates de passage en machine de la simulation. Cette page permet de suivre la progression d'une simulation en machine.
  • Le monitoring est lancé automatiquement à la fin des Time Series.
  • Sur la page ICMC Web Services il y a un outil permettant de comparer plusieurs monitoring entre eux. Son tutoriel est disponible ici. Les adresses à remplir pour accéder aux différents dods sont :



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

  • 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é. On peut les voir directement sur les serveurs de fichiers dans le répertoire : IGCM_OUT/IPSLCM5A/DEVT/pdControl/MyExp/ATLAS.
  • Les atlas sont des outils mis à disposition sous les comptes communs. Voir ~compte_commun/atlas/ Ils sont basés sur des fichiers atlas_composante.cfg. utilisant les outils fast/atlas. Voir : http://dods.ipsl.jussieu.fr/fast/



Post-traitements sur Cesium

La soumission des post-traitements de la SX9 et de Titane se fait vers cesium. Pour que cela marche il faut avoir créé une passphrase vide pour ssh et s'être connecté sur cesium au moins une fois.

Mémo :

mercure : pwd
~/.ssh
mercure : ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/cont003/xxxxxx/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): (RETURN)
Enter same passphrase again: (RETURN)
Your identification has been saved in ...../.ssh/id_rsa.
Your public key has been saved in ...../.ssh/id_rsa.pub.
The key fingerprint is:
af:....
mercure  : cat id_rsa.pub >>authorized_keys

Commandes à passer pour vérifier que les post-traitements se feront bien sur ceisum :

cesium : ssh mercure pwd
mercure : ssh mercure01 pwd
mercure : ssh mercure01 ssh cesium pwd

Plus d'informations sur la compilation SX9/SX8 : là (Intranet)


FAQ

Attachments (2)

Download all attachments as: .zip