LMDZ Coding conventions and guidelines : Différence entre versions

De LMDZPedia
Aller à : navigation, rechercher
 
Ligne 1 : Ligne 1 :
 
+
__TOC__
 
== Generalities ==
 
== Generalities ==
  
Ligne 83 : Ligne 83 :
 
* all dimensions of tables (e.g. '''nbsrf''') should be passed as arguments to the routine rather than passed through a module
 
* all dimensions of tables (e.g. '''nbsrf''') should be passed as arguments to the routine rather than passed through a module
  
 +
24 janvier 2025 à 17:37 (CET)
 
[[Category:HowTo]]
 
[[Category:HowTo]]
 
[[Category:Notes Techniques]]
 
[[Category:Notes Techniques]]
 
[[Category:FAQ]]
 
[[Category:FAQ]]

Version actuelle en date du 24 janvier 2025 à 17:37

Generalities

  • IMPLICT NONE
  • useful comments in all files (of course)
  • fortran keywords in fortran files will be in UPPER case
  • in the physics module, all SAVE variables should be declared as THREADPRIVATE (this includes all variables that are initialized in their declaration)
1   LOGICAL, SAVE :: first = .TRUE.
2   !$OMP THREADPRIVATE(first)
  • variables and functions included through modules should be explicitly defined through the USE ..., ONLY statement:
1 USE ioipsl_getin_p_mod, ONLY : getin_p

Naming of modules

Module names should have a lmdz_ prefix. For example, the file lmdz_wave.F90 would be a module containing one or more subroutines:

 1   MODULE lmdz_wave
 2   IMPLICIT NONE
 3 
 4   CONTAINS
 5 
 6   SUBROUTINE wave_init (...)
 7   ...
 8   END SUBROUTINE wave_init
 9 
10   SUBROUTINE wave_calc (...)
11   ...
12   END SUBROUTINE wave_calc
13 
14   END MODULE lmdz_wave

Beware: the renaming of already existing parametrization modules (to the lmdz_ format) should only occur once they have been re-written to adhere to the coding conventions for parametrizations (see below) as we use it as a marker that the recoding work on that particular parametrization has been done.

Coding conventions for parametrizations

Following different discussions among LMDZ developpers (summarized in one of our weekly meetings here), the following coding rules apply to the development of LMDZ parametrizations:

  • constants and variables that need to be initialized for all routines of the parametrization param should be declared and initialized in a specific initialisation module called lmdz_param_ini
1 MODULE lmdz_param_ini
2 REAL, SAVE :: cst1
3 !$OMPTREADPRIVATE cst1
4 ...
5 END MODULE lmdz_param_ini
  • the routines associated to a parametrization can either be gathered in a unique module or each have their own module. The name of the module will reflect the parametrization the routine belongs to:
1 MODULE lmdz_param1_subroutine1
2 CONTAINS
3 SUBROUTINE param1_subroutine1
4 USE lmdz_param1_ini, ONLY : cst1
5 ...
6 END SUBROUTINE param1_subroutine1
7 END MODULE lmdz_param1_subroutine1
  • the first arguments of parametrization routines should be the dimensions of the domain (e.g. klon, klev)
  • all the variables in a routine must be 'properly' declared with TYPE, DIMENSION and INTENT for arguments to the routine
 1 MODULE lmdz_param1_subroutine1
 2 CONTAINS
 3 SUBROUTINE param1_subroutine1(klon, klev, ..., dtdwn, dqdwn, ..., dth, ...)
 4 ! Input arguments to routine
 5 INTEGER, INTENT(IN) :: klon,klev
 6 REAL, DIMENSION (klon, klev),     INTENT(IN)          :: dtdwn, dqdwn
 7 ...
 8 ! Output arguments
 9 REAL, DIMENSION (klon, klev),     INTENT(OUT)         :: dth
10 ...
11 ! Local variables
12 REAL, DIMENSION(klon)                                 :: act
13 ...
  • all dimensions of tables (e.g. nbsrf) should be passed as arguments to the routine rather than passed through a module

24 janvier 2025 à 17:37 (CET)