Branche Amaury dev
Ceci est une page temporaire qui commente certains aspects de la branche Amaury_dev en attendant qu'elle soit mergée
La branche Amaury_dev vise à moderniser une grande partie du code de LMDZ, en partant de r5056.
Les grands changements (r5155) sont :
- Le remplacement de nombreux
INCLUDE *.hpar des modules, en particulier cela remplace un certain nombre deCOMMON - La conversion de tous les fichiers fixed-form
*.Fen free-form*.[fF]90 - Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin
- Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les
INCLUDE "netcdf.h") - La suppression / déplacement dans
obsoletede code très ancien et inutilisé - La correction de la plupart des warnings de compilation
gfortran - La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)
- La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage
- Le renommage des modules en
ldmz_*pour éviter les collisions de namespace - L'harmonisation de la syntaxe Fortran (cf [1])
- Un linting de la plupart des fichiers
Sommaire
Convergence
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :
# Tests auto de convergence All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd All good ! for r5155/r5017=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd All good ! for r5155/r5017=-rad rrtm -parallel none -veget none -compilephysiq lmd All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd All good ! for r5155/r5017=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd All good ! for r5155/r5017=-rad ecrad -parallel none -veget none -compilephysiq lmd All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd All good ! for r5155/r5017=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd All good ! for r5155/r5017=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd All good ! for r5155/r5017=-debug -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd -d 79 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmdiso -d 48x36x39 All good ! for r5157/r5150=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd All good ! for r5157/r5017=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd
(XIOS n'est pas testé vs 5150 car il segfault sur 5017)
Opérations mises "de côté"
Remplacement de FCTTRE.h
FCTTRE.h contient des fonctions "en ligne", syntaxe qui est dépréciée. De plus, c'est utilisé via un INCLUDE.
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.
Remplacement du commun comgeom
Le common /comgeom/ est partagé entre lmdz_comgeom.f90 et lmdz_comgeom2.f90, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.
Une solution serait de passer par des pointeurs et une routine d'initialisation.
Common iniCOSP
Le common défini dans ini_COSP.h est un peu tricky à remplacer car il a besoin de klon,klev qui ne sont pas des constantes.
Une (bonne) manière de faire serait de faire un type dérivé. C'est d'ailleurs ce que je préconise pour remplacer les très longues listes d'arguments, mais c'est à discuter avec le reste du groupe...
