• MesonhTEAMFAQ/FAQgenerale

MASDEV4_8

Why MASDEV4_8

• MASDEV4_8.doc ( by C.Lac )

Why BUG1

• why_48_bug1.doc ( by G.Tanguy )

Why BUG2

• http://mesonh.aero.obs-mip.fr/cgi-bin/mesonh_interne/mail2html.cgi?file=2010_01_04_16:42:38

Why BUG2B

• http://mesonh.aero.obs-mip.fr/cgi-bin/mesonh_interne/viewcvs.cgi/MNH-VX-Y-Z/src/MNH/?only_with_tag=MNH48-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

• http://mesonh.aero.obs-mip.fr/cgi-bin/mesonh_interne/mail2html.cgi?file=2007_07_10_18:46:58

Why BUG2

• http://mesonh.aero.obs-mip.fr/cgi-bin/mesonh_interne/mail2html.cgi?file=2007_10_11_11:11:29

Why BUG3

• http://mesonh.aero.obs-mip.fr/cgi-bin/mesonh_interne/mail2html.cgi?file=2007_11_29_10:30:31

Why BUG4

• http://mesonh.aero.obs-mip.fr/cgi-bin/mesonh_interne/mail2html.cgi?file=2008_04_22_11:25:58

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é

    • GOBPTOUT_mesonh pour Arpege et GOBPTOUT_mocage pour Mocage maintenus par jean-marc.audoin@meteo.fr

    • COD_isba3 pour Aladin et Arome (source sur tori:~mrmh008/MESONH/MAKE/grib_ala) contact francois.bonnardot@meteo.fr

  • - 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.