source: trunk/MESOSCALE_DEV/NOTES.txt @ 330

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

--- makegcm_g95 ne marche pas avec -no-second-underscore
    marche sans et semble compiler correctement

--- 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


gfortran https://bi.offis.de/wisent/tiki-index.php?page=WRF-gFortran


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