= Portage Ada -> Jean Zay =

[[TOC]]

Les arch Jean Zay sont en place depuis la r3562

Pour info : [http://wiki.ipsl.jussieu.fr/Pole/ESCI/PortageJeanzay 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_dissip 
}}} 
  commis 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 ?