LMDZ Coding conventions and guidelines

2026-01-06T10:58:37Z

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

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

* '''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)
<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:
<syntaxhighlight lang="fortran" line>
USE ioipsl_getin_p_mod, ONLY : getin_p
</syntaxhighlight>

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

* 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'''
<syntaxhighlight lang="fortran" line>
MODULE lmdz_param_ini
REAL, SAVE :: cst1
!$OMPTREADPRIVATE cst1
...
END MODULE lmdz_param_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:

<syntaxhighlight lang="fortran" line>
MODULE lmdz_param1_subroutine1
CONTAINS
SUBROUTINE param1_subroutine1
USE lmdz_param1_ini, ONLY : cst1
...
END SUBROUTINE param1_subroutine1
END MODULE lmdz_param1_subroutine1
</syntaxhighlight>

* 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
<syntaxhighlight lang="fortran" line>
MODULE lmdz_param1_subroutine1
CONTAINS
SUBROUTINE param1_subroutine1(klon, klev, ..., dtdwn, dqdwn, ..., dth, ...)
! Input arguments to routine
INTEGER, INTENT(IN) :: klon,klev
REAL, DIMENSION (klon, klev), INTENT(IN) :: dtdwn, dqdwn
...
! Output arguments
REAL, DIMENSION (klon, klev), INTENT(OUT) :: dth
...
! Local variables
REAL, DIMENSION(klon) :: act
...
</syntaxhighlight>

* 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:Notes Techniques]]
[[Category:FAQ]]

LMDZPedia - Contributions de l’utilisateur [fr]

LMDZ Coding conventions and guidelines