Changes between Version 26 and Version 27 of IPSLCM6/IPSLCM6.2


Ignore:
Timestamp:
02/04/21 13:42:41 (3 years ago)
Author:
oboucher
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • IPSLCM6/IPSLCM6.2

    v26 v27  
    8181 
    8282=== problèmes de diagnostiques ===  
    83 * s'assurer qu'il n'y a plus de problèmes de t2m et q2m  
     83* s'assurer qu'il n'y a plus de problèmes de t2m et q2m (Ionela) 
    8484* 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)  
    8585* diagnostics de respiration du sol dans ORCHIDEE (Patricia)  
    86 *  
     86* 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 
    8787 
     88* 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: 
     89Pour 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 
     90* Pour toutes les données publiées apres CM6.2: Commentaire ESGF: Caution: Nemo runs with TEOS10 but all outputs are converted in psu.  
    8891=== problèmes de moyen à long terme pour CM7 ===  
    8992* 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 ?