Portage Ada -> Jean Zay

TOC?

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.

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