=== 19 janvier 2024 === Julie, GGac, Etienne, Brady, Thibault * presentation rapide de MEVISTO par GGac Etienne suggere d'essayer une autre approche (complémentaire de MEVISTO) pour extraire les parametres qui ont le plus d'influence pour une metrique donnée : https://scikit-learn.org/stable/auto_examples/ensemble/plot_forest_importances.html * suite aux analyses de Brady, il semble que les metriques sont plus sensibles à FALLV en mode couplé vs en mode forcé est-ce qu'on peut visualiser cela avec MEVISTO ? pas encore car on n'a pas les metriques atmospheriques de Fred -> Brady transmet les scripts de Fred pour produire ces metriques à GGac, pour qu'il les execute et le transmette ensuite à MEVISTO * Thibault a produit un ensemble de simulations LMDZ-OR-ICO (nbp40) pour comparer avec le meme ensemble LMDZ-OR-lonlat produit par Ionela, afin de comparer la sensibilité aux parametres (et, ulterieurement, inter-comparer differentes resolutions spatiales ICO) GGac propose de former Thibault à l'utilisation de MEVISTO pour produire directement les scatterplots de metriques atmospheriques -> session commune (avec Julie & Brady) mardi 23 janvier, 13h prochain point tuning après la reunion PEDALONS (lundi 29 janvier) === 11 janvier 2024 === Julie, GGac, Juliette, Redouane, Etienne, Brady * discussion autour des analyses en cours, et des experiences à relancer * calcul rapide du cout d'un exercice de tuning semi-automatique sur IPSL-CM pour tester rn-efr IPSLCM (1080 hCPU / an) * 3 parametres * 10 membres * 2 waves * 30 yr = 2MhCPU avec NEMO seul, ca couterait seulement 0.5 MhCPU * prochain point tuning vendredi 19 janvier 14h00 === 21 decembre 2023 === Julie, GGac * fin des simulations (60 ans) avec bug NEMO corrigé (tuning 5, 13 et 35). intermonitoring : https://thredds-su.ipsl.fr/thredds/fileServer/ipsl_thredds/ggachon/InterMonitoring/interMonitoring_plot01_40pqw2_prod/index.html * GGac lance un atlas C-ESM-EP pour partager avec groupe de travail "NEMO", incluant la simu de reference QUEST (CM62-LR-pd-01), CM65v420-LR-pd-tn-13 (avec bug), CM7v420-LR0-pd-tn-13 (en version IPSLCM7), et les 3 simulations avec bug SI3 corrigé * il faut reflechir sur la suite de ce groupe de travail (tuning du couplé) compte tenu de la re-structuration de la gouvernance ICMC : option 2 (2 groupes) : groupe de travail "tuning du couplé" IPSLCM7, idem que presentement reunit actuellement 5 (JM+JD+GGac+GGas+BF) + 0.5 (FH) personnes reunions hebdomadaires ideales pour l'instant à fusionner après avec "tuning LMDZ" ? groupe de travail "océan de IPSLCM7" : evolution de la config eORCA1 NEMO (developpements autour de l'Antarctique) + travail sur fermeture du cycle de l'eau rassemblerait a priori 9 (JD+GGac+Ggas+JM+MV+CdL+CB+CR+GM) + 2 (OM+MK, LSCE) personnes des reunions bi-mestrielles semblent suffisantes pour l'instant option 1 (1 seul groupe) : qui fusionne les 2 ci-dessus quand la frequence des reunions sera plus similaire ? c'est l'option préférée de Martin et Christian, pour éviter la multiplication des réunions * Julie essaye d'installer la nouvelle version de mevisto mais galère avec conda... prochaine reunion en 2024 ! === 15 decembre 2023 === Juliette, Julie, Guillaume * upgrade de mevisto avec cartes de climato. rappel tuto install : https://docs.google.com/document/d/16R39X16GQHR9dezTqQP0Ytecp8LebTly0S4s4DRRero * les 3 simulations LR0 (5, 13 et 35) avec bug NEMO corrigé sont en cours (14 ans simulés) * sur le code NEMO v4.2 pour nn_etau : a priori on peut explorer une variation continue de nn_etau entre 0 et 1, en jouant sur rn_efr (reste à comprendre un peu mieux comment en est utilisé par le code, en dehors de tke) * poursuivre analyse des simulations existantes LR0 et LR1 pour identifier en quoi nn_etau semble discriminant (ou pas), et alimenter notre stratégie future de tuning nn_etau === 8 decembre 2023 === GGac, Juliette, Julie * terminer l’inclusion des cartes dans mevisto [GGac] * lancer 3 simulations LR0 (5, 13 et 35) avec bug NEMO corrigé [GGac] pour tester 3 niveaux d'englacement différent * regarder le code NEMO v4.2 pour nn_etau [GGac] * est-ce qu’il est bien possible d’avoir l’equivalent de nn_etau = 0 en jouant sur efr et htau (et nn_etau=1) ? * quelles experiences de sensibilité il faudrait lancer pour ameliorer le couplé avec nn_etau=1 ? * poursuivre les analyses des simulations existantes * avec quels outils stats / ML pour reduire dimensionnalité ? * quelles avancées du coté de Brady ? * incorporer les progrès metriques + analyse dans synthèse tuning [JD] prochain point d’avancement le vendredi 15/12 à 13h30 === 22 novembre 2023 === GGac, Juliette, Julie * Exploration sea ice extent NH et SH dans LR et VLR * Différentes sensibilité LR et VLR * effet rnlc et gkdrag conjoint sur SIE_SH avec couple optimal (pic) * fallv et omepmx sont correlés dans le préconditionnement -> pourquoi on les garde? === 15 novembre 2023 === GGac, Juliette, Brady * Outil dash: * GGac a implémenté les régressions dans l'outil (lineaire, polynomial, exponentiel) + intervalle de confiance (stat.t de scipy). Cela necessite de mettre a jour l'environnement conda. Ggac doit mettre sa doc a jour et nous passer la derniere version de MEVISTO. * Param-param avec metrique couleur, pour se rapprocher des diag de Fred. * '''Juliette : demander login forge Ggac''' + ecrire Myriam AMIP VLR. + ref nn_etau pour Guillaume? * En parallèle du boulot de Brady: * Explorer métriques de glace de mer: quelles corrélations, quelles paramètres? cf [4c] * Implémenter metriques strato Brady pour verifier lien avec autres metriques * automatiser l'identification des 10 metriques les + correlees. ou faire des PCA? -> apres les petits exercices nn_etau et glace de mer à la main. * Explorer effet specifique de nn_etau=1 [5d] === 8 novembre 2023 === GGac, GGas, Juliette, Brady, Julie 1. on the topic glob.rt [Ggas] * slope between SST and glob.rt different in VLR whether we use glob.rt from AMIP LR vs VLR -> implies to redo preconditioning AMIP in VLR * warning : conclusion drawn on only 5 points yet * [1.a] but crash test of preconditioning as done this summer not so wrong for VLR -> implies that it is the preconditioning AMIP in LR that should be redone ! -> first we need more members AMIP VLR to make this point solid 2. stratosphere vs troposphere metrics (what should be added to preconditioning ?) * [2.a] LR AMIP vs CMIP pretty well aligned for some metrics (150hPa, mid lat) -> encouraging * [2.b] LR AMIP vs VLR CMIP not so well aligned for those metrics -> needs to confirm with more VLR AMIP ? * [2.c] 150hPa or 200hPa ? seem to have different impacts on sea ice in arctic, depending on LR or VLR * [2.d] adding stratosphere metrics, what for ? need a synthesis of climate variables affected by stratosphere metrics - and make sure that including troposphere metrics directly would not make a better job * [2.e] contact Francois Lott to imagine other metrics describing stratosphere ? 3. overall tuning of VLR and LR * [3.a] southern ocean warm bias systematic in VLR, much larger than in LR * [3.b] stratosphere warm bias more dramatic in VLR than in LR (cf progress from Myriam in reducing stratosphere bias via change in vertical levels ?) 4. sea ice * [4.a] adding atmospheric metrics in preconditioning could help increasing sea ice - can we prove that ? * [4.b] very different behavior in VLR vs LR in southern hemisphere - because not enough ice in VLR (cf strong warm bias in t2m) ? * [4.c] which metrics / parameters have the most impact on sea ice - north and south ? 5. upper ocean variables (the blue ones…) * [5.a] southern ocean warm bias, already mentioned in 4.b and * [5.b] what else ? * [5.c] does the 60yr long simulations provide a different picture from the 20yr long ones ? * [5.d] can we say something interesting about the 5 LR1 simulations ? 6. atmospheric variables : can we identify where there is an added value in running in CMIP rather than AMIP, when tuning the atmosphere parameters ? === 12 octobre 2023 === GGac, Juliette, Brady, Julie * Guillaume métriques (ocean principalement et un tout petit peu d'atmosphere) * adaptations TGCC * 5 min / Simu LR et 2 à 3 fois plus rapide VLR. * Demain (vendredi): tableau de chiffres netcdf. * GGac travaille ensuite à la visualisation - tableau de couleurs et outils dash * timeseries : les memes que metriques mais sans moyennes temporelles. En cours de développement et de parallélisation * Next step: * observations et evaluations des métriques. Il faudra commencer par identifier les jeux de données cible (tous à partir de mi novembre). * prévoir une formation à l'outil dash pour les dinosaures JJ (GGac avant le 20 octobre) * Convertir les métriques HighTUne dans l'outil de GGac (Brady & GGac) * Exploiter ces métriques pour la questions scientifique de Brady: quelles changements de T strato pour enhance AMOC? (Brady) * 2 sujets stage de Master: un mousson (Juliette & Elsa, AMIP, couple, LR et VLR) et un ocean (Julie). * Prochains rdv: * pirate tuning: 10 novembre a priori * 19 novembre: abstract AMA + abstract Brady === 29 septembre 2023 === 1. rational for "tuning" exercice Passage de NEMOv3.6 à v4 : (A noter que namelist NEMOv3.6 differente de NEMOv4 donc ce changement n'est pas juste un branchement. Implique de facto qqs changements de param) Base QUEST pour v3.6, qui ressemble à 6ALR avec biais dans l’austral, pour IPSLCM65, biais plus importants en SST, "aussi pire". Pour la glace, à peu près pareil, avec plus de glace en hiver en austral en 65, avec été pas top. Pour boréal, peu de glace, mais pas pire. Émergence de soucis en 65 : anomalie de couche de mélange dans le PacNordOuest. Pour ne pas refaire comme 6ALR, on envisage de passer en VLR pour accélérer le tuning et de faire du tuning semi-automatique en couplé. Myriam : Utilise la 65, décuplage/augmentation des défauts quand passage en VLR. Attention CM65 pas finale, donc pas objectif de tuner, c’est une question de méthode pour tuner, comment on tune ? 2. protocol for semi-automatic tuning Paramètres LMDZOR + Dynamique + Orchidée + SI + Ocean (mélange) LMDZOR 1D+3D -> Précontrainte de métriques 3. waves of LR simulations : Couplé : Refroidissement plus ou moins intense. AMOC : 20 ans c’est pas suffisant 20 ans suffisant pour faire abaque de température vs bilan radiatif TOA  en AMIP (glob.rt) abac sst glob.rt : 2.747 target for glob.rt in AMIP seems inappropriate why NEMOv4.2 induces different abac ?!? Question sur la question du préconditionnement et le glob.rt à viser : faire un test avec un choix réduit de paramètres ? pas de préconditionnement ? Olivier Boucher : Ce serait bien d’équilibrer rapidement les couplés, jeu sur les nuages. AMOC trop lent, mais peut-être tendances à identifier dedans. Juliette : Quel diagnostic faire pour identifier impact sur AMOC. Sujet de stage possible. Julie : Est-ce qu’on peut utiliser VLR pour accélérer TUNINg... 4. waves of VLR simulations abac sst glob.rt : yet different target for global SST presumably due to different spatial resolution in atmosphere - then does it challenge the validity of preconditioning in LR for VLR ? Cible globrt VLR autour de 4 plutot que 5.19 en LR. Attention avec AMIP LR!! Il faut vérifier un graph abaque AMIP VLR vs Couplé VLR. Myriam a 5 runs AMIP VLR. A intégrer à cette abaque. 2 préconditionnements différents LR ET VLR ?? Fantôme de Fred (Juliette) : chaque métrique a ses incertitudes, donc peut-être que glob.rt entre 4 et 5 c’est en fait la même cible, et donc ...??? Problème itératif dans le choix du glob.rt et les modifications du modèles dans le tuning. Juliette : Faisons 5 simus couplées où tire dans l’hypercube non réduit pour voir si ça correspond à celles de notre espace préconditionné. Myriam : Préconditionnement contraint les variables atm, mais permet pas exploration complète des params océaniques : sous-échantillonage. OB : glob.rt, contrainte dans le préconditionnement ? Pourquoi tout ce range de SST au final. Julie : Params qui change le bilan radiatif, notamment OCE/ICE. Myriam : AMIP qui nous évite les ±2degres en couplé. Juliette : Le Heat uptake est changé, donc la relation au glob.rt est changée. Question : Pas de préconditionnement pour avoir un sampling plus large et moins certain. OB : Retoucher les simus qui divergent, notamment avec params de nuages (CLC). JD : Mais d’autres params jouent autant (FALLV, ALB) donc là on remanualise le tuning auto. OB : Éliminer les outliers qui se stabilisent pas. 5. still we can learn from these waves : ATM biases : Strato too warm, Tropo too cold. Current study in review on CMIP models to reduce bias : using ozone reduction, temp is lowered. Reduced bias in strato is linked to poleward shift of jets. Similar bias in our tuning AMIP. in coupled : 150/400 hPa temp for strato/tropo bias to try metrics. There is a metric that can relate AMIP to coupled model : the 150 hPA temp. Strato temp link : Warming of strato <-> cooling of tropo. For winds : Change in 150hPa -> Change in tropics/equatorial winds in AMIP. In coupled : Effect in tropics and poles » Jet shift. FALLV and OMEPMX have strong effect on the 2 metrics given here. Julie : Jet Position is very important, so exploring params is important to adjust in the same way as glob.rt. Myriam : Impact of CDRAG on stratosphere (dynamics) and jet position ? Effect of Ice clouds in strato in recent papers on Hadley expansion (????) Brady : Important part on radiative budget is ozone latitudinal gradient. Brady : checking preconditionning metrics between coupled and amip, not 1 to 1. Julie : If precond in AMIP for coupled, dropping the metrics where behavior is different ? Need input from Atmosphericians. Myriam : Problem : we’re tuning NH Hadley cells here, and not SH, which we haven’t been able to tune yet. GGas : We have the option to choose to add metrics that seem to matter on coupled system Brady : How long do we need to run to have a better idea of the coupled sims. Julie : Longer preconditionning sim time, more params , to better constrain. Julie: Has there been progress in tuning ? Have we tuned ? Comparing LR & VLR : SI increased a bit by tuning (good run 18), too cold, but big bias in SO in VLR, "VLR is still VLR, so we can’t trust it too much" also issues with using base metrics only, maps needed to understand better. Extra effort for VLR needed. Specific tuning for VLR, with amplified biases in VLR. Specific adjustment of variables needed. Julie : "Did we progress, Juliette ? Yes we did." How do we handle similarities and differences between LR and VLR in tuning ? Co-tuning with post-hoc adjustments ? Myriam : VLR 39lv vs 59lv in ATM, 39lv is better in biases, so we would be closer to LR in tuning that way. CCL de Julie : "Faire LR et VLR a été positif pour identifier problèmes, mieux cibler le glob.rt, calage des jets, ouverture de questions essentielles, stratégie commune permet de mieux explorer, plus rapide, malgré usage d’un nouvel outil, Myriam : Méta analyse à faire. OB : Documentation à faire sur différents comportements couplé/AMIP, voir si dans premières années on peut isoler des indications pour voir sur simus plus longues. Besoin de travail spécifique sur phénomènes pour faire métriques prédictives. Dépend des phénomènes : AMOC pas ouf, mais d’autres ça peut aller, glace par exemple . Juliette : Comment on continue ? Analyses, Simus, augment set, prolonger, refaire ? Myriam : Utiliser 18 comme seed pour meilleur exploration des params. Julie : On peut plus faire un tuning complet, donc faut faire avec ce qu’on a, éventuellement un précond en plus, peut-être attendre l’évolution des composante du modèle (orchidée 4), Prendre le temps d’analyser Refaire préconditionnement ? avec ICO qui est plus cher ? Choix MBP ? Exploration from 18 old-school 18 dans IPSLCM7 ? Fait-on de la science du tuning ? Ou prépare-t-on IPSLCM7 ? Les deux... T-T Joindre Dynamico à l’effort pour pas qu’ils soient seuls. Thomas Dubos : Pas trop d’inquiétudes côté LMDZ, la résolution plus élevée fait disparaître biais, bon signe pour ICO LMDZ chez LMD, souci chez les couplés/paléo à cause du coût. Dynamico ne sera pas utilisé pour run ultra-longue, autres applications éventuelle, donc besoin de maintenir version avec lon-lat. -> Marcher ensemble : préconditionnement commun avec lonlat et ICO . === 13 septembre 2023 === Brady is making progress on analysis of wind position, results should be ready next week. Juliette have not done much on redoing files for monitoring, yet. Guillaume Gachon's priorities : 1) inter-monitoring + C-ESM-EP of LR simulations, in particular #18 (LR + VLR) to be compared to QUEST reference (with NEMO 3.6) and IPSLCM6.5 reference (that was used to produce initial conditions, with NEMOv4.2) 2) continue fixing and applying package of metric computation to LR and VLR simulations, to fill in the xls spreadsheet and advance in the assessment of the sensitivity of simulations 1) inter-monitoring and C-ESM-EP ongoing 2) requires several steps... 2.1) create an environment with appropriate python packages on irene (previous developments done on spirit through jupyter notebook) 2.2) create a dictionnary to reference all simulations on irene 2.3) migrate metrics back on spirit for visualization alternatively, we could cp_thredds all LR simulations automatically, so that they are visible from spirit directly. is there a limit in data / inode in irene-thredds ? Julie asks Arnaud about this... how to bring more manpower to help with Guillaume Gachon's developments / what lessons to learn, in terms of collaborative developments, from this non-tuning exercice ? this is a generic question, concerning both ongoing activities on irene and spirit. obviously we have more flexibility on spirit, and could ask for a new "fabric" account that we can all read/write. Julie discusses this with Guillaume Levavasseur... + each of us that ran LR simulations with nn-etau = 0, runs the equivalent with nn-etau = 1 for 20 years regarding glob.rt vs SST figure for VLR that Guillaume Gastineau produced : Julie writes values on xls spreadsheet so that we can plot the same parameter sets as for LR, and evaluate how much dispersion around correlation is similar in LR vs VLR next discussion on tuning : wednesday 20 Sep 10:00 for informal discussion to follow up on common diagnostics from Brady and Guillaume Gachon friday 29 Sep for official Pirates tuning discussion, about LR and VLR diagnostics === 6 septembre 2023 === Myriam, Guillaume Gac, Julie, Juliette, Maelle, Guillaume Gas, Brady, Juliette, Karsten, Fred Karsten (CCCma) Note on Karsten's activities : developing parameterizations for atm convection and calibration. currently CCCma using NEMO v3.4 & LIM2, moving to NEMO v4 with SI3 ; Going to 1deg atmosphere to 1/4deg ocean rappel contexte de cet exercice : lack of sea ice in VLR and LR with NEMOv4 -> exploration of sensitivity to sea ice parameters needed for coupled tuning mais Abaques entre SST et glob rt suggerent qu'il faudrait un glob rt de 5.9 W/m2 pour atteindre la bonne cible en SST globale - c’est acceptable, on refait un préconditionnement? - ce n’est pas acceptable, il faut envisager du tuning plus important du modele ocean + glace - c’est du à du transitoire, il faudrait faire les simulations couplées plus longues. A priori non, d’apres les longues simulations qu’on a faites. Karsten: their SST has a very strong transient behavior. if vertical diffusion and other related parameters is changed. Our approach: some parameters are well constrained by ocean only simulation and not touched by the tuning. We change the quantity of energy that is injected below the mixed layer and sea ice albedo. jets closer to equ -> atm cooler because more reflection. Forced to Coupled : jets move towards atm. This may explain that we need to be a bit warmer in Forced to have good SSTs in Coupled. Should be checked. Easy to diagnose, but also pb that we do not have the same sea ice. Could be diagnosed from SW. Brady ongoing to diagnose latitude of the jets. Look at the Forced-Coupled systematic difference. Remember : Model is too cold with not enough sea ice with netau = 0. nnetau=1 yields cooling. What about including metric of the jets in the preconditionning? Fred: no, because it requires 20 yrs of simulation in history matching (variability) What about not doing preconditionning and running 20yrs coupled simulations? Fred: you will end up with globrt from -15W/m2 to 15W/m2. Rq John Sinocca is in favor of NOT doing preconditionning. Idee: refaire en 1D des simulations non preconditionnées pour voir si on les aurait ruled out ou pas? Fred: Reruns QUEST configuration with latest versions to make sure the atmospheric configurations we are setting in LMDZ lead to acceptable coupled configuration in coupled mode? Julie says it is indeed the case by contruction of the protocol. Configuration 18 is not to bad in LR. Even for sea ice in SH. To be further analyzed. Fred: re-run 3D preconditionning with more appropriate target. Karsten: in CMIP6 AMIP gobrt reaches such values in some models. VLR: Myriam a fait les AMIP retracer abaques avec VLR Calculer les métriques de controle de preconditionnement avec VLR, à comparer avec LR? Fred voudrait les cycles saisonniers pour tous les runs. -> GGac? Actions 1. Rerun preconditionning -> Brady? 2. Run metrics on the already performed simulations -> GGac? 3. Diagnose latitude of the jets. -> Brady + Juliette & GGas? 4. VLR diagnostics. -> GGas + Myriam + all? 5. Préparer les cycles saisonniers moyens de toutes les simulations pour Fred. === 30 aout 2023 === Julie, GGas, Myriam, Brady, Juliette * Pb deadlock sur skl, en cours d’investigation par plateforme[[BR]] MK : c’est en partie résolu sur AMD. Prevoir de tourner plus sur rome ?[[BR]] A13 : il nous reste des heures sur rome sur gen7403 et sur gen2212[[BR]] Rq IPSL plus cher en temps de calcule sur rome, plus rapide sur skl. [[BR]] * Reprendre calculs de GGas par GGac sur excel. Pas encore fait. * Nouvel abaque par guillaume suggère que globrt doit être de l’ordre de 5.19W/m2 pour que sst proche obs. Cela remet en cause préconditionnement. A partager avec Fred. + lui rappeler de donner accès à Brady aux scripts. * VLR : sea ice bias in SH. LR seems to have a different sensitivity. Mb 18 is quite good in LR, much worse in VLR. MK thinks of putting orca1 with atm VLR. The other hybrid orca2-LR didn’t give satisfying results. Rappel: métriques du préconditionnement ne font pas appel à de la dynamique (pas position des jets notamment). Papier en cours Brady et Alexey : correction température stratosphère (via ozone) corrige position des jets Comment varie la position des jets dans nos tests couplés ? A TESTER. Ajouter des diagnostiques atm. + S’approprier les atlas atmosphériques. GGac should apply his metrics to VLR as well. * Penser au préconditionnement VLR. === 2 aout 2023 === Julie, Guillaume Gac, Myriam liste des logins pour augmentation quota scratch et periode purge : p86caub ; fersterb ; deshayej ; p86mign ; gachongu ; p86ggas ; p48ethe ; p25khod ; sfromang ; jebribey Note : l'augmentation ne concerne que le scratch gencmip6 donc attention de bien specifier config.card Myriam a relancé les 25 simus suivantes en VLR et va completer le tableau https://docs.google.com/spreadsheets/d/1phahMBCVjbWkkb2AXN4yFjJHAInzMYgfC0eB0rGO7UI/edit?usp=sharing pour qu'on puisse tout analyser en meme temps toujours des soucis avec deadlocks, il semble incontournable de recompiler - Guillaume Gachon ajoute les modifs dans le google doc : https://docs.google.com/document/d/16R39X16GQHR9dezTqQP0Ytecp8LebTly0S4s4DRRero/edit?usp=sharing diagnostiques SST pour avancer dans les abacs : Guillaume Gastineau a partagé ses scripts de calculs de SST, pour qu'on puisse les reprendre et converger vers une solution robuste et fiable Guillaume Gachon integre le calcul dans ses scripts de post-processing pour intercomparer : SST globale moyenne calculée à partir des données NEMO, partout (y compris sous glace) (colonne N) SST globale calculée hors de glace à partir des données ATM, puis moyenne temporelle (colonne K) SST globale moyenne calculée à partir des données atm, moyenne temporelle d'abord puis moyenne globale (colonne M) Julie modifie spreadsheet pour avoir la figure instantanément est-ce qu'on relance des simus LR pour completer ? oui ! et on vise d'avoir des simus en moyenne plus chaudes que la cible des observations, donc 58 (Guillaume Gachon) et 75 (Julie) - pour 20 ans a priori (d'apres les simus existantes, l'ajustement est relativement rapide) scripts post-processing sur simus LR et VLR : en cours (action Guillaume Gachon), adaptation des jupyter notebooks en scripts python pour faciliter le lancement pour ensembles de simulations === 20 juillet 2023 === Julie, Juliette, Guillaume Gac, GGas, Myriam * Rappel philosophie tests LR en cours pour verifier le tuning rt en fonction de SST couplé. * Discussion faut il zapper etape amip * VLR: Myriam a refait des tests restart * hybride depart au repos -> pb etat initial desequilibre glace de mer au sud et au nord. * depart LR climato T, S, glace de mer. * remarque: Myriam voit asymetries de sensibilite glace de mer N et S. Or nos parametres de tuning sont symétriques a priori. * Myriam lance les 120 simus a partir du meilleur restart possible semaine du 24/07 * CM7(Dynamico): * modele suffisamment bon pour etre tuné. On est prets à lancer du HM dynamico. Arnaud pret. Julie lui fournit les param 18 et 2 extreme TOA. * Intermonitoring des sorties d'ensembles * pose un pb car dans strategie ensemble, tous les mb sans le meme dossier * Il faut modifier monitoring.job pour que ca fonctionne. + pour atm, Il va aussi falloir modifier un peu nos outputs, GGac fournit une petite routine * Graphe SST/TOA: * GGas calcule les SST des 10 dernieres années des simu LR pour donnees SST globales * GGac testera ses scripts metriques des que possible. Il faudra en effet verifier que nos sauvegardes sont ok pour sortir les metriques === 13 juillet 2023 === Tuneurs Julie,, Juliette, Guillaume Gac, GGas === 29 juin 2023 === Tuneurs Julie, Brady, Juliette, Guillaume Gac, Fred Hourdin * Discussion autour des premiers tests VLR qui partent dans froid. * Cible de desequilibre global? * metrique rt dans hightune: vise 2.7W/m2 (+/- 1-2 W/m2), valeur héritée de QUEST, qui donne SST observée, avec un bon pmagic. Il faut tracer SST couple vs rt AMIP pour savoir quel cible il faut avoir. * VLR: il faut les AMIP VLR -> [Myriam] les fait pour tester, et [Brady] les fait pour alimenter metriques de Fred. * LR: a t on des couplés qui permettraient de se positionner? Run de Christian pour preparer les restart. -> [GGac] avec possiblement script Fred. * GGac lance aussi le LR AMIP Clim pour ces references * Et on ([GGac], [GGas], [Juliette]) tourne deja 5 puis 25 LR . Les 5-6 premiers correspondant aux extremes de metriques rt des AMIP LR. Voir: https://docs.google.com/document/d/16R39X16GQHR9dezTqQP0Ytecp8LebTly0S4s4DRRero/edit * Simulations en cours id number refers to Brady's big table of 120 sets of parameters (outcome from preconditionning in 1D + 3D) || tuneur || config || id number || issues ? || TOA in AMIP || SST in CMIP || || Myriam || VLR || 1-25 || ongoing || || || || fersterb || LR || 1 || done - to be extended to 60 yr || 0.903560 || || || fersterb || LR || 19 || crashed (terminate after 20 yr) || 1.494170 || || || deshayej || LR || 11 || done (no crash) || -2.525688 || || || deshayej || LR || 5 || todo for 60 yrs - crashed on 20/07/65 || 1.839810|| || || p86mign || LR || 13 || Done to 60 yr (July 20th) || -1.407830 || || || p86mign || LR || 17 || Done (Jul 20th) || -0.115180 || || || gachongu || LR || 18 || done - to be extended to 60 yr || 1.400940 || || || gachongu || LR || 121 || (18e set de parametres issus de wave 44) done || ? || || || gachongu || LR || 18 - nnetau = 1 || en cours - crashing || 1.400940 || || || gachongu || LR || 35 - nnetau = 1 || en cours || ? || || || gachongu || LR || 36 - nnetau = 1 || en cours - crashing || ? || || || fersterb || LR || 19 || ongoing - year 6 - crashing || 1.494170 || || || p86ggas || LR || 20 || Done 60 yr (ROME)|| -1.980387 || || || p86ggas || LR || 20 - nnetau = 1 || Done 20 yrs || -1.980387 || || == 26 juin 2023 == Tuneurs Julie, Maya, Juliette, Guillaume Gac Brady '''Analyse des 25 simulations VLR''' * 3 hypotheses: Bug, Parametres n'echantillonnent pas l'ensemble des valeurs, strategie de tuning (AMIP, resolution etc) pas adaptée. * A faire d'ici reunion de travail jeudi [GGac]: metriques oceaniques de Guillaume + intermonitoring sur les simulations VLR de Myriam + interface plotly de Guillaume * A garder en tete prochaines etapes GT metriques * Tableaux de metriques a separer en 2: 2 niveaux de detail, en ajoutant varables globales (rt, t2m etc) sur le niveau 1? * quid xml alleges intermonitoring * Hypothese bug: * pd vs pi? [JM] + compare logs [Brady] * NROY pas compact, que selectionne t on? En effet, clc pas tres contraint sur figures Brady. * [GGac] trace les scatterplots des 25 parametres * simulations Atm seules * 25 LMDZ LR -> done (Wave 45). Brady is plotting metrics. and runs the 120 simulations (Wave 45b) * Run LMDZ VLR?? 10 simulations? [Brady] * Run 1 LR: GGac and Brady have problems. Let's see who solves the pb first. == Manque 23 juin == == 12 mai 2203 == Notes collectives Pirates 12 mai 2023[[BR]] Présent·es: Julie, Juliette, Brady, Olivier B, Maya, Masa, Etienne, Didier, Jean-Baptiste, Pierre S, Olivier M, Guillaume Gastineau, Arnaud, Clément Dehondt, Guillaume Gachon, Sébastien Fromang, Thomas, Sébastien N, Philippe P, , Patricia[[BR]] News : 10 Mh CPU disponibles sur irene-rome gen7403 (allocation A13), qui est en sous-consommation, idem pour gen2212 (allocation A13) '''Choix des 12 paramètres[[BR]]''' Christian a intégré les modifications nécessaires pour mettre les paramètres dans les .def[[BR]] Lien entre keywords (en capitales) qui sortent du préconditonnement et paramètres qui apparaissent dans les namelist. [[BR]] Transfert ente ces 2 étapes= David (parti), Beyrem et Myriam[[BR]] '''Préconditionnement [[BR]]''' (= vague 1D et atm seule (AMIP) avant de commencer en couplé = pré-sélection)[[BR]] input : paramètres et ranges [[BR]] output : tableau 2D avec valeurs des paramètres pour chaque simulation[[BR]] 40 waves with 1D then 1 wave at 3D then combination of both (+ emulator) , producing finally 60 acceptable configurations (ie parameter sets) - only atmopsheric parameters have been tested / preconditionnned. But oceanic parameters have been sampled through LHS from the very beginning of the procedure -> comment passer des 60 configurations aux 120 finales ? cf 12 paramètres * 10 [[BR]] Pour aboutir à 120 simulations qui incluent un échantillonnage des paramètres océaniques + orchidée : [[BR]] [choix a] Idéalement il faudrait refaire depuis le préconditonnement 1D pour aboutir à 120 simulations[[BR]] [choix b] Ici, on pourrait refaire uniquement la dernière vagues, en relâchant le seuil d’acceptabilité de I (matrice d'implausibilité) et aboutir à 120 configurations[[BR]] [choix c] sans relâcher le seuil d’acceptabilité juste echantilloner 120 et non 60 sets de paramètres dans l'espace NROY de la dernière vague[[BR]] Production de 1 préconditionnement 40 waves 1D puis 1 waves 3D avec LMDZOR[[BR]] STORE 7600 inodes, 3Tb[[BR]] 90 000 CPUh on qstcmip6[[BR]] 1 jour de calculs en gros [[BR]] -> Pas contraignant. on ne change pas cette procédure.[[BR]] Reste 1 étape à réaliser : combiner préconditionnement 1D et 3D pour avoir les 120 sets de paramètres finaux (incluant ocean et orchidee)[[BR]] '''Préparation des configurations'''[[BR]] a priori Christian a tout fait, Myriam aussi pour VLR[[BR]] états initiaux prêts aussi [[BR]] https://forge.ipsl.jussieu.fr/igcmg/wiki/Pirates2022/Tuning2023[[BR]] configuration avec DYNAMICO (equivalent LR) prete à partir aussi ! run en cours pour obtenir etat initial[[BR]] pour info Christian reste disponible par email si besoin[[BR]] '''Vagues à lancer'''[[BR]] on part sur des jobs de 10 ans ? si fréquence de pack de 20 ans alors simulations de 20 ans aussi...[[BR]] on conserve le dernier restart (seulement) (via l'option LightRestartPack=TRUE dans le config.card, section [Post]) sur le STORE (inclut dans l'aide technique préparée par Christian. )[[BR]] on conserve les outputs sur STORE ou SCRATCH ? comme on ne sait pas combien de temps va nous prendre la production des métriques, on n'est pas surs que la limite de 40 jours du SCRATCH soit suffisante -> on se dirige vers une production "classique" avec une fréquence de pack de 20 ans (= durée de la simulation).[[BR]] Arnaud propose de demander une augmentation TEMPORAIRE du nombre d'inodes sur le STORE, le temps de lancer les scripts de pack avec dimension "ensemble", et de pouvoir ensuite "faire du ménage"[[BR]] alternativement Arnaud va discuter si c'est possible d'augmenter la date limite de 40 jours sur SCRATCH (point TGCC dans une 10aine de jour)[[BR]] '''Métriques'''[[BR]] coordination avec Patricia, Philippe et Guillaume Gachon pour inclure métriques sur land et végétation[[BR]] Flux d'énergie, d'eau et de carbone. (On ne sort pas de stock, sauf neige)[[BR]] Il faudra sortir des variables climat. [[BR]] Débits des fleuves[[BR]] Pour l'instant, calcul de scalaires, pas de métriques en tant que distance à une référence...[[BR]] '''Prochain point 26 mai 9h30''' == '''Exercice de tuning automatique du modele couplé Printemps 2023''' == === Technical details === #### The configuration in mod.def #### {{{ #-H- IPSLCM6.5.2 IPSLCM6.5.2 coupled configuration ( For tuning ) #-H- IPSLCM6.5.2 NEMO v4.2.0 #-H- IPSLCM6.5.2 XIOS trunk revision 1862 #-H- IPSLCM6.5.2 IOIPSL tags v2_2_5 #-H- IPSLCM6.5.2 LMDZ6 trunk revision 4507 #-H- IPSLCM6.5.2 ORCHIDEE version branches/ORCHIDEE_2_2/ORCHIDEE revision 7983 #-H- IPSLCM6.5.2 INCA6 trunk revison 1079 #-H- IPSLCM6.5.2 OASIS3-MCT 2.0_branch (rev 1818 Cerfacs server, rev 4775 IPSL server) #-H- IPSLCM6.5.2 CONFIG/IPSLCM6.5.1 rev 6435 #-H- IPSLCM6.5.2 libIGCM trunk rev 1552 #-C- IPSLCM6.5.2 IOIPSL/tags/v2_2_5 6058 8 IOIPSL modeles #-C- IPSLCM6.5.2 branches/ORCHIDEE_2_2/ORCHIDEE 7983 14 ORCHIDEE modeles #-C- IPSLCM6.5.2 CPL/oasis3-mct/branches/OASIS3-MCT_2.0_branch 4775 8 oasis3-mct . #-C- IPSLCM6.5.2 LMDZ6/trunk 4507 20 LMDZ modeles #-C- IPSLCM6.5.2 CONFIG/UNIFORM/v6/IPSLCM6.5 6443 8 IPSLCM6 config #-C- IPSLCM6.5.2 4.2.0 HEAD 22 NEMO modeles #-C- IPSLCM6.5.2 trunk/INCA6 1079 9 INCA modeles #-C- IPSLCM6.5.2 trunk/libIGCM 1581 10 libIGCM . #-C- IPSLCM6.5.2 XIOS2/trunk 2439 12 XIOS modeles }}} #### Setting up pre-builded tuning experiment #### ##### Installation and Compiling ##### {{{ mkdir $WORKDIR/TUNING_STD ; cd $WORKDIR/TUNING_STD svn co http://forge.ipsl.jussieu.fr/igcmg/svn/modipsl/trunk modipsl cd modipsl/util ./model IPSLCM6.5.2 cd ../config/IPSLCM6 ./compile_ipslcm6.sh }}} ##### Creating the job ##### From a pre-built pdControl_TUNING experiment {{{ cp EXPERIMENTS/IPSLCM/pdControl_TUNING/config.card . ../../libIGCM/ins_job }}} This example is a 20 pdControl run for tuning {{{ [UserChoices] #=========================== JobName= CM65v420-LR-pd-tun-01 #----- Short Name of Experiment ExperimentName=pdControl #----- DEVT TEST PROD SpaceName=DEVT LongName="IPSLCM6.5.0-LR" ModelName=IPSL-CM6A-LR TagName=IPSLCM6 #D- Choice of experiment in EXPERIMENTS directory ExpType=IPSLCM/pdControl_TUNING #============================ #-- leap, noleap, 360d CalendarType=leap #-- Experiment dates : Beginning and ending #-- "YYYY-MM-DD" DateBegin=1850-01-01 DateEnd=1869-12-31 }}} Ajout de JM le 12/05/2023 suite a reunion pirates du jour: [[BR]] Dans config.card, {{{ [Post]: [[BR]] LightRestartPack=TRUE [[BR]] }}} Pour ne sauver que le dernier Restart dans le STORE[[BR]] #### Notes on the Restart ##### For the LR configuration, the initial state are coming from : - a 300 years of CM6.5 pdControl run for ATM/OCE/ICE : '''CM65v420-LR-CdL-pd-04''' - a 3800 years of CM6.1 piControl run for MBG/SRF/SBG : '''CM61-LR-pi-03g''' 60 years of a pre-spinup have been done to smooth the shift from the '''pi''' atm conditions to '''pd''' for the BGC components. Two initial states have been then built : - '''CM65v420-LR-pd-tun-00''' : with nn_etau = 0 - '''CM65v420-LR-pd-tun-01''' : with nn_etau = 1 {{{ #======================================================================== #D-- Restarts - [Restarts] #D- by default: config.card describes no restart for all components #D- ie start from Levitus or limit files #D- If you want to restart all components from the same simulation, #D- put OveRule flag to 'y' and set the next 3 parameters OverRule=y #D- Last day of the experience used as restart for all components RestartDate=1919-12-31 #D- Define restart simulation name for all components #for nn_etau = 0 RestartJobName=CM65v420-LR-pd-tun-00 #for nn_etau = 1 #RestartJobName=CM65v420-LR-pd-tun-01 #D- Path Server Group Login RestartPath=${R_IN}/RESTART/IPSLCM6/DEVT/pdControl }}} === Espace de discussion === ''n'hesitez pas à ajouter ici vos questions / reponses / commentaires, ou bien directement dans le texte ci-dessous'' Juliette et Myriam 4 mai Preparation Tests VLR: Sorties: OCE, SBC,LBG: voir xml alleges et adaptes de Christian ATM: histmth MO et pr daily Restart: Myriam genere les restart a partir de ses runs. MBG partir de VLR car run 3000 ans equilibré. NEMO et SI3 en ORCA2 a partir de hybride car run avec AMOC dynamique et glace de mer HS ok. Outils d'ensemble de David en cours de transfert a Myriam. Tests en cours. Configurations: ORCHIDEE 7820+1 a confirmer avec Christian LMDZ: 4507 (= version qui a ete utilisee pour preconditionnement 3D) a confirmer avec Christian NEMO4.0 (LR partira en 4.2 mais seule difference = ghostcells car on ne rends pas les dernieres routines de Casimir) [Julie Deshayes - 18/04] je prepare un flow chart pour assembler les differentes pieces de l'exercice et rendre visible les inter-dependances des differentes actions à mener... [Juliette Guillaume Gas Guillaume Gac Jérome Vialard- 25/04] Importance du controle des gradients et du pincement de la thermocline pour les tropiques. Les parametres selectionnes n'incluent rien sur l'horizontal. Manque? -> on n'a pas encore l'expertise sur ca dans NEMOv4. On commence par quelques parametres qu'on connait et dont on sait qu'ils jouent un role sur des characteristiques importantes de l'etat moyen de l'ocean. + Ajouter explication physique de chacun des parametres du taleau. === Reunion du 18 Avril 2023 === ==== Parametres ==== || nom raccourci || vrai nom ||fichier dans /PARAM/ à modifier|| || RNALG ||(1) ||namelist_ice_ORCA1_cfg || || RNCDN ||rn_cnd_s ||namelist_ice_ORCA1_cfg || || RNCE ||rn_ce ||namelist_ORCA1_cfg || || RNLC ||rn_lc ||namelist_ORCA1_cfg || || CLC ||cld_lc_lsc & cld_lc_con (3) ||physiq.def_NPv6.2 || || FALLV ||ffallv_lsc & ffallv_con (3) ||physiq.def_NPv6.2 || || OMEPMX ||oliqmax & oicemax (3) ||physiq.def_NPv6.2 || || DZ ||fact_thermals_ed_d ||physiq.def_NPv6.2 || || EVAP ||coef_eva ||physiq.def_NPv6.2 || || GKDRAG ||sso_gkdrag ||physiq.def_NPv6.2 || || PCENT ||à externaliser (5) ||orchidee.def_CWRR || || ASNOW ||TCST_SNOWA (4) ||orchidee.def_CWRR || (1) affecte les 4 parametres suivants selon les formules: rn_alb_sdry = RNALG * (0.87-0.85) + 0.85 rn_alb_smlt = RNALG * (0.82-0.72) + 0.72 rn_alb_idry = RNALG * (0.65-0.54) + 0.54 rn_alb_imlt = RNALG * (0.58-0.49) + 0.49 @David prépare script supplémentaire pour réaliser ces opérations à partir de RNALG (3) lequel ? ou les deux ? (4) commit à venir par @Christian UPDATE JM-CE 26 avril : voir: # Time constant of the albedo decay of snow (days) (5-15) TCST_SNOWA=10 dans orchidee.def (5) modif attendue de @Patricia puis commit ? UPDATE JM-CE 26 avril : voir: # Fraction of saturated volumetric soil moisture above which transpir is max (0-1, unitless) WETNESS_TRANSPIR_MAX= 0.8, 0.8, 0.8, 0.8, 0.8, 0.8, 0.8, 0.8, 0.8, 0.8, 0.8, 0.8, 0.8 dans orchidee.def ==== Configuration pour preconditonnement et simulations couplées ==== IPSLCM6.5_work qui va devenir 6.5.2 LMDZ6 rev4305 : écho du POIHL de lundi : s'assurer de la correspondance des versions avec IPSLCM7_work ? note : ce n'est pas crucial d'assurer ce type de correspondance - priorité IPSLCM6.5_work -> à discuter avec @Etienne + modif arch file à decider pour nouveau compilateur : nouveau numero de revision ou pas ? @Laurent ORCHIDEE 2.2 rev 7820+1 : il y aura un point majeur de divergence entre vagues ICO et lonlat à cause du routage : routage simple (pour simus couplées ICO) vs routage CMIP6-style (pour simus couplées LMDZlonlat ie VLR, hybride et LR) autrement dit on ne fera pas du routage simple dans simus couplées avec LMDZlonlat note : cela n'impactera pas dans le preconditionnement meme 3D, a priori NEMOv4.2.0 pour LR et ICO, v4.0 pour VLR - n'a pas d'impact sur la physique a priori, ni sur les parametres ==== Preconditionnement ==== 3D prend 10 jours est-ce que la configuration LMDZ+OR avec les bonnes versions+revisions existe deja ? JD écrit à @Josefine pour lui poser la question (Cc @Fred, @Ionela, @Brady...) pour le routage on choisit l'option comme CMIP6 warning pour l'etat initial du precondtionnement : vu qu'on inclut 2 variables ORCHIDEE, est-ce que 1 seul etat initial unique est toujours valable pour le preconditionnement 3D ? autrement dit est-ce que 2 ans pour les vagues du preconditionnement 3D c'est suffisant pour exclure des valeurs de PCENT et ASNOW qui donnent mauvais climats ? @Frederic, @Philippe, @Agnes et @Catherine ? ==== Etats initiaux pour vagues couplées ==== etats pi pour BGC et surface continentales, et pd pour physique OCE+ATM necessite de produire 50 ans avec cette association pour lisser le choc du demarrage LR nnetau 0 et 1 : action @Christian VLR et hybride, pour 2 valeurs de nnetau : action @Myriam ==== Sorties ==== OCE: Métriques océan ont été codées (sauf enso, en cours). Liste des variables nécessaires : @Christian reprend ce que @GuillaumeGastineau a préparé ATM: (échange F Hourdin, F Codron, G Gastineau 13 avril) Métriques atm: plutot radiatives. Des métriques plus dynamiques existent, voir: https://web.lmd.jussieu.fr/~hourdin/PUBLIS/2019MS002010.pdf Variables necessaires: Histmth classique + histday de la pluie si on veut ajouter une métrique MJO (très grossière, variab des pluies jour à jour sur une région) Ils ont leurs propres scripts de génération de métriques, indépendant des métriques océaniques. Guillaume reboucle avec @Fred et @Francis pour faire du tri dans histmth puis envoie à @Christian ce qu'il a préparé MBG @Christian a fait ce qu'il faut ORCHIDEE @Patricia : il faut envoyer un nouveau file_def_lmdz (ou juste nom des variables) à @Guillaume qui combinera avec son propre tri, avant envoi à @Christian @Patricia : il faut envoyer file_def_orchidee à @Christian === Reunion du 14 Avril 2023 === Point irene: difficultés openMP. Ca semble aller normalement depuis ce matin vendredi 14 avril. Feu vert à venir dans les prochaines heures. Petit souci irene-skl avec des deadlock impromptus. Ils étaient la avant, et le sont toujours; Besoin de prévenir le TGCC: Arnaud s'en occupe, cc Julie. Discussion sur outils de communication: wiki, lien éventuels vers fichiers excel ou autre. On décide de ne pas faire de slack/mattermost/discord supplementaire. ==== 1) Paramètres inclus dans l’exploration ==== Paramètres NEMO ||nom raccourci || min || max || default || nominal exploration || nom complet || || RNALB || 0.49 || 0.58 || 0.50 || linear || rn_alb_imlt (albedo of melting bare sea ice) || || RNCDN || 0.10 || 0.50 || 0.31 || linear || rn_cnd_s (thermal conductivity of the snow over sea ice, W/m/K) || || RNCE || 0.06 || 0.08 || 0.06 || linear || rn_ce || || RNLC || 0.05 || 0.5 || 0.15 || linear || rn_lc || Guillaume Gastineau insiste pour modifier le paramètre albédo de sorte qu'on affecte les 4 valeurs d'albédo et pas 1 seule - nécessite écriture d'un (bout de) script pour transformer le scaling générique en scaling pour chacun des 4 albédos et remplacer ||RNALB || 0.49 || 0.58 || 0.50 || linear || rn_alb_imlt (albedo of melting bare sea ice) || par ||RNALG || 0 || 1 || 0.50 || linear || facteur multiplicatif pour régler les 4 albédos en même temps || Paramètres LMDZ ||CLC || 1e-4 || 1e-3 || 6.5e-4 || linear |||| ||FALLV || 0.3 || 2. || 0.8 || linear |||| ||OMEPMX || 0.0001 || 0.1 || 0.001 || log |||| ||DZ || 0.05 || 0.2 || 0.07 || linear |||| ||EVAP || 5e-5 || 5e-4 || 1e-4 || log |||| ||GKDRAG || 0.2 || 2 || 0.6 || linear || sso_gkdrag || Paramètres ORCHIDEE ||PCENT || 0.3 || 1 || 0.8 || linear || Pcent || Philippe Peylin : "Utiliser le paramètre Pcent avec les valeurs que nous t’avons données ; Ce paramètre aura une influence medium sur le flux de transpiration sur tout le globe. Catherine a aussi suggéré un paramètre du vieillissement de la neige qui aurait un impact fort mais uniquement sur les régions boréales : tcst_snowa qui est défini dans constantes.f90 (décroissance de l’albédo de la neige en fonction de son age) ; Défaut 10 jour, Range de variations plausibles: 5 - 15 jours (linear) ; Attention : il s'agit d'une constante définie avant compilation ; il faudrait donc modifier le code pour externaliser ce paramètre Patricia vérifie le code et confirme qu'il n'y a pas grand chose à faire, mais préfère confirmer auprès de Josefine la manière de procéder -> commit à inclure dans IPSLCM6.5_work ? ou autrement ? Attention implique aussi d'ajouter une nouvelle ligne au tableau : ||ASNOW || 5 || 15 || 10 || linear || tcst_snowa|| -> total 12 paramètres à inclure dans précondtionnement 1D et 3D ==== 2) Préconditionnement 1D et 3D ==== Revoir total de membres depuis qu'on upgrade à 12 variables... 120 ? Attention : préconditonnement 3D avec LMDZOR Étienne : Aussi DYNAMICO-LMDZOR seul ? (souci lié à orographie sous-maille avec GKDRAG) Julie : Non, LMDZ lonlat exclusif pour préconditionnement. Étienne : On peut espérer que l'utilisation de métriques radiatives exclusivement, pour préconditionnement, vont rendre l'exercice quand même utile. Julie : Importance scientifique pour sonder interactions OCE-ATM même avec DYNAMICO pas parfait. ==== 3) Préparation des configurations et des états initiaux ==== IPSLCM6.5_work LR (VLR - Myriam only) (LR-hybride - Myriam only) IPSLCM7_work LR Préparer Experiments LR : pdcontrol_tuning avec états intiaux pd pour LMDZ et NEMO-ICE et pi pour ORCHIDEE et PISCES -> Christian et Patricia (COMP, PARAM, DRIVER) + vérifier paramètres par défaut : ln_mle = true (par défaut dans IPSLCM6.5_work et IPSLCM7_work) do_airsol = False (a vérifier) nn_etau = 0 ou 1 en fonction de la famille d'ensemble + modif pour Carbone (pd et pi en meme temps) (Patricia : rajouter + de details ici please) ==== 4) Scripts de lancement des ensembles de simulation ==== ins_job -e : produit simulation sles.sh (en préparation par David Niezgoda) : script qui prend donnée tableau préconditonnement et modifie fichiers dans PARAM de chaque simulation - insérer ici modif pour albédos NEMO-ICE Action Julie : transmettre à David liste de noms des variables correspondant aux params sortis du precondtionnement - verifier au passage que pas de doublons dans PARAM ! Qsub_ensemble_ppe1.sh : boucle sur toutes les simulations d'une vague, va dans répertoire de chaque simu et lance qsub + modifs dans libIGCM pour mettre sorties dans SCRATCH (1 répertoire par ensemble) et non STORE Comment partager ces scripts et modifs ? Arnaud : Attention à mettre à jour avec la dernière version de libIGCM (trunk) + création d'une branche libIGCM pour tuning_ensemble ? OK dans un premier temps Documentation pour utiliser ces scripts : en cours de rédaction pour sles.sh ; pour les autres scripts c'est déjà inclus dans doc libIGCM. ==== 5) Gestion des sorties, packing et archivage dans STORE ==== NEMO on peut ne pas sortir 3D dans l'océan en modifiant field_def (et EXP/config.xml) pour rajouter des diagnostiques Christian : ca va poser des problèmes pour le monitoring tel qu'il est ; il faudrait le modifier pour qu'il prenne les nouveaux diagnostiques (t200...) ; est-ce qu'on veut avoir le monitoring pour suivre en live les simulations ? a priori non car simulations très courtes Priorité : réduire au maximum les sorties 3D de NEMO -> modifications en cours de test par Guillaume Gastineau, à intégrer dans finalisation des configurations par Christian ATM histday precip nécessaires pour diagnostiques MJO OK mais bien supprimer les autres histday pour réduire poids des sorties discussion sur différentes solutions pour modifier... xml ? Guillaume Gastineau fait les modifications nécessaires et envoie info à Christian pour finalisation configs en même temps validation par Juliette et Fred - inclure conclusion du point (6) ci-dessous [u,v,t,q en 3D en mensuel + 2D classiques (inclus flux, precip, nuages...)] ORCHIDEE Patricia souligne que si diagsHF (3h) sortis alors utile pour finaliser développements ORCHIDEE (simus offline) utile surtout pour LR a priori Attention : préparer un pack à la volée pour réduire nombre d'inodes PISCES ? Patricia et Christian réfléchissent aux variables à conserver... sachant qu'on ne fait tourner que 20 ans en tout -> moyennes annuelles ? ==== 6) Script de post-processing pour calculer les métriques ==== scripts dépendent des sorties des simulations (mais déjà modulable) ; pour l'instant surtout metriques pour ocean (inclus variables atmosphériques), en grand nombre au contraire, coté atmosphère, il y a deja eu une forte réduction des métriques pour se concentrer sur l'essentiel (ie surtout métriques radiatives), ce qui exclut des variables pertinentes pour l'océan (vent...) -> être prudent coté sorties atmosphériques pour conserver variables nécessaires pour bien qualifier / discriminer les simus -> u,v,t,q en 3D en mensuel + 2D classiques (inclus flux, précip, nuages...) ==== 7) Contacts ==== ''n'hesitez pas à ajouter votre nom ci-dessous si vous voulez etre inclus dans les mails...'' || Nom || mail || || || Myriam Khodri || myriam.khodri@locean.ipsl.fr || prod. vagues VLR et LR hybride, sur Irene ROME || || Juliette Mignot || juliette.mignot@locean.ipsl.fr || prod. vagues LR sur Irene SKL || || Guillaume Gastineau || guillaume.gastineau@locean.ipsl.fr || prod. vagues LR sur Irene SKL || || Arnaud Caubel || arnaud.caubel@lsce.ipsl.fr || prod. vagues ICO sur SKL || || Sebastien Fromang || sebastien.fromang@cea.fr || prod. vagues ICO sur SKL || || Julie Deshayes || julie.deshayes@locean.ipsl.fr || || || Frederic Hourdin || hourdin@lmd.jussieu.fr || || || Brady Fester || brady.ferster@locean.ipsl.fr || preconditionnement || || Laurent Fairhead || laurent.fairhead@lmd.ipsl.fr || || || Ionela Musat || musat@lmd.jussieu.fr || || || Maelle Coulon Decorzens || maelle.coulon-decorzens@lmd.ipsl.fr || || || Etienne Vignon || etienne.vignon@lmd.ipsl.fr || || || Philippe Peylin || peylin@lsce.ipsl.fr || || || Christian Ethe || christian.ethe@ipsl.fr ||Dev. config IPSLCM6.5.2 pour tuning|| || David Niezgoda || david.niezgoda@locean.ipsl.fr ||scripts lancement jobs et stockage || || Patricia Cadule || patricia.cadule@lsce.ipsl.fr ||initialisation et config ORCHIDEE || || Agnes Ducharne || agnes.ducharne@upmc.fr || || || Catherine Ottle || catherine.ottle@lsce.ipsl.fr || || || Frederique Cheruy || frederique.cheruy@lmd.ipsl.fr || || || Sébastien Nguyen || sebastien.nguyen@lsce.ipsl.fr || ||