LMDZPedia - Contributions de l’utilisateur [fr]

LMDZ Coding conventions and guidelines

2025-01-24T16:37:37Z

Lfairhead :

__TOC__
== 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]]

LMDZ Coding conventions and guidelines

2025-01-24T16:30:13Z

Lfairhead :

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

[[Category:HowTo]]
[[Category:Notes Techniques]]
[[Category:FAQ]]

LMDZ Coding conventions and guidelines

2025-01-24T15:39:10Z

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... »

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

HowTo: LMDZ code guidelines

2025-01-23T11:50:13Z

Lfairhead :

/!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\

''Note: this documents draws from various sources, including [http://broken.link.todo.replace the OPA guidelines], [https://fortranwiki.org/fortran/show/Modernizing+Old+Fortran Modernizing Old Fortran], [http://pages.swcp.com/~walt/F/F_bnf.html F syntax rules], [https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md the stdlib style guide], [https://github.com/codee-com/fortran-modernization CODEE Fortran recommendations].

== Code guidelines and conventions ==

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

== Example code ==

''Note: in this example, we added "meta-comments" indicated by <code>!!</code>''

''Note: of course, there's always exceptions to "Always", but they should '''systematically''' documented by a comment, with a proper explanation.''

<syntaxhighlight lang="fortran" line>
!! File: lmdz_mymodule.f90
!! ^ all module files should start with their component name, (e.g. "lmdz")
!! ^ use ".f90" for all free-form files, unless they contain preprocessor directives (then use ".F90").

!! At the top of the file, we provide a comment to explain what this modules does
! implementation of my_useful_stuff.
! ----------------------------------

!! Unless specified otherwise, all files should contain a single module with the same name which encapsulates all their content
MODULE lmdz_mymodule
!! ^ all Fortran keywords are in CAPS, everything else is in lowercase.
USE my_other_module, ONLY: function_a, function_b
!! ^ Always specify explicitely which functions you use from a module.
!!^ use indentation (2 spaces) to provide visual clarity
IMPLICIT NONE; PRIVATE
!! ^ Always make your module private, and expose explicitely which functions are public
!! ^ Always use IMPLICIT NONE at the module-level
PUBLIC my_var, my_subroutine

REAL, PARAMETER :: my_var
REAL :: a, b, c, d, e, f
!! ^ use "::" even if it's not strictly necessary
!! ^ Alignment of "::" is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)

CONTAINS

!! Put at least a blank line before/after each function/subroutine2
!! A routine should have a clear, unambiguous name, describing what the routine does.
SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx
!! ^ comments should always be right before, or on the same line as what they're commenting
!! ^ as for modules, all functions should be documented in a comment
INTEGER, INTENT(IN) :: arg1
!! ^ Always provide intent
REAL, INTENT(IN) :: arg2

INTEGER, INTENT(INOUT) :: arg3

REAl, INTENT(OUT) :: out1
!!^ Group together IN, then INOUT, then OUT

IF (arg2 > arg1) THEN
!! ^ .ge., .le., etc are deprecated. Use >, <, ==, etc instead
! ...
END IF
!! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)
END SUBROUTINE my_subroutine
!! ^ always use named blocks for END

END MODULE my_module
!! ^ always use named blocks for END
</syntaxhighlight>

== Comments and Documentation ==

Documentation consists of putting information both inside and outside the source code. On large, formal projects, most of the documentation is outside the source code. However because the internal documentation is most closely associated with the code, it is the part most likely to remain correct as the code is modified. The thing to be really careful with is that misleading comments are even worse than having no comments at all. So, please report any misleading comments you found.

Try to avoid having superfluous comments such as: <code>A = A + 1 ! Increment A by one.</code> This is not adding anything that is not immediately obvious. A person looking through your code should only have to scan your comments to be able to get a good idea of what the code does and where to look for any special activity.

Good comments do not just repeat verbally what is happening in the code or just explain it. They clarify its intent. They should explain at a higher level of abstraction what the code or what you are trying to do. In addition, you should comment:
* Everything that gets around an error or an undocumented feature in a language or environment.
* Any violations of good programming style should be justified. This will ensure that any well-intentioned programmer does not break your code by changing the source to implement a “better” style.
* The lines before a control structure, e.g. IF, CASE, loop, etc. are a natural spot to comment and explain what these constructs are about to do.
* The start of '''any''' subroutine or function whose usage is not downright obvious.

== Misc ==

=== Fortran standard ===

Fortran 2008 is now widely supported on all [https://fortranwiki.org/fortran/show/Fortran+2008+status major compilers], and should be taken as a reference.

=== Allocatable arrays ===

Allocatable arrays can be relevant, but should be substituted by automatic arrays (= passing the array size as an argument) whenever possible, for performance and debugging reasons.

=== Compiler warnings ===

Compiler warnings are useful - unless there's too many of them. Effort should be made such that during the compiling phase, no warning appears, so that user can be easily alerted of potential bugs.
when some appear in their configuration.

In particular, all component must be able to run when a compile-time and/or run-time array bounds checking option is enabled.
Use of the (*) construct in array dimensioning to circumvent this problem is forbidden because it effectively disables array bounds checking.

=== Side effects ===

Whenever possible, write functions without side-effects, and label them accordingly as <code>PURE</code> or <code>ELEMENTAL</code>.

=== SAVE ===

Since all files contain a <code>MODULE</code>, attribute <code>SAVE</code> is banned. Variables whose value have to be preserved between two calls should be declared at the module level.

=== Deprecated features ===

In terms of keeping code up to date and easier to maintain the code should always follow the current standards of FORTRAN and ANSI C. We decide to restrict the languages use to the elements, which are not obsolete or deleted -- even if they are still available with almost all compilers.

''Note: just because a feature is deprecated doesn't mean it '''must''' be converted in old, working code - this can be tricky and bug-prone in complex instances.''

Some notable deprecated features:

* <code>COMMON</code> blocks. Instead, use <code>MODULE</code> initialisation.
* <code>EQUIVALENCE</code> should be replaced by pointers or derived data types.
* Any kind of <code>GOTO</code> has absolutely no place in modern programming. Use <code>CASE</code> whenever relevant rather than <code>IF</code>.
* Arithmetic <code>IF</code> statements. Use block <code>IF</code> or <code>CASE</code> instead.
* <code>CONTINUE</code> statement: use <code>IF, CASE, DO WHILE, EXIT, CYCLE</code> statements or a contained <code>SUBROUTINE</code> instead.
* I/O routines <code>END</code> and <code>ERR</code> - use <code>IOSTAT</code> instead
* <code>FORMAT</code> statements: use character parameters or explicit format- specifiers inside the <code>READ</code> or <code>WRITE</code> statement instead.
* <code>ENTRY</code> statements: a subprogram must only have one entry point
* ''Alternate'' <code>RETURN</code> is obsolescent, and <code>RETURN</code> at the end of a function is useless clutter.
* Statement functions have been replaced by corresponding functions or subroutines in the <code>CONTAIN</code> block of the current scope.
* <code>DATA</code> and <code>BLOCK DATA</code> should be replaced by initializers.

=== Preprocessor ===

Limit '''to the bare minimum''' the use of preprocessor <code>#ifdef</code> keys. Those decrease lisibility, disable automatic code analysis, and generally make code a pain to manage and read. Ideally, a given preprocessor key should be used only once, or if not possible, in a single module for the entire codebase.

=== INCLUDE ===

Limit the use of <code>include</code> headers to the bare minimum. Whenever not possible, wrap those include in a module, and import that module instead. This provides much more flexibility, e.g. when using <code>ONLY: ...</code>.

== Recent examples of improper LMDZ code ==

''Note: The purpose of this section is '''obviously not''' to blame anyone, but to stress that "bad"/perfectible code in LMDZ isn't limited to old legacy code, and that even current code is being written in a way that can be greatly improved.''

==== 07/24: Unhelpful comment ====

<syntaxhighlight lang="fortran" line>
IF (iflag_ice_thermo == 0) THEN
!pas necessaire a priori
</syntaxhighlight>

This comment fails to convey a clear indication. What is necessary or not ? In which condition ? "A priori" further conveys a sense of uncertainty that may make sense to the writer, but certainly not to an external reader.

==== 07/24: Unclear conventions, no PURE, useless RETURN ====

<syntaxhighlight lang="fortran" line>
function grid_index(lon_deg,lat_deg)
!--------------------------------------------------------------------------------
! Get local index of grid point of longitude,latitude lon_deg,lat_deg
! Author : XXX 2024/07/XX
! Please do not put this function in a m*odule not to complexify the replay script
!--------------------------------------------------------------------------------
USE dimphy, only : klon
USE geometry_mod, ONLY: latitude_deg, longitude_deg
implicit none
real, intent(in) :: lon_deg,lat_deg
integer :: grid_index
integer i
grid_index=0
do i=1,klon
if ( abs(lon_deg-longitude_deg(i)) < 0.02 .and. abs(lat_deg-latitude_deg(i)) < 0.02 ) then
grid_index=i
exit
endif
enddo
return
end
</syntaxhighlight>

This function is actually mostly great ! It is documented, the author put a clear statement to indicate a deviation from standards (no module), <code>USE</code> is used in conjuction with <code>ONLY</code>, <code>INTENT</code> is declared.
However, it is also lacking in some areas, notably:
* This function should be declared as <code>PURE</code>
* This function has inconsistent syntax: mix of uppercase and lowercase for Fortran keywords, sometimes uses <code>::</code> in declarations and sometimes not
* The function ends with a useless <code>RETURN</code>

==== 07/24: Duplicated, uncommented code ====

<syntaxhighlight lang="fortran" line>
zx_tmp_fi3d=0.
IF (vars_defined) THEN
DO nsrf=1,nbsrf
DO k=1,klev
zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &
+pctsrf(:,nsrf)*tke_shear(:,k,nsrf)
ENDDO
ENDDO
ENDIF

CALL histwrite_phy(o_tke_shear, zx_tmp_fi3d)

zx_tmp_fi3d=0.
IF (vars_defined) THEN
DO nsrf=1,nbsrf
DO k=1,klev
zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &
+pctsrf(:,nsrf)*tke_buoy(:,k,nsrf)
ENDDO
ENDDO
ENDIF

CALL histwrite_phy(o_tke_buoy, zx_tmp_fi3d)

zx_tmp_fi3d=0.
IF (vars_defined) THEN
DO nsrf=1,nbsrf
DO k=1,klev
zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &
+pctsrf(:,nsrf)*tke_trans(:,k,nsrf)
ENDDO
ENDDO
ENDIF

CALL histwrite_phy(o_tke_trans, zx_tmp_fi3d)
</syntaxhighlight>

This code:
* Duplicates three times essentially the same code. Refactoring into a routine would be much more readable and reduce the potential of typos.
* Contains no comment justifying such behavior, or what is even being done here, which to an external reader is fairly obscure.

==== 06/24: Undocumented variable ====

<syntaxhighlight lang="fortran" line>
INTEGER :: nsrf, k, iq, iff, i, j, ilev, itr, itrb
!! ^ Added this
!! (...)
itrb = 0
!! (...)
if(tracers(iq)%name(1:3)=='BIN') then
itrb = itrb + 1
</syntaxhighlight>

Just because a variable is a "dumb" counter doesn't mean it shouldn't be documented. In this particular example, the variable name is devoid of any obvious meaning.
Properly documenting this variable would also make it clear to others whether it would make sense to reuse it later on in the code.

==== 06/24: Comments as code storage ====

<syntaxhighlight lang="fortran" line>
!CALL writefield_phy('latitude',latitude_deg,1)
!CALL writefield_phy('pressure_hl',pressure_hl,klev+1)
!CALL writefield_phy('Ldecorel',PDECORR_LEN_EDGES_M,klev)
</syntaxhighlight>

'''Comments are ''NOT'' for code storage'''. Unfortunately, the LMDZ code is ''littered'' with bits of commented code without any indication of when or why the code was commented.
As a result, there are in a lot of places such comments, many dating from 20+ years ago, for which we have no clue whether we can remove them or not. This greatly hinders readability and maintainability.

Of course, in ''some'' cases, it is warranted to keep some code at hand, e.g. for diagnostic purpose. In such case, please '''make sure to always clearly document ''why, when and by whom'' the code was commented out''', so that it can be cleaned up at a later date when it becomes irrelevant.

== Questions à élucider ==

* Prescrit-on une langue (Français / Anglais) ?
* Longueur des lignes: dans la limite du raisonable, pourquoi se limiter à 100-140 chars ? Le wrapping fonctionne très bien.

HowTo: debug the quality control

2023-07-12T10:58:28Z

Lfairhead :

As explained on the page [https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/controle-qualite Contrôle qualité], a number of quality control checks of the code are run every night to ensure that nothing was broken by the most recent commits to the svn depository (note that only the trunk version of the code is tested by this procedure).

This note explains what to do if those regular tests reveal that the code is broken.

The checks are launched by the script [https://web.lmd.jussieu.fr/~lmdz/Distrib/creation_modipsl.sh creation_modipsl.sh] which prepares the distribution version of the code and then lauches [https://web.lmd.jussieu.fr/~lmdz/Distrib/check_version.sh check_version.sh], which actually launches the quality checks. The results of the tests are synthesized in one line and recorded in the file [https://web.lmd.jussieu.fr/~lmdz/pub/src_archives/Readme Readme]. Each line of this file (besides the comments) gives the version of the code being tested, its corresponding svn revision number and the results of the different checks (as explained in the file and the page [https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/controle-qualite Contrôle qualité]).

=== How to debug a failed quality check ===

Once a failed quality check is established, one should look in the file [https://web.lmd.jussieu.fr/~lmdz/pub/LISMOI.trunk LISMOI.trunk] to find out which version of the code caused a problem (for example 20211105.trunk). One can then find the output of the quality control check in the directory:

lmdz-cq:/home/lmdz/tmp/LMDZ[version_number]

with the actual output file of the check_version.sh script in

lmdz-cq:~lmdz/WWW/Distrib/WORK/check.out.[version_number]

('''''lmdz-cq:/tmp/lmdz/LMDZ20211105.trunk''''' and '''''lmdz-cq:~lmdz/WWW/Distrib/WORK/check.out.20211105.trunk''''' respectively in our example). This output file is also [https://lmdz.lmd.jussieu.fr/Distrib/WORK accessible on internet].

One can then go through the script [https://www.lmd.jussieu.fr/~lmdz/Distrib/check_version.sh check_version.sh] comparing with the different output to find out what went wrong. Tests of correction can actually be done in the
lmdz-cq:/home/lmdz/tmp/LMDZ[version_number]
directory.

[[Category:HowTo]]
[[Category:ExpertDev]]

HowTo: debug the quality control

2023-07-12T10:56:40Z

Lfairhead :

As explained on the page [https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/controle-qualite Contrôle qualité], a number of quality control checks of the code are run every night to ensure that nothing was broken by the most recent commits to the svn depository (note that only the trunk version of the code is tested by this procedure).

This note explains what to do if those regular tests reveal that the code is broken.

The checks are launched by the script [https://www.lmd.jussieu.fr/~lmdz/Distrib/creation_modipsl.sh creation_modipsl.sh] which prepares the distribution version of the code and then lauches [https://www.lmd.jussieu.fr/~lmdz/Distrib/check_version.sh check_version.sh], which actually launches the quality checks. The results of the tests are synthesized in one line and recorded in the file [https://web.lmd.jussieu.fr/~lmdz/pub/src_archives/Readme Readme]. Each line of this file (besides the comments) gives the version of the code being tested, its corresponding svn revision number and the results of the different checks (as explained in the file and the page [https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/controle-qualite Contrôle qualité]).

=== How to debug a failed quality check ===

Once a failed quality check is established, one should look in the file [https://www.lmd.jussieu.fr/~lmdz/pub/LISMOI.trunk LISMOI.trunk] to find out which version of the code caused a problem (for example 20211105.trunk). One can then find the output of the quality control check in the directory:

lmdz-cq:/home/lmdz/tmp/LMDZ[version_number]

with the actual output file of the check_version.sh script in

lmdz-cq:~lmdz/WWW/Distrib/WORK/check.out.[version_number]

('''''lmdz-cq:/tmp/lmdz/LMDZ20211105.trunk''''' and '''''lmdz-cq:~lmdz/WWW/Distrib/WORK/check.out.20211105.trunk''''' respectively in our example). This output file is also [https://lmdz.lmd.jussieu.fr/Distrib/WORK accessible on internet].

One can then go through the script [https://www.lmd.jussieu.fr/~lmdz/Distrib/check_version.sh check_version.sh] comparing with the different output to find out what went wrong. Tests of correction can actually be done in the
lmdz-cq:/home/lmdz/tmp/LMDZ[version_number]
directory.

[[Category:HowTo]]
[[Category:ExpertDev]]

HowTo: debug the quality control

2023-02-07T14:27:39Z

Lfairhead :

As explained on the page [https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/controle-qualite Contrôle qualité], a number of quality control checks of the code are run every night to ensure that nothing was broken by the most recent commits to the svn depository (note that only the trunk version of the code is tested by this procedure).

This note explains what to do if those regular tests reveal that the code is broken.

The checks are launched by the script [https://www.lmd.jussieu.fr/~lmdz/Distrib/creation_modipsl.sh creation_modipsl.sh] which prepares the distribution version of the code and then lauches [https://www.lmd.jussieu.fr/~lmdz/Distrib/check_version.sh check_version.sh], which actually launches the quality checks. The results of the tests are synthesized in one line and recorded in the file [https://web.lmd.jussieu.fr/~lmdz/pub/src_archives/Readme Readme]. Each line of this file (besides the comments) gives the version of the code being tested, its corresponding svn revision number and the results of the different checks (as explained in the file and the page [https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/controle-qualite Contrôle qualité]).

=== How to debug a failed quality check ===

Once a failed quality check is established, one should look in the file [https://www.lmd.jussieu.fr/~lmdz/pub/LISMOI.trunk LISMOI.trunk] to find out which version of the code caused a problem (for example 20211105.trunk). One can then find the output of the quality control check in the directory:

lmdz-cq:/tmp/lmdz/LMDZ[version_number]

with the actual output file of the check_version.sh script in

lmdz-cq:~lmdz/WWW/Distrib/WORK/check.out.[version_number]

('''''lmdz-cq:/tmp/lmdz/LMDZ20211105.trunk''''' and '''''lmdz-cq:~lmdz/WWW/Distrib/WORK/check.out.20211105.trunk''''' respectively in our example). This output file is also [https://lmdz.lmd.jussieu.fr/Distrib/WORK accessible on internet].

One can then go through the script [https://www.lmd.jussieu.fr/~lmdz/Distrib/check_version.sh check_version.sh] comparing with the different output to find out what went wrong. Tests of correction can actually be done in the
lmdz-cq:/tmp/lmdz/LMDZ[version_number]
directory.

[[Category:HowTo]]
[[Category:ExpertDev]]

Cosp

2023-01-27T15:30:22Z

Lfairhead :

A quoi correspondent les différents répertoires cosp dans le répertoire libf/phylmd?

* Le répertoire cosp correspond à la version cospv1 que nous avons utilisée pour les simulations CMIP6.
* Le répertoire cospv2 correspond à la version récente cospv2 de Cosp. La différence entre les 2 versions est la réécriture avec du fortran récent et l'ajout de nouveaux diagnostics.
* Le répertoire cosp2 est une version intermédiaire avec des développement d'un doctorant de Jean-Louis qu'on voulait conserver et qui n'est pas maintenue.

Cosp

2023-01-27T15:28:25Z

Lfairhead :

* Le répertoire cosp correspond à la version cospv1 que nous avons utilisée pour les simulations CMIP6.
* Le répertoire cospv2 correspond à la version récente cospv2 de Cosp. La différence entre les 2 versions est la réécriture avec du fortran récent et l'ajout de nouveaux diagnostics.
* Le répertoire cosp2 est une version intermédiaire avec des développement d'un doctorant de Jean-Louis qu'on voulait conserver et qui n'est pas maintenue.

HowTo: Create a Trac ticket

2023-01-25T18:57:37Z

Lfairhead :

== HowTo: Create a Trac ticket ==

To create a trac ticket, first check that you are allowed to login to the trac server (so that you can actually write something). If you have a LMDZ svn account, you can use that account to login to the trac server. Head to

https://trac.lmd.jussieu.fr/LMDZ

Connect to your account, the connection link is in the red menu line on the upper left:
[[Fichier:Connexion.png|vignette|none]]

Once connected, you should see a new button appear in the main menu line 'Nouveau ticket':
[[Fichier:Nouveau ticket.png|vignette|néant]]

After clicking the 'Nouveau ticket' button, you will be taken to the following forms page
[[Fichier:Ticket.png|vignette|néant]]
which you need to fill out to create your ticket. Items to fill out are

* ''Résumé'' : a one-line description of the problem/bug/enhancement you want the ticket for
* ''Description'' : a longer description of the problem/bug/enhancement
* ''Type'' : describes the type of ticket you want to create. Possible values are
** plantage / defect
** incoherences
** vérifications
** améliorations / enhancements
** formation / documentation
* ''Priorité'' : describes the severity or priority you want to assign to your ticket. Possible values are
** blocker
** critical
** major
** minor
** trivial
* ''Composant'' : gives an indication of the LMDZ component that is involved in your report. Possible values are
** Consolidation
** Documentation
** Dynamic core
** Environnement
** I/O
** LMDZ
** Optimisation
** Parallelisation
** Terrestrial Physics
** Tracers

You can add some keywords in the 'Mots-clés' field and inform other members of the LMDZ team directly of your ticket by inserting their username in the 'Copie à' field. You can also attach some files explaining your problem to your ticket. You can finally assign your new ticket to some other member of the team by switching on the 'assign' button rather than the 'create' button and providing their username in the 'Action' grey box.

Once you've filled out all these informations, you can go ahead and click the 'Création d'un nouveau ticket' button to create you ticket and voilà !
[[Category:HowTo]]

HowTo: Create a Trac ticket

2023-01-25T16:42:21Z

Lfairhead :

== HowTo: Create a Trac ticket ==

To create a trac ticket, first check that you are allowed to login to the trac server (so that you can actually write something) then head to

https://trac.lmd.jussieu.fr/LMDZ

Connect to your account, the connection link is in the red menu line on the upper left:
[[Fichier:Connexion.png|vignette|none]]

Once connected, you should see a new button appear in the main menu line 'Nouveau ticket':
[[Fichier:Nouveau ticket.png|vignette|néant]]

After clicking the 'Nouveau ticket' button, you will be taken to the following forms page
[[Fichier:Ticket.png|vignette|néant]]
which you need to fill out to create your ticket. Items to fill out are

* ''Résumé'' : a one-line description of the problem/bug/enhancement you want the ticket for
* ''Description'' : a longer description of the problem/bug/enhancement
* ''Type'' : describes the type of ticket you want to create. Possible values are
** plantage / defect
** incoherences
** vérifications
** améliorations / enhancements
** formation / documentation
* ''Priorité'' : describes the severity or priority you want to assign to your ticket. Possible values are
** blocker
** critical
** major
** minor
** trivial
* ''Composant'' : gives an indication of the LMDZ component that is involved in your report. Possible values are
** Consolidation
** Documentation
** Dynamic core
** Environnement
** I/O
** LMDZ
** Optimisation
** Parallelisation
** Terrestrial Physics
** Tracers

You can add some keywords in the 'Mots-clés' field and inform other members of the LMDZ team directly of your ticket by inserting their username in the 'Copie à' field. You can also attach some files explaining your problem to your ticket. You can finally assign your new ticket to some other member of the team by switching on the 'assign' button rather than the 'create' button and providing their username in the 'Action' grey box.

Once you've filled out all these informations, you can go ahead and click the 'Création d'un nouveau ticket' button to create you ticket and voilà !
[[Category:HowTo]]

Fichier:Ticket.png

2023-01-25T16:13:02Z

Lfairhead :

Description du formulaire de création d'un nouveau ticket

Fichier:Nouveau ticket.png

2023-01-25T16:10:15Z

Lfairhead :

Le bouton pour rajouter les tickets

HowTo: Create a Trac ticket

2023-01-25T16:07:21Z

Lfairhead : Page créée avec « == HowTo: Create a Trac ticket == To create a trac ticket, first check that you are allowed to login to the trac server (so that you can actually write something) then h... »

Fichier:Connexion.png

2023-01-25T16:03:31Z

Lfairhead :

Connection to the trac server

MediaWiki:Sidebar

2022-11-16T15:54:32Z

Lfairhead :

* navigation
** mainpage|mainpage-description
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help-mediawiki
* SEARCH
* TOOLBOX
* LANGUAGES

MediaWiki:Sidebar

2022-11-16T15:52:26Z

Lfairhead :

* navigation
** mainpage|mainpage-description
*** informatique
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help-mediawiki
* SEARCH
* TOOLBOX
* LANGUAGES

MediaWiki:Sidebar

2022-11-16T15:49:08Z

Lfairhead :

* navigation
** mainpage|mainpage-description
# informatique
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help-mediawiki
* SEARCH
* TOOLBOX
* LANGUAGES

MediaWiki:Sidebar

2022-11-16T15:47:21Z

Lfairhead :

* navigation
** mainpage|mainpage-description
*** informatique
*** administratif
*** utilisateur
*** FAQs
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help-mediawiki
* SEARCH
* TOOLBOX
* LANGUAGES

Nudging in LMDZ

2022-05-16T13:29:30Z

Lfairhead : /* Nudging files */

== The concept ==
''For indepth theoretical explanations, see this doc in French (dated 2009, some code détails are obsolete): https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/notes-techniques/ressources/guidage_LMDZ.pdf''

Nudging is simply adding a forcing term to the GFD equation governing a variable $$V$$ to drive it towards a known value $$V_{analysis}$$ over a given time scale $$\tau$$:
\begin{align}
\frac{\partial V}{\partial t} = \frac{\partial V}{\partial t}_{GCM} + \frac{V_{analysis}-V}{\tau}
\end{align}
Where $$V$$ can be zonal wind u, meridional wind v, relative humidity Q, pressure P or temperature T

Nudging is often used in conjunction with zoomed configurations, where strong nudging towards reanalyses in enforced outside the zoomed region.

== Nudging parameters in LMDZ ==
The master parameter to turn nudging on is ''ok_guide'' (most often all nudging parameters are put in a '''guide.def''' file included in '''run.def''') which must be set to "y" (or equivalently ".true."):
<pre>
ok_guide = y
</pre>
("guide" means "nudge" in French).

Then one must select which fields will be nudged via the ''guide_*'' parameters:
<pre>
guide_u=y
guide_v=y
guide_T=y
guide_P=n
guide_Q=n
</pre>
In the example above, nudging is done on horizontal winds (u,v) and on temperature (T) only.

In addition, the user must provide two time scales $\tau$, for each of the nudged variables; one for the inner zoom area ''tau_max_*'' and another relative to outside the zoomed area ''tau_min_*''. These time scales are stated in unit of days, e.g.
<pre>
tau_min_u= 0.0208333
tau_max_u= 10.
tau_min_v= 0.0208333
tau_max_v= 10.
tau_min_T= 0.0208333
tau_max_T= 10.
</pre>
In this example all 3 variables are nudged with a time scale of 10 days, i.e very loosely, within the zoomed region and a time scale of 30 minutes (30.*60/86400.= 0.0208333), i.e. very strongly, outside the zoomed region.

'''''Caution''''':

==== Ne pas confondre constante de rappel et fréquence d'appel au guidage ====

Quand on guide :

# On lit les champs typiquement toutes les 6 heures (suivant la disponibiité des champs de guidage).
# On interpole linéairement en temps les champs de guidage.
# On rappelle à chaque pas de temps vers ces champs interpolés avec une constante définie dans guide.def avec les tau_min tau_max.

mais "je nudge à chaque pas de temps".

== Nudging files ==
In addition to stating which variable is nudged and the related time scales, one must provide the fields towards which to nudge (these must be on the same grid as the simulation and must be created separately, e.g. using a re-interpolation of ERA-interim files). These files must be in the directory where LMDZ runs and must be called ''u.nc'', ''v.nc'', ''T.nc'', etc.

To create these files see [[Création des fichiers de guidage et adaptation de l'exécution]]

== Nudging contribution output ==
One can request that the nudging term be stored in an output file, '''guide_ins.nc''' by setting (in guide.def):
<pre>
guide_sav=y
</pre>

== Notes ==
==== Nudging towards the wind zonal mean ====

Quelques précisions :

* Par défaut, on lit un état de guidage 4x / jour, pareil pour l'interpolation sur les niveaux du modèle. Mais ça peut être modifié (paramètres iguide_read, iguide_int).
* Il y a une option au cas où (guide_2D) pour lire un état de guidage 2D (latitude - Pression) et pas 3D.
* L'option guide_zon veut dire qu'on a un terme de rappel qui est uniforme suivant les longitudes :
** on calcule (u-ug) en chaque point
** puis on fait la moyenne zonale de ce nudging. ug n'est pas forcément symétrique ici, mais comme c'est linéaire...
Attention aux interférences avec guide_reg, le plus simple étant peut-être
de commenter les lignes "if guide_reg..." dans la routine guide_zonave.
Ne pas confondre constante de rappel et fréquence d'appel au guidage

==== Nudging towards surface pressure ====

Il faut probablement restreindre le guidage en pression de surface à l'océan pour éviter d'injecter plein de modes de gravités liés au déséquilibre hydrostatique qui sera nécessairement engendré par le fait que le relief vu par les analyses est différent de celui du modèle.

14/12/2021
[[Category:Nudging]]
[[Category:Guidage]]

Création des fichiers de guidage et adaptation de l'exécution

2022-05-16T13:27:38Z

Lfairhead :

== Créer les fichiers de guidage ==

1 => Créer le fichier grilles_gcm.nc avec ce0l. Pour cela, avant de lancer ce0l, ajouter dans run.def :
grilles_gcm_netcdf=y
2 => Extraire les scripts pour interpolation de fichiers de guidage :
wget http://forge.ipsl.jussieu.fr/igcmg/browser/TOOLS/INTERP_NUDGE
ou (avec ID et mdp) :
svn co http://forge.ipsl.jussieu.fr/igcmg/svn/TOOLS/INTERP_NUDGE
On utilisera interp_from_era.ksh pour fichiers ERA*, ou interp_from_TS.ksh pour séries de temps sorties du modèle.
Les choix de l'utilisateur se font dans ces scripts, qui lancent automatiquement era2gcm.ksh pour l'interpolation.

(un exemple d'utilisation de CDO pour interpoler les champs se trouve [[https://lmdz.lmd.jussieu.fr/utilisateurs/ressources/interp_from_era_nudging_with_cdo.sh ici]])

3 => Vérifier l'emplacement, la disponibilité et le droit d'accès aux fichiers non-interpolés (ERA* ou TS). Télécharger les fichiers si besoin.

4 => Interpoler avec interp_from_*.ksh :
4.a => Adapter les variables en tête du script, dans la section "USER DEFINITION":
gridfile=chemin pour grilles_gcm.nc
indir= ou se trouver les fichier era-i
varlist="u v" etc : les variables a interpoler
outdir= répertoire de resultats
first_year=2011
last_year=2011
rundir= répertoire temporaire
(for ERA*) : OutFreq='monthly' ou 'yearly' : fichiers de sortie par mois ou par année

4.b => Lancer le script ; par ex :
./interp_from_era.ksh

== Adapter le run ==

5 => Créer/adapter le fichier guide.def, par exemple :
## debut guide.def
# ok_guide=y : guidage active
ok_guide=y

guide_u= y
guide_v= y
guide_T= n
guide_P= n
guide_Q= n

tau_min_u=0.0208333
tau_max_u=0.125
tau_min_v=0.0208333
tau_max_v=0.125
## fin guide.def

Remarque : 
Ici, dans ce guide.def, uniquement le guidage des variables u et v sont activés. 
Temps de relaxation, pour une grille régulière, la valeur tau_max est utilisé, ici tau_max=0.125 => 3H. 
Temps de relaxation, pour une grille zoomée, la valeur tau_max est utilisé à l'intérieur de la zone du zoom et tau_min à l'extérieur de la zone du zoom, ici tau_min=0.0208333 => 30min. 
Plus le temps de relaxation(tau) est petit, plus le guidage est fort. 

6 => Ajouter en tête de run.def la prise en compte du fichier guide.def :
INCLUDEDEF=guide.def

7 => Copier (ou créer des liens vers) les fichier de guidage interpolés dans le répertoire où le modèle sera lancé, avec des noms génériques : u.nc, v.nc, T.nc, hur.nc ;
Exemple :
ln -s ERAI_interp/2011/u_201101_erai.nc u.nc
ln -s ERAI_interp/2011/v_201101_erai.nc v.nc

8 => Lancer l’exécution ; exemple :
./gcm.e > out_guide 2>&1

2022 mai 13
[[Category:Guidage]][[Category:Nudging]][[Category:HowTo]]

Création des fichiers de guidage et adaptation de l'exécution

2022-05-16T13:27:04Z

Lfairhead :

== Créer les fichiers de guidage ==

1 => Créer le fichier grilles_gcm.nc avec ce0l. Pour cela, avant de lancer ce0l, ajouter dans run.def :
grilles_gcm_netcdf=y
2 => Extraire les scripts pour interpolation de fichiers de guidage :
wget http://forge.ipsl.jussieu.fr/igcmg/browser/TOOLS/INTERP_NUDGE
ou (avec ID et mdp) :
svn co http://forge.ipsl.jussieu.fr/igcmg/svn/TOOLS/INTERP_NUDGE
On utilisera interp_from_era.ksh pour fichiers ERA*, ou interp_from_TS.ksh pour séries de temps sorties du modèle.
Les choix de l'utilisateur se font dans ces scripts, qui lancent automatiquement era2gcm.ksh pour l'interpolation.

(un exemple d'utilisation de CDO pour interpoler les champs se trouve [[https://lmdz.lmd.jussieu.fr/utilisateurs/ressources/interp_from_era_nudging_with_cdo.sh/view ici]])

3 => Vérifier l'emplacement, la disponibilité et le droit d'accès aux fichiers non-interpolés (ERA* ou TS). Télécharger les fichiers si besoin.

4 => Interpoler avec interp_from_*.ksh :
4.a => Adapter les variables en tête du script, dans la section "USER DEFINITION":
gridfile=chemin pour grilles_gcm.nc
indir= ou se trouver les fichier era-i
varlist="u v" etc : les variables a interpoler
outdir= répertoire de resultats
first_year=2011
last_year=2011
rundir= répertoire temporaire
(for ERA*) : OutFreq='monthly' ou 'yearly' : fichiers de sortie par mois ou par année

4.b => Lancer le script ; par ex :
./interp_from_era.ksh

== Adapter le run ==

5 => Créer/adapter le fichier guide.def, par exemple :
## debut guide.def
# ok_guide=y : guidage active
ok_guide=y

guide_u= y
guide_v= y
guide_T= n
guide_P= n
guide_Q= n

tau_min_u=0.0208333
tau_max_u=0.125
tau_min_v=0.0208333
tau_max_v=0.125
## fin guide.def

Remarque : 
Ici, dans ce guide.def, uniquement le guidage des variables u et v sont activés. 
Temps de relaxation, pour une grille régulière, la valeur tau_max est utilisé, ici tau_max=0.125 => 3H. 
Temps de relaxation, pour une grille zoomée, la valeur tau_max est utilisé à l'intérieur de la zone du zoom et tau_min à l'extérieur de la zone du zoom, ici tau_min=0.0208333 => 30min. 
Plus le temps de relaxation(tau) est petit, plus le guidage est fort. 

6 => Ajouter en tête de run.def la prise en compte du fichier guide.def :
INCLUDEDEF=guide.def

7 => Copier (ou créer des liens vers) les fichier de guidage interpolés dans le répertoire où le modèle sera lancé, avec des noms génériques : u.nc, v.nc, T.nc, hur.nc ;
Exemple :
ln -s ERAI_interp/2011/u_201101_erai.nc u.nc
ln -s ERAI_interp/2011/v_201101_erai.nc v.nc

8 => Lancer l’exécution ; exemple :
./gcm.e > out_guide 2>&1

2022 mai 13
[[Category:Guidage]][[Category:Nudging]][[Category:HowTo]]

Création des fichiers de guidage et adaptation de l'exécution

2022-05-16T13:21:04Z

Lfairhead :

== Créer les fichiers de guidage ==

1 => Créer le fichier grilles_gcm.nc avec ce0l. Pour cela, avant de lancer ce0l, ajouter dans run.def :
grilles_gcm_netcdf=y
2 => Extraire les scripts pour interpolation de fichiers de guidage :
wget http://forge.ipsl.jussieu.fr/igcmg/browser/TOOLS/INTERP_NUDGE
ou (avec ID et mdp) :
svn co http://forge.ipsl.jussieu.fr/igcmg/svn/TOOLS/INTERP_NUDGE
On utilisera interp_from_era.ksh pour fichiers ERA*, ou interp_from_TS.ksh pour séries de temps sorties du modèle.
Les choix de l'utilisateur se font dans ces scripts, qui lancent automatiquement era2gcm.ksh pour l'interpolation.

3 => Vérifier l'emplacement, la disponibilité et le droit d'accès aux fichiers non-interpolés (ERA* ou TS). Télécharger les fichiers si besoin.

4 => Interpoler avec interp_from_*.ksh :
4.a => Adapter les variables en tête du script, dans la section "USER DEFINITION":
gridfile=chemin pour grilles_gcm.nc
indir= ou se trouver les fichier era-i
varlist="u v" etc : les variables a interpoler
outdir= répertoire de resultats
first_year=2011
last_year=2011
rundir= répertoire temporaire
(for ERA*) : OutFreq='monthly' ou 'yearly' : fichiers de sortie par mois ou par année

4.b => Lancer le script ; par ex :
./interp_from_era.ksh

== Adapter le run ==

5 => Créer/adapter le fichier guide.def, par exemple :
## debut guide.def
# ok_guide=y : guidage active
ok_guide=y

guide_u= y
guide_v= y
guide_T= n
guide_P= n
guide_Q= n

tau_min_u=0.0208333
tau_max_u=0.125
tau_min_v=0.0208333
tau_max_v=0.125
## fin guide.def

Remarque : 
Ici, dans ce guide.def, uniquement le guidage des variables u et v sont activés. 
Temps de relaxation, pour une grille régulière, la valeur tau_max est utilisé, ici tau_max=0.125 => 3H. 
Temps de relaxation, pour une grille zoomée, la valeur tau_max est utilisé à l'intérieur de la zone du zoom et tau_min à l'extérieur de la zone du zoom, ici tau_min=0.0208333 => 30min. 
Plus le temps de relaxation(tau) est petit, plus le guidage est fort. 

6 => Ajouter en tête de run.def la prise en compte du fichier guide.def :
INCLUDEDEF=guide.def

7 => Copier (ou créer des liens vers) les fichier de guidage interpolés dans le répertoire où le modèle sera lancé, avec des noms génériques : u.nc, v.nc, T.nc, hur.nc ;
Exemple :
ln -s ERAI_interp/2011/u_201101_erai.nc u.nc
ln -s ERAI_interp/2011/v_201101_erai.nc v.nc

8 => Lancer l’exécution ; exemple :
./gcm.e > out_guide 2>&1

2022 mai 13
[[Category:Guidage]][[Category:Nudging]][[Category:HowTo]]

Création des fichiers de guidage et adaptation de l'exécution

2022-05-16T13:19:33Z

Lfairhead :

== Créer les fichiers de guidage ==

1 => Créer le fichier grilles_gcm.nc avec ce0l. Pour cela, avant de lancer ce0l, ajouter dans run.def :
grilles_gcm_netcdf=y
2 => Extraire les scripts pour interpolation de fichiers de guidage :
wget http://forge.ipsl.jussieu.fr/igcmg/browser/TOOLS/INTERP_NUDGE
ou (avec ID et mdp) :
svn co http://forge.ipsl.jussieu.fr/igcmg/svn/TOOLS/INTERP_NUDGE
On utilisera interp_from_era.ksh pour fichiers ERA*, ou interp_from_TS.ksh pour séries de temps sorties du modèle.
Les choix de l'utilisateur se font dans ces scripts, qui lancent automatiquement era2gcm.ksh pour l'interpolation.

3 => Vérifier l'emplacement, la disponibilité et le droit d'accès aux fichiers non-interpolés (ERA* ou TS). Télécharger les fichiers si besoin.

4 => Interpoler avec interp_from_*.ksh :
4.a => Adapter les variables en tête du script, dans la section "USER DEFINITION":
gridfile=chemin pour grilles_gcm.nc
indir= ou se trouver les fichier era-i
varlist="u v" etc : les variables a interpoler
outdir= répertoire de resultats
first_year=2011
last_year=2011
rundir= répertoire temporaire
(for ERA*) : OutFreq='monthly' ou 'yearly' : fichiers de sortie par mois ou par année

4.b => Lancer le script ; par ex :
./interp_from_era.ksh

== Adapter le run ==

5 => Créer/adapter le fichier guide.def, par exemple :
## debut guide.def
# ok_guide=y : guidage active
ok_guide=y

guide_u= y
guide_v= y
guide_T= n
guide_P= n
guide_Q= n

tau_min_u=0.0208333
tau_max_u=0.125
tau_min_v=0.0208333
tau_max_v=0.125
## fin guide.def

Remarque : 
Ici, dans ce guide.def, uniquement le guidage des variables u et v sont activés. 
Temps de relaxation, pour une grille régulière, la valeur tau_max est utilisé, ici tau_max=0.125 => 3H. 
Temps de relaxation, pour une grille zoomée, la valeur tau_max est utilisé à l'intérieur de la zone du zoom et tau_min à l'extérieur de la zone du zoom, ici tau_min=0.0208333 => 30min. 
Plus le temps de relaxation(tau) est petit, plus le guidage est fort. 

6 => Ajouter en tête de run.def la prise en compte du fichier guide.def :
INCLUDEDEF=guide.def

7 => Copier (ou créer des liens vers) les fichier de guidage interpolés dans le répertoire où le modèle sera lancé, avec des noms génériques : u.nc, v.nc, T.nc, hur.nc ;
Exemple :
ln -s ERAI_interp/2011/u_201101_erai.nc u.nc
ln -s ERAI_interp/2011/v_201101_erai.nc v.nc

8 => Lancer l’exécution ; exemple :
./gcm.e > out_guide 2>&1

2022 mai 13
[[Category:Guidage]][[Category:Nudging]][[Category:HowTo]]

Création des fichiers de guidage et adaptation de l'exécution

2022-05-16T13:18:16Z

Lfairhead :

== Créer les fichiers de guidage ==

1 => Créer le fichier grilles_gcm.nc avec ce0l. Pour cela, avant de lancer ce0l, ajouter dans run.def :
grilles_gcm_netcdf=y
2 => Extraire les scripts pour interpolation de fichiers de guidage :
wget http://forge.ipsl.jussieu.fr/igcmg/browser/TOOLS/INTERP_NUDGE
ou (avec ID et mdp) :
svn co http://forge.ipsl.jussieu.fr/igcmg/svn/TOOLS/INTERP_NUDGE
On utilisera interp_from_era.ksh pour fichiers ERA*, ou interp_from_TS.ksh pour séries de temps sorties du modèle.
Les choix de l'utilisateur se font dans ces scripts, qui lancent automatiquement era2gcm.ksh pour l'interpolation.

3 => Vérifier l'emplacement, la disponibilité et le droit d'accès aux fichiers non-interpolés (ERA* ou TS). Télécharger les fichiers si besoin.

4 => Interpoler avec interp_from_*.ksh :
4.a => Adapter les variables en tête du script, dans la section "USER DEFINITION":
gridfile=chemin pour grilles_gcm.nc
indir= ou se trouver les fichier era-i
varlist="u v" etc : les variables a interpoler
outdir= répertoire de resultats
first_year=2011
last_year=2011
rundir= répertoire temporaire
(for ERA*) : OutFreq='monthly' ou 'yearly' : fichiers de sortie par mois ou par année

4.b => Lancer le script ; par ex :
./interp_from_era.ksh

== Adapter le run ==

5 => Créer/adapter le fichier guide.def, par exemple :
## debut guide.def
# ok_guide=y : guidage active
ok_guide=y

[[Category:guidage]]
[[Category:HowTo]]

guide_u= y
guide_v= y
guide_T= n
guide_P= n
guide_Q= n

tau_min_u=0.0208333
tau_max_u=0.125
tau_min_v=0.0208333
tau_max_v=0.125
## fin guide.def

Remarque : 
Ici, dans ce guide.def, uniquement le guidage des variables u et v sont activés. 
Temps de relaxation, pour une grille régulière, la valeur tau_max est utilisé, ici tau_max=0.125 => 3H. 
Temps de relaxation, pour une grille zoomée, la valeur tau_max est utilisé à l'intérieur de la zone du zoom et tau_min à l'extérieur de la zone du zoom, ici tau_min=0.0208333 => 30min. 
Plus le temps de relaxation(tau) est petit, plus le guidage est fort. 

6 => Ajouter en tête de run.def la prise en compte du fichier guide.def :
INCLUDEDEF=guide.def

7 => Copier (ou créer des liens vers) les fichier de guidage interpolés dans le répertoire où le modèle sera lancé, avec des noms génériques : u.nc, v.nc, T.nc, hur.nc ;
Exemple :
ln -s ERAI_interp/2011/u_201101_erai.nc u.nc
ln -s ERAI_interp/2011/v_201101_erai.nc v.nc

8 => Lancer l’exécution ; exemple :
./gcm.e > out_guide 2>&1

2022 mai 13
[[Category:Guidage]][[Category:Nudging]]

Nudging in LMDZ

2022-05-16T13:16:36Z

Lfairhead :

== The concept ==
''For indepth theoretical explanations, see this doc in French (dated 2009, some code détails are obsolete): https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/notes-techniques/ressources/guidage_LMDZ.pdf''

Nudging is simply adding a forcing term to the GFD equation governing a variable $$V$$ to drive it towards a known value $$V_{analysis}$$ over a given time scale $$\tau$$:
\begin{align}
\frac{\partial V}{\partial t} = \frac{\partial V}{\partial t}_{GCM} + \frac{V_{analysis}-V}{\tau}
\end{align}
Where $$V$$ can be zonal wind u, meridional wind v, relative humidity Q, pressure P or temperature T

Nudging is often used in conjunction with zoomed configurations, where strong nudging towards reanalyses in enforced outside the zoomed region.

== Nudging parameters in LMDZ ==
The master parameter to turn nudging on is ''ok_guide'' (most often all nudging parameters are put in a '''guide.def''' file included in '''run.def''') which must be set to "y" (or equivalently ".true."):
<pre>
ok_guide = y
</pre>
("guide" means "nudge" in French).

Then one must select which fields will be nudged via the ''guide_*'' parameters:
<pre>
guide_u=y
guide_v=y
guide_T=y
guide_P=n
guide_Q=n
</pre>
In the example above, nudging is done on horizontal winds (u,v) and on temperature (T) only.

In addition, the user must provide two time scales $\tau$, for each of the nudged variables; one for the inner zoom area ''tau_max_*'' and another relative to outside the zoomed area ''tau_min_*''. These time scales are stated in unit of days, e.g.
<pre>
tau_min_u= 0.0208333
tau_max_u= 10.
tau_min_v= 0.0208333
tau_max_v= 10.
tau_min_T= 0.0208333
tau_max_T= 10.
</pre>
In this example all 3 variables are nudged with a time scale of 10 days, i.e very loosely, within the zoomed region and a time scale of 30 minutes (30.*60/86400.= 0.0208333), i.e. very strongly, outside the zoomed region.

'''''Caution''''':

==== Ne pas confondre constante de rappel et fréquence d'appel au guidage ====

Quand on guide :

# On lit les champs typiquement toutes les 6 heures (suivant la disponibiité des champs de guidage).
# On interpole linéairement en temps les champs de guidage.
# On rappelle à chaque pas de temps vers ces champs interpolés avec une constante définie dans guide.def avec les tau_min tau_max.

mais "je nudge à chaque pas de temps".

== Nudging files ==
In addition to stating which variable is nudged and the related time scales, one must provide the fields towards which to nudge (these must be on the same grid as the simulation and must be created separately, e.g. using a re-interpolation of ERA-interim files). These files must be in the directory where LMDZ runs and must be called ''u.nc'', ''v.nc'', ''T.nc'', etc.

== Nudging contribution output ==
One can request that the nudging term be stored in an output file, '''guide_ins.nc''' by setting (in guide.def):
<pre>
guide_sav=y
</pre>

== Notes ==
==== Nudging towards the wind zonal mean ====

Quelques précisions :

* Par défaut, on lit un état de guidage 4x / jour, pareil pour l'interpolation sur les niveaux du modèle. Mais ça peut être modifié (paramètres iguide_read, iguide_int).
* Il y a une option au cas où (guide_2D) pour lire un état de guidage 2D (latitude - Pression) et pas 3D.
* L'option guide_zon veut dire qu'on a un terme de rappel qui est uniforme suivant les longitudes :
** on calcule (u-ug) en chaque point
** puis on fait la moyenne zonale de ce nudging. ug n'est pas forcément symétrique ici, mais comme c'est linéaire...
Attention aux interférences avec guide_reg, le plus simple étant peut-être
de commenter les lignes "if guide_reg..." dans la routine guide_zonave.
Ne pas confondre constante de rappel et fréquence d'appel au guidage

==== Nudging towards surface pressure ====

Il faut probablement restreindre le guidage en pression de surface à l'océan pour éviter d'injecter plein de modes de gravités liés au déséquilibre hydrostatique qui sera nécessairement engendré par le fait que le relief vu par les analyses est différent de celui du modèle.

14/12/2021
[[Category:Nudging]]
[[Category:Guidage]]

Nudging in LMDZ

2022-05-16T13:13:02Z

Lfairhead :

== The concept ==
''For indepth theoretical explanations, see this doc in French (dated 2009, some code détails are obsolete): https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/notes-techniques/ressources/guidage_LMDZ.pdf''

Nudging is simply adding a forcing term to the GFD equation governing a variable $$V$$ to drive it towards a known value $$V_{analysis}$$ over a given time scale $$\tau$$:
\begin{align}
\frac{\partial V}{\partial t} = \frac{\partial V}{\partial t}_{GCM} + \frac{V_{analysis}-V}{\tau}
\end{align}
Where $$V$$ can be zonal wind u, meridional wind v, relative humidity Q, pressure P or temperature T

Nudging is often used in conjunction with zoomed configurations, where strong nudging towards reanalyses in enforced outside the zoomed region.

== Nudging parameters in LMDZ ==
The master parameter to turn nudging on is ''ok_guide'' (most often all nudging parameters are put in a '''guide.def''' file included in '''run.def''') which must be set to "y" (or equivalently ".true."):
<pre>
ok_guide = y
</pre>
("guide" means "nudge" in French).

Then one must select which fields will be nudged via the ''guide_*'' parameters:
<pre>
guide_u=y
guide_v=y
guide_T=y
guide_P=n
guide_Q=n
</pre>
In the example above, nudging is done on horizontal winds (u,v) and on temperature (T) only.

In addition, the user must provide two time scales $\tau$, for each of the nudged variables; one for the inner zoom area ''tau_max_*'' and another relative to outside the zoomed area ''tau_min_*''. These time scales are stated in unit of days, e.g.
<pre>
tau_min_u= 0.0208333
tau_max_u= 10.
tau_min_v= 0.0208333
tau_max_v= 10.
tau_min_T= 0.0208333
tau_max_T= 10.
</pre>
In this example all 3 variables are nudged with a time scale of 10 days, i.e very loosely, within the zoomed region and a time scale of 30 minutes (30.*60/86400.= 0.0208333), i.e. very strongly, outside the zoomed region.

'''''Caution''''':

==== Ne pas confondre constante de rappel et fréquence d'appel au guidage ====

Quand on guide :

# On lit les champs typiquement toutes les 6 heures (suivant la disponibiité des champs de guidage).
# On interpole linéairement en temps les champs de guidage.
# On rappelle à chaque pas de temps vers ces champs interpolés avec une constante définie dans guide.def avec les tau_min tau_max.

mais "je nudge à chaque pas de temps".

== Nudging files ==
In addition to stating which variable is nudged and the related time scales, one must provide the fields towards which to nudge (these must be on the same grid as the simulation and must be created separately, e.g. using a re-interpolation of ERA-interim files). These files must be in the directory where LMDZ runs and must be called ''u.nc'', ''v.nc'', ''T.nc'', etc.

== Nudging contribution output ==
One can request that the nudging term be stored in an output file, '''guide_ins.nc''' by setting (in guide.def):
<pre>
guide_sav=y
</pre>

== Nudging towards the wind zonal mean ==

Quelques précisions :

* Par défaut, on lit un état de guidage 4x / jour, pareil pour l'interpolation sur les niveaux du modèle. Mais ça peut être modifié (paramètres iguide_read, iguide_int).
* Il y a une option au cas où (guide_2D) pour lire un état de guidage 2D (latitude - Pression) et pas 3D.
* L'option guide_zon veut dire qu'on a un terme de rappel qui est uniforme suivant les longitudes :
** on calcule (u-ug) en chaque point
** puis on fait la moyenne zonale de ce nudging. ug n'est pas forcément symétrique ici, mais comme c'est linéaire...
Attention aux interférences avec guide_reg, le plus simple étant peut-être
de commenter les lignes "if guide_reg..." dans la routine guide_zonave.
Ne pas confondre constante de rappel et fréquence d'appel au guidage

14/12/2021
[[Category:Nudging]]
[[Category:Guidage]]

Nudging in LMDZ

2022-05-16T13:06:05Z

Lfairhead :

== The concept ==
''For indepth theoretical explanations, see this doc in French (dated 2009, some code détails are obsolete): https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/notes-techniques/ressources/guidage_LMDZ.pdf''

Nudging is simply adding a forcing term to the GFD equation governing a variable $$V$$ to drive it towards a known value $$V_{analysis}$$ over a given time scale $$\tau$$:
\begin{align}
\frac{\partial V}{\partial t} = \frac{\partial V}{\partial t}_{GCM} + \frac{V_{analysis}-V}{\tau}
\end{align}
Where $$V$$ can be zonal wind u, meridional wind v, relative humidity Q, pressure P or temperature T

Nudging is often used in conjunction with zoomed configurations, where strong nudging towards reanalyses in enforced outside the zoomed region.

== Nudging parameters in LMDZ ==
The master parameter to turn nudging on is ''ok_guide'' (most often all nudging parameters are put in a '''guide.def''' file included in '''run.def''') which must be set to "y" (or equivalently ".true."):
<pre>
ok_guide = y
</pre>
("guide" means "nudge" in French).

Then one must select which fields will be nudged via the ''guide_*'' parameters:
<pre>
guide_u=y
guide_v=y
guide_T=y
guide_P=n
guide_Q=n
</pre>
In the example above, nudging is done on horizontal winds (u,v) and on temperature (T) only.

In addition, the user must provide two time scales $\tau$, for each of the nudged variables; one for the inner zoom area ''tau_max_*'' and another relative to outside the zoomed area ''tau_min_*''. These time scales are stated in unit of days, e.g.
<pre>
tau_min_u= 0.0208333
tau_max_u= 10.
tau_min_v= 0.0208333
tau_max_v= 10.
tau_min_T= 0.0208333
tau_max_T= 10.
</pre>
In this example all 3 variables are nudged with a time scale of 10 days, i.e very loosely, within the zoomed region and a time scale of 30 minutes (30.*60/86400.= 0.0208333), i.e. very strongly, outside the zoomed region.

'''''Caution''''':

=== Ne pas confondre constante de rappel et fréquence d'appel au guidage ===

Quand on guide :

# On lit les champs typiquement toutes les 6 heures (suivant la disponibiité des champs de guidage).
# On interpole linéairement en temps les champs de guidage.
# On rappelle à chaque pas de temps vers ces champs interpolés avec une constante définie dans guide.def avec les tau_min tau_max.

mais "je nudge à chaque pas de temps".

== Nudging files ==
In addition to stating which variable is nudged and the related time scales, one must provide the fields towards which to nudge (these must be on the same grid as the simulation and must be created separately, e.g. using a re-interpolation of ERA-interim files). These files must be in the directory where LMDZ runs and must be called ''u.nc'', ''v.nc'', ''T.nc'', etc.

== Nudging contribution output ==
One can request that the nudging term be stored in an output file, '''guide_ins.nc''' by setting (in guide.def):
<pre>
guide_sav=y
</pre>

14/12/2021
[[Category:Nudging]]
[[Category:Guidage]]

HowTo: Using gcov (the GNU coverage tool) with LMDZ

2022-05-02T08:58:14Z

Lfairhead :

If you want a summary of the lines (and branches) in your code that are actually executed, you can use the GNU [[https://gcc.gnu.org/onlinedocs/gcc/Gcov.html coverage tool]]. This entails the following three steps:

# compiling your code with the right options
# running the code to output the statistics that gcov will analyze
# running gcov on the data files created in the previous step to analyze the code coverage

=== Running gcov on LMDZ ===

We will be using [[https://gcovr.com/en/stable/ gcovr]] a utility using gcov and providing different types of outputs

'''''Compiling LMDZ'''''

You will need to add the following flags to your compilation flags in the arch.fcm.file:

%BASE_FFLAGS -cpp -ffree-line-length-0 -fdefault-real-8 -DNC_DOUBLE '''-pg --coverage -fprofile-arcs -ftest-coverage -fprofile-abs-path'''
....
%BASE_LD -Wl,-rpath=/data/fairhead/Test_coverage/LMDZ20211102.trunk/netcdf-4.0.1/lib '''-pg -lgcov'''

'''''Running LMDZ'''''

You just run gcm.e as you usually do. This will create a bunch of gcda and gcno files that are used by gcov in the following step

'''''Running gcovr'''''

You then launch the gcovr command as
gcovr -r . -v --html-details gcm_details libo/local_32x32x39_phylmd_seq.e/.config/tmp/
^
this is where the gcda and gcno files are saved by the compiler. They're created where the source files were actually compiled.

to create html files with the prefix <code>gcm_details</code> and the name of the routine included in the file. Each file in your code will have a corresponding html file giving the usage for each line of the routine included in that file.

You'll find [[https://web.lmd.jussieu.fr/~fairhead/Labo/LMDZ_Coverage/sequential/example-html-details.html here]] an example of the output for the actual LMDZ code.

[[Category:HowTo]]

HowTo: Using gcov (the GNU coverage tool) with LMDZ

2022-04-29T11:56:58Z

Lfairhead :

If you want a summary of the lines (and branches) in your code that are actually executed, you can use the GNU [[https://gcc.gnu.org/onlinedocs/gcc/Gcov.html coverage tool]]. This entails the following three steps:

# compiling your code with the right options
# running the code to output the statistics that gcov will analyze
# running gcov on the data files created in the previous step to analyze the code coverage

=== Running gcov on LMDZ ===

We will be using [[https://gcovr.com/en/stable/ gcovr]] a utility using gcov and providing different types of outputs

'''''Compiling LMDZ'''''

You will need to add the following flags to your compilation flags in the arch.fcm.file:

%BASE_FFLAGS -cpp -ffree-line-length-0 -fdefault-real-8 -DNC_DOUBLE '''-pg --coverage -fprofile-arcs -ftest-coverage -fprofile-abs-path'''

'''''Running LMDZ'''''

You just run gcm.e as you usually do. This will create a bunch of gcda and gcno files that are used by gcov in the following step

'''''Running gcovr'''''

You then launch the gcovr command as
gcovr -r . -v --html-details gcm_details libo/local_32x32x39_phylmd_seq.e/.config/tmp/
^
this is where the gcda and gcno files are saved by the compiler. They're created where the source files were actually compiled.

to create html files with the prefix <code>gcm_details</code> and the name of the routine included in the file. Each file in your code will have a corresponding html file giving the usage for each line of the routine included in that file.

You'll find [[https://web.lmd.jussieu.fr/~fairhead/Labo/LMDZ_Coverage/sequential/example-html-details.html here]] an example of the output for the actual LMDZ code.

[[Category:HowTo]]

HowTo: Using gcov (the GNU coverage tool) with LMDZ

2022-04-29T11:54:29Z

Lfairhead :

If you want a summary of the lines (and branches) in your code that are actually executed, you can use the GNU [[https://gcc.gnu.org/onlinedocs/gcc/Gcov.html coverage tool]]. This entails the following three steps:

# compiling your code with the right options
# running the code to output the statistics that gcov will analyze
# running gcov on the data files created in the previous step to analyze the code coverage

=== Running gcov on LMDZ ===

We will be using [[https://gcovr.com/en/stable/ gcovr]] a utility using gcov and providing different types of outputs

'''''Compiling LMDZ'''''

You will need to add the following flags to your compilation flags in the arch.fcm.file:

%BASE_FFLAGS -cpp -ffree-line-length-0 -fdefault-real-8 -DNC_DOUBLE '''-pg --coverage -fprofile-arcs -ftest-coverage -fprofile-abs-path'''

'''''Running LMDZ'''''

You just run gcm.e as you usually do. This will create a bunch of gcda and gcno files that are used by gcov in the following step

'''''Running gcovr'''''

You then launch the gcovr command as
gcovr -r . -v --html-details gcm_details libo/local_32x32x39_phylmd_seq.e/.config/tmp/
^
this is where the gcda and gcno files are saved by the compiler. They're created where the source files were actually compiled
to create html files with the prefix <code>gcm_details</code> and the name of the routine included in the file. Each file in your code will have a corresponding html file giving the usage for each line of the routine included in that file.

[[Category:HowTo]]

HowTo: Using gcov (the GNU coverage tool) with LMDZ

2022-04-29T11:53:05Z

Lfairhead :

If you want a summary of the lines (and branches) in your code that are actually executed, you can use the GNU [[https://gcc.gnu.org/onlinedocs/gcc/Gcov.html coverage tool]]. This entails the following three steps:

# compiling your code with the right options
# running the code to output the statistics that gcov will analyze
# running gcov on the data files created in the previous step to analyze the code coverage

=== Running gcov on LMDZ ===

We will be using [[https://gcovr.com/en/stable/ gcovr]] a utility using gcov and providing different types of outputs

'''''Compiling LMDZ'''''

You will need to add the following flags to your compilation flags in the arch.fcm.file:

%BASE_FFLAGS -cpp -ffree-line-length-0 -fdefault-real-8 -DNC_DOUBLE '''-pg --coverage -fprofile-arcs -ftest-coverage -fprofile-abs-path'''

'''''Running LMDZ'''''

You just run gcm.e as you usually do. This will create a bunch of gcda and gcno files that are used by gcov in the following step

'''''Running gcovr'''''

You then launch the gcovr command as
gcovr -r . -v --html-details gcm_details libo/local_32x32x39_phylmd_seq.e/.config/tmp/
^
this is where the gcda and gcno files are saved by the compiler
to create html files with the prefix <code>gcm_details</code> and the name of the routine included in the file. Each file in your code will have a corresponding html file giving the usage for each line of the routine included in that file.

[[Category:HowTo]]

HowTo: Using gcov (the GNU coverage tool) with LMDZ

2022-04-28T15:41:19Z

Lfairhead : /* HowTo: Using the GNU coverage tool gcov with LMDZ */

HowTo: Using gcov (the GNU coverage tool) with LMDZ

2022-04-28T15:41:02Z

Lfairhead : Page créée avec « == HowTo: Using the GNU coverage tool gcov with LMDZ == If you want a summary of the lines (and branches) in your code that are actually executed, you can use the GNU h... »

== HowTo: Using the GNU coverage tool gcov with LMDZ ==

If you want a summary of the lines (and branches) in your code that are actually executed, you can use the GNU [[https://gcc.gnu.org/onlinedocs/gcc/Gcov.html coverage tool]]. This entails the following three steps:

# compiling your code with the right options
# running the code to output the statistics that gcov will analyze
# running gcov on the data file created in the previous step

=== Running gcov on LMDZ ===

We will be using [[https://gcovr.com/en/stable/ gcovr]] a utility using gcov and providing different types os outputs

'''''Compiling LMDZ'''''

You will need to add the following flags to your compilation flags in the arch.fcm.file:

%BASE_FFLAGS -cpp -ffree-line-length-0 -fdefault-real-8 -DNC_DOUBLE '''-pg --coverage -fprofile-arcs -ftest-coverage -fprofile-abs-path'''

'''''Running LMDZ'''''

You just run gcm.e as you usually do. This will create a bunch of gcda and gcno files that are used by gcov in the following step

'''''Running gcovr'''''

You then launch the gcovr command as
gcovr -r . -v --html-details gcm_details libo/local_32x32x39_phylmd_seq.e/.config/tmp/
^
this is where the gcda and gcno files are saved by the compiler
to create html files

[[Category:HowTo]]

ExempleMaths

2022-04-06T15:16:30Z

Lfairhead :

$$\newcommand{\Re}{\mathrm{Re}\,}
\newcommand{\pFq}[5]{{}_{#1}\mathrm{F}_{#2} \left( \genfrac{}{}{0pt}{}{#3}{#4} \bigg| {#5} \right)}$$

We consider, for various values of $$s$$, the $$n$$-dimensional integral
\begin{align}
\label{def:Wns}
W_n (s)
&:=
\int_{[0, 1]^n}
\left| \sum_{k = 1}^n \mathrm{e}^{2 \pi \mathrm{i} \, x_k} \right|^s \mathrm{d}\boldsymbol{x}
\end{align}
which occurs in the theory of uniform random walk integrals in the plane,
where at each step a unit-step is taken in a random direction. As such,
the integral \eqref{def:Wns} expresses the $$s$$-th moment of the distance
to the origin after $$n$$ steps.

By experimentation and some sketchy arguments we quickly conjectured and
strongly believed that, for $$k$$ a nonnegative integer
\begin{align}
\label{eq:W3k}
W_3(k) &= \Re \, \pFq32{\frac12, -\frac k2, -\frac k2}{1, 1}{4}.
\end{align}
Appropriately defined, \eqref{eq:W3k} also holds for negative odd integers.
The reason for \eqref{eq:W3k} was long a mystery, but it will be explained
at the end of the paper.

<syntaxhighlight lang="fortran">
PROGRAM Truc
IMPLICIT NONE
DO i = 1, iim
DO j = 1, jjm
.....
END DO
END DO
END PROGRAM
</syntaxhighlight>

MediaWiki:Sidebar

2022-04-04T08:47:23Z

Lfairhead :

* navigation
** mainpage|mainpage-description
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help-mediawiki
* SEARCH
* TOOLBOX
* LANGUAGES

MediaWiki:Sidebar

2022-04-04T08:44:04Z

Lfairhead :

MediaWiki:Sidebar

2022-04-04T08:43:37Z

Lfairhead :

MediaWiki:Sidebar

2022-04-04T08:43:03Z

Lfairhead :

MediaWiki:Sidebar

2022-04-04T08:42:22Z

Lfairhead :

MediaWiki:Sidebar

2022-04-04T08:42:09Z

Lfairhead :

MediaWiki:Sidebar

2022-04-04T08:41:34Z

Lfairhead :

* navigation
** mainpage|mainpage-description
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help-mediawiki
* SEARCH
** trucmuche
* TOOLBOX
* LANGUAGES

MediaWiki:Sidebar

2022-04-04T08:41:04Z

Lfairhead :

* navigation
** mainpage|mainpage-description
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help-mediawiki
* SEARCH

* LANGUAGES

MediaWiki:Sidebar

2022-04-04T08:40:33Z

Lfairhead :

* navigation
** mainpage|mainpage-description
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help-mediawiki
* trucmuche
* SEARCH
* TOOLBOX
* LANGUAGES

MediaWiki:Sidebar

2022-04-04T08:39:55Z

Lfairhead : Page créée avec « * SEARCH * navigation ** mainpage|mainpage-description ** recentchanges-url|recentchanges ** randompage-url|randompage ** helppage|help-mediawiki * SEARCH * TOOLBOX * LAN... »

* SEARCH
* navigation
** mainpage|mainpage-description
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help-mediawiki
* SEARCH
* TOOLBOX
* LANGUAGES

Nudging in LMDZ

2022-03-28T09:05:52Z

Lfairhead :

== The concept ==
Nudging is simply adding a forcing term to the GFD equation governing a variable $$V$$ to drive it towards a known value $$V_{analysis}$$ over a given time scale $$\tau$$:
\begin{align}
\frac{\partial V}{\partial t} = \frac{\partial V}{\partial t}_{GCM} + \frac{V_{analysis}-V}{\tau}
\end{align}
Where $$V$$ can be zonal wind u, meridional wind v, relative humidity Q, pressure P or temperature T

Nudging is often used in conjunction with zoomed configurations, where strong nudging towards reanalyses in enforced outside the zoomed region.

== Nudging parameters in LMDZ ==
The master parameter to turn nudging on is ''ok_guide'' (most often all nudging parameters are put in a '''guide.def''' file included in '''run.def''') which must be set to "y" (or equivalently ".true."):
<pre>
ok_guide = y
</pre>
("guide" means "nudge" in French).

Then one must select which fields will be nudged via the ''guide_*'' parameters:
<pre>
guide_u=y
guide_v=y
guide_T=y
guide_P=n
guide_Q=n
</pre>
In the example above, nudging is done on horizontal winds (u,v) and on temperature (T) only.

In addition, the user must provide two time scales $\tau$, for each of the nudged variables; one for the inner zoom area ''tau_max_*'' and another relative to outside the zoomed area ''tau_min_*''. These time scales are stated in unit of days, e.g.
<pre>
tau_min_u= 0.0208333
tau_max_u= 10.
tau_min_v= 0.0208333
tau_max_v= 10.
tau_min_T= 0.0208333
tau_max_T= 10.
</pre>
In this example all 3 variables are nudged with a time scale of 10 days, i.e very loosely, within the zoomed region and a time scale of 30 minutes (30.*60/86400.= 0.0208333), i.e. very strongly, outside the zoomed region.

== Nudging files ==
In addition to stating which variable is nudged and the related time scales, one must provide the fields towards which to nudge (these must be on the same grid as the simulation and must be created separately, e.g. using a re-interpolation of ERA-interim files). These files must be in the directory where LMDZ runs and must be called ''u.nc'', ''v.nc'', ''T.nc'', etc.

== Nudging contribution output ==
One can request that the nudging term be stored in an output file, '''guide_ins.nc''' by setting (in guide.def):
<pre>
guide_sav=y
</pre>

14/12/2021
[[Category:Guidage]][[Category:Nuging]][[Category:Guidage/Nuging]]

Nudging in LMDZ

2022-03-28T09:05:00Z

Lfairhead :

Nudging in LMDZ

2022-03-28T08:57:51Z

Lfairhead :

Création des fichiers de guidage et adaptation de l'exécution

2022-03-28T08:44:36Z

Lfairhead :

== Créer les fichiers de guidages ==

1 => Créer le fichier grilles_gcm.nc avec ce0l. Pour cela, avant de lancer ce0l, ajouter dans run.def :
grilles_gcm_netcdf=y
2 => Extraire les scripts pour interpolation de fichiers de guidage :
svn co http://forge.ipsl.jussieu.fr/igcmg/svn/CONFIG/LMDZOR/branches/LMDZOR_v4/CREATE/SCRIPT
3 => Recuperer les fichiers ERAI non-interpolé
4 => Interpoler avec interp_from_era.ksh. D'abord adapter qq variables en tete du script :
gridfile=chemin pour grilles_gcm.nc
indir= ou se trouver les fichier era-i
varlist="u v" : les variables a interpoler
outdir= repertoire de resultats
first_year=2011
last_year=2011
rundir= repertoire temporaire

./interp_from_era.ksh

== Adapter le run ==

5 => Crée le fichier guide.def, par exemple :
## debut guide.def
# ok_guide=y : guidage active
ok_guide=y

[[Category:guidage]]
[[Category:HowTo]]

guide_u= y
guide_v= y
guide_T= n
guide_P= n
guide_Q= n

tau_min_u=0.0208333
tau_max_u=0.125
tau_min_v=0.0208333
tau_max_v=0.125
## fin guide.def

Remarque : 
Ici, dans ce guide.def, uniquement le guidage des variables u et v sont activé. 
Temps de relaxation, pour une grille regulière, la valeur tau_max est utilisé, ici tau_max=0.125 => 3H. 
Temps de relaxation, pour une grille zoomée, la valeur tau_max est utilisé à l'interieure de la zoom et tau_min à l'exterieur de la zoom, ici tau_min=0.0208333 => 30min. 
Plus le temps de relaxation(tau) est petit, plus le guidage est fort.. 

6 => Ajouter en tete de run.def la prise en compte de la fichier guide.def :
INCLUDEDEF=guide.def

7 => Copier les fichier interpolé u_201101_erai.nc en u.nc et v_201101_erai.nc v.nc dans le repertoire où le modèle sera lancer :
ln -s ERAI_interp/2011/u_201101_erai.nc u.nc
ln -s ERAI_interp/2011/v_201101_erai.nc v.nc

8 => Lancer l'execution
./gcm.e > out_guide 2>&1

[[Category:Guidage]]

Catégorie:ExpertDev

2021-11-16T14:36:50Z

Lfairhead : Page créée avec « Useful information for experts and developpers »

Useful information for experts and developpers