Changeset 341 for trunk/MESOSCALE_DEV

Timestamp:

Nov 3, 2011, 2:28:57 PM (13 years ago)

Author:

aslmd

Message:

MESOSCALE: tests pour faire marcher le modele en parallele sur la ferme. toujours infructueux... toutes les notes incluses et options explorees en commentaire. les options par defaut restent les memes en attendant. ajout de scripts pour compiler NETCDF et MPI. correction d un probleme de Registry et de makemeso pour les runs LES ancienne physique. ajout d un cas test LES phoenix.

Location:

trunk/MESOSCALE_DEV

Files:

• MPI (added)
• MPI/install_gfortran_old (added)
• MPI/install_pgfortran (added)
• MPI/notes.mpi (added)
• NETCDF/netcdf-3.6.1.tar.gz (deleted)
• NETCDF/pgfortran_64 (added)
• NETCDF/pgfortran_64_note.txt (added)
• NOTES.txt (modified) (1 diff)
• TESTS/LMD_LES_MARS_test_phoenix.tar.gz (added)

trunk/MESOSCALE_DEV/NOTES.txt

@@ -10 +10 @@
   .... 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