IPSLCM6.2

Configuration et page sous construction... Ces pages sont écrit en français puisque actuellement tout les participants du groupe de travail sont francophone.
Des comptes rendu des réunions de travail sont ici : wiki:IPSLCM6/IPSLCM6.2/CR

IPSLCM6.2 est une configuration qui regroupe plusieurs sous-configurations avec différents type expériences. Tout les sous-configurations partages les mêmes source mais des options de compilation différents sont nécessaire.

Actuellement la configuration sous le nom IPSLCM6.2_work dans modipsl. Installation se fait de maniere standard avec ./model IPSLCM6.2_work.

Compilation par défaut maintenant avec script de compilation

La compilation est désormais faite avec le script compile_ipslcm6.sh. Le script accepte plusieurs options :

Options: [LR / VLR / MR1 / MR025] Model resolution, choose only one. Default: LR.
         [ESMCO2] Compile IPSLCM6 for CO2 interactif ocean/atmosphere.
         [-full] Full recompilation of all components. This option can be added to all other options.
         [-cleannemo] Full recompilation of NEMO component  only.
         [-debug / -dev / -prod] Level of optimization. One of these can be added to all other compile options. Default: -prod.

Les exécutables créés peuvent désormais contenir dans leurs noms : la résolution atmosphérique et l'option d'optimisation

> ls modipsl/bin 
ce0l_144x142x79_prod.e
gcm_144x142x79_prod.e
opa_prod   
xios_server_prod.exe

Pour prendre en compte ces nouveaux noms d'exécutables les fichiers config.card ont des nouvelles options :

#============================
#-- ResolAtm indicates the atmospheric resolution
#   This variable is used in the executable name 
ResolAtm=144x142x79
ResolOce=ORCA1
#============================
# OptMode indicates the optimization mode choosen during compilation
# This variable is used in the executable name
OptMode=prod

Nous nous affranchissons ainsi du fichier .resol.
Attention :

• résolue: le scripts va effacer sans poser de question. Il n'y a donc plus de vérification que la compilation n'est pas déjà en cours dans un autre répertoire. lors d'une compilation stoppée puis relancée nous ne voyons pas apparaître à l'écran le message de lmdz demandant si l'on veut continuer la compilation. Il faut donc surveiller le fichier out_compile créé
• lors d'une compilation avec changement d'option d'optimisation il ne faut pas oublier de modifier le paramètre OptMode dans le fichier config.card

Le script de compilation permet de gérer un environnement commun à tous les modèles de la configuration. Par défaut pour l'instant le fichier arch utilisé est celui stocké dans ARCH/arch.env.
Attention, pour l'instant la configuration est adapté uniquement pour tourner sur irene.

Compilation avec Makefile

Ce n'est plus possible de compiler avec l'ancien Makefile, basé sur AA_make. }}}

Note que arch.env est ajouté dans config.card pour sourcer le même environnement lors de l’exécution. Avant execution, il faut modifier dans config.card, section Executable, pour adapter les noms des executables.

Sous-configuration standard LR

• Responsable : Arnaud
• Compilation : Pour la version standard LR, utiliser la compilation par défaut avec ./compile_ipslcm6.sh sans argument pour un compilation en mode prod.
• Expériences compatibles dans EXPERIMENT : IPSLCM/pdControl_TEST, IPSLCM/piControl_TEST et tout les expériences dans EXPERIMENTS/LMDZ et EXPERIMENTS/LMDZOR.

Sous-configuration ESM CO2

• Responsable : Patricia
• Compilation : pour une compilation en mode prod, utiliser la commande ./compile_ipslcm6.sh ESMCO2 -cleannemo
• Expériences compatibles : IPSLCM6/EXPERIMENTS/IPSLESM/CO2/piControl_TEST

Sous-configuration ESM INCA/AER

• Responsable : Anne
• Compilation : ./compile_ipslcm6.sh ESMAER
• Expériences compatibles : EXPERIMENTS/IPSLESM/AER/piControl_AER_TEST

Sous-configuration standard MR025

• Responsable : Christian
• Compilation : En mode prod, exécuter la commande ./compile_ipslcm6.sh MR025
• Expériences compatibles dans EXPERIMENT : IPSLCM/pdControl_MR025

Configuration figée IPSLCM6.2.2

La configuration IPSLCM6.2.2 a été figée pour permettre de réaliser la production QUEST CMIP6 aux résolutions MR1 et MR025. Les révisions des composantes utilisées permettent :

• LMDZ-ORCHIDEE
  • de résoudre les problèmes de t2m et q2m
  • s'assurer que les métadonnées ap/b et ap_bnds/b_bnds dans les fichiers Plev sont bons et de bonne dimension
  • d'utiliser une physique NPv6.2 (quelques correctins de bug par rapport à la physique NPv6.1 utilisée dans les configurations IPSLCM6.1)
• NEMO
  • Ajout de nouveaux traceurs dans PISCES ( DMS et N20 )
  • Nudging conditionnel ( masque par bassin ) en salinité et température ( optionel, ln_ssr = .true. )
  • Nouvelle paramétrisation sur la fixation d'azote dans PISCES par défaut mais possiblilité d'activer l'ancienne pour avoir la rétro-compatibilité ( ln_nitrfix_old = .true. dans namelist_pisces_cfg )

Un inter-monitoring de comparaison de 50 ans de piControl est disponible là : ​http://webservices2017.ipsl.fr/interMonitoring/tmp/interMonitoring_plot01_ZC8lEA_prod/ Cet inter-monitoring compare des simulations piControl réalisées avec IPSLCM6.1.11 sur Curie (CM61-LR-pi-03), Irene-amd (avant et après maintenance, resp vs TEST-AMD-VALID.01,TEST-MAINTENANCE-pi.01), JeanZay (CM61-pi-valid.02.JZ) et IPSLCM6.2.2 (VALID-CM622-LR.01).

Pour la configuration LMDZORINCA_v6.2.2 un intermonitoring de comparaison sur 1 an avec la configuration v6.1.11 est disponible ici ​http://webservices2017.ipsl.fr/interMonitoring/tmp/interMonitoring_plot01_LfudS1_prod/

Aide mémoire des choses à régler dans CM6.2

problèmes de diagnostiques (a priori tous résolus depuis QUEST)

• s'assurer qu'il n'y a plus de problèmes de t2m et q2m (Ionela)

• s'assurer que les métadonnées ap/b et ap_bnds/b_bnds dans les fichiers Plev sont bons et de bonne dimension (discussion Ehouarn, Laurent, Frédéric, Olivier)

• s'assurer que la variable orog sort bien dans LMDZ.

• vérifier que les diagnostics de respiration du sol rhSoil et rhLitter dans ORCHIDEE ont bien été corrigés et ont aussi le bon signe (Patricia)

• The msftyz data file identified below has an error in the encoding: it is using "3basin" as a variable name (it should be "basin"). Names starting with an integer are not allowed in CF, so this will cause many applications to crash. filename: msftyz_Omon_IPSL-CM6A-LR_dcppC-amv-neg_r9i1p1f1_gn_185001-185912.nc

• Vérifier que l'ordre des détroits pour la variable mfo a bien été corrigé.

• Vérifier que chl et chlos (chlorophylle) sortent bien dans la bonne unité (il y avait un facteur 1000 de différence gm-3 au lieu de kgm-3)

• Juliette + Julie : Je voudrais ici faire le point sur qqs bugs concernant de près ou de loin la salinité et que nous proposons de corriger pour la prod quest. NEMO tourne avec une équation d'état dite "TEOS10", ce qui est assez nouveau dans la communauté et surement plus réaliste. Conséquence: la température et la salinité utilisés dans le code et donnés en sortie (field) ne sont pas exactement les mêmes quand dans le cas par défaut (EOS80). La température et la température dite conservative (TEOS10) par opposition à la température potentielle (EOS80) (mêmes unités). La salinité est la salinité absolue (TEOS10, en g/kg) par opportion à la salinité "classique" (EOS80, en psu, issue de mesure de conductivité electrique, mais correspondant bien à des g de NACl pour 1kg d'eau de mer). Dans NEMO: celà devrait à notre avis en toute rigueur impliquer un changement de nom de la variable T et/ou S selon l'équation d'état. Christian, c'est peut être à faire remonter? Dans le ping: Il y a 2 variables possibles pour la température: nous on n'a renseigné que la temperature conservative, et de ce point de vue, on est ok. En salinité, la DR (et le ping) ne proposent qu'une variable de salinité. Or, les papiers OMIP de référence soulignent que meme si c'est "mieux" de tourner en TEOS10, il vaut mieux donner les sorties en psu car + courant. La conversion se fait par un simple facteur multiplicatif. C'est ce qu'on a fait (facteur convSpsu dans context_nemo.xml). En se repenchant sur la DR, on réalise qu'on ne le dit nulle part explicitement, un utilisateur lambda ne peut pas forcément le deviner - est ce que ca vaut le coup de mettre un commentaire quelque part pour les données publiées? Est ce qu'on peut / devrait ajouter un commentaire dans la DR "corrigée" qu'on est en train de préparer? Par ailleurs, les flux de sel en sortie de NEMO sont donnés en [sel]*kg/m2/s or le field indique que ce sont des kg/m2/s. C'est faux, ce sont en fait des g/m2/s. Idem pour les tendances de sel: elles sont données en [sel]/s/m * rau0. Elles sont donc en g/m2/s alors que à nouveau le field annonce des kg/m2/s. Dans les 2 cas, il y a une erreur dans le field, valable qu'on soit en EOS80 ou TEOS10. -> Christian, a nouveau: est ce que tu pourrais faire remonter ça? Pour le moment, on n'a pas voulu toucher au field. On a donc corrigé le 1e3 manquant dans le ping (on a appelé ca un "pansement ping") qu'on s'apprete à soumettre pour le nouveau DECK. Notre problème est: comment faire le lien avec les éventuelles corrections du field ou du code qui seront faites; c'est à dire que si nemo décide d'ajouter 1e3, il faudra l'enlever du ping... Et il y a donc une erreur dans tous les flux et tendances de sel publiés en CM6.1.XX

• Juliette+Julie : Enfin, il y a un autre bug dans le field NEMO: wfo, wfocorr et wfonocorr sont renseignés avec le mauvais signe: le field dit que c'est un flux d'eau douce "into" the ocean, alors que non, c'est out . D'ailleurs, il s'appele empmr, donc bien dans le sens d'une évaporation, et ca se verifie facilement en regardant le champs moyen. -> Christian, encore qqchose à remonter à NEMO? Je dis "facilement" mais on ne l'avait pas fait avec Julie en préparant la DR, donc l'erreur s'est répercutée dans le ping et wfo est donné avec le mauvais signe jusqu'à présent. On a fait un "pansement ping" dans la nouvelle DR, mais à nouveau, il faudra penser à l'enlever le jour ou NEMO corrige... J'imagine que ca sort des procédures? Et à nouveau aussi, peut etre que ca merite un commentaire sur ESGF? On aurrait ainsi: Pour toutes les données publiées avant CM6.2: Commentaire ESGF: Caution: Nemo runs with TEOS10 but all outputs are converted in psu. Yet, all fluxes are then given in 1e-3 kg/m2/s -> all fluxes to be multiplied by 1e-3 . wfo is given as a freshwater flux "out" of the ocean rather than into. Pour toutes les données publiées apres CM6.2: Commentaire ESGF: Caution: Nemo runs with TEOS10 but all outputs are converted in psu.

problèmes de moyen à long terme pour CM7

• problème de signe sur le diagnostic dpco2
• rsdt <> tsi/4 en moyenne sur un an, sans doute car il y a une manip de faite sur rmu0 dans recmwf_aero.F90. Et le calcul du SZA est peut-être imparfait pour les situations rasantes. Veut-on conserver rsdt=tsi/4 sur l'année ou corriger le SZA de la sphéricité de la Terre ?
• enthalpie des icebergs
• enthalpie des précipitations dans la mer
• température des rivières
• albédo de la neige des régions montagneuses
• "Only two models, GFDL-ESM4 and IPSL-CM6A-LR, underestimate the QBO latitudinal extent by more than 10%" selon ​https://agupubs.onlinelibrary.wiley.com/doi/epdf/10.1029/2019JD032362, peut-on faire quelque chose ?
• absorption des poussières selon la paramétrisation de Yves B
• activer la source de H2O stratosphérique qui vient de l'oxydation du méthane (strato trop sèche)
• aller au bout de la conservation de l'eau (reste un petit souci de conservation, attention terme calving)
• il y a des hotspot de précipitations (> 80 mm/jour en moyenne) sur certains points de grille orographique dans les Tropiques, comme en Nouvelle-Guinée. Est-ce bien réaliste ?