source: trunk/MESOSCALE_DEV/NOTES.txt @ 342

NOUVELLE FERME
- OK avec pgf_64_single
- OK avec mpi_64 sur 1 proc
- pas OK avec mpi_64 et 4 proc
  cas Hellas crashe entre la sortie 9 et 10
  .... fastsse ou pas ne change rien [mpich fast dans les deux cas]
  .... changer radt ne fait que retarder
  .... baisser le pas de temps pose probleme plus tot
  .... ne marche pas en phasant les options WRF avec les options LMD physics
  .... avec fastsse partout (mm MPI), crash ds la sortie 2
  .... option de base SVN avec mpich sans fast, marche pas non plus crashe entre 9 et 10
  .... iradia=1 ne change rien, toujours le probleme
  .... la simulation tourne lorsqu'on fait callrad = F
  .... test avec Mbounds ne renvoie aucuune erreur
  .... test avec juste -Ktrap=fp et rien d'autre renvoie aucune erreur
  .... semble OK avec iaervar=1, probleme dans meso_dustopacity ??? ou avec la lecture NETCDF ???
  .... crashe direct avec WHERE_MPI=/donnees/aslmd/MPI/mpich2-1.3.1_normal/bin
  .... alors que ca passe nickel avec iaervar=1
  .... crashe direct avec mes librairies netcdf3.6.1 compilees avec le dernier pgf2011
  .... ne crashe pas direct avec mes librairies netcdf4.0.1 compilees avec le
         dernier pgf2011 et les options utilisees dans le modele ajoutees aux options
         dans la librairie compilee dans /distrib/local
       mais crashe entre la sortie 9 et 10 comme les autres !!!!
  .... marche bien aussi avec iaervar=3... probleme de lecture netcdf ???
  .... experience: on a iaervar=4 mais juste apres readtesassim
       on regle tauref a 0.3 et ca passe. donc ce n est pas un bug structurel.
       les valeurs lues ne sont probablement les bonnes soit par probleme
       dans le fichier soit par probleme structurel dans readtesassim
  .... pourtant en affichant les valeurs on ne voit pas de pb particulier !
  .... en changeant le nom hfx en sensheat et en enlevant z0 qui pose un pb
       avec l'ancienne physique, ca ne marche toujours pas.
  .... crash: semble stocker les variables qui sortent de la physique OK
       mais le reste, par exemple tsurf, est NaN c'est bizarre
  .... avec ndomainsz=ngridmx le modele va plus loin et crashe le second jour
       a la sortie 2
  .... mm comportement sur ulrich que sur penn
  .... avec mcmodel crashe tout de suite
  .... idem en invalidant les options d optimisation dans WRF et LMD phys [non en fait il faut enlever dans MPI]
  .... test avec netcdf3: marche pas. mais ne faut-il pas enlever toutes les options?
  .... avec aucune option d'optimisation et netcdf3: Nan avant la sortie 2
  .... avec aucune option d'optimisation et netcdf4: va plus loin mais NaN entre 9 et 10
  .... options d'optimisation en -O3 toujours le mm probleme
  .... toujours le mm probleme mm avec ulimit -s unlimited

  .... test qui donne des sortie 2 des NaN en recompilant avec -fast partout
       avec mpirun -np 1, aucun souci tout va bien
       avec mpirun -np 8, souci egalement des la sortie 2
       ... visiblement un souci avec readtesassim ???
       .... MAIS NON CAR SOUCI AUSSI AVEC iaervar=1 avec 8 procs
       .... ALORS QUE PAS DE SOUCI AVEC iaervar=1 avec 4 procs
export NETCDF=/donnees/aslmd/MODELES/MESOSCALE_DEV/NETCDF/pgfortran_64_netcdf-4.0.1_fast
export WHERE_MPI=/donnees/aslmd/MPI/pgfortran_mpich2-1.3.1/bin
  .... corrections readtesassim ne semblent rien changer...
  .... sorties frequentes permettent de voir que le probleme est localisee
       mais rempli tres vite le domaine
       avec dt=40s probleme apparait au bout de 700s
       avec dt=10s probleme apparait au bout de 300s
       avec dt=100s problemen apparait au bout de 1200s
       ... visiblement le probleme apparait aux jointures des domaines ?
       ... probleme sur le vitesse verticale calculee ???
       ... visiblement non puisque mm comportement avec non_hydrostatic ou W est normal
       ... apparemment il s'agit vraiment d'une instabilite numerique
       ... mettre les tendances R..BLEN a 0 ne change rien...
       ... changer dimradmars n'arrange pas en fait lorsquon met des sorties frequentes
       ... bizarre un des 4 processes wrf.exe passe en D quelques fois ????
... ne marche pas avec les options de compilation de WRF3 !!!
     (mais domain met moins de temps a compiler)
... toujours le mm probleme en acces local disque

TEST AVEC DEBUG
  .... s'arrete au beau milieu d integrations sans sortir de message d'erreur
TEST AVEC LES POUR VOIR SI PB CORRIGE AVEC WRF3
  .... rsl_lite ne compile pas avec l'option -fast
  .... OK avec nofast_nemesis version compilee de mpich2
TEST avec le vieux mpich2... CRASH aussi entre la sortie 9 et 10

memes erreurs avec RSL_LITE de WRF3
alors qu il compile sans souci chez LES
.... un probleme d'options de compilations ????
.... pendre direct la librairie compilee chez WRF3 ???
LES: run OK
juste des NaN a la toute fin...

peut etre faut il regler dans WRFV2 les warnings relies a la compilation de rsl_lite
------- il y a probablement des choses a corriger
------- coupler avec gcc [-CC=gcc] comme dans LES ????
.... mais lorsqu on utilise le vieux mpi compile avec pgf7 pas de warnings !


...le debugger voir une floating exception sur lwtt dans la boucle avec kdlon
...avec les options debug le modele semble aller loin OK --> a verifier??
...les warnins a la compilation ont ils de l importance ?
...le fait que netcdf4 ne soit pas supporte ???
...longue compil sur module_domain....

...des pistes ici
http://www.mmm.ucar.edu/wrf/users/wrfv3/known-prob-3.0.1.html

fonctionne avec le vieux mpi dans pgf2011 [et netcdf4]
mais les jobs ne sont pas a 100% sur les procs
probleme donc... c est tres lent

test basique avec WRFV2.2.1 et le cas em_quarter_ss et mpipgf
memes resultats avec un proc ou plusieurs
pas de crash


---------------------------------------------------------------------------------

--- sur nouvelles machines problemes run parallele avec nouvelle physique

--- makegcm_g95 ne marche pas avec -no-second-underscore
    marche sans et semble compiler correctement
    ne compile pas les exec avec mais OK pour liblmd.a

--- conflits quelque soit la combinaison (f-no-second-underscore ou pas) lors
de la compilation du dynamical core WRF avec g95 64 bits
http://forum.wrfforum.com/viewtopic.php?f=5&t=3467

--- absurde: fonctionne avec les librairies NETCDF gfortran compilees par
Ehouarn sur auric
et en remplacant readtesassim par le vieux readtesassim
dans ce cas meme testphys1d.e compile correctement
... il y a quelques erreurs netcdf dans la physique visiblement ss conseq [testphys1d compile....]
... surveiller tout de meme, en rapport avec ncf90
... faut-il enlever #include netcdf.inc dans readtesassim soit dit en passant?


gfortran https://bi.offis.de/wisent/tiki-index.php?page=WRF-gFortran
---> MAIS GROS PROBLEMES (time mgmt and seg fault)


cc-----------------------------------
cc you can still use meso_WRITEDIAGFI (e.g. for debugging purpose), 
cc though this is not the default strategy now
cc-----------------------------------
cc please use cudt in namelist.input to set frequency of outputs
cc----------------------------------- 
cc BEWARE: if at least one call to meso_WRITEDIAGFI is performed,
cc cudt cannot be 0 - otherwise you'll get a "Floating exception"
cc-----------------------------------         
!      call meso_WRITEDIAGFI(ngrid,"tauref",
!     .  "tauref","W.m-2",2,
!     .       tauref)
!      call meso_WRITEDIAGFI(ngrid,"zt",
!     .  "zt","W.m-2",3,
!     .       zt)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!! note WRF MESOSCALE AYMERIC -- mot cle "caps"
!!!!! watercaptag n'est plus utilise que dans vdifc
!!!!! ... pour que la sublimation ne soit pas stoppee 
!!!!! ... dans la calotte permanente nord si qsurf=0
!!!!! on desire garder cet effet regle par caps=T
!!!!! on a donc commente "if (caps.and.(obliquit.lt.27.))" ci-dessus
!!!!! --- remplacer ces lignes par qqch de plus approprie
!!!!!      si on s attaque a la calotte polaire sud
!!!!! pas d'autre occurrence majeure du mot-cle "caps"
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


kvdif ne sert a rien dans le mesoscale martien, en raison de l'appel a la
physique et MY

Venus_est_dans_SOURCES_FORTRAN

dire que si pb il faut regradre les premiers pas de temps

adapter runmeso pour les runs ideal et les ???

faire comme storm mais avec les pour eviter les recouvrements
user manual

il faut creer TMPDIR puis GCMINI WPSFEED WRFFEED actuellement

changer la gestion topo dans LES comme fait dans modele general

        13min_si_Registry_modifie     
        15min_makemeso_moins_f        
        1min_phys_plus_dyn_chgtresol  

        PD_SCALAR est T par defaut desormais !!


        il faudrait regler le prob du Registry dans le LES
il y a un souci avec les variables liees a l'eau et d'autres

        ---anciennes notes lES sur gnome pb avec ideal.exe
        ## jusque 201 OK avec ideal.exe sequentiel
        ## ensuite il vaut mieux utiliser
        ## mpirun -n 4 ideal.exe
        ## le MP_STACK_SIZE est dans le bashrc



concat.e puis localtime.e puis
localtime.e (tres long) puis concatnc.e pour avoir en ls
le resultat doit etre strider a 10... sinon bug affichage

ncwa -O -v mtot,icetot -a longitude -d longitude,-179.0,179.0 diagfi.nc yeye.nc
ncwa -O -v mtot -a longitude -d longitude,-180.0,180.0 concat_LT.nc mawd.nc
(si trop gros faire ncrcat -v mtot -d Time,,,2 concat_LT.nc yorgl.nc)

resumee
--> localtime.e tres long
--> concatnc.e en ls tres court
--> renomme le fichier
--> ncwa -O -v mtot,Time -a longitude -d longitude,-180.0,180.0 gcm_LT14_a035.nc mawd_a035.nc 

        A FAIRE:::: mettre des flags precompilo dans les meso_
        les reporter dans makegcm

changer le renormalisation dans aeropacity ????
on ne laisse pas aerosol comme le lifting veut qu'il soit !
tenter des taux de soulevement pour que taudust_tmp soit les obs
en prescivant une dust bomb fixe d opacite, on aura au moins la structure verticale

        tester traceurs radiativement actifs avec la nouvelle physique ?????

        A FAIRE: PB LES sur iDATAPLEX (les points HFX nuls) (pas de soucis sur ciclad)
METTRE SUR LE svn LA BASE d'ETATS INITIAUX ????

more than 4 procs w/ nest ??? y reflechir
        -----------------------------------------------------------------------
        -- si possible comment determiner taille ?
        nproc doit diviser e_we-1 (1er nest)
        grid_ratio doit diviser e_we-1 +4 (1er nest)
        soit e_we=ye+1
        grid_ratio divise ye+4 et nproc divise ye
        soit nproc=8, ye=8*i
        ainsi il existe j tel que 8i + 4 = 3j ou encore 4*[2i+1] = 3j
        verifie par exemple si 2i+1 est multiple de 3
        il suffit donc de trouver un multiple impair de 3 et de deduire i
        par exemple 2i+1=33 >>>> i=16
        >>>> e_we = 129 pour le 1er nest (et ajouter 4 pour les suivants)
        ------------------------------------------------------------------------

        ne pas utiliser le FASTCASE avec traceurs (instabilites en haut)
            ces instabilites sont cependant reglees si on augmente radt a 10 par exemple

        pour le cycle de l'eau c'est OK de regler caps=F dans le mesoscale
        sauf si on commence a devoiler la calotte permanente nord
        ---> corrige, scenario caps specifique au mesoscale

        NE SERAIT-CE PAS MIEUX DE TOUT TRANSMETTRE AUX BORNES ???
        tous les traceurs, pas seulement vapor


        - attention il faut les trois MARS sinon il s arrete sans message clair
        - attention a ne pas lancer le modele s il est deja lance
        - important que pd_scalar soit a T ... le mettre par defaut ????


ROUTINES a AJOUTER sont dans COMMON_GCM
- passer aux nouveaux makegcm [en commun avec Ehouarn si on veut le nouveau
  readtesassim qui est en F90]
- il faut tester le nest pour verifier les lignes trop longues

        (ok) lier gr_fi_dyn qui est dans dyn3d
        (ok) regler le pb du nouveau readtesassim (ou alors le lier tout simplement ou
          l'appeler meso_readtesassim)
        (ok) regler le pb meso_dustlift (le lier dans makemeso comme point precedent)
             (car le souci c que dustlift est appele dans vdifc)

        RESTE a ADAPTER le LES a la NOUVELLE PHYSIQUE
        il y a normalement peu a faire
        reste a faire egalement le -DNEWPHYS pour le LES

        attention pb d'affichage des valeurs dans le fichier texte avec LES ???
        bien que les valeurs du fichier soient tout a fait raisonnables
        ... n'est-ce pas un effet de bord cache ????


        apres fusion, le LES est reconnu par module_lmd_driver lorsque diff_opt=2 km_opt=2


        -attention PB si on ne sort pas HFX et USTM (note dans le Registry)
        -il faut run.def nouvelle physique [c est meme ce qui est utilise par runmeso]
        - IL FAUT SE PENCHER SUR LE FAIT QU'ON INDIQUE q2val=0 dans lmd_driver ....

-----------------------
ATTENTION NOUVELLE PHYSIQUE
Oui, c'est quelque chose qu'il faut probablement changer partout 
maintenant que la version de pgf90 à changé (sur les machines du LMD).
Avec cette nouvelle version (7.1-6), le '-fast' est plus agressif 
qu'avant (et inclue entre autre les horribles '-Mvect=sse -Mscalarsse' 
qui dégradent la précision de certains calculs pour accélérer le code); 
je préconise de ne plus s'en servir. Bon d'accord, je n'ai pas fait une 
étude approfondie de l'impact de '-fast', mais j'ai vu qu'avec, 
j'obtenais des résultats différents lorsque je changeais simplement 
l'ordre des traceurs...

Aymeric Spiga wrote:
> je détecte ces changements d'option de compilation ; ont-ils de
> l'importance ?
>
> Aymeric
>
> < #   set optim90=" -fast"
> < #   set optimtru90=" -fast -c -Mfree "
> < #   set optim90=" -O2 -Munroll=c:1 -Mnoframe -Mcache_align"
> < #   set optimtru90=" -O2 -Munroll=c:1 -Mnoframe -Mcache_align"
> <    set optim90=" -O2 -Munroll -Mcache_align"
> <    set optimtru90=" -O2 -Munroll -Mcache_align"
> ---
>   
>>    set optim90=" -fast"
>>    set optimtru90=" -fast -c -Mfree "
------------------------------


        - attention a cp et R, normaliser une bonne fois pour toutes
        - il manque sur le SVN les cas idealises
- il manque sur le SVN les scripts MPI
        - il faut recompiler les librairies NETCDF
        - mettre la nouvelle physique
        - mettre les DEF du meso-echelle

        - modele ok sur auric
- modele pas ok sur ciclad avec pgf2010, erreur inedite un seul module manquant
        - modele LES OK sur ciclad
        - modele LES ok sur auric

        24/01/2011
        tests g95 en 64bits natif sur systeme Linux
        -- modifications de makemeso, tests
        -- tout est OK sauf les libraires NETCDF, probleme d'underscore
        -- OK avec libraires maison compilees avec g95 standard sur flores [et tourne OK]



        mpi_64_pgf7_ncdf4_mpi1.2.txt
        - probleme lors de la compilation de solve_em : LINUX runs out of memory [huchard]
        - IL FAUT COMPILER SUR auric
        nougaro est lent a la compilation, utiliser surtout auric




______________________________________________________


PB MPI
/donnees/aslmd/MODELES/MPI/mpich2-1.2.1p1_PGF7/lib/libmpich.a(simple_pmi.o):
In function `PMI_Init':
simple_pmi.c:(.text+0x15c0): warning: Using 'gethostbyname' in statically
linked applications requires at runtime the shared libraries from the glibc
version used for linking
/donnees/aslmd/MODELES/MPI/mpich2-1.2.1p1_PGF7/lib/libmpich.a(simple_pmi.o):
In function `PMI_Init':
simple_pmi.c:(.text+0x15c0): warning: Using 'gethostbyname' in statically
linked applications requires at runtime the shared libraries from the glibc
version used for linking
/donnees/aslmd/MODELES/MPI/mpich2-1.2.1p1_PGF7/lib/libmpich.a(simple_pmi.o):
In function `PMI_Init':
simple_pmi.c:(.text+0x15c0): warning: Using 'gethostbyname' in statically
linked applications requires at runtime the shared libraries from the glibc
version used for linking
/donnees/aslmd/MODELES/MPI/mpich2-1.2.1p1_PGF7/lib/libmpich.a(simple_pmi.o):
In function `PMI_Init':
simple_pmi.c:(.text+0x15c0): warning: Using 'gethostbyname' in statically
linked applications requires at runtime the shared libraries from the glibc
version used for linking


POSSIBLE mars.sed

s+ *../frame/module_internal_header_util.o ../frame/pack_utils.o
-L../external/esmf_time_f90 -lesmf_time+& -L../mars_lmd/libo -llmd
-Mmpi=mpich2+g