Portage Ada -> Jean Zay
Les arch Jean Zay sont en place depuis la r3562
Pour info : la page ESCI pour le portage de la chaîne sur jean-zay
Attention: si on veut aussi utiliser XIOS (trunk) il faut aussi ajouter la ligne
module load gcc/6.5.0/gcc-4.8.5
au fichier arch-X64_JEANZAY.env Ca n'est pas mis par défaut car avec les configurations CM6.1.* utilisent une autre version de XIOS - branches/XIOS-2.5 - pour laquelle il ne faut pas charger ce module A partir de CM6.2 on est sur la trunk de XIOS et on aura besoin de ce module.
De plus, suivant les constats et recommandations d'autres utilisateurs (NEMO, WRF), il est préférable de tourner avec l'option "-fp-model strict" => ajouté dans la r3589
Problèmes rapportés par FH
1/ Variables non initialisées dans ce0l.
Pas très grave. C'est le même bug qu'en 1D.
FH a commis. r3584
2/ flxw
On passe flxw comme flux de masse verticale à physique dans dyn2dmem/leaprfog_loc. Or ce flux de masse n'est pas forcément calculé encore. Il l'est par caladvtrac_loc mais celui ci ne calcule flxw que tous les iapp_tracvl pas de temps. Peut être que ce n'est un problème que quand iapp_tracvl n'est pas égal à iphysiq ... Je n'ai plus la main sur jean-zay ce matin pour faire des tests la dessus. En fait , on peut passer w à la place de flxw. C'est pas exactement le même mais c'est plus cohérent. Malheureusement ca change un peu les résultats numériques avec la nouvelle physique. Mais du coup, je ne comprends plus comment on avait 1+1=2. Ceci dit, je vois que les résultats ne sont pas changé au premier jour. (ce w n'est utilisé que dans les fermetures convectives). Est-ce qu'on peut être passé à côté ?
Solution du problème
Ce problème survient quand la fréquence d'appel à la physique n'est pas un multiple de la fréquence d'appel aux traceurs. Il se trouve que dans les installations auotmatiques sur ada ou jean-zay, afin d'économiser du temps de calcul, j'avais mis iphysiq=7 et iapp_tracvl=14. Donc, au premier pas de temps physique, flxw n'était pas initialisé.
Ce prbolème explique pourquoi on n'avait pas 1+1=2 sur ada quand on utilisait le tutorial_ada
Vérifification faite on a maintenant 1=12 (1 an= 12 mois)
A décider
Est-ce qu'on commet w à la place de flxw dans l'interface pour éviter ce problème ?
Ou bien est-ce qu'on met simplement un stop avec des indications dans le code si iphysiq n'est pas multiple de iapp_tracvl ?
PS : un détail à propos de 2/
Dans le code, w s'appellerait alors flxw dans call_calfis_mod. En fait, plusieurs champs comme ucov, du ... sont définis deux foix comme POINTER,SAVE dans leaprfog_mod et call_calfis_mod Pour enlever un peu de confusion, dans leapfrog_loc, j'ai ajouté des ONLY dans les USE de leapfrog_loc (qui inclue aussi un USE call_calfis_mod, ONLY : call_calfis)
- USE leapfrog_mod + USE leapfrog_mod, ONLY : ucov,vcov,teta,ps,masse,phis,q,dq + & ,ucovm1,vcovm1,tetam1,massem1,psm1,p,pks,pk,pkf,flxw + & ,pbaru,pbarv,du,dv,dteta,phi,dp,w + & ,leapfrog_allocate,leapfrog_switch_caldyn,leapfrog_switch_dissipcommis par FH dans la r3582
3/ initialisation à Nan dans orografi_strato.F90
!ym Take the point at equator close to (0,0) coordinates.
dist_min=360
dist_min_glo=360.
cell=-1
DO ij=1,klon
current_dist=sqrt(longitude_deg(ij)**2+latitude_deg(ij)**2)
current_dist=current_dist*(1+(1e-10*ind_cell_glo(ij))/klon_glo) ! For point unicity
IF (dist_min>current_dist) THEN
dist_min=current_dist
cell=ij
ENDIF
ENDDO
CALL reduce_min(dist_min,dist_min_glo)
IF (dist_min/=dist_min_glo) cell=-1
!ym in future find the point at equator close to (0,0) coordinates.
Il manquait un broadcast derrière le reduce_min.
Le reduce_min fait appel en bout de chaîne à MPI_reducemin qui calcule le minimum de plusieurs valeurs réparties sur différentes tâches mpi. Mais cette procédure se contente de calculer cette valeur sur le MASTER. Il faut donc ensuite ici la renvoyer sur les autres tâches avec un
bcast(dist_min_glo)
Problème résolu par Laurent et Frédéric et commis dans la r3586
hm ... Tu crois ça Fredho ?
Il manquait encore
- zpm1r = pplay(cell+1, jk)/paprs(cell+1, 1) + !zpm1r = pplay(cell+1, jk)/paprs(cell+1, 1) + zpm1r = pplay(cell, jk)/paprs(cell, 1)
L'indice du point est cell et pas cell+1 A confirmer quand même (de Fredho).
Le MPI_REDUCEMIN, la routine MPI qui calcule le min global au fond des appels, ne fait pas de broadcast. Elle centralise simplement le min sur le master. L'ajout d'un bcast dans orografi_strato semble résoudre le problème.
4/ Dans phys_output_write
Sans doute une variable non initialisée. On peut commenter momentannéement. Mais ne pas oublier ...
CALL histwrite_phy(o_lcc3dstra, lcc3dstra)
CALL histwrite_phy(o_icc3dcon, icc3dcon)
CALL histwrite_phy(o_icc3dstra, icc3dstra)
CALL histwrite_phy(o_cldicemxrat, zfice)
!zx_tmp_fi3d(:,:)=1-zfice(:,:)
!CALL histwrite_phy(o_cldwatmxrat, zx_tmp_fi3d)
CALL histwrite_phy(o_reffclwtop, reffclwtop)
ENDIF
Commis par Fredho sur la svn 3588. Penser à remettre
5/ stokage des tr_ancien
Avec toutes les corrections ci-dessus, le modèle tourne en mode debug, sans orchidee. Mais, à la réinitialisation, il plante parce qu'il essaie de calculer des tendances dynamiques des traceurs à partir de tr-tr_ancien. Or tr_ancien n'est pas stoké dans les fichiers de démarrage
Si on met tr_ancien=0 artificiellement, alors ca marche
Il faut sans doute commettre la sauvegarde de tr_ancien dans les start. Eventuellement en option ?
6/ Dans Orchidee/Ioipsl?
Deux plantages.
Le premier est très étonnant. Depuis la routine tlen2itau dans IOIPSL/src/calendar.f90, les deux lignes
tmp_str = input_str
WRITE(*,*) 'CALENDAR 0','input=',input_str,'tmp=',tmp_str
renvoient dans le listing de sortie
6: CALENDAR 0input=1Ytmp=1Y
où les deux chaînes de caractères sont bien identiques (égales à '1Y') mais aussi, de temps en temps
6: CALENDAR 0input=1Ytmp=
ce qui est plus surprenant. Ceci n'arrive que quand on active la parallélisation OpenMP sur Jean-Zay.
Noter au passage que le '6:' dit le numéro du process sur lequel ces lignes ont été générées. On l'obtien en lançant le modèle avec
srun --label gcm.e
Le problème est peut-être lié à une non sécurisation de l'utilisation de la parallélisation OpenMP. En effet, on appelle cette routine sur tous les process openMP alors qu'on ne devrait le faire que sur le Master.
Solution du problème
Elle est beaucoup plus simple. Vérification faite dans le code par Josefine et Arnaud, puis testée ensuite, l'appel à tlen2itau depuis ORCHIDEE/src_global/time.f90 est apparemment inutile !
En attendant que des commissions soient faites dans Orchidee (et dans quelles versions ?), j'ai mis une verue dans install_lmdz.sh qui fait la correction (pour les utilisateurs de install_lmdz.sh évidemment).
7/ Un autre problème dans Orchidee ou pas
Dans les tests que je fais en 32x24x39 en mode debug, j'obtiens au jours 145 un dépassement d'un print dans
WRITE(numout,9010) 'GLOBAL net_biosp_prod_monthly (Peta gC/month) = ',net_biosp_prod_monthly_tot 9010 FORMAT(A52,F17.14)
Il produit une fois
GLOBAL net_biosp_prod_monthly (Peta gC/month) = *****************
mais il plante ensuite.
En passant le F17 en F20 ça passe. Mais je plante alors dans la convection ... J'ai aussi mis une sed pour modifier le F17 en F20 dans install_lmdz.sh.
Ca résould le problème en 144x142x79 (ce qui veut dire que je peux enfin retravailler sur Jean-Zay) mais dans la configuration debug, ca plante le même jour dans la convection. Donc le dépassement du print n'était peut être que le signe d'un autre problème ...
Ce serait bien de vérifier que les valeurs qui dépassaient le print étaient absurdes. En l'occurence, quand on passe le print à F20, on voit que cette valeur valait :
GLOBAL net_biosp_prod_monthly (Peta gC/month) = -19.90220742088318
Le plantage dans la convection arrive à un endroit bizare aussi par le commentaire qui est juste au dessus. C'est la dernière ligne qui plante ...
! ATTENTION, la LIGNE DESSOUS A ETE RAJOUTEE ARBITRAIREMENT ET
! MASQUE UN PB POTENTIEL
chi(i) = max(chi(i), 0.)
rh(i) = max(rh(i), 0.)
plcl(i) = pnk(i)*(rh(i)**chi(i))
Plantages long terme
En plus des problèmes ci-dessus, il y a une suspicion que le modèle puisse être un peu plus instable que précédemment.
Le précédemment étant a priori la branche IPSLCM6.0.15.
En effet, j'ai apparemment des plantages tous les ~100 ans.
J'avais peut-être déjà ça sur ada. Mais c'est un peu tard pour les analyser.
J'ai eu un plantage au bout de 98 ans pour une simulation en configuration LR NPv6.1 avec bucket pour la surface. la simulation à analyser se trouve sur
/gpfsscratch/rech/gzi/rgzi027/SERIE4/NPv6.184457
On peut essayer de debugger ca, mais on n'est pas vraiment sûr que le modèle puisse tourner sans planter en bucket.
en cours
En machine :
1) une simulation de 200 ans couplée à Orchidee depuis les dernières corrections (points 1 à 7 ci dessus) (sur SERIE5)
2) use simulation de 200 ans avec la branche 6015 (sur SERIE6015)
Une simulation NPv6.1popdyn, la même que NOVEG (ci dessus) avec population dynamique de poches, a passé les 100 ans. Les populations dynamiques pourraient elles avoir un effet stabilisateur ?
à faire
Vérifier que les .def sont bien les mêmes que dans les amip standard.
