LMDZ Coding conventions and guidelines : Différence entre versions
De LMDZPedia
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)