LMDZ Coding conventions and guidelines - Historique des versions

Evignon le 28 janvier 2026 à 09:04

2026-01-28T09:04:09Z

Evignon le 28 janvier 2026 à 08:39

2026-01-28T08:39:38Z

Evignon le 28 janvier 2026 à 08:38

2026-01-28T08:38:17Z

Rkazeroni : Add link to GPU-Morphosis coding rules for Fortran codes

2026-01-06T10:58:37Z

Add link to GPU-Morphosis coding rules for Fortran codes

Lfairhead le 24 janvier 2025 à 16:37

2025-01-24T16:37:37Z

Lfairhead le 24 janvier 2025 à 16:30

2025-01-24T16:30:13Z

Lfairhead : Page créée avec « == Generalities == * fortran keywords in fortran files will be in UPPER case == Naming of modules == Module names should have a '''lmdz_''' prefix. For example, the fi... »

2025-01-24T15:39:10Z

Page créée avec « == Generalities == * fortran keywords in fortran files will be in UPPER case == Naming of modules == Module names should have a '''lmdz_''' prefix. For example, the fi... »

Nouvelle page

== Generalities ==

* fortran keywords in fortran files will be in UPPER case

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

<syntaxhighlight lang="fortran" line>
MODULE lmdz_wave
IMPLICIT NONE

CONTAINS

SUBROUTINE wave_init (...)
...
END SUBROUTINE wave_init

SUBROUTINE wave_calc (...)
...
END SUBROUTINE wave_calc

END MODULE lmdz_wave
</syntaxhighlight>

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 [https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/cr-de-reunions/poihl/compte-rendus-poihl-2022/2022-05-16 here], the following coding rules apply to the development of LMDZ parametrizations:

@@ Ligne 9 : / Ligne 9 : @@
    More generally, all the variables in a routine must be 'properly' declared with '''TYPE''', '''DIMENSION''' and '''INTENT''' for arguments to the routine
 * It is '''HIGHLY RECOMMENDED''' to comment every input/output/inout variable with a short definition and the units.
-* Be generous and rigorous when commenting routines (of course)
+* Be generous and rigorous when commenting routines (of course). And please use '''ENGLISH''' when commenting.
 * Fortran keywords in fortran files will be in '''UPPER''' case
 * Indent your routine. We recommend using the script format_code.sh (based on fprettify) in LMDZ/tools for this purpose.

@@ Ligne 7 : / Ligne 7 : @@
 * '''IMPLICT NONE'''
 * For declarations of input/inout/output variables, systematically specify '''INTENT(IN)''', '''INTENT(INOUT)''', or '''INTENT(OUT)'''
-Mor generally, all the variables in a routine must be 'properly' declared with '''TYPE''', '''DIMENSION''' and '''INTENT''' for arguments to the routine
+  More generally, all the variables in a routine must be 'properly' declared with '''TYPE''', '''DIMENSION''' and '''INTENT''' for arguments to the routine
 * It is '''HIGHLY RECOMMENDED''' to comment every input/output/inout variable with a short definition and the units.
 * Be generous and rigorous when commenting routines (of course)
@@ Ligne 73 : / Ligne 73 : @@
 * the first arguments of parametrization routines should be the dimensions of the domain (e.g. '''klon, klev''')
 <syntaxhighlight lang="fortran" line>
-MODULE lmdz_param1_subroutine1
+MODULE lmdz_groupparam1_subroutine1
 CONTAINS
 SUBROUTINE param1_subroutine1(klon, klev, ..., dtdwn, dqdwn, ..., dth, ...)

@@ Ligne 6 : / Ligne 6 : @@
 * '''IMPLICT NONE'''
-* useful comments in all files (of course)
+* For declarations of input/inout/output variables, systematically specify '''INTENT(IN)''', '''INTENT(INOUT)''', or '''INTENT(OUT)'''
-* fortran keywords in fortran files will be in '''UPPER''' case
+Mor generally, all the variables in a routine must be 'properly' declared with '''TYPE''', '''DIMENSION''' and '''INTENT''' for arguments to the routine
-* in the physics module, all '''SAVE''' variables should be declared as '''THREADPRIVATE''' (this includes all variables that are initialized in their declaration)
+* It is '''HIGHLY RECOMMENDED''' to comment every input/output/inout variable with a short definition and the units.
 <syntaxhighlight lang="fortran" line>
    LOGICAL, SAVE :: first = .TRUE.
    !$OMP THREADPRIVATE(first)
 </syntaxhighlight>
-* variables and functions included through modules should be explicitly defined through the '''USE ..., ONLY''' statement:
+* Variables and functions included through modules should be explicitly defined through the '''USE ..., ONLY''' statement:
 <syntaxhighlight lang="fortran" line>
 USE ioipsl_getin_p_mod, ONLY : getin_p
@@ Ligne 45 : / Ligne 49 : @@
 Following different discussions among LMDZ developpers (summarized in one of our weekly meetings [https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/cr-de-reunions/poihl/compte-rendus-poihl-2022/2022-05-16 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'''
+* constants and variables that need to be initialized for all routines of a given "group" of parametrizations '''''groupparam''''' should be declared and initialized in a specific initialisation module called '''lmdz_''groupparam''_ini'''
 <syntaxhighlight lang="fortran" line>
-MODULE lmdz_param_ini
+MODULE lmdz_groupparam_ini
 REAL, SAVE :: cst1
 !$OMPTREADPRIVATE cst1
 ...
-END MODULE lmdz_param_ini
+END MODULE lmdz_groupparam_ini
 </syntaxhighlight>
-* 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:
+* 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 group of parametrizations the routine belongs to.
+* Furthermore, to make parameterizations as independent as possible, each parameterization should use only one module, which corresponds to the "ini" of its group.
 <syntaxhighlight lang="fortran" line>
-MODULE lmdz_param1_subroutine1
+MODULE lmdz_groupparam1_subroutine1
 CONTAINS
 SUBROUTINE param1_subroutine1
-USE lmdz_param1_ini, ONLY : cst1
+USE lmdz_groupparam1_ini, ONLY : cst1
 ...
 END SUBROUTINE param1_subroutine1
-END MODULE lmdz_param1_subroutine1
+END MODULE lmdz_groupparam1_subroutine1
 </syntaxhighlight>
 * the first arguments of parametrization routines should be the dimensions of the domain (e.g. '''klon, klev''')
 <syntaxhighlight lang="fortran" line>
 MODULE lmdz_param1_subroutine1

← Version précédente		Version du 6 janvier 2026 à 10:58
Ligne 1 :		Ligne 1 :
	__TOC__		__TOC__
		+
		+	Coding rules related to '''GPU porting with GPU-Morphosis''' are available on this [https://ipsl.pages.in2p3.fr/projets/traccs-gpu/gpu-morphosis/coding_rules/ webpage].
		+
	== Generalities ==		== Generalities ==

@@ Ligne 1 : / Ligne 1 : @@
+__TOC__
 == 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
 [[Category:HowTo]]
 [[Category:Notes Techniques]]
 [[Category:FAQ]]

@@ Ligne 2 : / Ligne 2 : @@
 == Generalities ==
-* fortran keywords in fortran files will be in UPPER case
+* '''IMPLICT NONE'''
 == Naming of modules ==
@@ Ligne 29 : / Ligne 40 : @@
 == Coding conventions for parametrizations ==
-Following different discussions among LMDZ developpers (summarized in one of our weekly meetings [https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/cr-de-reunions/poihl/compte-rendus-poihl-2022/2022-05-16 here], the following coding rules apply to the development of LMDZ parametrizations:
+Following different discussions among LMDZ developpers (summarized in one of our weekly meetings [https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/cr-de-reunions/poihl/compte-rendus-poihl-2022/2022-05-16 here]), the following coding rules apply to the development of LMDZ parametrizations: