Differences between revisions 38 and 39
Revision 38 as of 2011-07-08 12:58:03
Size: 6744
Editor: JuanEscobar
Comment:
Revision 39 as of 2013-06-04 11:53:57
Size: 6752
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
[[TableOfContents]] <<TableOfContents>>
Line 10: Line 10:
 . attachment:MASDEV4_8.doc ( by C.Lac )  . [[attachment:MASDEV4_8.doc]] ( by C.Lac )
Line 13: Line 13:
 . attachment:why_48_bug1.doc ( by G.Tanguy )  . [[attachment:why_48_bug1.doc]] ( by G.Tanguy )
  • MesonhTEAMFAQ/FAQgenerale


MASDEV4_8


Why MASDEV4_8


Why BUG1


Why BUG2


Why BUG2B

Why BUG4

. http://mesonh.aero.obs-mip.fr/cgi-bin/mesonh_interne/mail2html.cgi?file=2010_12_09_16:09:17


MASDEV4_7


Why BUG1


Why BUG2


Why BUG3


Why BUG4



Cout de Calcul En EUROS de MESONH


IDRIS

Pour l année 2007 (ne surtout pas extrapoler sur 2008)

Coût de l'heure monoprocesseur (frais de fonctionnement y compris salaires et charges, et investissements)

  • IBM SP4: 1.90 €
  • NEC SX8: 7.50 €


METEO-FRANCE

  • NEC SX8-R: 5.0 €


CEP

IBM-SP 4 :

  • Pour ce qui est du coût, notre budget annuel total est de £35M et nous produisons 536M d'SBUs (ou encore 41M d'heures de calcul HPC). Donc le prix maximum serait de £0.875 par heure.
  • Le budget supercalculateur + électricité + resources humaines HPC est en fait de ~£10M. Donc ~£0.25 de l'heure HPC au CEP.


LA

  • 100K€ HT
    • - pour 40 processeurs Opteron 240 = 1400€ * 48

      - switch InfiniBand 24 ports = 16000€

    • - sila stokage = 2 * 12 Tera = 9000€ * 2



Initialisation à partir des modèles opérationnels


extractecmwf

  • Cette procédure prépare un script outecmwf qui tourne sur la machine ecgate au CEPMMT, il contient:
    • - des directives MARS indiquant les champs à extraire, elles sont contruites en fonction de la date et du type d'archive (opérationnelle ou réanalyse) demandés,
    • - des commandes pour transférer le fichier GRIB produit vers ecfs ou une machine extérieure via ectrans ou ftp-gw.
  • L'équipe de soutien met à jour les directives MARS avec les changements opérationnels listés sur le site www.ecmwf.int/products rubrique 'Operational Upgrades'. Les changements impactants sont essentiellement:
    • - l'ajout/suppression de champs (en particulier de surface, cf cycle C32r3) et leur représentation (REPRES=GG,SH)
    • - la résolution horizontale du modèle: paramètres GRID, GAUSSIAN (la résolution verticale n'est pas indiquée explicitement cf LEVELIST=ALL),
    • - des traitements particuliers (par ex. pour les champs en SH extrait sur domaine limité).
    • > Si plantage à l'extraction ('Data not found'), on peut vérifier la disponibilité d'un champ ou la syntaxe de la directive sur http://www.ecmwf.int/services/archive/ . Par exemple, pour les champs de sfc non disponibles en FC 00 (mail du 16/05/2008 de J.Payart), on aurait pu utiliser le mot-clé LIST (plutôt que RETRIEVE) pour vérifier la disponibilité des champs, puis en testant le retour (voir ci-dessous) demander les champs ANalysés ou FC 00, ex. de requete LIST et de retour :

  • LIST,
    • CLASS = OD, TYPE = FC, LEVTYPE = SFC, REPRES = GG, PARAM = 139/141/170/39/40/41/42/43, DATE = 20040303, TIME = 0000, STEP = 00, TARGET = list_2004, GRID = 400, GAUSSIAN = REDUCED
  • cat list_2004
    • class = od cost = 0 field, date = 2004-03-03 expver = 1 id = 200644 levtype = sfc stream = oper time = 00:00:00 type = fc
    • > De nombreuses informations (ex. de directives, résolution (équivalence troncature-grille de Gauss),...) sont disponibles sur le site web du CEPMMT, sinon le contact est dominique.lucas@ecmwf.int


extractarpege

  • Cette procédure prépare un script tori.ext[mod]hhmmdd qui tourne sur le super-calculateur de Meteo-France, il contient 4 étapes ("Step" dans le script):
    • - Step 0: get depuis l'archive du (ou des, si boucle) fichier(s) historique(s) du modèle choisi,
    • - Step 1: post-processing
      • optionnellement (cas Arpege-Climat ou prévisions Arome) ajout de champs climatologiques dans le fichier historique,
      • FULLPOS pour Arpege, Aladin, Arome,
      • PREPAGRIB2 pour Mocage (source sur tori:~mrmh008/MESONH/MAKE/mocage),
    • - Step 2: mise au format GRIB du fichier post-processé
    • - Step 3: transfert du (ou des) fichier(s) GRIB produit(s) vers archive MF, archive Idris ou cnrmftp.
  • La mise à jour consiste surtout à suivre les changements de cycle de la chaîne Arpege/Aladin/Arome et donc à adapter la namelist de FULLPOS en conséquence.
  • Contacts: Genevieve Jaubert au GMME pour Arome, Francois Bonnardot ou Vivien Pourret à la DP ou Sylvie Donier au GMME pour Aladin, Olivier Nuissier au GMME pour Arpege-Climat, David Barbary à la CRC pour Aladin-Reunion.


programme PREP_REAL_CASE

  • Avec une augmentation de la résolution verticale et/ou horizontale des modèles opérationnels, il est souvent nécessaire d'augmenter la taille du buffer recevant le champ GRIB (code d'erreur -3 en sortie de PBGRIB): augmenter la valeur de JPACK dans read_grib_field.f90 pour mesonh et read_grib.f90 pour surfex.
  • La lecture des champs GRIB représente plus de la moité du temps CPU: une solution à envisager serait d'utiliser les routines PBG (plutôt que PBIO) également présentes dans la librairie EMOS (voir documentation sur site web du CEPMMT).
  • La parallélisation du programme est déjà faite pour la partie Surfex (voir programme Prep_Surfex). Donc s'en inspirer pour les champs d'altitude (cas ATMFILETYPE=GRIBEX) : le principe est d'avoir le champ d'entrée (2D car sur 1 niveau) en entier en mémoire et de ne faire l'interpolation horizontale que sur les points MesoNH qui sont dans le domaine du processeur : ça évite de paralléliser la routine d'interpolation horibl.

Mesonh-54: MesonhTEAMFAQ/FAQgenerale (last edited 2013-06-04 11:53:57 by localhost)