<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="fr">
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Abarral</id>
		<title>LMDZPedia - Contributions de l’utilisateur [fr]</title>
		<link rel="self" type="application/atom+xml" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Abarral"/>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php/Sp%C3%A9cial:Contributions/Abarral"/>
		<updated>2026-06-12T02:06:18Z</updated>
		<subtitle>Contributions de l’utilisateur</subtitle>
		<generator>MediaWiki 1.27.7</generator>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=512</id>
		<title>LMDZ Setup</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=512"/>
				<updated>2024-12-13T10:34:52Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LMDZ_Setup is a set of scripts that allows a light automatic setup of LMDZ long chained climate simulations, including the installation of the model itself.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can only be used on the Jean-Zay computer at Idris so far.&lt;br /&gt;
&lt;br /&gt;
Coming VERY soon (summer 2024) : extension to other computing centers (&amp;quot;spirit&amp;quot;, adastra) and Linux PCs&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Documentation (in French):'''&lt;br /&gt;
[https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit LMDZ_Setup_HowTo]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''To extract LMDZ_Setup :'''&lt;br /&gt;
&lt;br /&gt;
a/ Recommended : extraction from svn repository : &lt;br /&gt;
&lt;br /&gt;
    svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&lt;br /&gt;
&lt;br /&gt;
b/ Download of the &amp;quot;tar&amp;quot; archive :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&lt;br /&gt;
 &lt;br /&gt;
c/ For those used with the old name &amp;quot;tutorial_prod.tar&amp;quot; : a link with this name still exists, pointing to LMDZ_Setup.tar :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''(Text extracted from LMDZ_Setup/README0_HowTo):''&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup consists in running '''LMDZ coupled to Orchidee''' for land surface (optional), but with '''imposed sea surface temperature'''.&lt;br /&gt;
&lt;br /&gt;
The '''basic default configuration''' makes use of the IPSL-CM6A grid configuration and tuning, and runs a multi annual simulation on &amp;quot;climatological&amp;quot;&lt;br /&gt;
amip sea surface temperature (with a mean annual cycle) using a calendar with 360 days.&lt;br /&gt;
&lt;br /&gt;
Optionally : the configuration includes the '''ability to use interannually varying SST''' and to activate '''&amp;quot;nudging&amp;quot;''' by a reanalysis.&lt;br /&gt;
In both cases, the calendar is then a real one.&lt;br /&gt;
When nudging is activated, the simulation must be run on a monthly basis, while otherwise, it can be either monthly or yearly.&lt;br /&gt;
&lt;br /&gt;
Since LMDZ_Setup automatically generates its own initial files, it can be run with '''zoom configurations''' by only changing the number of grid points (&amp;quot;resol&amp;quot; in main.sh) and the DEF/gcm.def file (see bellow).&lt;br /&gt;
&lt;br /&gt;
'''Aerosols''' can be read for the year 2000 (weighted average  over 1999-2001 cf Lurton et al 2020), and instantaneous forcing with respect to 1850 can be computed as well.&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can also run LMDZ coupled with the '''SPLA model''' (SimPLe Aerosol, activated with option aerosols=spla in setup.sh).&lt;br /&gt;
Emissions of dust and sea salt are then computed interactively.&lt;br /&gt;
For the time being, SPLA-specific input files (anthropic aerosol emissions)are only available on the grid zoomed over N Africa used by J. Escribano in his PhD thesis, and by B. Diallo and H. Senghor in subsequent work on N-African dust (file DEF/gcm.def_zNAfrica_BiJe).&lt;br /&gt;
&lt;br /&gt;
A configuration with '''isotopes''' is also available since 2023-04.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Below: new LMDZ_Setup docs ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Old documentation (French): [https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c LMDZ_Setup_HowTo]''&lt;br /&gt;
&lt;br /&gt;
== User guide ==&lt;br /&gt;
&lt;br /&gt;
 ''' /!\ WARNING''' 06/2024 - (ignore if installing a new version)&lt;br /&gt;
 The JeanZay calculator, as well as Adastra, do not allow (anymore) communication from/to $STORE for running jobs on the main computing partitions.&lt;br /&gt;
 As a result, make sure to replace $STORE by $WORK in &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt; wherever relevant.&lt;br /&gt;
&lt;br /&gt;
 '''READ comments at the top of scripts ! Often your questions are answered there.'''&lt;br /&gt;
&lt;br /&gt;
 ''Note'': &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; has been tested on Adastra and Spirit, and to a lesser extent on JeanZay (legacy support only). No guarantee is made on other platforms, although it should be easy to adapt it. It can also be ran locally - for expert use only.&lt;br /&gt;
&lt;br /&gt;
=== Downloading LMDZ_Setup ===&lt;br /&gt;
&lt;br /&gt;
 /!\ Note: below is for when the new version will replace the old one - for now, use &amp;lt;code&amp;gt;svn co http://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup_amaury&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''(recommended)'' Using ''subversion'': &amp;lt;code&amp;gt;svn co http://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(alternative)'' &amp;lt;code&amp;gt;wget http://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(deprecated)'' The old &amp;lt;code&amp;gt;tutorial_prod&amp;lt;/code&amp;gt; version: &amp;lt;code&amp;gt;wget http://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Structure ===&lt;br /&gt;
&lt;br /&gt;
Once you have downloaded &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;, you will find the following main files:&lt;br /&gt;
* &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;: the main script. It contains the basic settings you will modify.&lt;br /&gt;
* &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;: this script contains the internal workings of &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. It's where you can edit expert-level settings.&lt;br /&gt;
* &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;: this file contains platform-specific configuration, such as where to install the model, where to run the simulations, etc.&lt;br /&gt;
&lt;br /&gt;
=== How to run a simulation ===&lt;br /&gt;
&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;set_env&amp;lt;/code&amp;gt;, find the case corresponding to your supercomputer: &amp;lt;code&amp;gt;jean-)&amp;lt;/code&amp;gt; for JeanZay, &amp;lt;code&amp;gt;spiri)&amp;lt;/code&amp;gt; for Spirit, &amp;lt;code&amp;gt;adast)&amp;lt;/code&amp;gt; for Adastra. Edit the variables required for your use case. All the variables are documented in the last &amp;lt;code&amp;gt;*)&amp;lt;/code&amp;gt; case. In particular:&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;define_expert_options&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;DEF/*&amp;lt;/code&amp;gt;.''' Edit the &amp;lt;code&amp;gt;DEF/*.def&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt; files, such as &amp;lt;code&amp;gt;config.def&amp;lt;/code&amp;gt;, to your liking. ''The options you specify in main.sh/setup.sh don't require any adjustment here; such adjustments are automatically performed at runtime.''&lt;br /&gt;
# '''Launch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;'''.&lt;br /&gt;
&lt;br /&gt;
=== Miscellanous notes ===&lt;br /&gt;
&lt;br /&gt;
* Simulations run in a subdirectory of &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; with the same name as the &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder (if you have extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; and renamed it to &amp;lt;code&amp;gt;My_Setup&amp;lt;/code&amp;gt; then simulations will run in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/My_Setup&amp;lt;/code&amp;gt;). Each simulation is contained in its own folder, named after the simulation's name + a process number. As a result, '''you don't need to clean $SIMRUNBASEDIR before relaunching a simulation'''.&lt;br /&gt;
* If your simulation crashes, look directly in &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; for the relevant log.&lt;br /&gt;
* If you need a version of ORCHIDEE different from the one provided by default in the model (such as &amp;lt;code&amp;gt;CMIP6&amp;lt;/code&amp;gt;), a password is required - ask ''orchidee-help at listes.ipsl.fr'' if you need help.&lt;br /&gt;
&lt;br /&gt;
==== XIOS ====&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' Although XIOS is not ''required'' for ORCHIDEE &amp;gt;=2.2, not using it will disable some features.&lt;br /&gt;
Different sets of &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt; files are available in &amp;lt;code&amp;gt;LMDZ_Setup/DEF/XMLFiles*&amp;lt;/code&amp;gt;. However, only some common files (&amp;lt;code&amp;gt;histf, histday, histmth&amp;lt;/code&amp;gt;) have been adapted for &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. ''If you need other outputs, '''be sure to edit/check the relevant &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt;''''':&lt;br /&gt;
* replace the &amp;lt;code&amp;gt;_AUTO_&amp;lt;/code&amp;gt; for &amp;lt;code&amp;gt;output_level&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;enabled&amp;lt;/code&amp;gt; by actual values;&lt;br /&gt;
* use &amp;lt;code&amp;gt;compression_level=0&amp;lt;/code&amp;gt; instead of the default values (&amp;lt;code&amp;gt;2&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;4&amp;lt;/code&amp;gt;) (since &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; uses XIOS in attached mode rather than client-server mode, using non-zero compression levels would require running XIOS on 1+ dedicated MPI).&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' After installing the model, two files are automatically initialized in &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;context_lmdz.xml&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;field_def_lmdz.xml&amp;lt;/code&amp;gt;. Those files don't require user intervention, and must match the exact LMDZ revision used.&lt;br /&gt;
&lt;br /&gt;
==== Compilation ====&lt;br /&gt;
&lt;br /&gt;
When launching &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, before running the simulation, we first download and compile the required models. Although we call the compilation script every time, if the model has already been compiled before, the script should detect that and skip the actual compilation, and thus execute very quickly.&lt;br /&gt;
&lt;br /&gt;
''Note: on supported clusters, compilation is launched in jobs rather than on the login node. This speeds up the compilation.''&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' As written in the comments of &amp;lt;code&amp;gt;main.sh/setup.sh&amp;lt;/code&amp;gt;, '''if you change the &amp;lt;code&amp;gt;veget&amp;lt;/code&amp;gt; version or the &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt;, it is highly recommended to do so in a NEW clean &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder''' rather than recompiling in the same folder.&lt;br /&gt;
&lt;br /&gt;
=== Nudging ===&lt;br /&gt;
&lt;br /&gt;
Nudging is set via the &amp;lt;code&amp;gt;nudging&amp;lt;/code&amp;gt; variable in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. If activated, then after installing the model, &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; will prompt you to run &amp;lt;code&amp;gt;era2gcm_tuto.sh&amp;lt;/code&amp;gt;. This script fetches reanalysis data and puts it in a &amp;lt;code&amp;gt;GUIDE/&amp;lt;/code&amp;gt; folder.&lt;br /&gt;
Once this is done, simply set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and relaunch it.&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' On Adastra, the reanalysis files are not yet available.&lt;br /&gt;
&lt;br /&gt;
=== Aerosols ===&lt;br /&gt;
&lt;br /&gt;
 '''/!\ As written in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, it is highly recommended to install &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; in a new clean directory when changing aerosols options. Otherwise i.e. the &amp;lt;code&amp;gt;DEF/config.def&amp;lt;/code&amp;gt; may not get modified accordingly.'''&lt;br /&gt;
&lt;br /&gt;
When &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt; is set to anything other than &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, aerosols files will be downloaded in &amp;lt;code&amp;gt;LIMIT/&amp;lt;/code&amp;gt;, and will be interpolated to the horizontal grid resolution (vertical interpolation is performed at runtime by the GCM.)&lt;br /&gt;
&lt;br /&gt;
==== More detail ====&lt;br /&gt;
&lt;br /&gt;
The aerosols files used for the options &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt; are those used in CMIP6 with the LMDZORINCA configuration, from [https://www.lmd.jussieu.fr/~lmdz/pub/3DInputData/AerChem/ here].&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt;, we only use &amp;lt;code&amp;gt;aerosols1850_from_inca.nc&amp;lt;/code&amp;gt; (natural aerosols), interpolated as &amp;lt;code&amp;gt;aerosols.nat.nc&amp;lt;/code&amp;gt;&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt;, we also use &amp;lt;code&amp;gt;aerosols9999_from_inca.nc&amp;lt;/code&amp;gt; with the mean aerosols on 1995-2014, interpolated as &amp;lt;code&amp;gt;aerosols.clim.nc&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== ORCHIDEE ===&lt;br /&gt;
&lt;br /&gt;
The officially supported versions of ORCHIDEE supported by LMDZ_Setup are:&lt;br /&gt;
* the CMIP6 version (the last version where the use of the old two-layer hydrology is still possible)&lt;br /&gt;
* version 2.2 r7983&lt;br /&gt;
* version 4 (trunk) r7994 (corresponding to libIGCM's LMDZOR_6.4work configuration)&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' The relevant ORCHIDEE def file &amp;lt;code&amp;gt;DEF/orchidee.def_*&amp;lt;/code&amp;gt; gets copied as &amp;lt;code&amp;gt;DEF/orchidee.def&amp;lt;/code&amp;gt; at initialisation.&lt;br /&gt;
&lt;br /&gt;
==== Activating sechiba outputs ====&lt;br /&gt;
&lt;br /&gt;
Sechiba outputs are written to &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt;, but are deleted by &amp;lt;code&amp;gt;tmp_SIM&amp;lt;/code&amp;gt; before they're rebuilt. To counter that, remove the &amp;lt;code&amp;gt;sec*&amp;lt;/code&amp;gt; on the relevant line &amp;lt;code&amp;gt;set +e ; \rm out* sec* sta* list* rest* gcm.e aer* ; set -e&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Simple routing ====&lt;br /&gt;
&lt;br /&gt;
From orch 2.2 r7597 onwards, the &amp;quot;simple&amp;quot; routing scheme by Y. Meurdesoif can be activated.&lt;br /&gt;
&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/orchidee.def_6.*&amp;lt;/code&amp;gt;, set &amp;lt;code&amp;gt;RIVER_ROUTING=y&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;ROUTING_METHOD = simple&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;RIVER_DESC=y&amp;lt;/code&amp;gt; (''Note: &amp;lt;code&amp;gt;RIVER_DESC&amp;lt;/code&amp;gt; is automatically set to &amp;quot;n&amp;quot; after the first simulation period.)&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/XMLfilesOR7***/iodef.xml&amp;lt;/code&amp;gt;, add at the end of &amp;lt;code&amp;gt;context_orchidee.xml&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;&amp;lt;context id=&amp;quot;orchidee&amp;quot; src=&amp;quot;./context_routing_orchidee.xml&amp;quot;/&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
See also:[https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/UserGuide/RoutageSimple User Guide/Routage Simple] (French).&lt;br /&gt;
&lt;br /&gt;
=== Isotopes ===&lt;br /&gt;
&lt;br /&gt;
To activate isotopes, simply change the &amp;lt;code&amp;gt;lmd_phys&amp;lt;/code&amp;gt; parameter to &amp;lt;code&amp;gt;&amp;quot;lmdiso&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. This will automatically&lt;br /&gt;
* use &amp;lt;code&amp;gt;&amp;quot;phylmdiso&amp;quot;&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;&amp;quot;phylmd&amp;quot;&amp;lt;/code&amp;gt;;&lt;br /&gt;
* copy &amp;lt;code&amp;gt;DEF/PHYS/physiq.def_NPiso&amp;lt;/code&amp;gt; to &amp;lt;code&amp;gt;DEF/physiq.def&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: for isotopes, &amp;lt;code&amp;gt;iflag_ice_thermo&amp;lt;/code&amp;gt; is automatically set to &amp;lt;code&amp;gt;0&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;1&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
* ''How to relaunch a failed simulation ?''&lt;br /&gt;
&lt;br /&gt;
If the simulation ran for at least one successful period, simplys set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and rerun it. Otherwise, see the following question.&lt;br /&gt;
&lt;br /&gt;
* ''I have ran a simulation, but I messed up the parameters. I want to run a new clean simulation with the same name (e.g. &amp;lt;code&amp;gt;NPv6.3&amp;lt;/code&amp;gt;.)''&lt;br /&gt;
&lt;br /&gt;
Remove &amp;lt;code&amp;gt;INIT, LIMIT, NPv6.3&amp;lt;/code&amp;gt; and relaunch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; with &amp;lt;code&amp;gt;init=1&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
* ''How can I follow the state of a running simulation ?''&lt;br /&gt;
&lt;br /&gt;
Check the file &amp;lt;code&amp;gt;LMDZ_Setup/$SIM_NAME/etat&amp;lt;/code&amp;gt;. After each period (mo/yr), it gets updated like so:&lt;br /&gt;
 200001 a faire&lt;br /&gt;
 200001 OK&lt;br /&gt;
 200002 a faire&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To check if the simulation is still running, query your cluster's queue (e.g. &amp;lt;code&amp;gt;squeue --me&amp;lt;/code&amp;gt; on SLURM clusters). If nothing is running, read the next question.&lt;br /&gt;
&lt;br /&gt;
* ''How to investigate a crash ?''&lt;br /&gt;
&lt;br /&gt;
The job error log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/out*&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The simulation log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/$SIM_NAME*/listing&amp;lt;/code&amp;gt;. (''Note: to know which folder is the latest, run &amp;lt;code&amp;gt;ls -lat&amp;lt;/code&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Cluster-specific information ==&lt;br /&gt;
&lt;br /&gt;
=== Generic ===&lt;br /&gt;
&lt;br /&gt;
==== ORCH 4 (trunk) ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4 is currently not able to compile with &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;, and as a result can't be used. This has been reported to the relevant team, and hopefully should be fixed soon (06/2024).&lt;br /&gt;
&lt;br /&gt;
==== CDO &amp;amp; aerosols ====&lt;br /&gt;
&lt;br /&gt;
The current version of &amp;lt;code&amp;gt;cdo&amp;lt;/code&amp;gt; on Adastra (&amp;lt;code&amp;gt;2.4.0&amp;lt;/code&amp;gt;) and Spirit (&amp;lt;code&amp;gt;2.3.0&amp;lt;/code&amp;gt;) contain [https://code.mpimet.mpg.de/boards/1/topics/15752 a bug] which interferes with the script interpolating aerosols. This bug is supposedly solved in version &amp;lt;code&amp;gt;2.4.1+&amp;lt;/code&amp;gt;. This bug corrupts the aerosols files, and results in a &amp;lt;code&amp;gt;hgardfou&amp;lt;/code&amp;gt; error when running the simulation.&lt;br /&gt;
&lt;br /&gt;
=== JeanZay ===&lt;br /&gt;
&lt;br /&gt;
JeanZay was the main supported cluster of the old &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. Although the new version can be ran there, it is discouraged.&lt;br /&gt;
&lt;br /&gt;
==== Slowness ====&lt;br /&gt;
&lt;br /&gt;
Compilation of the various components of the model, in particular of LMDZ and XIOS, is extremely slow on JeanZay compared to other clusters (for unknown reasons) (~15 minutes for LMDZ+rrtm). Moreover, it seems that for uninvestigated reasons, the LMDZ model is systematically recompiled on each call to &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; (expected behavior, as on other clusters: the &amp;lt;code&amp;gt;fcm&amp;lt;/code&amp;gt; system detects that it's already compiled and avoids compiling again). As a result, the whole process of '''launching a simulation is much slower'''.&lt;br /&gt;
&lt;br /&gt;
[[Category:HowTo]]&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=500</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=500"/>
				<updated>2024-09-23T08:14:16Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;lmdz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [[HowTo:_LMDZ_code_guidelines | LMDZ_code_guidelines]])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd -d 79&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmdiso -d 48x36x39&lt;br /&gt;
 All good ! for r5157/r5150=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5157/r5017=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
(XIOS est testé vs 5150 car il segfault sur 5017)&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le common &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;br /&gt;
&lt;br /&gt;
=== Common iniCOSP ===&lt;br /&gt;
&lt;br /&gt;
Le common défini dans &amp;lt;code&amp;gt;ini_COSP.h&amp;lt;/code&amp;gt;  est un peu tricky à remplacer car il a besoin de &amp;lt;code&amp;gt;klon,klev&amp;lt;/code&amp;gt; qui ne sont pas des constantes.&lt;br /&gt;
Une (bonne) manière de faire serait de faire un type dérivé. C'est d'ailleurs ce que je préconise pour remplacer les très longues listes d'arguments, mais c'est à discuter avec le reste du groupe...&lt;br /&gt;
&lt;br /&gt;
== Vitesse ==&lt;br /&gt;
&lt;br /&gt;
A titre indicatif, quelques stats. Attention à l'interprétation (variabilité interne, etc.), la quantité intéressant est le &amp;lt;code&amp;gt;min&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== r5158 v r5017 ===&lt;br /&gt;
&lt;br /&gt;
==== séquentiel ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     152.594 s ± 62.315 s | Range (min … max):   109.719 s … 263.752 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     123.119 s ± 42.065 s | Range (min … max):   89.570 s … 200.606 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     111.737 s ±  4.910 s | Range (min … max):   106.716 s … 118.421 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     92.876 s ±  2.105 s | Range (min … max):   87.766 s … 94.780 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== mpi_omp ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     119.116 s ±  4.124 s | Range (min … max):   114.514 s … 125.466 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     50.382 s ±  0.994 s | Range (min … max):   49.248 s … 52.130 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz:  &amp;lt;code&amp;gt;Time (mean ± σ):     130.779 s ±  5.543 s | Range (min … max):   123.503 s … 139.438 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     52.444 s ±  1.080 s | Range (min … max):   51.387 s … 54.530 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== r5159 ===&lt;br /&gt;
&lt;br /&gt;
This rev replaces all &amp;lt;code&amp;gt;INCLUDE &amp;quot;dimensions.h&amp;quot;,INCLUDE&amp;quot;paramet.h&amp;quot;&amp;lt;/code&amp;gt; by modules. One could think this would impact performance.&lt;br /&gt;
The bench suggests otherwise:&lt;br /&gt;
&lt;br /&gt;
Seq: &amp;lt;code&amp;gt;Time (mean ± σ):     101.333 s ± 20.405 s | Range (min … max):   91.460 s … 150.911 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Para: &amp;lt;code&amp;gt;Time (mean ± σ):     49.341 s ±  0.353 s | Range (min … max):   48.740 s … 50.028 s    10 runs&amp;lt;/code&amp;gt;&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=499</id>
		<title>LMDZ Setup</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=499"/>
				<updated>2024-09-10T10:21:33Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LMDZ_Setup is a set of scripts that allows a light automatic setup of LMDZ long chained climate simulations, including the installation of the model itself.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can only be used on the Jean-Zay computer at Idris so far.&lt;br /&gt;
&lt;br /&gt;
Coming VERY soon (summer 2024) : extension to other computing centers (&amp;quot;spirit&amp;quot;, adastra) and Linux PCs&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Documentation (in French):'''&lt;br /&gt;
[https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit LMDZ_Setup_HowTo]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''To extract LMDZ_Setup :'''&lt;br /&gt;
&lt;br /&gt;
a/ Recommended : extraction from svn repository : &lt;br /&gt;
&lt;br /&gt;
    svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&lt;br /&gt;
&lt;br /&gt;
b/ Download of the &amp;quot;tar&amp;quot; archive :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&lt;br /&gt;
 &lt;br /&gt;
c/ For those used with the old name &amp;quot;tutorial_prod.tar&amp;quot; : a link with this name still exists, pointing to LMDZ_Setup.tar :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''(Text extracted from LMDZ_Setup/README0_HowTo):''&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup consists in running '''LMDZ coupled to Orchidee''' for land surface (optional), but with '''imposed sea surface temperature'''.&lt;br /&gt;
&lt;br /&gt;
The '''basic default configuration''' makes use of the IPSL-CM6A grid configuration and tuning, and runs a multi annual simulation on &amp;quot;climatological&amp;quot;&lt;br /&gt;
amip sea surface temperature (with a mean annual cycle) using a calendar with 360 days.&lt;br /&gt;
&lt;br /&gt;
Optionally : the configuration includes the '''ability to use interannually varying SST''' and to activate '''&amp;quot;nudging&amp;quot;''' by a reanalysis.&lt;br /&gt;
In both cases, the calendar is then a real one.&lt;br /&gt;
When nudging is activated, the simulation must be run on a monthly basis, while otherwise, it can be either monthly or yearly.&lt;br /&gt;
&lt;br /&gt;
Since LMDZ_Setup automatically generates its own initial files, it can be run with '''zoom configurations''' by only changing the number of grid points (&amp;quot;resol&amp;quot; in main.sh) and the DEF/gcm.def file (see bellow).&lt;br /&gt;
&lt;br /&gt;
'''Aerosols''' can be read for the year 2000 (weighted average  over 1999-2001 cf Lurton et al 2020), and instantaneous forcing with respect to 1850 can be computed as well.&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can also run LMDZ coupled with the '''SPLA model''' (SimPLe Aerosol, activated with option aerosols=spla in setup.sh).&lt;br /&gt;
Emissions of dust and sea salt are then computed interactively.&lt;br /&gt;
For the time being, SPLA-specific input files (anthropic aerosol emissions)are only available on the grid zoomed over N Africa used by J. Escribano in his PhD thesis, and by B. Diallo and H. Senghor in subsequent work on N-African dust (file DEF/gcm.def_zNAfrica_BiJe).&lt;br /&gt;
&lt;br /&gt;
A configuration with '''isotopes''' is also available since 2023-04.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Below: new LMDZ_Setup docs ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Old documentation (French): [https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c LMDZ_Setup_HowTo]''&lt;br /&gt;
&lt;br /&gt;
== User guide ==&lt;br /&gt;
&lt;br /&gt;
 ''' /!\ WARNING''' 06/2024 - (ignore if installing a new version)&lt;br /&gt;
 The JeanZay calculator, as well as Adastra, do not allow (anymore) communication from/to $STORE for running jobs on the main computing partitions.&lt;br /&gt;
 As a result, make sure to replace $STORE by $WORK in &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt; wherever relevant.&lt;br /&gt;
&lt;br /&gt;
 '''READ comments at the top of scripts ! Often your questions are answered there.'''&lt;br /&gt;
&lt;br /&gt;
 ''Note'': &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; has been tested on Adastra and Spirit, and to a lesser extent on JeanZay (legacy support only). No guarantee is made on other platforms, although it should be easy to adapt it. It can also be ran locally - for expert use only.&lt;br /&gt;
&lt;br /&gt;
=== Downloading LMDZ_Setup ===&lt;br /&gt;
&lt;br /&gt;
 /!\ Note: below is for when the new version will replace the old one - for now, use &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup_amaury&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''(recommended)'' Using ''subversion'': &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(alternative)'' &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(deprecated)'' The old &amp;lt;code&amp;gt;tutorial_prod&amp;lt;/code&amp;gt; version: &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Structure ===&lt;br /&gt;
&lt;br /&gt;
Once you have downloaded &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;, you will find the following main files:&lt;br /&gt;
* &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;: the main script. It contains the basic settings you will modify.&lt;br /&gt;
* &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;: this script contains the internal workings of &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. It's where you can edit expert-level settings.&lt;br /&gt;
* &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;: this file contains platform-specific configuration, such as where to install the model, where to run the simulations, etc.&lt;br /&gt;
&lt;br /&gt;
=== How to run a simulation ===&lt;br /&gt;
&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;set_env&amp;lt;/code&amp;gt;, find the case corresponding to your supercomputer: &amp;lt;code&amp;gt;jean-)&amp;lt;/code&amp;gt; for JeanZay, &amp;lt;code&amp;gt;spiri)&amp;lt;/code&amp;gt; for Spirit, &amp;lt;code&amp;gt;adast)&amp;lt;/code&amp;gt; for Adastra. Edit the variables required for your use case. All the variables are documented in the last &amp;lt;code&amp;gt;*)&amp;lt;/code&amp;gt; case. In particular:&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;define_expert_options&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;DEF/*&amp;lt;/code&amp;gt;.''' Edit the &amp;lt;code&amp;gt;DEF/*.def&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt; files, such as &amp;lt;code&amp;gt;config.def&amp;lt;/code&amp;gt;, to your liking. ''The options you specify in main.sh/setup.sh don't require any adjustment here; such adjustments are automatically performed at runtime.''&lt;br /&gt;
# '''Launch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;'''.&lt;br /&gt;
&lt;br /&gt;
=== Miscellanous notes ===&lt;br /&gt;
&lt;br /&gt;
* Simulations run in a subdirectory of &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; with the same name as the &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder (if you have extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; and renamed it to &amp;lt;code&amp;gt;My_Setup&amp;lt;/code&amp;gt; then simulations will run in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/My_Setup&amp;lt;/code&amp;gt;). Each simulation is contained in its own folder, named after the simulation's name + a process number. As a result, '''you don't need to clean $SIMRUNBASEDIR before relaunching a simulation'''.&lt;br /&gt;
* If your simulation crashes, look directly in &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; for the relevant log.&lt;br /&gt;
* If you need a version of ORCHIDEE different from the one provided by default in the model (such as &amp;lt;code&amp;gt;CMIP6&amp;lt;/code&amp;gt;), a password is required - ask ''orchidee-help at listes.ipsl.fr'' if you need help.&lt;br /&gt;
&lt;br /&gt;
==== XIOS ====&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' Although XIOS is not ''required'' for ORCHIDEE &amp;gt;=2.2, not using it will disable some features.&lt;br /&gt;
Different sets of &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt; files are available in &amp;lt;code&amp;gt;LMDZ_Setup/DEF/XMLFiles*&amp;lt;/code&amp;gt;. However, only some common files (&amp;lt;code&amp;gt;histf, histday, histmth&amp;lt;/code&amp;gt;) have been adapted for &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. ''If you need other outputs, '''be sure to edit/check the relevant &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt;''''':&lt;br /&gt;
* replace the &amp;lt;code&amp;gt;_AUTO_&amp;lt;/code&amp;gt; for &amp;lt;code&amp;gt;output_level&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;enabled&amp;lt;/code&amp;gt; by actual values;&lt;br /&gt;
* use &amp;lt;code&amp;gt;compression_level=0&amp;lt;/code&amp;gt; instead of the default values (&amp;lt;code&amp;gt;2&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;4&amp;lt;/code&amp;gt;) (since &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; uses XIOS in attached mode rather than client-server mode, using non-zero compression levels would require running XIOS on 1+ dedicated MPI).&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' After installing the model, two files are automatically initialized in &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;context_lmdz.xml&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;field_def_lmdz.xml&amp;lt;/code&amp;gt;. Those files don't require user intervention, and must match the exact LMDZ revision used.&lt;br /&gt;
&lt;br /&gt;
==== Compilation ====&lt;br /&gt;
&lt;br /&gt;
When launching &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, before running the simulation, we first download and compile the required models. Although we call the compilation script every time, if the model has already been compiled before, the script should detect that and skip the actual compilation, and thus execute very quickly.&lt;br /&gt;
&lt;br /&gt;
''Note: on supported clusters, compilation is launched in jobs rather than on the login node. This speeds up the compilation.''&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' As written in the comments of &amp;lt;code&amp;gt;main.sh/setup.sh&amp;lt;/code&amp;gt;, '''if you change the &amp;lt;code&amp;gt;veget&amp;lt;/code&amp;gt; version or the &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt;, it is highly recommended to do so in a NEW clean &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder''' rather than recompiling in the same folder.&lt;br /&gt;
&lt;br /&gt;
=== Nudging ===&lt;br /&gt;
&lt;br /&gt;
Nudging is set via the &amp;lt;code&amp;gt;nudging&amp;lt;/code&amp;gt; variable in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. If activated, then after installing the model, &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; will prompt you to run &amp;lt;code&amp;gt;era2gcm_tuto.sh&amp;lt;/code&amp;gt;. This script fetches reanalysis data and puts it in a &amp;lt;code&amp;gt;GUIDE/&amp;lt;/code&amp;gt; folder.&lt;br /&gt;
Once this is done, simply set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and relaunch it.&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' On Adastra, the reanalysis files are not yet available.&lt;br /&gt;
&lt;br /&gt;
=== Aerosols ===&lt;br /&gt;
&lt;br /&gt;
 '''/!\ As written in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, it is highly recommended to install &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; in a new clean directory when changing aerosols options. Otherwise i.e. the &amp;lt;code&amp;gt;DEF/config.def&amp;lt;/code&amp;gt; may not get modified accordingly.'''&lt;br /&gt;
&lt;br /&gt;
When &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt; is set to anything other than &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, aerosols files will be downloaded in &amp;lt;code&amp;gt;LIMIT/&amp;lt;/code&amp;gt;, and will be interpolated to the horizontal grid resolution (vertical interpolation is performed at runtime by the GCM.)&lt;br /&gt;
&lt;br /&gt;
==== More detail ====&lt;br /&gt;
&lt;br /&gt;
The aerosols files used for the options &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt; are those used in CMIP6 with the LMDZORINCA configuration, from [https://www.lmd.jussieu.fr/~lmdz/pub/3DInputData/AerChem/ here].&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt;, we only use &amp;lt;code&amp;gt;aerosols1850_from_inca.nc&amp;lt;/code&amp;gt; (natural aerosols), interpolated as &amp;lt;code&amp;gt;aerosols.nat.nc&amp;lt;/code&amp;gt;&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt;, we also use &amp;lt;code&amp;gt;aerosols9999_from_inca.nc&amp;lt;/code&amp;gt; with the mean aerosols on 1995-2014, interpolated as &amp;lt;code&amp;gt;aerosols.clim.nc&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== ORCHIDEE ===&lt;br /&gt;
&lt;br /&gt;
The officially supported versions of ORCHIDEE supported by LMDZ_Setup are:&lt;br /&gt;
* the CMIP6 version (the last version where the use of the old two-layer hydrology is still possible)&lt;br /&gt;
* version 2.2 r7983&lt;br /&gt;
* version 4 (trunk) r7994 (corresponding to libIGCM's LMDZOR_6.4work configuration)&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' The relevant ORCHIDEE def file &amp;lt;code&amp;gt;DEF/orchidee.def_*&amp;lt;/code&amp;gt; gets copied as &amp;lt;code&amp;gt;DEF/orchidee.def&amp;lt;/code&amp;gt; at initialisation.&lt;br /&gt;
&lt;br /&gt;
==== Activating sechiba outputs ====&lt;br /&gt;
&lt;br /&gt;
Sechiba outputs are written to &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt;, but are deleted by &amp;lt;code&amp;gt;tmp_SIM&amp;lt;/code&amp;gt; before they're rebuilt. To counter that, remove the &amp;lt;code&amp;gt;sec*&amp;lt;/code&amp;gt; on the relevant line &amp;lt;code&amp;gt;set +e ; \rm out* sec* sta* list* rest* gcm.e aer* ; set -e&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Simple routing ====&lt;br /&gt;
&lt;br /&gt;
From orch 2.2 r7597 onwards, the &amp;quot;simple&amp;quot; routing scheme by Y. Meurdesoif can be activated.&lt;br /&gt;
&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/orchidee.def_6.*&amp;lt;/code&amp;gt;, set &amp;lt;code&amp;gt;RIVER_ROUTING=y&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;ROUTING_METHOD = simple&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;RIVER_DESC=y&amp;lt;/code&amp;gt; (''Note: &amp;lt;code&amp;gt;RIVER_DESC&amp;lt;/code&amp;gt; is automatically set to &amp;quot;n&amp;quot; after the first simulation period.)&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/XMLfilesOR7***/iodef.xml&amp;lt;/code&amp;gt;, add at the end of &amp;lt;code&amp;gt;context_orchidee.xml&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;&amp;lt;context id=&amp;quot;orchidee&amp;quot; src=&amp;quot;./context_routing_orchidee.xml&amp;quot;/&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
See also:[https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/UserGuide/RoutageSimple User Guide/Routage Simple] (French).&lt;br /&gt;
&lt;br /&gt;
=== Isotopes ===&lt;br /&gt;
&lt;br /&gt;
To activate isotopes, simply change the &amp;lt;code&amp;gt;lmd_phys&amp;lt;/code&amp;gt; parameter to &amp;lt;code&amp;gt;&amp;quot;lmdiso&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. This will automatically&lt;br /&gt;
* use &amp;lt;code&amp;gt;&amp;quot;phylmdiso&amp;quot;&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;&amp;quot;phylmd&amp;quot;&amp;lt;/code&amp;gt;;&lt;br /&gt;
* copy &amp;lt;code&amp;gt;DEF/PHYS/physiq.def_NPiso&amp;lt;/code&amp;gt; to &amp;lt;code&amp;gt;DEF/physiq.def&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: for isotopes, &amp;lt;code&amp;gt;iflag_ice_thermo&amp;lt;/code&amp;gt; is automatically set to &amp;lt;code&amp;gt;0&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;1&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
* ''How to relaunch a failed simulation ?''&lt;br /&gt;
&lt;br /&gt;
If the simulation ran for at least one successful period, simplys set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and rerun it. Otherwise, see the following question.&lt;br /&gt;
&lt;br /&gt;
* ''I have ran a simulation, but I messed up the parameters. I want to run a new clean simulation with the same name (e.g. &amp;lt;code&amp;gt;NPv6.3&amp;lt;/code&amp;gt;.)''&lt;br /&gt;
&lt;br /&gt;
Remove &amp;lt;code&amp;gt;INIT, LIMIT, NPv6.3&amp;lt;/code&amp;gt; and relaunch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; with &amp;lt;code&amp;gt;init=1&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
* ''How can I follow the state of a running simulation ?''&lt;br /&gt;
&lt;br /&gt;
Check the file &amp;lt;code&amp;gt;LMDZ_Setup/$SIM_NAME/etat&amp;lt;/code&amp;gt;. After each period (mo/yr), it gets updated like so:&lt;br /&gt;
 200001 a faire&lt;br /&gt;
 200001 OK&lt;br /&gt;
 200002 a faire&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To check if the simulation is still running, query your cluster's queue (e.g. &amp;lt;code&amp;gt;squeue --me&amp;lt;/code&amp;gt; on SLURM clusters). If nothing is running, read the next question.&lt;br /&gt;
&lt;br /&gt;
* ''How to investigate a crash ?''&lt;br /&gt;
&lt;br /&gt;
The job error log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/out*&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The simulation log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/$SIM_NAME*/listing&amp;lt;/code&amp;gt;. (''Note: to know which folder is the latest, run &amp;lt;code&amp;gt;ls -lat&amp;lt;/code&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Cluster-specific information ==&lt;br /&gt;
&lt;br /&gt;
=== Generic ===&lt;br /&gt;
&lt;br /&gt;
==== ORCH 4 (trunk) ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4 is currently not able to compile with &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;, and as a result can't be used. This has been reported to the relevant team, and hopefully should be fixed soon (06/2024).&lt;br /&gt;
&lt;br /&gt;
==== CDO &amp;amp; aerosols ====&lt;br /&gt;
&lt;br /&gt;
The current version of &amp;lt;code&amp;gt;cdo&amp;lt;/code&amp;gt; on Adastra (&amp;lt;code&amp;gt;2.4.0&amp;lt;/code&amp;gt;) and Spirit (&amp;lt;code&amp;gt;2.3.0&amp;lt;/code&amp;gt;) contain [https://code.mpimet.mpg.de/boards/1/topics/15752 a bug] which interferes with the script interpolating aerosols. This bug is supposedly solved in version &amp;lt;code&amp;gt;2.4.1+&amp;lt;/code&amp;gt;. This bug corrupts the aerosols files, and results in a &amp;lt;code&amp;gt;hgardfou&amp;lt;/code&amp;gt; error when running the simulation.&lt;br /&gt;
&lt;br /&gt;
=== JeanZay ===&lt;br /&gt;
&lt;br /&gt;
JeanZay was the main supported cluster of the old &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. Although the new version can be ran there, it is discouraged.&lt;br /&gt;
&lt;br /&gt;
==== Slowness ====&lt;br /&gt;
&lt;br /&gt;
Compilation of the various components of the model, in particular of LMDZ and XIOS, is extremely slow on JeanZay compared to other clusters (for unknown reasons) (~15 minutes for LMDZ+rrtm). Moreover, it seems that for uninvestigated reasons, the LMDZ model is systematically recompiled on each call to &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; (expected behavior, as on other clusters: the &amp;lt;code&amp;gt;fcm&amp;lt;/code&amp;gt; system detects that it's already compiled and avoids compiling again). As a result, the whole process of '''launching a simulation is much slower'''.&lt;br /&gt;
&lt;br /&gt;
[[Category:HowTo]]&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=498</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=498"/>
				<updated>2024-09-09T13:40:32Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;lmdz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [[HowTo:_LMDZ_code_guidelines | LMDZ_code_guidelines]])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd -d 79&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmdiso -d 48x36x39&lt;br /&gt;
 All good ! for r5157/r5150=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5157/r5017=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
(XIOS n'est pas testé vs 5150 car il segfault sur 5017)&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le common &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;br /&gt;
&lt;br /&gt;
=== Common iniCOSP ===&lt;br /&gt;
&lt;br /&gt;
Le common défini dans &amp;lt;code&amp;gt;ini_COSP.h&amp;lt;/code&amp;gt;  est un peu tricky à remplacer car il a besoin de &amp;lt;code&amp;gt;klon,klev&amp;lt;/code&amp;gt; qui ne sont pas des constantes.&lt;br /&gt;
Une (bonne) manière de faire serait de faire un type dérivé. C'est d'ailleurs ce que je préconise pour remplacer les très longues listes d'arguments, mais c'est à discuter avec le reste du groupe...&lt;br /&gt;
&lt;br /&gt;
== Vitesse ==&lt;br /&gt;
&lt;br /&gt;
A titre indicatif, quelques stats. Attention à l'interprétation (variabilité interne, etc.), la quantité intéressant est le &amp;lt;code&amp;gt;min&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== r5158 v r5017 ===&lt;br /&gt;
&lt;br /&gt;
==== séquentiel ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     152.594 s ± 62.315 s | Range (min … max):   109.719 s … 263.752 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     123.119 s ± 42.065 s | Range (min … max):   89.570 s … 200.606 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     111.737 s ±  4.910 s | Range (min … max):   106.716 s … 118.421 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     92.876 s ±  2.105 s | Range (min … max):   87.766 s … 94.780 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== mpi_omp ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     119.116 s ±  4.124 s | Range (min … max):   114.514 s … 125.466 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     50.382 s ±  0.994 s | Range (min … max):   49.248 s … 52.130 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz:  &amp;lt;code&amp;gt;Time (mean ± σ):     130.779 s ±  5.543 s | Range (min … max):   123.503 s … 139.438 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     52.444 s ±  1.080 s | Range (min … max):   51.387 s … 54.530 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== r5159 ===&lt;br /&gt;
&lt;br /&gt;
This rev replaces all &amp;lt;code&amp;gt;INCLUDE &amp;quot;dimensions.h&amp;quot;,INCLUDE&amp;quot;paramet.h&amp;quot;&amp;lt;/code&amp;gt; by modules. One could think this would impact performance.&lt;br /&gt;
The bench suggests otherwise:&lt;br /&gt;
&lt;br /&gt;
Seq: &amp;lt;code&amp;gt;Time (mean ± σ):     101.333 s ± 20.405 s | Range (min … max):   91.460 s … 150.911 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Para: &amp;lt;code&amp;gt;Time (mean ± σ):     49.341 s ±  0.353 s | Range (min … max):   48.740 s … 50.028 s    10 runs&amp;lt;/code&amp;gt;&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=497</id>
		<title>LMDZ Setup</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=497"/>
				<updated>2024-09-09T10:48:45Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LMDZ_Setup is a set of scripts that allows a light automatic setup of LMDZ long chained climate simulations, including the installation of the model itself.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can only be used on the Jean-Zay computer at Idris so far.&lt;br /&gt;
&lt;br /&gt;
Coming VERY soon (summer 2024) : extension to other computing centers (&amp;quot;spirit&amp;quot;, adastra) and Linux PCs&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Documentation (in French):'''&lt;br /&gt;
[https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit LMDZ_Setup_HowTo]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''To extract LMDZ_Setup :'''&lt;br /&gt;
&lt;br /&gt;
a/ Recommended : extraction from svn repository : &lt;br /&gt;
&lt;br /&gt;
    svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&lt;br /&gt;
&lt;br /&gt;
b/ Download of the &amp;quot;tar&amp;quot; archive :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&lt;br /&gt;
 &lt;br /&gt;
c/ For those used with the old name &amp;quot;tutorial_prod.tar&amp;quot; : a link with this name still exists, pointing to LMDZ_Setup.tar :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''(Text extracted from LMDZ_Setup/README0_HowTo):''&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup consists in running '''LMDZ coupled to Orchidee''' for land surface (optional), but with '''imposed sea surface temperature'''.&lt;br /&gt;
&lt;br /&gt;
The '''basic default configuration''' makes use of the IPSL-CM6A grid configuration and tuning, and runs a multi annual simulation on &amp;quot;climatological&amp;quot;&lt;br /&gt;
amip sea surface temperature (with a mean annual cycle) using a calendar with 360 days.&lt;br /&gt;
&lt;br /&gt;
Optionally : the configuration includes the '''ability to use interannually varying SST''' and to activate '''&amp;quot;nudging&amp;quot;''' by a reanalysis.&lt;br /&gt;
In both cases, the calendar is then a real one.&lt;br /&gt;
When nudging is activated, the simulation must be run on a monthly basis, while otherwise, it can be either monthly or yearly.&lt;br /&gt;
&lt;br /&gt;
Since LMDZ_Setup automatically generates its own initial files, it can be run with '''zoom configurations''' by only changing the number of grid points (&amp;quot;resol&amp;quot; in main.sh) and the DEF/gcm.def file (see bellow).&lt;br /&gt;
&lt;br /&gt;
'''Aerosols''' can be read for the year 2000 (weighted average  over 1999-2001 cf Lurton et al 2020), and instantaneous forcing with respect to 1850 can be computed as well.&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can also run LMDZ coupled with the '''SPLA model''' (SimPLe Aerosol, activated with option aerosols=spla in setup.sh).&lt;br /&gt;
Emissions of dust and sea salt are then computed interactively.&lt;br /&gt;
For the time being, SPLA-specific input files (anthropic aerosol emissions)are only available on the grid zoomed over N Africa used by J. Escribano in his PhD thesis, and by B. Diallo and H. Senghor in subsequent work on N-African dust (file DEF/gcm.def_zNAfrica_BiJe).&lt;br /&gt;
&lt;br /&gt;
A configuration with '''isotopes''' is also available since 2023-04.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Below: new LMDZ_Setup docs ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Old documentation (French): [https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c LMDZ_Setup_HowTo]''&lt;br /&gt;
&lt;br /&gt;
== User guide ==&lt;br /&gt;
&lt;br /&gt;
 ''' /!\ WARNING''' 06/2024 - (ignore if installing a new version)&lt;br /&gt;
 The JeanZay calculator, as well as Adastra, do not allow (anymore) communication from/to $STORE for running jobs on the main computing partitions.&lt;br /&gt;
 As a result, make sure to replace $STORE by $WORK in &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt; wherever relevant.&lt;br /&gt;
&lt;br /&gt;
 '''READ comments at the top of scripts ! Often your questions are answered there.'''&lt;br /&gt;
&lt;br /&gt;
 ''Note'': &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; has been tested on Adastra and Spirit, and to a lesser extent on JeanZay (legacy support only). No guarantee is made on other platforms, although it should be easy to adapt it. It can also be ran locally - for expert use only.&lt;br /&gt;
&lt;br /&gt;
=== Downloading LMDZ_Setup ===&lt;br /&gt;
&lt;br /&gt;
 /!\ Note: below is for when the new version will replace the old one - for now, use &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup_amaury&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''(recommended)'' Using ''subversion'': &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(alternative)'' &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(deprecated)'' The old &amp;lt;code&amp;gt;tutorial_prod&amp;lt;/code&amp;gt; version: &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Structure ===&lt;br /&gt;
&lt;br /&gt;
Once you have downloaded &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;, you will find the following main files:&lt;br /&gt;
* &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;: the main script. It contains the basic settings you will modify.&lt;br /&gt;
* &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;: this script contains the internal workings of &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. It's where you can edit expert-level settings.&lt;br /&gt;
* &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;: this file contains platform-specific configuration, such as where to install the model, where to run the simulations, etc.&lt;br /&gt;
&lt;br /&gt;
=== How to run a simulation ===&lt;br /&gt;
&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;set_env&amp;lt;/code&amp;gt;, find the case corresponding to your supercomputer: &amp;lt;code&amp;gt;jean-)&amp;lt;/code&amp;gt; for JeanZay, &amp;lt;code&amp;gt;spiri)&amp;lt;/code&amp;gt; for Spirit, &amp;lt;code&amp;gt;adast)&amp;lt;/code&amp;gt; for Adastra. Edit the variables required for your use case. All the variables are documented in the last &amp;lt;code&amp;gt;*)&amp;lt;/code&amp;gt; case. In particular:&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;define_expert_options&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;DEF/*&amp;lt;/code&amp;gt;.''' Edit the &amp;lt;code&amp;gt;DEF/*.def&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt; files, such as &amp;lt;code&amp;gt;config.def&amp;lt;/code&amp;gt;, to your liking. ''The options you specify in main.sh/setup.sh don't require any adjustment here; such adjustments are automatically performed at runtime.''&lt;br /&gt;
# '''Launch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;'''.&lt;br /&gt;
&lt;br /&gt;
=== Miscellanous notes ===&lt;br /&gt;
&lt;br /&gt;
* Simulations run in a subdirectory of &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; with the same name as the &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder (if you have extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; and renamed it to &amp;lt;code&amp;gt;My_Setup&amp;lt;/code&amp;gt; then simulations will run in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/My_Setup&amp;lt;/code&amp;gt;). Each simulation is contained in its own folder, named after the simulation's name + a process number. As a result, '''you don't need to clean $SIMRUNBASEDIR before relaunching a simulation'''.&lt;br /&gt;
* If your simulation crashes, look directly in &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; for the relevant log.&lt;br /&gt;
* If you need a version of ORCHIDEE different from the one provided by default in the model (such as &amp;lt;code&amp;gt;CMIP6&amp;lt;/code&amp;gt;), a password is required - ask ''orchidee-help at listes.ipsl.fr'' if you need help.&lt;br /&gt;
&lt;br /&gt;
==== XIOS ====&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' Although XIOS is not ''required'' for ORCHIDEE &amp;gt;=2.2, not using it will disable some features.&lt;br /&gt;
Different sets of &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt; files are available in &amp;lt;code&amp;gt;LMDZ_Setup/DEF/XMLFiles*&amp;lt;/code&amp;gt;. However, only some common files (&amp;lt;code&amp;gt;histf, histday, histmth&amp;lt;/code&amp;gt;) have been adapted for &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. ''If you need other outputs, '''be sure to edit/check the relevant &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt;''''':&lt;br /&gt;
* replace the &amp;lt;code&amp;gt;_AUTO_&amp;lt;/code&amp;gt; for &amp;lt;code&amp;gt;output_level&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;enabled&amp;lt;/code&amp;gt; by actual values;&lt;br /&gt;
* use &amp;lt;code&amp;gt;compression_level=0&amp;lt;/code&amp;gt; instead of the default values (&amp;lt;code&amp;gt;2&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;4&amp;lt;/code&amp;gt;) (since &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; uses XIOS in attached mode rather than client-server mode, using non-zero compression levels would require running XIOS on 1+ dedicated MPI).&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' After installing the model, two files are automatically initialized in &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;context_lmdz.xml&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;field_def_lmdz.xml&amp;lt;/code&amp;gt;. Those files don't require user intervention, and must match the exact LMDZ revision used.&lt;br /&gt;
&lt;br /&gt;
==== Compilation ====&lt;br /&gt;
&lt;br /&gt;
When launching &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, before running the simulation, we first download and compile the required models. Although we call the compilation script every time, if the model has already been compiled before, the script should detect that and skip the actual compilation, and thus execute very quickly.&lt;br /&gt;
&lt;br /&gt;
''Note: on supported clusters, compilation is launched in jobs rather than on the login node. This speeds up the compilation.''&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' As written in the comments of &amp;lt;code&amp;gt;main.sh/setup.sh&amp;lt;/code&amp;gt;, '''if you change the &amp;lt;code&amp;gt;veget&amp;lt;/code&amp;gt; version or the &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt;, it is highly recommended to do so in a NEW clean &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder''' rather than recompiling in the same folder.&lt;br /&gt;
&lt;br /&gt;
=== Nudging ===&lt;br /&gt;
&lt;br /&gt;
Nudging is set via the &amp;lt;code&amp;gt;nudging&amp;lt;/code&amp;gt; variable in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. If activated, then after installing the model, &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; will prompt you to run &amp;lt;code&amp;gt;era2gcm_tuto.sh&amp;lt;/code&amp;gt;. This script fetches reanalysis data and puts it in a &amp;lt;code&amp;gt;GUIDE/&amp;lt;/code&amp;gt; folder.&lt;br /&gt;
Once this is done, simply set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and relaunch it.&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' On Adastra, the reanalysis files are not yet available.&lt;br /&gt;
&lt;br /&gt;
=== Aerosols ===&lt;br /&gt;
&lt;br /&gt;
 '''/!\ As written in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, it is highly recommended to install &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; in a new clean directory when changing aerosols options. Otherwise i.e. the &amp;lt;code&amp;gt;DEF/config.def&amp;lt;/code&amp;gt; may not get modified accordingly.'''&lt;br /&gt;
&lt;br /&gt;
When &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt; is set to anything other than &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, aerosols files will be downloaded in &amp;lt;code&amp;gt;LIMIT/&amp;lt;/code&amp;gt;, and will be interpolated to the horizontal grid resolution (vertical interpolation is performed at runtime by the GCM.)&lt;br /&gt;
&lt;br /&gt;
==== More detail ====&lt;br /&gt;
&lt;br /&gt;
The aerosols files used for the options &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt; are those used in CMIP6 with the LMDZORINCA configuration, from [https://www.lmd.jussieu.fr/~lmdz/pub/3DInputData/AerChem/ here].&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt;, we only use &amp;lt;code&amp;gt;aerosols1850_from_inca.nc&amp;lt;/code&amp;gt; (natural aerosols), interpolated as &amp;lt;code&amp;gt;aerosols.nat.nc&amp;lt;/code&amp;gt;&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt;, we also use &amp;lt;code&amp;gt;aerosols9999_from_inca.nc&amp;lt;/code&amp;gt; with the mean aerosols on 1995-2014, interpolated as &amp;lt;code&amp;gt;aerosols.clim.nc&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== ORCHIDEE ===&lt;br /&gt;
&lt;br /&gt;
The officially supported versions of ORCHIDEE supported by LMDZ_Setup are:&lt;br /&gt;
* the CMIP6 version (still using the two-layer hydrology channel)&lt;br /&gt;
* version 2.2 r7983&lt;br /&gt;
* version 4 (trunk) r7994 (corresponding to libIGCM's LMDZOR_6.4work configuration)&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' The relevant ORCHIDEE def file &amp;lt;code&amp;gt;DEF/orchidee.def_*&amp;lt;/code&amp;gt; gets copied as &amp;lt;code&amp;gt;DEF/orchidee.def&amp;lt;/code&amp;gt; at initialisation.&lt;br /&gt;
&lt;br /&gt;
==== Activating sechiba outputs ====&lt;br /&gt;
&lt;br /&gt;
Sechiba outputs are written to &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt;, but are deleted by &amp;lt;code&amp;gt;tmp_SIM&amp;lt;/code&amp;gt; before they're rebuilt. To counter that, remove the &amp;lt;code&amp;gt;sec*&amp;lt;/code&amp;gt; on the relevant line &amp;lt;code&amp;gt;set +e ; \rm out* sec* sta* list* rest* gcm.e aer* ; set -e&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Simple routing ====&lt;br /&gt;
&lt;br /&gt;
From orch 2.2 r7597 onwards, the &amp;quot;simple&amp;quot; routing scheme by Y. Meurdesoif can be activated.&lt;br /&gt;
&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/orchidee.def_6.*&amp;lt;/code&amp;gt;, set &amp;lt;code&amp;gt;RIVER_ROUTING=y&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;ROUTING_METHOD = simple&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;RIVER_DESC=y&amp;lt;/code&amp;gt; (''Note: &amp;lt;code&amp;gt;RIVER_DESC&amp;lt;/code&amp;gt; is automatically set to &amp;quot;n&amp;quot; after the first simulation period.)&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/XMLfilesOR7***/iodef.xml&amp;lt;/code&amp;gt;, add at the end of &amp;lt;code&amp;gt;context_orchidee.xml&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;&amp;lt;context id=&amp;quot;orchidee&amp;quot; src=&amp;quot;./context_routing_orchidee.xml&amp;quot;/&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
See also:[https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/UserGuide/RoutageSimple User Guide/Routage Simple] (French).&lt;br /&gt;
&lt;br /&gt;
=== Isotopes ===&lt;br /&gt;
&lt;br /&gt;
To activate isotopes, simply change the &amp;lt;code&amp;gt;lmd_phys&amp;lt;/code&amp;gt; parameter to &amp;lt;code&amp;gt;&amp;quot;lmdiso&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. This will automatically&lt;br /&gt;
* use &amp;lt;code&amp;gt;&amp;quot;phylmdiso&amp;quot;&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;&amp;quot;phylmd&amp;quot;&amp;lt;/code&amp;gt;;&lt;br /&gt;
* copy &amp;lt;code&amp;gt;DEF/PHYS/physiq.def_NPiso&amp;lt;/code&amp;gt; to &amp;lt;code&amp;gt;DEF/physiq.def&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: for isotopes, &amp;lt;code&amp;gt;iflag_ice_thermo&amp;lt;/code&amp;gt; is automatically set to &amp;lt;code&amp;gt;0&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;1&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
* ''How to relaunch a failed simulation ?''&lt;br /&gt;
&lt;br /&gt;
If the simulation ran for at least one successful period, simplys set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and rerun it. Otherwise, see the following question.&lt;br /&gt;
&lt;br /&gt;
* ''I have ran a simulation, but I messed up the parameters. I want to run a new clean simulation with the same name (e.g. &amp;lt;code&amp;gt;NPv6.3&amp;lt;/code&amp;gt;.)''&lt;br /&gt;
&lt;br /&gt;
Remove &amp;lt;code&amp;gt;INIT, LIMIT, NPv6.3&amp;lt;/code&amp;gt; and relaunch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; with &amp;lt;code&amp;gt;init=1&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
* ''How can I follow the state of a running simulation ?''&lt;br /&gt;
&lt;br /&gt;
Check the file &amp;lt;code&amp;gt;LMDZ_Setup/$SIM_NAME/etat&amp;lt;/code&amp;gt;. After each period (mo/yr), it gets updated like so:&lt;br /&gt;
 200001 a faire&lt;br /&gt;
 200001 OK&lt;br /&gt;
 200002 a faire&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To check if the simulation is still running, query your cluster's queue (e.g. &amp;lt;code&amp;gt;squeue --me&amp;lt;/code&amp;gt; on SLURM clusters). If nothing is running, read the next question.&lt;br /&gt;
&lt;br /&gt;
* ''How to investigate a crash ?''&lt;br /&gt;
&lt;br /&gt;
The job error log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/out*&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The simulation log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/$SIM_NAME*/listing&amp;lt;/code&amp;gt;. (''Note: to know which folder is the latest, run &amp;lt;code&amp;gt;ls -lat&amp;lt;/code&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Cluster-specific information ==&lt;br /&gt;
&lt;br /&gt;
=== Generic ===&lt;br /&gt;
&lt;br /&gt;
==== ORCH 4 (trunk) ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4 is currently not able to compile with &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;, and as a result can't be used. This has been reported to the relevant team, and hopefully should be fixed soon (06/2024).&lt;br /&gt;
&lt;br /&gt;
==== CDO &amp;amp; aerosols ====&lt;br /&gt;
&lt;br /&gt;
The current version of &amp;lt;code&amp;gt;cdo&amp;lt;/code&amp;gt; on Adastra (&amp;lt;code&amp;gt;2.4.0&amp;lt;/code&amp;gt;) and Spirit (&amp;lt;code&amp;gt;2.3.0&amp;lt;/code&amp;gt;) contain [https://code.mpimet.mpg.de/boards/1/topics/15752 a bug] which interferes with the script interpolating aerosols. This bug is supposedly solved in version &amp;lt;code&amp;gt;2.4.1+&amp;lt;/code&amp;gt;. This bug corrupts the aerosols files, and results in a &amp;lt;code&amp;gt;hgardfou&amp;lt;/code&amp;gt; error when running the simulation.&lt;br /&gt;
&lt;br /&gt;
=== JeanZay ===&lt;br /&gt;
&lt;br /&gt;
JeanZay was the main supported cluster of the old &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. Although the new version can be ran there, it is discouraged.&lt;br /&gt;
&lt;br /&gt;
==== Slowness ====&lt;br /&gt;
&lt;br /&gt;
Compilation of the various components of the model, in particular of LMDZ and XIOS, is extremely slow on JeanZay compared to other clusters (for unknown reasons) (~15 minutes for LMDZ+rrtm). Moreover, it seems that for uninvestigated reasons, the LMDZ model is systematically recompiled on each call to &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; (expected behavior, as on other clusters: the &amp;lt;code&amp;gt;fcm&amp;lt;/code&amp;gt; system detects that it's already compiled and avoids compiling again). As a result, the whole process of '''launching a simulation is much slower'''.&lt;br /&gt;
&lt;br /&gt;
[[Category:HowTo]]&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=496</id>
		<title>LMDZ Setup</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=496"/>
				<updated>2024-09-09T09:38:11Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : remove obsolete root_dir comment&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LMDZ_Setup is a set of scripts that allows a light automatic setup of LMDZ long chained climate simulations, including the installation of the model itself.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can only be used on the Jean-Zay computer at Idris so far.&lt;br /&gt;
&lt;br /&gt;
Coming VERY soon (summer 2024) : extension to other computing centers (&amp;quot;spirit&amp;quot;, adastra) and Linux PCs&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Documentation (in French):'''&lt;br /&gt;
[https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit LMDZ_Setup_HowTo]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''To extract LMDZ_Setup :'''&lt;br /&gt;
&lt;br /&gt;
a/ Recommended : extraction from svn repository : &lt;br /&gt;
&lt;br /&gt;
    svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&lt;br /&gt;
&lt;br /&gt;
b/ Download of the &amp;quot;tar&amp;quot; archive :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&lt;br /&gt;
 &lt;br /&gt;
c/ For those used with the old name &amp;quot;tutorial_prod.tar&amp;quot; : a link with this name still exists, pointing to LMDZ_Setup.tar :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''(Text extracted from LMDZ_Setup/README0_HowTo):''&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup consists in running '''LMDZ coupled to Orchidee''' for land surface (optional), but with '''imposed sea surface temperature'''.&lt;br /&gt;
&lt;br /&gt;
The '''basic default configuration''' makes use of the IPSL-CM6A grid configuration and tuning, and runs a multi annual simulation on &amp;quot;climatological&amp;quot;&lt;br /&gt;
amip sea surface temperature (with a mean annual cycle) using a calendar with 360 days.&lt;br /&gt;
&lt;br /&gt;
Optionally : the configuration includes the '''ability to use interannually varying SST''' and to activate '''&amp;quot;nudging&amp;quot;''' by a reanalysis.&lt;br /&gt;
In both cases, the calendar is then a real one.&lt;br /&gt;
When nudging is activated, the simulation must be run on a monthly basis, while otherwise, it can be either monthly or yearly.&lt;br /&gt;
&lt;br /&gt;
Since LMDZ_Setup automatically generates its own initial files, it can be run with '''zoom configurations''' by only changing the number of grid points (&amp;quot;resol&amp;quot; in main.sh) and the DEF/gcm.def file (see bellow).&lt;br /&gt;
&lt;br /&gt;
'''Aerosols''' can be read for the year 2000 (weighted average  over 1999-2001 cf Lurton et al 2020), and instantaneous forcing with respect to 1850 can be computed as well.&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can also run LMDZ coupled with the '''SPLA model''' (SimPLe Aerosol, activated with option aerosols=spla in setup.sh).&lt;br /&gt;
Emissions of dust and sea salt are then computed interactively.&lt;br /&gt;
For the time being, SPLA-specific input files (anthropic aerosol emissions)are only available on the grid zoomed over N Africa used by J. Escribano in his PhD thesis, and by B. Diallo and H. Senghor in subsequent work on N-African dust (file DEF/gcm.def_zNAfrica_BiJe).&lt;br /&gt;
&lt;br /&gt;
A configuration with '''isotopes''' is also available since 2023-04.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Below: new LMDZ_Setup docs ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Old documentation (French): [https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c LMDZ_Setup_HowTo]''&lt;br /&gt;
&lt;br /&gt;
== User guide ==&lt;br /&gt;
&lt;br /&gt;
 ''' /!\ WARNING''' 06/2024 - (ignore if installing a new version)&lt;br /&gt;
 The JeanZay calculator, as well as Adastra, do not allow (anymore) communication from/to $STORE for running jobs on the main computing partitions.&lt;br /&gt;
 As a result, make sure to replace $STORE by $WORK in &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt; wherever relevant.&lt;br /&gt;
&lt;br /&gt;
 '''READ comments at the top of scripts ! Often your questions are answered there.'''&lt;br /&gt;
&lt;br /&gt;
 ''Note'': &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; has been tested on Adastra and Spirit, and to a lesser extent on JeanZay (legacy support only). No guarantee is made on other platforms, although it should be easy to adapt it. It can also be ran locally - for expert use only.&lt;br /&gt;
&lt;br /&gt;
=== Downloading LMDZ_Setup ===&lt;br /&gt;
&lt;br /&gt;
* ''(recommended)'' Using ''subversion'': &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(alternative)'' &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(deprecated)'' The old &amp;lt;code&amp;gt;tutorial_prod&amp;lt;/code&amp;gt; version: &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Structure ===&lt;br /&gt;
&lt;br /&gt;
Once you have downloaded &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;, you will find the following main files:&lt;br /&gt;
* &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;: the main script. It contains the basic settings you will modify.&lt;br /&gt;
* &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;: this script contains the internal workings of &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. It's where you can edit expert-level settings.&lt;br /&gt;
* &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;: this file contains platform-specific configuration, such as where to install the model, where to run the simulations, etc.&lt;br /&gt;
&lt;br /&gt;
=== How to run a simulation ===&lt;br /&gt;
&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;set_env&amp;lt;/code&amp;gt;, find the case corresponding to your supercomputer: &amp;lt;code&amp;gt;jean-)&amp;lt;/code&amp;gt; for JeanZay, &amp;lt;code&amp;gt;spiri)&amp;lt;/code&amp;gt; for Spirit, &amp;lt;code&amp;gt;adast)&amp;lt;/code&amp;gt; for Adastra. Edit the variables required for your use case. All the variables are documented in the last &amp;lt;code&amp;gt;*)&amp;lt;/code&amp;gt; case. In particular:&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;define_expert_options&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;DEF/*&amp;lt;/code&amp;gt;.''' Edit the &amp;lt;code&amp;gt;DEF/*.def&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt; files, such as &amp;lt;code&amp;gt;config.def&amp;lt;/code&amp;gt;, to your liking. ''The options you specify in main.sh/setup.sh don't require any adjustment here; such adjustments are automatically performed at runtime.''&lt;br /&gt;
# '''Launch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;'''.&lt;br /&gt;
&lt;br /&gt;
=== Miscellanous notes ===&lt;br /&gt;
&lt;br /&gt;
* Simulations run in a subdirectory of &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; with the same name as the &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder (if you have extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; and renamed it to &amp;lt;code&amp;gt;My_Setup&amp;lt;/code&amp;gt; then simulations will run in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/My_Setup&amp;lt;/code&amp;gt;). Each simulation is contained in its own folder, named after the simulation's name + a process number. As a result, '''you don't need to clean $SIMRUNBASEDIR before relaunching a simulation'''.&lt;br /&gt;
* If your simulation crashes, look directly in &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; for the relevant log.&lt;br /&gt;
* If you need a version of ORCHIDEE different from the one provided by default in the model (such as &amp;lt;code&amp;gt;CMIP6&amp;lt;/code&amp;gt;), a password is required - ask ''orchidee-help at listes.ipsl.fr'' if you need help.&lt;br /&gt;
&lt;br /&gt;
==== XIOS ====&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' Although XIOS is not ''required'' for ORCHIDEE &amp;gt;=2.2, not using it will disable some features.&lt;br /&gt;
Different sets of &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt; files are available in &amp;lt;code&amp;gt;LMDZ_Setup/DEF/XMLFiles*&amp;lt;/code&amp;gt;. However, only some common files (&amp;lt;code&amp;gt;histf, histday, histmth&amp;lt;/code&amp;gt;) have been adapted for &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. ''If you need other outputs, '''be sure to edit/check the relevant &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt;''''':&lt;br /&gt;
* replace the &amp;lt;code&amp;gt;_AUTO_&amp;lt;/code&amp;gt; for &amp;lt;code&amp;gt;output_level&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;enabled&amp;lt;/code&amp;gt; by actual values;&lt;br /&gt;
* use &amp;lt;code&amp;gt;compression_level=0&amp;lt;/code&amp;gt; instead of the default values (&amp;lt;code&amp;gt;2&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;4&amp;lt;/code&amp;gt;) (since &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; uses XIOS in attached mode rather than client-server mode, using non-zero compression levels would require running XIOS on 1+ dedicated MPI).&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' After installing the model, two files are automatically initialized in &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;context_lmdz.xml&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;field_def_lmdz.xml&amp;lt;/code&amp;gt;. Those files don't require user intervention, and must match the exact LMDZ revision used.&lt;br /&gt;
&lt;br /&gt;
==== Compilation ====&lt;br /&gt;
&lt;br /&gt;
When launching &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, before running the simulation, we first download and compile the required models. Although we call the compilation script every time, if the model has already been compiled before, the script should detect that and skip the actual compilation, and thus execute very quickly.&lt;br /&gt;
&lt;br /&gt;
''Note: on supported clusters, compilation is launched in jobs rather than on the login node. This speeds up the compilation.''&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' As written in the comments of &amp;lt;code&amp;gt;main.sh/setup.sh&amp;lt;/code&amp;gt;, '''if you change the &amp;lt;code&amp;gt;veget&amp;lt;/code&amp;gt; version or the &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt;, it is highly recommended to do so in a NEW clean &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder''' rather than recompiling in the same folder.&lt;br /&gt;
&lt;br /&gt;
=== Nudging ===&lt;br /&gt;
&lt;br /&gt;
Nudging is set via the &amp;lt;code&amp;gt;nudging&amp;lt;/code&amp;gt; variable in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. If activated, then after installing the model, &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; will prompt you to run &amp;lt;code&amp;gt;era2gcm_tuto.sh&amp;lt;/code&amp;gt;. This script fetches reanalysis data and puts it in a &amp;lt;code&amp;gt;GUIDE/&amp;lt;/code&amp;gt; folder.&lt;br /&gt;
Once this is done, simply set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and relaunch it.&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' On Adastra, the reanalysis files are not yet available.&lt;br /&gt;
&lt;br /&gt;
=== Aerosols ===&lt;br /&gt;
&lt;br /&gt;
 '''/!\ As written in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, it is highly recommended to install &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; in a new clean directory when changing aerosols options. Otherwise i.e. the &amp;lt;code&amp;gt;DEF/config.def&amp;lt;/code&amp;gt; may not get modified accordingly.'''&lt;br /&gt;
&lt;br /&gt;
When &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt; is set to anything other than &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, aerosols files will be downloaded in &amp;lt;code&amp;gt;LIMIT/&amp;lt;/code&amp;gt;, and will be interpolated to the horizontal grid resolution (vertical interpolation is performed at runtime by the GCM.)&lt;br /&gt;
&lt;br /&gt;
==== More detail ====&lt;br /&gt;
&lt;br /&gt;
The aerosols files used for the options &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt; are those used in CMIP6 with the LMDZORINCA configuration, from [https://www.lmd.jussieu.fr/~lmdz/pub/3DInputData/AerChem/ here].&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt;, we only use &amp;lt;code&amp;gt;aerosols1850_from_inca.nc&amp;lt;/code&amp;gt; (natural aerosols), interpolated as &amp;lt;code&amp;gt;aerosols.nat.nc&amp;lt;/code&amp;gt;&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt;, we also use &amp;lt;code&amp;gt;aerosols9999_from_inca.nc&amp;lt;/code&amp;gt; with the mean aerosols on 1995-2014, interpolated as &amp;lt;code&amp;gt;aerosols.clim.nc&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== ORCHIDEE ===&lt;br /&gt;
&lt;br /&gt;
The officially supported versions of ORCHIDEE supported by LMDZ_Setup are:&lt;br /&gt;
* the CMIP6 version (still using the two-layer hydrology channel)&lt;br /&gt;
* version 2.2 r7983&lt;br /&gt;
* version 4 (trunk) r7994 (corresponding to libIGCM's LMDZOR_6.4work configuration)&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' The relevant ORCHIDEE def file &amp;lt;code&amp;gt;DEF/orchidee.def_*&amp;lt;/code&amp;gt; gets copied as &amp;lt;code&amp;gt;DEF/orchidee.def&amp;lt;/code&amp;gt; at initialisation.&lt;br /&gt;
&lt;br /&gt;
==== Activating sechiba outputs ====&lt;br /&gt;
&lt;br /&gt;
Sechiba outputs are written to &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt;, but are deleted by &amp;lt;code&amp;gt;tmp_SIM&amp;lt;/code&amp;gt; before they're rebuilt. To counter that, remove the &amp;lt;code&amp;gt;sec*&amp;lt;/code&amp;gt; on the relevant line &amp;lt;code&amp;gt;set +e ; \rm out* sec* sta* list* rest* gcm.e aer* ; set -e&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Simple routing ====&lt;br /&gt;
&lt;br /&gt;
From orch 2.2 r7597 onwards, the &amp;quot;simple&amp;quot; routing scheme by Y. Meurdesoif can be activated.&lt;br /&gt;
&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/orchidee.def_6.*&amp;lt;/code&amp;gt;, set &amp;lt;code&amp;gt;RIVER_ROUTING=y&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;ROUTING_METHOD = simple&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;RIVER_DESC=y&amp;lt;/code&amp;gt; (''Note: &amp;lt;code&amp;gt;RIVER_DESC&amp;lt;/code&amp;gt; is automatically set to &amp;quot;n&amp;quot; after the first simulation period.)&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/XMLfilesOR7***/iodef.xml&amp;lt;/code&amp;gt;, add at the end of &amp;lt;code&amp;gt;context_orchidee.xml&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;&amp;lt;context id=&amp;quot;orchidee&amp;quot; src=&amp;quot;./context_routing_orchidee.xml&amp;quot;/&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
See also:[https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/UserGuide/RoutageSimple User Guide/Routage Simple] (French).&lt;br /&gt;
&lt;br /&gt;
=== Isotopes ===&lt;br /&gt;
&lt;br /&gt;
To activate isotopes, simply change the &amp;lt;code&amp;gt;lmd_phys&amp;lt;/code&amp;gt; parameter to &amp;lt;code&amp;gt;&amp;quot;lmdiso&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. This will automatically&lt;br /&gt;
* use &amp;lt;code&amp;gt;&amp;quot;phylmdiso&amp;quot;&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;&amp;quot;phylmd&amp;quot;&amp;lt;/code&amp;gt;;&lt;br /&gt;
* copy &amp;lt;code&amp;gt;DEF/PHYS/physiq.def_NPiso&amp;lt;/code&amp;gt; to &amp;lt;code&amp;gt;DEF/physiq.def&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: for isotopes, &amp;lt;code&amp;gt;iflag_ice_thermo&amp;lt;/code&amp;gt; is automatically set to &amp;lt;code&amp;gt;0&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;1&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
* ''How to relaunch a failed simulation ?''&lt;br /&gt;
&lt;br /&gt;
If the simulation ran for at least one successful period, simplys set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and rerun it. Otherwise, see the following question.&lt;br /&gt;
&lt;br /&gt;
* ''I have ran a simulation, but I messed up the parameters. I want to run a new clean simulation with the same name (e.g. &amp;lt;code&amp;gt;NPv6.3&amp;lt;/code&amp;gt;.)''&lt;br /&gt;
&lt;br /&gt;
Remove &amp;lt;code&amp;gt;INIT, LIMIT, NPv6.3&amp;lt;/code&amp;gt; and relaunch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; with &amp;lt;code&amp;gt;init=1&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
* ''How can I follow the state of a running simulation ?''&lt;br /&gt;
&lt;br /&gt;
Check the file &amp;lt;code&amp;gt;LMDZ_Setup/$SIM_NAME/etat&amp;lt;/code&amp;gt;. After each period (mo/yr), it gets updated like so:&lt;br /&gt;
 200001 a faire&lt;br /&gt;
 200001 OK&lt;br /&gt;
 200002 a faire&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To check if the simulation is still running, query your cluster's queue (e.g. &amp;lt;code&amp;gt;squeue --me&amp;lt;/code&amp;gt; on SLURM clusters). If nothing is running, read the next question.&lt;br /&gt;
&lt;br /&gt;
* ''How to investigate a crash ?''&lt;br /&gt;
&lt;br /&gt;
The job error log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/out*&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The simulation log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/$SIM_NAME*/listing&amp;lt;/code&amp;gt;. (''Note: to know which folder is the latest, run &amp;lt;code&amp;gt;ls -lat&amp;lt;/code&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Cluster-specific information ==&lt;br /&gt;
&lt;br /&gt;
=== Generic ===&lt;br /&gt;
&lt;br /&gt;
==== ORCH 4 (trunk) ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4 is currently not able to compile with &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;, and as a result can't be used. This has been reported to the relevant team, and hopefully should be fixed soon (06/2024).&lt;br /&gt;
&lt;br /&gt;
==== CDO &amp;amp; aerosols ====&lt;br /&gt;
&lt;br /&gt;
The current version of &amp;lt;code&amp;gt;cdo&amp;lt;/code&amp;gt; on Adastra (&amp;lt;code&amp;gt;2.4.0&amp;lt;/code&amp;gt;) and Spirit (&amp;lt;code&amp;gt;2.3.0&amp;lt;/code&amp;gt;) contain [https://code.mpimet.mpg.de/boards/1/topics/15752 a bug] which interferes with the script interpolating aerosols. This bug is supposedly solved in version &amp;lt;code&amp;gt;2.4.1+&amp;lt;/code&amp;gt;. This bug corrupts the aerosols files, and results in a &amp;lt;code&amp;gt;hgardfou&amp;lt;/code&amp;gt; error when running the simulation.&lt;br /&gt;
&lt;br /&gt;
=== JeanZay ===&lt;br /&gt;
&lt;br /&gt;
JeanZay was the main supported cluster of the old &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. Although the new version can be ran there, it is discouraged.&lt;br /&gt;
&lt;br /&gt;
==== Slowness ====&lt;br /&gt;
&lt;br /&gt;
Compilation of the various components of the model, in particular of LMDZ and XIOS, is extremely slow on JeanZay compared to other clusters (for unknown reasons) (~15 minutes for LMDZ+rrtm). Moreover, it seems that for uninvestigated reasons, the LMDZ model is systematically recompiled on each call to &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; (expected behavior, as on other clusters: the &amp;lt;code&amp;gt;fcm&amp;lt;/code&amp;gt; system detects that it's already compiled and avoids compiling again). As a result, the whole process of '''launching a simulation is much slower'''.&lt;br /&gt;
&lt;br /&gt;
[[Category:HowTo]]&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=495</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=495"/>
				<updated>2024-08-03T07:37:33Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;ldmz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [[HowTo:_LMDZ_code_guidelines | LMDZ_code_guidelines]])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd -d 79&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmdiso -d 48x36x39&lt;br /&gt;
 All good ! for r5157/r5150=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5157/r5017=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
(XIOS n'est pas testé vs 5150 car il segfault sur 5017)&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le common &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;br /&gt;
&lt;br /&gt;
=== Common iniCOSP ===&lt;br /&gt;
&lt;br /&gt;
Le common défini dans &amp;lt;code&amp;gt;ini_COSP.h&amp;lt;/code&amp;gt;  est un peu tricky à remplacer car il a besoin de &amp;lt;code&amp;gt;klon,klev&amp;lt;/code&amp;gt; qui ne sont pas des constantes.&lt;br /&gt;
Une (bonne) manière de faire serait de faire un type dérivé. C'est d'ailleurs ce que je préconise pour remplacer les très longues listes d'arguments, mais c'est à discuter avec le reste du groupe...&lt;br /&gt;
&lt;br /&gt;
== Vitesse ==&lt;br /&gt;
&lt;br /&gt;
A titre indicatif, quelques stats. Attention à l'interprétation (variabilité interne, etc.), la quantité intéressant est le &amp;lt;code&amp;gt;min&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== r5158 v r5017 ===&lt;br /&gt;
&lt;br /&gt;
==== séquentiel ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     152.594 s ± 62.315 s | Range (min … max):   109.719 s … 263.752 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     123.119 s ± 42.065 s | Range (min … max):   89.570 s … 200.606 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     111.737 s ±  4.910 s | Range (min … max):   106.716 s … 118.421 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     92.876 s ±  2.105 s | Range (min … max):   87.766 s … 94.780 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== mpi_omp ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     119.116 s ±  4.124 s | Range (min … max):   114.514 s … 125.466 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     50.382 s ±  0.994 s | Range (min … max):   49.248 s … 52.130 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz:  &amp;lt;code&amp;gt;Time (mean ± σ):     130.779 s ±  5.543 s | Range (min … max):   123.503 s … 139.438 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     52.444 s ±  1.080 s | Range (min … max):   51.387 s … 54.530 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== r5159 ===&lt;br /&gt;
&lt;br /&gt;
This rev replaces all &amp;lt;code&amp;gt;INCLUDE &amp;quot;dimensions.h&amp;quot;,INCLUDE&amp;quot;paramet.h&amp;quot;&amp;lt;/code&amp;gt; by modules. One could think this would impact performance.&lt;br /&gt;
The bench suggests otherwise:&lt;br /&gt;
&lt;br /&gt;
Seq: &amp;lt;code&amp;gt;Time (mean ± σ):     101.333 s ± 20.405 s | Range (min … max):   91.460 s … 150.911 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Para: &amp;lt;code&amp;gt;Time (mean ± σ):     49.341 s ±  0.353 s | Range (min … max):   48.740 s … 50.028 s    10 runs&amp;lt;/code&amp;gt;&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=494</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=494"/>
				<updated>2024-08-02T17:16:33Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;ldmz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [[HowTo:_LMDZ_code_guidelines | LMDZ_code_guidelines]])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd -d 79&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmdiso -d 48x36x39&lt;br /&gt;
 All good ! for r5157/r5150=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5157/r5017=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
(XIOS n'est pas testé vs 5150 car il segfault sur 5017)&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le common &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;br /&gt;
&lt;br /&gt;
=== Common iniCOSP ===&lt;br /&gt;
&lt;br /&gt;
Le common défini dans &amp;lt;code&amp;gt;ini_COSP.h&amp;lt;/code&amp;gt;  est un peu tricky à remplacer car il a besoin de &amp;lt;code&amp;gt;klon,klev&amp;lt;/code&amp;gt; qui ne sont pas des constantes.&lt;br /&gt;
Une (bonne) manière de faire serait de faire un type dérivé. C'est d'ailleurs ce que je préconise pour remplacer les très longues listes d'arguments, mais c'est à discuter avec le reste du groupe...&lt;br /&gt;
&lt;br /&gt;
== Vitesse ==&lt;br /&gt;
&lt;br /&gt;
A titre indicatif, quelques stats. Attention à l'interprétation (variabilité interne, etc.), la quantité intéressant est le &amp;lt;code&amp;gt;min&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== r5158 v r5017 ===&lt;br /&gt;
&lt;br /&gt;
==== séquentiel ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     152.594 s ± 62.315 s | Range (min … max):   109.719 s … 263.752 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     123.119 s ± 42.065 s | Range (min … max):   89.570 s … 200.606 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     111.737 s ±  4.910 s | Range (min … max):   106.716 s … 118.421 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     92.876 s ±  2.105 s | Range (min … max):   87.766 s … 94.780 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== mpi_omp ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     119.116 s ±  4.124 s | Range (min … max):   114.514 s … 125.466 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     50.382 s ±  0.994 s | Range (min … max):   49.248 s … 52.130 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz:  &amp;lt;code&amp;gt;Time (mean ± σ):     130.779 s ±  5.543 s | Range (min … max):   123.503 s … 139.438 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     52.444 s ±  1.080 s | Range (min … max):   51.387 s … 54.530 s    10 runs&amp;lt;/code&amp;gt;&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=493</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=493"/>
				<updated>2024-08-02T15:49:47Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;ldmz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [https://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php/HowTo:_LMDZ_code_guidelines])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd -d 79&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmdiso -d 48x36x39&lt;br /&gt;
 All good ! for r5157/r5150=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5157/r5017=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
(XIOS n'est pas testé vs 5150 car il segfault sur 5017)&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le common &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;br /&gt;
&lt;br /&gt;
=== Common iniCOSP ===&lt;br /&gt;
&lt;br /&gt;
Le common défini dans &amp;lt;code&amp;gt;ini_COSP.h&amp;lt;/code&amp;gt;  est un peu tricky à remplacer car il a besoin de &amp;lt;code&amp;gt;klon,klev&amp;lt;/code&amp;gt; qui ne sont pas des constantes.&lt;br /&gt;
Une (bonne) manière de faire serait de faire un type dérivé. C'est d'ailleurs ce que je préconise pour remplacer les très longues listes d'arguments, mais c'est à discuter avec le reste du groupe...&lt;br /&gt;
&lt;br /&gt;
== Vitesse ==&lt;br /&gt;
&lt;br /&gt;
A titre indicatif, quelques stats. Attention à l'interprétation (variabilité interne, etc.).&lt;br /&gt;
&lt;br /&gt;
=== r5158 v r5017 ===&lt;br /&gt;
&lt;br /&gt;
==== séquentiel ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     152.594 s ± 62.315 s | Range (min … max):   109.719 s … 263.752 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     123.119 s ± 42.065 s | Range (min … max):   89.570 s … 200.606 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz: &amp;lt;code&amp;gt;Time (mean ± σ):     111.737 s ±  4.910 s | Range (min … max):   106.716 s … 118.421 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
* bench: &amp;lt;code&amp;gt;Time (mean ± σ):     92.876 s ±  2.105 s | Range (min … max):   87.766 s … 94.780 s    10 runs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== mpi_omp ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: 80s&lt;br /&gt;
* bench: 55s&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz: 126s&lt;br /&gt;
* bench: 46-s&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=492</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=492"/>
				<updated>2024-08-02T13:03:41Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;ldmz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [https://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php/HowTo:_LMDZ_code_guidelines])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd -d 79&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmdiso -d 48x36x39&lt;br /&gt;
 All good ! for r5157/r5150=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5157/r5017=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
(XIOS n'est pas testé vs 5150 car il segfault sur 5017)&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le common &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;br /&gt;
&lt;br /&gt;
=== Common iniCOSP ===&lt;br /&gt;
&lt;br /&gt;
Le common défini dans &amp;lt;code&amp;gt;ini_COSP.h&amp;lt;/code&amp;gt;  est un peu tricky à remplacer car il a besoin de &amp;lt;code&amp;gt;klon,klev&amp;lt;/code&amp;gt; qui ne sont pas des constantes.&lt;br /&gt;
Une (bonne) manière de faire serait de faire un type dérivé. C'est d'ailleurs ce que je préconise pour remplacer les très longues listes d'arguments, mais c'est à discuter avec le reste du groupe...&lt;br /&gt;
&lt;br /&gt;
== Vitesse ==&lt;br /&gt;
&lt;br /&gt;
A titre indicatif, quelques stats. Attention à l'interprétation (variabilité interne, etc.).&lt;br /&gt;
&lt;br /&gt;
=== r5158 v r5017 ===&lt;br /&gt;
&lt;br /&gt;
==== séquentiel ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: 100s&lt;br /&gt;
* bench: 86s&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz: 115s&lt;br /&gt;
* bench: 100s&lt;br /&gt;
&lt;br /&gt;
==== mpi_omp ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: 80s&lt;br /&gt;
* bench: 55s&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz: 126s&lt;br /&gt;
* bench: 47s&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=491</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=491"/>
				<updated>2024-08-02T12:54:17Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;ldmz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [https://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php/HowTo:_LMDZ_code_guidelines])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd -d 79&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmdiso -d 48x36x39&lt;br /&gt;
 All good ! for r5157/r5150=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5157/r5017=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
(XIOS n'est pas testé vs 5150 car il segfault sur 5017)&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le common &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;br /&gt;
&lt;br /&gt;
=== Common iniCOSP ===&lt;br /&gt;
&lt;br /&gt;
Le common défini dans &amp;lt;code&amp;gt;ini_COSP.h&amp;lt;/code&amp;gt;  est un peu tricky à remplacer car il a besoin de &amp;lt;code&amp;gt;klon,klev&amp;lt;/code&amp;gt; qui ne sont pas des constantes.&lt;br /&gt;
Une (bonne) manière de faire serait de faire un type dérivé. C'est d'ailleurs ce que je préconise pour remplacer les très longues listes d'arguments, mais c'est à discuter avec le reste du groupe...&lt;br /&gt;
&lt;br /&gt;
== Vitesse ==&lt;br /&gt;
&lt;br /&gt;
A titre indicatif, quelques stats. Attention à l'interprétation (variabilité interne, etc.).&lt;br /&gt;
&lt;br /&gt;
=== r5158 v r5017 ===&lt;br /&gt;
&lt;br /&gt;
==== séquentiel ====&lt;br /&gt;
&lt;br /&gt;
r5017:&lt;br /&gt;
* compil lmdz: 100s&lt;br /&gt;
* bench: 86s&lt;br /&gt;
&lt;br /&gt;
r5158&lt;br /&gt;
* compil lmdz: 115s&lt;br /&gt;
* bench: 100s&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=490</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=490"/>
				<updated>2024-08-02T11:17:51Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;ldmz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [https://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php/HowTo:_LMDZ_code_guidelines])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd -d 79&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmdiso -d 48x36x39&lt;br /&gt;
 All good ! for r5157/r5150=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5157/r5017=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
(XIOS n'est pas testé vs 5150 car il segfault sur 5017)&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le common &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;br /&gt;
&lt;br /&gt;
=== Common iniCOSP ===&lt;br /&gt;
&lt;br /&gt;
Le common défini dans &amp;lt;code&amp;gt;ini_COSP.h&amp;lt;/code&amp;gt;  est un peu tricky à remplacer car il a besoin de &amp;lt;code&amp;gt;klon,klev&amp;lt;/code&amp;gt; qui ne sont pas des constantes.&lt;br /&gt;
Une (bonne) manière de faire serait de faire un type dérivé. C'est d'ailleurs ce que je préconise pour remplacer les très longues listes d'arguments, mais c'est à discuter avec le reste du groupe...&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=489</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=489"/>
				<updated>2024-08-02T11:17:36Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;ldmz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [https://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php/HowTo:_LMDZ_code_guidelines])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd -d 79&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmdiso -d 48x36x39&lt;br /&gt;
 All good ! for r5157/r5150=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5157/r5017=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
(XIOS n'est pas testé vs 5150 car il segfault sur 5017)&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le common &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;br /&gt;
&lt;br /&gt;
=== Common iniCOSP ===&lt;br /&gt;
&lt;br /&gt;
Le common défini dans &amp;lt;code&amp;gt;ini_COSP.h&amp;lt;/code&amp;gt;  est un peu tricky à remplacer car il a besoin de &amp;lt;code&amp;gt;klon,klev&amp;lt;/code&amp;gt; qui ne sont pas des constantes.&lt;br /&gt;
Une (bonne)à manière de faire serait de faire un type dérivé. C'est d'ailleurs ce que je préconise pour remplacer les très longues listes d'arguments, mais c'est à discuter avec le reste du groupe...&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=488</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=488"/>
				<updated>2024-08-02T10:50:07Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;ldmz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [https://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php/HowTo:_LMDZ_code_guidelines])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-debug -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmd -d 79&lt;br /&gt;
 All good ! for r5155/r5017=-rad oldrad -parallel none -veget none -compilephysiq lmdiso -d 48x36x39&lt;br /&gt;
 All good ! for r5157/r5150=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
 All good ! for r5157/r5017=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
(XIOS n'est pas testé vs 5150 car il segfault sur 5017)&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le commun &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=487</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=487"/>
				<updated>2024-08-01T19:59:09Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;ldmz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [https://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php/HowTo:_LMDZ_code_guidelines])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5157=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
XIOS n'est pas testé vs 5017, car il segfault sur trunk à cette révision, mais on a bien convergence avec r5150:&lt;br /&gt;
  All good ! for r5150/r5157=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
''&amp;lt;TODO: Debug segfault de même avec une lib ompi moderne [-&amp;gt; vérif à la main]&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le commun &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=486</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=486"/>
				<updated>2024-08-01T19:05:06Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;ldmz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [https://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php/HowTo:_LMDZ_code_guidelines])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5150/r5057=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
XIOS n'est pas testé vs 5017, car il segfault sur trunk à cette révision, mais on a bien convergence avec r5150:&lt;br /&gt;
  All good ! for r5150/r5055=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''&amp;lt;TODO: Debug segfault de même avec une lib ompi moderne [-&amp;gt; vérif à la main]&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le commun &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=485</id>
		<title>Branche Amaury dev</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Branche_Amaury_dev&amp;diff=485"/>
				<updated>2024-08-01T19:04:22Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : Page créée avec «   Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'... »&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  Ceci est une page temporaire qui commente certains aspects de la branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] en attendant qu'elle soit mergée&lt;br /&gt;
&lt;br /&gt;
La branche [https://trac.lmd.jussieu.fr/LMDZ/browser/LMDZ6/branches/Amaury_dev Amaury_dev] vise à moderniser une grande partie du code de LMDZ, en partant de r5056.&lt;br /&gt;
&lt;br /&gt;
Les grands changements (r5155) sont :&lt;br /&gt;
* Le remplacement de nombreux &amp;lt;code&amp;gt;INCLUDE *.h&amp;lt;/code&amp;gt; par des modules, en particulier cela remplace un certain nombre de &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt;&lt;br /&gt;
* La conversion de tous les fichiers fixed-form &amp;lt;code&amp;gt;*.F&amp;lt;/code&amp;gt; en free-form &amp;lt;code&amp;gt;*.[fF]90&amp;lt;/code&amp;gt;&lt;br /&gt;
* Le remplacement d'un certain nombre d'utilisations de clés CPP par des booléens Fortran, et la création de wrappers associés au besoin&lt;br /&gt;
* Le remplacement des appels à la librairie netcdf-fortran77 par la librairie netcdf-fortran90 (ce qui vire les &amp;lt;code&amp;gt;INCLUDE &amp;quot;netcdf.h&amp;quot;&amp;lt;/code&amp;gt;)&lt;br /&gt;
* La suppression / déplacement dans &amp;lt;code&amp;gt;obsolete&amp;lt;/code&amp;gt; de code très ancien et inutilisé&lt;br /&gt;
* La correction de la plupart des warnings de compilation &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;&lt;br /&gt;
* La mise à jour des sources FCM à la dernière version (mais sans passer à FCM2, on utilise encore les options legacy)&lt;br /&gt;
* La correction de bugs mineurs (e.g. type casting) et majeurs (e.g. mauvais indices de boucles, appels erronés) trouvés lors du nettoyage&lt;br /&gt;
* Le renommage des modules en &amp;lt;code&amp;gt;ldmz_*&amp;lt;/code&amp;gt; pour éviter les collisions de namespace&lt;br /&gt;
* L'harmonisation de la syntaxe Fortran (cf [https://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php/HowTo:_LMDZ_code_guidelines])&lt;br /&gt;
* Un linting de la plupart des fichiers&lt;br /&gt;
&lt;br /&gt;
== Convergence ==&lt;br /&gt;
&lt;br /&gt;
La version r5157 (=r5155 + hotfix cosp) est quasiment convergée partout, et peut servir de référence :&lt;br /&gt;
  &lt;br /&gt;
  # Tests auto de convergence&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad oldrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad rrtm -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel none -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-rad ecrad -parallel mpi_omp -veget CMIP6 -compilephysiq lmd&lt;br /&gt;
  All good ! for r5017/r5155=-debug -rad oldrad -parallel none -veget none -compilephysiq lmd&lt;br /&gt;
  All good ! for r5150/r5057=-cosp v1 -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
XIOS n'est pas testé vs 5017, car il segfault sur trunk à cette révision, mais on a bien convergence avec r5150:&lt;br /&gt;
  All good ! for r5150/r5055=-xios -rad oldrad -parallel mpi_omp -veget none -compilephysiq lmd&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''&amp;lt;TODO: Debug segfault de même avec une lib ompi moderne [-&amp;gt; vérif à la main]&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Opérations mises &amp;quot;de côté&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
=== Remplacement de FCTTRE.h ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/code&amp;gt;FCTTRE.h&amp;lt;/code&amp;gt; contient des fonctions &amp;quot;en ligne&amp;quot;, syntaxe qui est dépréciée. De plus, c'est utilisé via un &amp;lt;code&amp;gt;INCLUDE&amp;lt;/code&amp;gt;.&lt;br /&gt;
Cependant, si on met ces fonctions dans un module à part (indépendament de questions de performance), on perd la convergence compilo car l'optimisation réalisée n'est pas la même.&lt;br /&gt;
Il sera donc intéressant, une fois qu'on est sur une version dont on est bien confiant, de tester cette migration, tant en performance qu'en résultats.&lt;br /&gt;
&lt;br /&gt;
=== Remplacement du commun comgeom ===&lt;br /&gt;
&lt;br /&gt;
Le commun &amp;lt;code&amp;gt;/comgeom/&amp;lt;/code&amp;gt; est partagé entre &amp;lt;code&amp;gt;lmdz_comgeom.f90&amp;lt;/code&amp;gt; et &amp;lt;code&amp;gt;lmdz_comgeom2.f90&amp;lt;/code&amp;gt;, afin de pouvoir de manière transparents passer les même tableaux en tant que 1D ou 2D.&lt;br /&gt;
Cette utilisation est dépréciée par Fortran, mais pas triviale à changer en module.&lt;br /&gt;
Une solution serait de passer par des pointeurs et une routine d'initialisation.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=484</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=484"/>
				<updated>2024-08-01T07:17:30Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
''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].&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!! File: lmdz_mymodule.f90&lt;br /&gt;
!!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
!!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
!! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
! implementation of my_useful_stuff.&lt;br /&gt;
! ----------------------------------&lt;br /&gt;
&lt;br /&gt;
!! Unless specified otherwise, all files should contain a single module with the same name which encapsulates all their content&lt;br /&gt;
MODULE lmdz_mymodule&lt;br /&gt;
!!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
  USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
  !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
!!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
  IMPLICIT NONE; PRIVATE&lt;br /&gt;
  !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
  !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
  PUBLIC my_var, my_subroutine&lt;br /&gt;
&lt;br /&gt;
  REAL, PARAMETER :: my_var&lt;br /&gt;
  REAL            :: a, b, c, d, e, f&lt;br /&gt;
  !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
  !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
        &lt;br /&gt;
CONTAINS&lt;br /&gt;
  &lt;br /&gt;
 !! Put at least a blank line before/after each function/subroutine2&lt;br /&gt;
 !! A routine should have a clear, unambiguous name, describing what the routine does.&lt;br /&gt;
  SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
  !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
  !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
    INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
    !!          ^ Always provide intent &lt;br /&gt;
    REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
    INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
    REAl, INTENT(OUT) :: out1&lt;br /&gt;
    !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
    IF (arg2 &amp;gt; arg1) THEN&lt;br /&gt;
    !!       ^ .ge., .le., etc are deprecated. Use &amp;gt;, &amp;lt;, ==, etc instead&lt;br /&gt;
      ! ...&lt;br /&gt;
    END IF&lt;br /&gt;
    !! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)&lt;br /&gt;
  END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
END MODULE my_module&lt;br /&gt;
!!       ^ always use named blocks for END&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Comments and Documentation ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Try to avoid having superfluous comments such as: &amp;lt;code&amp;gt;A = A + 1 ! Increment A by one.&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
* Everything that gets around an error or an undocumented feature in a language or environment.&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* The start of '''any''' subroutine or function whose usage is not downright obvious.&lt;br /&gt;
&lt;br /&gt;
== Misc ==&lt;br /&gt;
&lt;br /&gt;
=== Fortran standard ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Allocatable arrays ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Compiler warnings ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
when some appear in their configuration.&lt;br /&gt;
&lt;br /&gt;
In particular, all component must be able to run when a compile-time and/or run-time array bounds checking option is enabled.&lt;br /&gt;
Use of the (*) construct in array dimensioning to circumvent this problem is forbidden because it effectively disables array bounds checking.&lt;br /&gt;
&lt;br /&gt;
=== Side effects ===&lt;br /&gt;
&lt;br /&gt;
Whenever possible, write functions without side-effects, and label them accordingly as &amp;lt;code&amp;gt;PURE&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;ELEMENTAL&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== SAVE ===&lt;br /&gt;
&lt;br /&gt;
Since all files contain a &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt;, attribute &amp;lt;code&amp;gt;SAVE&amp;lt;/code&amp;gt; is banned. Variables whose value have to be preserved between two calls should be declared at the module level.&lt;br /&gt;
&lt;br /&gt;
=== Deprecated features ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
''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.''&lt;br /&gt;
&lt;br /&gt;
Some notable deprecated features:&lt;br /&gt;
&lt;br /&gt;
* &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt; blocks. Instead, use &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt; initialisation.&lt;br /&gt;
* &amp;lt;code&amp;gt;EQUIVALENCE&amp;lt;/code&amp;gt; should be replaced by pointers or derived data types.&lt;br /&gt;
* Any kind of &amp;lt;code&amp;gt;GOTO&amp;lt;/code&amp;gt; has absolutely no place in modern programming. Use &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; whenever relevant rather than &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt;.&lt;br /&gt;
* Arithmetic &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; statements. Use block &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;CONTINUE&amp;lt;/code&amp;gt; statement:  use &amp;lt;code&amp;gt;IF, CASE, DO WHILE, EXIT, CYCLE&amp;lt;/code&amp;gt; statements or a contained &amp;lt;code&amp;gt;SUBROUTINE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* I/O routines &amp;lt;code&amp;gt;END&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;ERR&amp;lt;/code&amp;gt; - use &amp;lt;code&amp;gt;IOSTAT&amp;lt;/code&amp;gt; instead&lt;br /&gt;
* &amp;lt;code&amp;gt;FORMAT&amp;lt;/code&amp;gt; statements: use character parameters or explicit format- specifiers inside the &amp;lt;code&amp;gt;READ&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;WRITE&amp;lt;/code&amp;gt; statement instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;ENTRY&amp;lt;/code&amp;gt; statements: a subprogram must only have one entry point&lt;br /&gt;
* ''Alternate'' &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; is obsolescent, and &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; at the end of a function is useless clutter.&lt;br /&gt;
* Statement functions have been replaced by corresponding functions or subroutines in the &amp;lt;code&amp;gt;CONTAIN&amp;lt;/code&amp;gt; block of the current scope.&lt;br /&gt;
* &amp;lt;code&amp;gt;DATA&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;BLOCK DATA&amp;lt;/code&amp;gt; should be replaced by initializers.&lt;br /&gt;
&lt;br /&gt;
=== Preprocessor ===&lt;br /&gt;
&lt;br /&gt;
Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
=== INCLUDE ===&lt;br /&gt;
&lt;br /&gt;
Limit the use of &amp;lt;code&amp;gt;include&amp;lt;/code&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Recent examples of improper LMDZ code ==&lt;br /&gt;
&lt;br /&gt;
''Note: The purpose of this section is '''obviously not''' to blame anyone, but to stress that &amp;quot;bad&amp;quot;/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.''&lt;br /&gt;
&lt;br /&gt;
==== 07/24: Unhelpful comment ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
IF (iflag_ice_thermo == 0) THEN   &lt;br /&gt;
           !pas necessaire a priori&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This comment fails to convey a clear indication. What is necessary or not ? In which condition ? &amp;quot;A priori&amp;quot; further conveys a sense of uncertainty that may make sense to the writer, but certainly not to an external reader.&lt;br /&gt;
&lt;br /&gt;
==== 07/24: Unclear conventions, no PURE, useless RETURN ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
function grid_index(lon_deg,lat_deg)&lt;br /&gt;
!--------------------------------------------------------------------------------&lt;br /&gt;
! Get local index of grid point of longitude,latitude lon_deg,lat_deg&lt;br /&gt;
! Author : XXX 2024/07/XX&lt;br /&gt;
! Please do not put this function in a m*odule not to complexify the replay script&lt;br /&gt;
!--------------------------------------------------------------------------------&lt;br /&gt;
USE dimphy, only : klon&lt;br /&gt;
USE geometry_mod, ONLY: latitude_deg, longitude_deg&lt;br /&gt;
implicit none&lt;br /&gt;
real, intent(in) :: lon_deg,lat_deg&lt;br /&gt;
integer :: grid_index&lt;br /&gt;
integer i&lt;br /&gt;
grid_index=0&lt;br /&gt;
do i=1,klon&lt;br /&gt;
   if ( abs(lon_deg-longitude_deg(i)) &amp;lt; 0.02 .and.  abs(lat_deg-latitude_deg(i)) &amp;lt; 0.02 ) then&lt;br /&gt;
        grid_index=i&lt;br /&gt;
        exit&lt;br /&gt;
   endif&lt;br /&gt;
enddo&lt;br /&gt;
return&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This function is actually mostly great ! It is documented, the author put a clear statement to indicate a deviation from standards (no module), &amp;lt;code&amp;gt;USE&amp;lt;/code&amp;gt; is used in conjuction with &amp;lt;code&amp;gt;ONLY&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;INTENT&amp;lt;/code&amp;gt; is declared.&lt;br /&gt;
However, it is also lacking in some areas, notably:&lt;br /&gt;
* This function should be declared as &amp;lt;code&amp;gt;PURE&amp;lt;/code&amp;gt;&lt;br /&gt;
* This function has inconsistent syntax: mix of uppercase and lowercase for Fortran keywords, sometimes uses &amp;lt;code&amp;gt;::&amp;lt;/code&amp;gt; in declarations and sometimes not&lt;br /&gt;
* The function ends with a useless &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== 07/24: Duplicated, uncommented code ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
          zx_tmp_fi3d=0.&lt;br /&gt;
          IF (vars_defined) THEN&lt;br /&gt;
             DO nsrf=1,nbsrf&lt;br /&gt;
                DO k=1,klev&lt;br /&gt;
                   zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &amp;amp;&lt;br /&gt;
                        +pctsrf(:,nsrf)*tke_shear(:,k,nsrf)&lt;br /&gt;
                ENDDO&lt;br /&gt;
             ENDDO&lt;br /&gt;
          ENDIF&lt;br /&gt;
&lt;br /&gt;
          CALL histwrite_phy(o_tke_shear, zx_tmp_fi3d)&lt;br /&gt;
&lt;br /&gt;
          zx_tmp_fi3d=0.&lt;br /&gt;
          IF (vars_defined) THEN&lt;br /&gt;
             DO nsrf=1,nbsrf&lt;br /&gt;
                DO k=1,klev&lt;br /&gt;
                   zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &amp;amp;&lt;br /&gt;
                        +pctsrf(:,nsrf)*tke_buoy(:,k,nsrf)&lt;br /&gt;
                ENDDO&lt;br /&gt;
             ENDDO&lt;br /&gt;
          ENDIF&lt;br /&gt;
&lt;br /&gt;
          CALL histwrite_phy(o_tke_buoy, zx_tmp_fi3d)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
          zx_tmp_fi3d=0.&lt;br /&gt;
          IF (vars_defined) THEN&lt;br /&gt;
             DO nsrf=1,nbsrf&lt;br /&gt;
                DO k=1,klev&lt;br /&gt;
                   zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &amp;amp;&lt;br /&gt;
                        +pctsrf(:,nsrf)*tke_trans(:,k,nsrf)&lt;br /&gt;
                ENDDO&lt;br /&gt;
             ENDDO&lt;br /&gt;
          ENDIF&lt;br /&gt;
&lt;br /&gt;
          CALL histwrite_phy(o_tke_trans, zx_tmp_fi3d)&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This code:&lt;br /&gt;
* Duplicates three times essentially the same code. Refactoring into a routine would be much more readable and reduce the potential of typos.&lt;br /&gt;
* Contains no comment justifying such behavior, or what is even being done here, which to an external reader is fairly obscure.&lt;br /&gt;
&lt;br /&gt;
==== 06/24: Undocumented variable ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
INTEGER                               :: nsrf, k, iq, iff, i, j, ilev, itr, itrb&lt;br /&gt;
!!                                                                           ^ Added this&lt;br /&gt;
!! (...)&lt;br /&gt;
itrb = 0&lt;br /&gt;
!! (...)&lt;br /&gt;
if(tracers(iq)%name(1:3)=='BIN') then&lt;br /&gt;
               itrb = itrb + 1&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Just because a variable is a &amp;quot;dumb&amp;quot; counter doesn't mean it shouldn't be documented. In this particular example, the variable name is devoid of any obvious meaning.&lt;br /&gt;
Properly documenting this variable would also make it clear to others whether it would make sense to reuse it later on in the code.&lt;br /&gt;
&lt;br /&gt;
==== 06/24: Comments as code storage ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!CALL writefield_phy('latitude',latitude_deg,1)&lt;br /&gt;
!CALL writefield_phy('pressure_hl',pressure_hl,klev+1)&lt;br /&gt;
!CALL writefield_phy('Ldecorel',PDECORR_LEN_EDGES_M,klev)&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''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.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Questions à élucider ==&lt;br /&gt;
&lt;br /&gt;
* Prescrit-on une langue (Français / Anglais) ?&lt;br /&gt;
* Longueur des lignes: dans la limite du raisonable, pourquoi se limiter à 100-140 chars ? Le wrapping fonctionne très bien.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=483</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=483"/>
				<updated>2024-08-01T07:15:52Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
''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].&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!! File: lmdz_mymodule.f90&lt;br /&gt;
!!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
!!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
!! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
! implementation of my_useful_stuff.&lt;br /&gt;
! ----------------------------------&lt;br /&gt;
&lt;br /&gt;
!! Unless specified otherwise, all files should contain a single module with the same name which encapsulates all their content&lt;br /&gt;
MODULE lmdz_mymodule&lt;br /&gt;
!!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
  USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
  !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
!!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
  IMPLICIT NONE; PRIVATE&lt;br /&gt;
  !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
  !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
  PUBLIC my_var, my_subroutine&lt;br /&gt;
&lt;br /&gt;
  REAL, PARAMETER :: my_var&lt;br /&gt;
  REAL            :: a, b, c, d, e, f&lt;br /&gt;
  !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
  !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
        &lt;br /&gt;
CONTAINS&lt;br /&gt;
  &lt;br /&gt;
 !! Put at least a blank line before/after each function/subroutine2&lt;br /&gt;
 !! A routine should have a clear, unambiguous name, describing what the routine does.&lt;br /&gt;
  SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
  !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
  !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
    INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
    !!          ^ Always provide intent &lt;br /&gt;
    REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
    INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
    REAl, INTENT(OUT) :: out1&lt;br /&gt;
    !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
    IF (arg2 &amp;gt; arg1) THEN&lt;br /&gt;
    !!       ^ .ge., .le., etc are deprecated. Use &amp;gt;, &amp;lt;, ==, etc instead&lt;br /&gt;
      ! ...&lt;br /&gt;
    END IF&lt;br /&gt;
    !! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)&lt;br /&gt;
  END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
END MODULE my_module&lt;br /&gt;
!!       ^ always use named blocks for END&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Comments and Documentation ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Try to avoid having superfluous comments such as: &amp;lt;code&amp;gt;A = A + 1 ! Increment A by one.&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
* Everything that gets around an error or an undocumented feature in a language or environment.&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* The start of '''any''' subroutine or function whose usage is not downright obvious.&lt;br /&gt;
&lt;br /&gt;
== Misc ==&lt;br /&gt;
&lt;br /&gt;
=== Fortran standard ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Allocatable arrays ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Compiler warnings ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
when some appear in their configuration.&lt;br /&gt;
&lt;br /&gt;
In particular, all component must be able to run when a compile-time and/or run-time array bounds checking option is enabled.&lt;br /&gt;
Use of the (*) construct in array dimensioning to circumvent this problem is forbidden because it effectively disables array bounds checking.&lt;br /&gt;
&lt;br /&gt;
=== Side effects ===&lt;br /&gt;
&lt;br /&gt;
Whenever possible, write functions without side-effects, and label them accordingly as &amp;lt;code&amp;gt;PURE&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;ELEMENTAL&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== SAVE ===&lt;br /&gt;
&lt;br /&gt;
Since all files contain a &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt;, attribute &amp;lt;code&amp;gt;SAVE&amp;lt;/code&amp;gt; is banned. Variables whose value have to be preserved between two calls should be declared at the module level.&lt;br /&gt;
&lt;br /&gt;
=== Deprecated features ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
''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.''&lt;br /&gt;
&lt;br /&gt;
Some notable deprecated features:&lt;br /&gt;
&lt;br /&gt;
* &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt; blocks. Instead, use &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt; initialisation.&lt;br /&gt;
* &amp;lt;code&amp;gt;EQUIVALENCE&amp;lt;/code&amp;gt; should be replaced by pointers or derived data types.&lt;br /&gt;
* Any kind of &amp;lt;code&amp;gt;GOTO&amp;lt;/code&amp;gt; has absolutely no place in modern programming. Use &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; whenever relevant rather than &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt;.&lt;br /&gt;
* Arithmetic &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; statements. Use block &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;CONTINUE&amp;lt;/code&amp;gt; statement:  use &amp;lt;code&amp;gt;IF, CASE, DO WHILE, EXIT, CYCLE&amp;lt;/code&amp;gt; statements or a contained &amp;lt;code&amp;gt;SUBROUTINE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* I/O routines &amp;lt;code&amp;gt;END&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;ERR&amp;lt;/code&amp;gt; - use &amp;lt;code&amp;gt;IOSTAT&amp;lt;/code&amp;gt; instead&lt;br /&gt;
* &amp;lt;code&amp;gt;FORMAT&amp;lt;/code&amp;gt; statements: use character parameters or explicit format- specifiers inside the &amp;lt;code&amp;gt;READ&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;WRITE&amp;lt;/code&amp;gt; statement instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;ENTRY&amp;lt;/code&amp;gt; statements: a subprogram must only have one entry point&lt;br /&gt;
* ''Alternate'' &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; is obsolescent, and &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; at the end of a function is useless clutter.&lt;br /&gt;
* Statement functions have been replaced by corresponding functions or subroutines in the &amp;lt;code&amp;gt;CONTAIN&amp;lt;/code&amp;gt; block of the current scope.&lt;br /&gt;
* &amp;lt;code&amp;gt;DATA&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;BLOCK DATA&amp;lt;/code&amp;gt; should be replaced by initializers.&lt;br /&gt;
&lt;br /&gt;
=== Preprocessor ===&lt;br /&gt;
&lt;br /&gt;
Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
=== INCLUDE ===&lt;br /&gt;
&lt;br /&gt;
Limit the use of &amp;lt;code&amp;gt;include&amp;lt;/code&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Recent examples of &amp;quot;bad&amp;quot;/perfectible LMDZ code ==&lt;br /&gt;
&lt;br /&gt;
''Note: The purpose of this section is '''obviously not''' to blame anyone, but to stress that &amp;quot;bad&amp;quot; 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.''&lt;br /&gt;
&lt;br /&gt;
==== 07/24: Unhelpful comment ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
IF (iflag_ice_thermo == 0) THEN   &lt;br /&gt;
           !pas necessaire a priori&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This comment fails to convey a clear indication. What is necessary or not ? In which condition ? &amp;quot;A priori&amp;quot; further conveys a sense of uncertainty that may make sense to the writer, but certainly not to an external reader.&lt;br /&gt;
&lt;br /&gt;
==== 07/24: Unclear conventions, no PURE, useless RETURN ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
function grid_index(lon_deg,lat_deg)&lt;br /&gt;
!--------------------------------------------------------------------------------&lt;br /&gt;
! Get local index of grid point of longitude,latitude lon_deg,lat_deg&lt;br /&gt;
! Author : XXX 2024/07/XX&lt;br /&gt;
! Please do not put this function in a m*odule not to complexify the replay script&lt;br /&gt;
!--------------------------------------------------------------------------------&lt;br /&gt;
USE dimphy, only : klon&lt;br /&gt;
USE geometry_mod, ONLY: latitude_deg, longitude_deg&lt;br /&gt;
implicit none&lt;br /&gt;
real, intent(in) :: lon_deg,lat_deg&lt;br /&gt;
integer :: grid_index&lt;br /&gt;
integer i&lt;br /&gt;
grid_index=0&lt;br /&gt;
do i=1,klon&lt;br /&gt;
   if ( abs(lon_deg-longitude_deg(i)) &amp;lt; 0.02 .and.  abs(lat_deg-latitude_deg(i)) &amp;lt; 0.02 ) then&lt;br /&gt;
        grid_index=i&lt;br /&gt;
        exit&lt;br /&gt;
   endif&lt;br /&gt;
enddo&lt;br /&gt;
return&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This function is actually mostly great ! It is documented, the author put a clear statement to indicate a deviation from standards (no module), &amp;lt;code&amp;gt;USE&amp;lt;/code&amp;gt; is used in conjuction with &amp;lt;code&amp;gt;ONLY&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;INTENT&amp;lt;/code&amp;gt; is declared.&lt;br /&gt;
However, it is also lacking in some areas, notably:&lt;br /&gt;
* This function should be declared as &amp;lt;code&amp;gt;PURE&amp;lt;/code&amp;gt;&lt;br /&gt;
* This function has inconsistent syntax: mix of uppercase and lowercase for Fortran keywords, sometimes uses &amp;lt;code&amp;gt;::&amp;lt;/code&amp;gt; in declarations and sometimes not&lt;br /&gt;
* The function ends with a useless &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== 07/24: Duplicated, uncommented code ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
          zx_tmp_fi3d=0.&lt;br /&gt;
          IF (vars_defined) THEN&lt;br /&gt;
             DO nsrf=1,nbsrf&lt;br /&gt;
                DO k=1,klev&lt;br /&gt;
                   zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &amp;amp;&lt;br /&gt;
                        +pctsrf(:,nsrf)*tke_shear(:,k,nsrf)&lt;br /&gt;
                ENDDO&lt;br /&gt;
             ENDDO&lt;br /&gt;
          ENDIF&lt;br /&gt;
&lt;br /&gt;
          CALL histwrite_phy(o_tke_shear, zx_tmp_fi3d)&lt;br /&gt;
&lt;br /&gt;
          zx_tmp_fi3d=0.&lt;br /&gt;
          IF (vars_defined) THEN&lt;br /&gt;
             DO nsrf=1,nbsrf&lt;br /&gt;
                DO k=1,klev&lt;br /&gt;
                   zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &amp;amp;&lt;br /&gt;
                        +pctsrf(:,nsrf)*tke_buoy(:,k,nsrf)&lt;br /&gt;
                ENDDO&lt;br /&gt;
             ENDDO&lt;br /&gt;
          ENDIF&lt;br /&gt;
&lt;br /&gt;
          CALL histwrite_phy(o_tke_buoy, zx_tmp_fi3d)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
          zx_tmp_fi3d=0.&lt;br /&gt;
          IF (vars_defined) THEN&lt;br /&gt;
             DO nsrf=1,nbsrf&lt;br /&gt;
                DO k=1,klev&lt;br /&gt;
                   zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &amp;amp;&lt;br /&gt;
                        +pctsrf(:,nsrf)*tke_trans(:,k,nsrf)&lt;br /&gt;
                ENDDO&lt;br /&gt;
             ENDDO&lt;br /&gt;
          ENDIF&lt;br /&gt;
&lt;br /&gt;
          CALL histwrite_phy(o_tke_trans, zx_tmp_fi3d)&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This code:&lt;br /&gt;
* Duplicates three times essentially the same code. Refactoring into a routine would be much more readable and reduce the potential of typos.&lt;br /&gt;
* Contains no comment justifying such behavior, or what is even being done here, which to an external reader is fairly obscure.&lt;br /&gt;
&lt;br /&gt;
==== 06/24: Undocumented variable ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
INTEGER                               :: nsrf, k, iq, iff, i, j, ilev, itr, itrb&lt;br /&gt;
!!                                                                           ^ Added this&lt;br /&gt;
!! (...)&lt;br /&gt;
itrb = 0&lt;br /&gt;
!! (...)&lt;br /&gt;
if(tracers(iq)%name(1:3)=='BIN') then&lt;br /&gt;
               itrb = itrb + 1&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Just because a variable is a &amp;quot;dumb&amp;quot; counter doesn't mean it shouldn't be documented. In this particular example, the variable name is devoid of any obvious meaning.&lt;br /&gt;
Properly documenting this variable would also make it clear to others whether it would make sense to reuse it later on in the code.&lt;br /&gt;
&lt;br /&gt;
==== 06/24: Comments as code storage ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!CALL writefield_phy('latitude',latitude_deg,1)&lt;br /&gt;
!CALL writefield_phy('pressure_hl',pressure_hl,klev+1)&lt;br /&gt;
!CALL writefield_phy('Ldecorel',PDECORR_LEN_EDGES_M,klev)&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''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.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Questions à élucider ==&lt;br /&gt;
&lt;br /&gt;
* Prescrit-on une langue (Français / Anglais) ?&lt;br /&gt;
* Longueur des lignes: dans la limite du raisonable, pourquoi se limiter à 100-140 chars ? Le wrapping fonctionne très bien.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=482</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=482"/>
				<updated>2024-08-01T07:13:54Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : Add examples of &amp;quot;bad&amp;quot; practices&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
''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].&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!! File: lmdz_mymodule.f90&lt;br /&gt;
!!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
!!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
!! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
! implementation of my_useful_stuff.&lt;br /&gt;
! ----------------------------------&lt;br /&gt;
&lt;br /&gt;
!! Unless specified otherwise, all files should contain a single module with the same name which encapsulates all their content&lt;br /&gt;
MODULE lmdz_mymodule&lt;br /&gt;
!!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
  USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
  !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
!!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
  IMPLICIT NONE; PRIVATE&lt;br /&gt;
  !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
  !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
  PUBLIC my_var, my_subroutine&lt;br /&gt;
&lt;br /&gt;
  REAL, PARAMETER :: my_var&lt;br /&gt;
  REAL            :: a, b, c, d, e, f&lt;br /&gt;
  !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
  !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
        &lt;br /&gt;
CONTAINS&lt;br /&gt;
  &lt;br /&gt;
 !! Put at least a blank line before/after each function/subroutine2&lt;br /&gt;
 !! A routine should have a clear, unambiguous name, describing what the routine does.&lt;br /&gt;
  SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
  !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
  !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
    INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
    !!          ^ Always provide intent &lt;br /&gt;
    REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
    INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
    REAl, INTENT(OUT) :: out1&lt;br /&gt;
    !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
    IF (arg2 &amp;gt; arg1) THEN&lt;br /&gt;
    !!       ^ .ge., .le., etc are deprecated. Use &amp;gt;, &amp;lt;, ==, etc instead&lt;br /&gt;
      ! ...&lt;br /&gt;
    END IF&lt;br /&gt;
    !! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)&lt;br /&gt;
  END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
END MODULE my_module&lt;br /&gt;
!!       ^ always use named blocks for END&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Comments and Documentation ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Try to avoid having superfluous comments such as: &amp;lt;code&amp;gt;A = A + 1 ! Increment A by one.&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
* Everything that gets around an error or an undocumented feature in a language or environment.&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* The start of '''any''' subroutine or function whose usage is not downright obvious.&lt;br /&gt;
&lt;br /&gt;
== Misc ==&lt;br /&gt;
&lt;br /&gt;
=== Fortran standard ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Allocatable arrays ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Compiler warnings ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
when some appear in their configuration.&lt;br /&gt;
&lt;br /&gt;
In particular, all component must be able to run when a compile-time and/or run-time array bounds checking option is enabled.&lt;br /&gt;
Use of the (*) construct in array dimensioning to circumvent this problem is forbidden because it effectively disables array bounds checking.&lt;br /&gt;
&lt;br /&gt;
=== Side effects ===&lt;br /&gt;
&lt;br /&gt;
Whenever possible, write functions without side-effects, and label them accordingly as &amp;lt;code&amp;gt;PURE&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;ELEMENTAL&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== SAVE ===&lt;br /&gt;
&lt;br /&gt;
Since all files contain a &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt;, attribute &amp;lt;code&amp;gt;SAVE&amp;lt;/code&amp;gt; is banned. Variables whose value have to be preserved between two calls should be declared at the module level.&lt;br /&gt;
&lt;br /&gt;
=== Deprecated features ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
''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.''&lt;br /&gt;
&lt;br /&gt;
Some notable deprecated features:&lt;br /&gt;
&lt;br /&gt;
* &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt; blocks. Instead, use &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt; initialisation.&lt;br /&gt;
* &amp;lt;code&amp;gt;EQUIVALENCE&amp;lt;/code&amp;gt; should be replaced by pointers or derived data types.&lt;br /&gt;
* Any kind of &amp;lt;code&amp;gt;GOTO&amp;lt;/code&amp;gt; has absolutely no place in modern programming. Use &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; whenever relevant rather than &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt;.&lt;br /&gt;
* Arithmetic &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; statements. Use block &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;CONTINUE&amp;lt;/code&amp;gt; statement:  use &amp;lt;code&amp;gt;IF, CASE, DO WHILE, EXIT, CYCLE&amp;lt;/code&amp;gt; statements or a contained &amp;lt;code&amp;gt;SUBROUTINE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* I/O routines &amp;lt;code&amp;gt;END&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;ERR&amp;lt;/code&amp;gt; - use &amp;lt;code&amp;gt;IOSTAT&amp;lt;/code&amp;gt; instead&lt;br /&gt;
* &amp;lt;code&amp;gt;FORMAT&amp;lt;/code&amp;gt; statements: use character parameters or explicit format- specifiers inside the &amp;lt;code&amp;gt;READ&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;WRITE&amp;lt;/code&amp;gt; statement instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;ENTRY&amp;lt;/code&amp;gt; statements: a subprogram must only have one entry point&lt;br /&gt;
* ''Alternate'' &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; is obsolescent, and &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; at the end of a function is useless clutter.&lt;br /&gt;
* Statement functions have been replaced by corresponding functions or subroutines in the &amp;lt;code&amp;gt;CONTAIN&amp;lt;/code&amp;gt; block of the current scope.&lt;br /&gt;
* &amp;lt;code&amp;gt;DATA&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;BLOCK DATA&amp;lt;/code&amp;gt; should be replaced by initializers.&lt;br /&gt;
&lt;br /&gt;
=== Preprocessor ===&lt;br /&gt;
&lt;br /&gt;
Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
=== INCLUDE ===&lt;br /&gt;
&lt;br /&gt;
Limit the use of &amp;lt;code&amp;gt;include&amp;lt;/code&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Recent examples of &amp;quot;bad&amp;quot;/perfectible LMDZ code ==&lt;br /&gt;
&lt;br /&gt;
''Note: The purpose of this section is '''obviously not''' to blame anyone, but to stress that &amp;quot;bad&amp;quot; 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.''&lt;br /&gt;
&lt;br /&gt;
==== 07/24: Unhelpful comment ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
IF (iflag_ice_thermo == 0) THEN   &lt;br /&gt;
           !pas necessaire a priori&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This comment fails to convey a clear indication. What is necessary or not ? In which condition ? &amp;quot;A priori&amp;quot; further conveys a sense of uncertainty that may make sense to the writer, but certainly not to an external reader.&lt;br /&gt;
&lt;br /&gt;
==== 07/24: Unclear conventions, no PURE, useless RETURN ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
function grid_index(lon_deg,lat_deg)&lt;br /&gt;
!--------------------------------------------------------------------------------&lt;br /&gt;
! Get local index of grid point of longitude,latitude lon_deg,lat_deg&lt;br /&gt;
! Author : XXX 2024/07/XX&lt;br /&gt;
! Please do not put this function in a m*odule not to complexify the replay script&lt;br /&gt;
!--------------------------------------------------------------------------------&lt;br /&gt;
USE dimphy, only : klon&lt;br /&gt;
USE geometry_mod, ONLY: latitude_deg, longitude_deg&lt;br /&gt;
implicit none&lt;br /&gt;
real, intent(in) :: lon_deg,lat_deg&lt;br /&gt;
integer :: grid_index&lt;br /&gt;
integer i&lt;br /&gt;
grid_index=0&lt;br /&gt;
do i=1,klon&lt;br /&gt;
   if ( abs(lon_deg-longitude_deg(i)) &amp;lt; 0.02 .and.  abs(lat_deg-latitude_deg(i)) &amp;lt; 0.02 ) then&lt;br /&gt;
        grid_index=i&lt;br /&gt;
        exit&lt;br /&gt;
   endif&lt;br /&gt;
enddo&lt;br /&gt;
return&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This function is actually mostly great ! It is documented, the author put a clear statement to indicate a deviation from standards (no module), &amp;lt;code&amp;gt;USE&amp;lt;/code&amp;gt; is used in conjuction with &amp;lt;code&amp;gt;ONLY&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;INTENT&amp;lt;/code&amp;gt; is declared.&lt;br /&gt;
However, it is also lacking in some areas, notably:&lt;br /&gt;
* This function should be declared as &amp;lt;code&amp;gt;PURE&amp;lt;/code&amp;gt;&lt;br /&gt;
* This function has inconsistent syntax: mix of uppercase and lowercase for Fortran keywords, sometimes uses &amp;lt;code&amp;gt;::&amp;lt;/code&amp;gt; in declarations and sometimes not&lt;br /&gt;
* The function ends with a useless &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== 07/24: Duplicated, uncommented code ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
          zx_tmp_fi3d=0.&lt;br /&gt;
          IF (vars_defined) THEN&lt;br /&gt;
             DO nsrf=1,nbsrf&lt;br /&gt;
                DO k=1,klev&lt;br /&gt;
                   zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &amp;amp;&lt;br /&gt;
                        +pctsrf(:,nsrf)*tke_shear(:,k,nsrf)&lt;br /&gt;
                ENDDO&lt;br /&gt;
             ENDDO&lt;br /&gt;
          ENDIF&lt;br /&gt;
&lt;br /&gt;
          CALL histwrite_phy(o_tke_shear, zx_tmp_fi3d)&lt;br /&gt;
&lt;br /&gt;
          zx_tmp_fi3d=0.&lt;br /&gt;
          IF (vars_defined) THEN&lt;br /&gt;
             DO nsrf=1,nbsrf&lt;br /&gt;
                DO k=1,klev&lt;br /&gt;
                   zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &amp;amp;&lt;br /&gt;
                        +pctsrf(:,nsrf)*tke_buoy(:,k,nsrf)&lt;br /&gt;
                ENDDO&lt;br /&gt;
             ENDDO&lt;br /&gt;
          ENDIF&lt;br /&gt;
&lt;br /&gt;
          CALL histwrite_phy(o_tke_buoy, zx_tmp_fi3d)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
          zx_tmp_fi3d=0.&lt;br /&gt;
          IF (vars_defined) THEN&lt;br /&gt;
             DO nsrf=1,nbsrf&lt;br /&gt;
                DO k=1,klev&lt;br /&gt;
                   zx_tmp_fi3d(:,k)=zx_tmp_fi3d(:,k) &amp;amp;&lt;br /&gt;
                        +pctsrf(:,nsrf)*tke_trans(:,k,nsrf)&lt;br /&gt;
                ENDDO&lt;br /&gt;
             ENDDO&lt;br /&gt;
          ENDIF&lt;br /&gt;
&lt;br /&gt;
          CALL histwrite_phy(o_tke_trans, zx_tmp_fi3d)&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This code:&lt;br /&gt;
* Duplicates three times essentially the same code. Refactoring into a routine would be much more readable and reduce the potential of typos.&lt;br /&gt;
* Contains no comment justifying such behavior, or what is even being done here, which to an external reader is fairly obscure.&lt;br /&gt;
&lt;br /&gt;
==== 06/24: Undocumented variable ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
INTEGER                               :: nsrf, k, iq, iff, i, j, ilev, itr, itrb&lt;br /&gt;
!!                                                                           ^ Added this&lt;br /&gt;
!! (...)&lt;br /&gt;
itrb = 0&lt;br /&gt;
!! (...)&lt;br /&gt;
if(tracers(iq)%name(1:3)=='BIN') then&lt;br /&gt;
               itrb = itrb + 1&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Just because a variable is a &amp;quot;dumb&amp;quot; counter doesn't mean it shouldn't be documented. In this particular example, the variable name is devoid of any obvious meaning.&lt;br /&gt;
Properly documenting this variable would also make it clear to others whether it would make sense to reuse it later on in the code.&lt;br /&gt;
&lt;br /&gt;
==== 06/24: Comments as code storage ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!CALL writefield_phy('latitude',latitude_deg,1)&lt;br /&gt;
!CALL writefield_phy('pressure_hl',pressure_hl,klev+1)&lt;br /&gt;
!CALL writefield_phy('Ldecorel',PDECORR_LEN_EDGES_M,klev)&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''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.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 the code was commented out''', so that it can be cleaned up at a later date when it becomes irrelevant.&lt;br /&gt;
&lt;br /&gt;
== Questions à élucider ==&lt;br /&gt;
&lt;br /&gt;
* Prescrit-on une langue (Français / Anglais) ?&lt;br /&gt;
* Longueur des lignes: dans la limite du raisonable, pourquoi se limiter à 100-140 chars ? Le wrapping fonctionne très bien.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=481</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=481"/>
				<updated>2024-08-01T03:46:52Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
''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].&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!! File: lmdz_mymodule.f90&lt;br /&gt;
!!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
!!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
!! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
! implementation of my_useful_stuff.&lt;br /&gt;
! ----------------------------------&lt;br /&gt;
&lt;br /&gt;
!! Unless specified otherwise, all files should contain a single module with the same name which encapsulates all their content&lt;br /&gt;
MODULE lmdz_mymodule&lt;br /&gt;
!!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
  USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
  !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
!!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
  IMPLICIT NONE; PRIVATE&lt;br /&gt;
  !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
  !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
  PUBLIC my_var, my_subroutine&lt;br /&gt;
&lt;br /&gt;
  REAL, PARAMETER :: my_var&lt;br /&gt;
  REAL            :: a, b, c, d, e, f&lt;br /&gt;
  !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
  !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
        &lt;br /&gt;
CONTAINS&lt;br /&gt;
  &lt;br /&gt;
 !! Put at least a blank line before/after each function/subroutine2&lt;br /&gt;
 !! A routine should have a clear, unambiguous name, describing what the routine does.&lt;br /&gt;
  SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
  !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
  !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
    INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
    !!          ^ Always provide intent &lt;br /&gt;
    REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
    INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
    REAl, INTENT(OUT) :: out1&lt;br /&gt;
    !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
    IF (arg2 &amp;gt; arg1) THEN&lt;br /&gt;
    !!       ^ .ge., .le., etc are deprecated. Use &amp;gt;, &amp;lt;, ==, etc instead&lt;br /&gt;
      ! ...&lt;br /&gt;
    END IF&lt;br /&gt;
    !! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)&lt;br /&gt;
  END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
END MODULE my_module&lt;br /&gt;
!!       ^ always use named blocks for END&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Comments and Documentation ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Try to avoid having superfluous comments such as: &amp;lt;code&amp;gt;A = A + 1 ! Increment A by one.&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
* Everything that gets around an error or an undocumented feature in a language or environment.&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* The start of '''any''' subroutine or function whose usage is not downright obvious.&lt;br /&gt;
&lt;br /&gt;
== Misc ==&lt;br /&gt;
&lt;br /&gt;
=== Fortran standard ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Allocatable arrays ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Compiler warnings ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
when some appear in their configuration.&lt;br /&gt;
&lt;br /&gt;
In particular, all component must be able to run when a compile-time and/or run-time array bounds checking option is enabled.&lt;br /&gt;
Use of the (*) construct in array dimensioning to circumvent this problem is forbidden because it effectively disables array bounds checking.&lt;br /&gt;
&lt;br /&gt;
=== Side effects ===&lt;br /&gt;
&lt;br /&gt;
Whenever possible, write functions without side-effects, and label them accordingly as &amp;lt;code&amp;gt;PURE&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;ELEMENTAL&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== SAVE ===&lt;br /&gt;
&lt;br /&gt;
Since all files contain a &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt;, attribute &amp;lt;code&amp;gt;SAVE&amp;lt;/code&amp;gt; is banned. Variables whose value have to be preserved between two calls should be declared at the module level.&lt;br /&gt;
&lt;br /&gt;
=== Deprecated features ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
''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.''&lt;br /&gt;
&lt;br /&gt;
Some notable deprecated features:&lt;br /&gt;
&lt;br /&gt;
* &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt; blocks. Instead, use &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt; initialisation.&lt;br /&gt;
* &amp;lt;code&amp;gt;EQUIVALENCE&amp;lt;/code&amp;gt; should be replaced by pointers or derived data types.&lt;br /&gt;
* Any kind of &amp;lt;code&amp;gt;GOTO&amp;lt;/code&amp;gt; has absolutely no place in modern programming. Use &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; whenever relevant rather than &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt;.&lt;br /&gt;
* Arithmetic &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; statements. Use block &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;CONTINUE&amp;lt;/code&amp;gt; statement:  use &amp;lt;code&amp;gt;IF, CASE, DO WHILE, EXIT, CYCLE&amp;lt;/code&amp;gt; statements or a contained &amp;lt;code&amp;gt;SUBROUTINE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* I/O routines &amp;lt;code&amp;gt;END&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;ERR&amp;lt;/code&amp;gt; - use &amp;lt;code&amp;gt;IOSTAT&amp;lt;/code&amp;gt; instead&lt;br /&gt;
* &amp;lt;code&amp;gt;FORMAT&amp;lt;/code&amp;gt; statements: use character parameters or explicit format- specifiers inside the &amp;lt;code&amp;gt;READ&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;WRITE&amp;lt;/code&amp;gt; statement instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;ENTRY&amp;lt;/code&amp;gt; statements: a subprogram must only have one entry point&lt;br /&gt;
* ''Alternate'' &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; is obsolescent, and &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; at the end of a function is useless clutter.&lt;br /&gt;
* Statement functions have been replaced by corresponding functions or subroutines in the &amp;lt;code&amp;gt;CONTAIN&amp;lt;/code&amp;gt; block of the current scope.&lt;br /&gt;
* &amp;lt;code&amp;gt;DATA&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;BLOCK DATA&amp;lt;/code&amp;gt; should be replaced by initializers.&lt;br /&gt;
&lt;br /&gt;
=== Preprocessor ===&lt;br /&gt;
&lt;br /&gt;
Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
=== INCLUDE ===&lt;br /&gt;
&lt;br /&gt;
Limit the use of &amp;lt;code&amp;gt;include&amp;lt;/code&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Questions à élucider ==&lt;br /&gt;
&lt;br /&gt;
* Prescrit-on une langue (Français / Anglais) ?&lt;br /&gt;
* Longueur des lignes: dans la limite du raisonable, pourquoi se limiter à 100-140 chars ? Le wrapping fonctionne très bien.&lt;br /&gt;
*&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=480</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=480"/>
				<updated>2024-08-01T03:38:22Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
''Note: this documents draws from various sources, including [http://broken.link.todo.replace the OPA guidelines].&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!! File: lmdz_mymodule.f90&lt;br /&gt;
!!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
!!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
!! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
! implementation of my_useful_stuff.&lt;br /&gt;
! ----------------------------------&lt;br /&gt;
&lt;br /&gt;
!! Unless specified otherwise, all files should contain a single module with the same name which encapsulates all their content&lt;br /&gt;
MODULE lmdz_mymodule&lt;br /&gt;
!!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
  USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
  !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
!!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
  IMPLICIT NONE; PRIVATE&lt;br /&gt;
  !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
  !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
  PUBLIC my_var, my_subroutine&lt;br /&gt;
&lt;br /&gt;
  REAL, PARAMETER :: my_var&lt;br /&gt;
  REAL            :: a, b, c, d, e, f&lt;br /&gt;
  !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
  !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
        &lt;br /&gt;
CONTAINS&lt;br /&gt;
  &lt;br /&gt;
 !! Put at least a blank line before/after each function/subroutine2&lt;br /&gt;
 !! A routine should have a clear, unambiguous name, describing what the routine does.&lt;br /&gt;
  SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
  !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
  !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
    INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
    !!          ^ Always provide intent &lt;br /&gt;
    REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
    INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
    REAl, INTENT(OUT) :: out1&lt;br /&gt;
    !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
    IF (arg2 &amp;gt; arg1) THEN&lt;br /&gt;
    !!       ^ .ge., .le., etc are deprecated. Use &amp;gt;, &amp;lt;, ==, etc instead&lt;br /&gt;
      ! ...&lt;br /&gt;
    END IF&lt;br /&gt;
    !! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)&lt;br /&gt;
  END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
END MODULE my_module&lt;br /&gt;
!!       ^ always use named blocks for END&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Comments and Documentation ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Try to avoid having superfluous comments such as: &amp;lt;code&amp;gt;A = A + 1 ! Increment A by one.&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
* Everything that gets around an error or an undocumented feature in a language or environment.&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* The start of '''any''' subroutine or function whose usage is not downright obvious.&lt;br /&gt;
&lt;br /&gt;
== Misc ==&lt;br /&gt;
&lt;br /&gt;
=== Fortran standard ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Allocatable arrays ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Compiler warnings ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
when some appear in their configuration.&lt;br /&gt;
&lt;br /&gt;
In particular, all component must be able to run when a compile-time and/or run-time array bounds checking option is enabled.&lt;br /&gt;
Use of the (*) construct in array dimensioning to circumvent this problem is forbidden because it effectively disables array bounds checking.&lt;br /&gt;
&lt;br /&gt;
=== Side effects ===&lt;br /&gt;
&lt;br /&gt;
Whenever possible, write functions without side-effects, and label them accordingly as &amp;lt;code&amp;gt;PURE&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;ELEMENTAL&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== SAVE ===&lt;br /&gt;
&lt;br /&gt;
Since all files contain a &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt;, attribute &amp;lt;code&amp;gt;SAVE&amp;lt;/code&amp;gt; is banned. Variables whose value have to be preserved between two calls should be declared at the module level.&lt;br /&gt;
&lt;br /&gt;
=== Deprecated features ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
''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.''&lt;br /&gt;
&lt;br /&gt;
Some notable deprecated features:&lt;br /&gt;
&lt;br /&gt;
* &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt; blocks. Instead, use &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt; initialisation.&lt;br /&gt;
* &amp;lt;code&amp;gt;EQUIVALENCE&amp;lt;/code&amp;gt; should be replaced by pointers or derived data types.&lt;br /&gt;
* Any kind of &amp;lt;code&amp;gt;GOTO&amp;lt;/code&amp;gt; has absolutely no place in modern programming. Use &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; whenever relevant rather than &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt;.&lt;br /&gt;
* Arithmetic &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; statements. Use block &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;CONTINUE&amp;lt;/code&amp;gt; statement:  use &amp;lt;code&amp;gt;IF, CASE, DO WHILE, EXIT, CYCLE&amp;lt;/code&amp;gt; statements or a contained &amp;lt;code&amp;gt;SUBROUTINE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* I/O routines &amp;lt;code&amp;gt;END&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;ERR&amp;lt;/code&amp;gt; - use &amp;lt;code&amp;gt;IOSTAT&amp;lt;/code&amp;gt; instead&lt;br /&gt;
* &amp;lt;code&amp;gt;FORMAT&amp;lt;/code&amp;gt; statements: use character parameters or explicit format- specifiers inside the &amp;lt;code&amp;gt;READ&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;WRITE&amp;lt;/code&amp;gt; statement instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;ENTRY&amp;lt;/code&amp;gt; statements: a subprogram must only have one entry point&lt;br /&gt;
* ''Alternate'' &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; is obsolescent, and &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; at the end of a function is useless clutter.&lt;br /&gt;
* Statement functions have been replaced by corresponding functions or subroutines in the &amp;lt;code&amp;gt;CONTAIN&amp;lt;/code&amp;gt; block of the current scope.&lt;br /&gt;
* &amp;lt;code&amp;gt;DATA&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;BLOCK DATA&amp;lt;/code&amp;gt; should be replaced by initializers.&lt;br /&gt;
&lt;br /&gt;
=== Preprocessor ===&lt;br /&gt;
&lt;br /&gt;
Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
=== INCLUDE ===&lt;br /&gt;
&lt;br /&gt;
Limit the use of &amp;lt;code&amp;gt;include&amp;lt;/code&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Questions à élucider ==&lt;br /&gt;
&lt;br /&gt;
* Prescrit-on une langue (Français / Anglais) ?&lt;br /&gt;
* Longueur des lignes: dans la limite du raisonable, pourquoi se limiter à 100-140 chars ? Le wrapping fonctionne très bien.&lt;br /&gt;
*&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=479</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=479"/>
				<updated>2024-08-01T03:30:26Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
''Note: this documents draws from various sources, including [http://broken.link.todo.replace the OPA guidelines].&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!! File: lmdz_mymodule.f90&lt;br /&gt;
!!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
!!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
!! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
! implementation of my_useful_stuff.&lt;br /&gt;
! ----------------------------------&lt;br /&gt;
&lt;br /&gt;
!! Unless specified otherwise, all files should contain a single module with the same name which encapsulates all their content&lt;br /&gt;
MODULE lmdz_mymodule&lt;br /&gt;
!!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
  USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
  !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
!!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
  IMPLICIT NONE; PRIVATE&lt;br /&gt;
  !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
  !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
  PUBLIC my_var, my_subroutine&lt;br /&gt;
&lt;br /&gt;
  REAL, PARAMETER :: my_var&lt;br /&gt;
  REAL            :: a, b, c, d, e, f&lt;br /&gt;
  !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
  !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
        &lt;br /&gt;
CONTAINS&lt;br /&gt;
  &lt;br /&gt;
 !! Put at least a blank line before/after each function/subroutine&lt;br /&gt;
  SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
  !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
  !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
    INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
    !!          ^ Always provide intent &lt;br /&gt;
    REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
    INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
    REAl, INTENT(OUT) :: out1&lt;br /&gt;
    !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
    IF (arg2 &amp;gt; arg1) THEN&lt;br /&gt;
    !!       ^ .ge., .le., etc are deprecated. Use &amp;gt;, &amp;lt;, ==, etc instead&lt;br /&gt;
      ! ...&lt;br /&gt;
    END IF&lt;br /&gt;
    !! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)&lt;br /&gt;
  END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
END MODULE my_module&lt;br /&gt;
!!       ^ always use named blocks for END&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Some comments:&lt;br /&gt;
* Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
* Limit the use of &amp;lt;code&amp;gt;include&amp;lt;/code&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Misc ==&lt;br /&gt;
&lt;br /&gt;
=== Fortran standard ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Allocatable arrays ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Compiler warnings ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
when some appear in their configuration.&lt;br /&gt;
&lt;br /&gt;
In particular, all component must be able to run when a compile-time and/or run-time array bounds checking option is enabled.&lt;br /&gt;
Use of the (*) construct in array dimensioning to circumvent this problem is forbidden because it effectively disables array bounds checking.&lt;br /&gt;
&lt;br /&gt;
=== Side effects ===&lt;br /&gt;
&lt;br /&gt;
Whenever possible, write functions without side-effects, and label them accordingly as &amp;lt;code&amp;gt;PURE&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;ELEMENTAL&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== SAVE ===&lt;br /&gt;
&lt;br /&gt;
Since all files contain a &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt;, attribute &amp;lt;code&amp;gt;SAVE&amp;lt;/code&amp;gt; is banned. Variables whose value have to be preserved between two calls should be declared at the module level.&lt;br /&gt;
&lt;br /&gt;
=== Deprecated features ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
''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.''&lt;br /&gt;
&lt;br /&gt;
Some notable deprecated features:&lt;br /&gt;
&lt;br /&gt;
* &amp;lt;code&amp;gt;COMMON&amp;lt;/code&amp;gt; blocks. Instead, use &amp;lt;code&amp;gt;MODULE&amp;lt;/code&amp;gt; initialisation.&lt;br /&gt;
* &amp;lt;code&amp;gt;EQUIVALENCE&amp;lt;/code&amp;gt; should be replaced by pointers or derived data types.&lt;br /&gt;
* Any kind of &amp;lt;code&amp;gt;GOTO&amp;lt;/code&amp;gt; has absolutely no place in modern programming. Use &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; whenever relevant rather than &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt;.&lt;br /&gt;
* Arithmetic &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; statements. Use block &amp;lt;code&amp;gt;IF&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;CASE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;CONTINUE&amp;lt;/code&amp;gt; statement:  use &amp;lt;code&amp;gt;IF, CASE, DO WHILE, EXIT, CYCLE&amp;lt;/code&amp;gt; statements or a contained &amp;lt;code&amp;gt;SUBROUTINE&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
* I/O routines &amp;lt;code&amp;gt;END&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;ERR&amp;lt;/code&amp;gt; - use &amp;lt;code&amp;gt;IOSTAT&amp;lt;/code&amp;gt; instead&lt;br /&gt;
* &amp;lt;code&amp;gt;FORMAT&amp;lt;/code&amp;gt; statements: use character parameters or explicit format- specifiers inside the &amp;lt;code&amp;gt;READ&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;WRITE&amp;lt;/code&amp;gt; statement instead.&lt;br /&gt;
* &amp;lt;code&amp;gt;ENTRY&amp;lt;/code&amp;gt; statements: a subprogram must only have one entry point&lt;br /&gt;
* ''Alternate'' &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; is obsolescent, and &amp;lt;code&amp;gt;RETURN&amp;lt;/code&amp;gt; at the end of a function is useless clutter.&lt;br /&gt;
* Statement functions have been replaced by corresponding functions or subroutines in the &amp;lt;code&amp;gt;CONTAIN&amp;lt;/code&amp;gt; block of the current scope.&lt;br /&gt;
* &amp;lt;code&amp;gt;DATA&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;BLOCK DATA&amp;lt;/code&amp;gt; should be replaced by initializers.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Questions à élucider ==&lt;br /&gt;
&lt;br /&gt;
* Prescrit-on une langue (Français / Anglais) ?&lt;br /&gt;
* Longueur des lignes: dans la limite du raisonable, pourquoi se limiter à 100-140 chars ? Le wrapping fonctionne très bien.&lt;br /&gt;
*&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=476</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=476"/>
				<updated>2024-07-24T15:47:43Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!! File: lmdz_mymodule.f90&lt;br /&gt;
!!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
!!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
!! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
! implementation of my_useful_stuff.&lt;br /&gt;
! ----------------------------------&lt;br /&gt;
&lt;br /&gt;
!! Unless specified otherwise, all files should contain a single module with the same name which encapsulates all their content&lt;br /&gt;
MODULE lmdz_mymodule&lt;br /&gt;
!!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
  USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
  !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
!!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
  IMPLICIT NONE; PRIVATE&lt;br /&gt;
  !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
  !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
  PUBLIC my_var, my_subroutine&lt;br /&gt;
&lt;br /&gt;
  REAL, PARAMETER :: my_var&lt;br /&gt;
  REAL            :: a, b, c, d, e, f&lt;br /&gt;
  !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
  !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
        &lt;br /&gt;
CONTAINS&lt;br /&gt;
  &lt;br /&gt;
 !! Put at least a blank line before/after each function/subroutine&lt;br /&gt;
  SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
  !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
  !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
    INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
    !!          ^ Always provide intent &lt;br /&gt;
    REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
    INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
    REAl, INTENT(OUT) :: out1&lt;br /&gt;
    !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
    IF (arg2 &amp;gt; arg1) THEN&lt;br /&gt;
    !!       ^ .ge., .le., etc are deprecated. Use &amp;gt;, &amp;lt;, ==, etc instead&lt;br /&gt;
      ! ...&lt;br /&gt;
    END IF&lt;br /&gt;
    !! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)&lt;br /&gt;
  END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
END MODULE my_module&lt;br /&gt;
!!       ^ always use named blocks for END&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Some comments:&lt;br /&gt;
* Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
* Limit the use of &amp;lt;code&amp;gt;include&amp;lt;/code&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=475</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=475"/>
				<updated>2024-07-24T15:46:58Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!! File: lmdz_mymodule.f90&lt;br /&gt;
!!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
!!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
!! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
! implementation of my_useful_stuff.&lt;br /&gt;
! ----------------------------------&lt;br /&gt;
&lt;br /&gt;
!! Unless specified otherwise, all files should contain a single module which encapsulates all their content&lt;br /&gt;
MODULE lmdz_mymodule&lt;br /&gt;
!!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
  USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
  !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
!!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
  IMPLICIT NONE; PRIVATE&lt;br /&gt;
  !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
  !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
  PUBLIC my_var, my_subroutine&lt;br /&gt;
&lt;br /&gt;
  REAL, PARAMETER :: my_var&lt;br /&gt;
  REAL            :: a, b, c, d, e, f&lt;br /&gt;
  !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
  !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
        &lt;br /&gt;
CONTAINS&lt;br /&gt;
  &lt;br /&gt;
 !! Put at least a blank line before/after each function/subroutine&lt;br /&gt;
  SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
  !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
  !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
    INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
    !!          ^ Always provide intent &lt;br /&gt;
    REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
    INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
    REAl, INTENT(OUT) :: out1&lt;br /&gt;
    !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
    IF (arg2 &amp;gt; arg1) THEN&lt;br /&gt;
    !!       ^ .ge., .le., etc are deprecated. Use &amp;gt;, &amp;lt;, ==, etc instead&lt;br /&gt;
      ! ...&lt;br /&gt;
    END IF&lt;br /&gt;
    !! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)&lt;br /&gt;
  END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
END MODULE my_module&lt;br /&gt;
!!       ^ always use named blocks for END&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Some comments:&lt;br /&gt;
* Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
* Limit the use of &amp;lt;code&amp;gt;include&amp;lt;/code&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=474</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=474"/>
				<updated>2024-07-18T11:17:02Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!! File: lmdz_mymodule.f90&lt;br /&gt;
!!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
!!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
!! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
! implementation of my_useful_stuff.&lt;br /&gt;
! ----------------------------------&lt;br /&gt;
&lt;br /&gt;
!! Unless specified otherwise, all files should contain a single module which encapsulates all their content&lt;br /&gt;
MODULE my_module&lt;br /&gt;
!!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
  USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
  !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
!!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
  IMPLICIT NONE; PRIVATE&lt;br /&gt;
  !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
  !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
  PUBLIC my_var, my_subroutine&lt;br /&gt;
&lt;br /&gt;
  REAL, PARAMETER :: my_var&lt;br /&gt;
  REAL            :: a, b, c, d, e, f&lt;br /&gt;
  !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
  !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
        &lt;br /&gt;
CONTAINS&lt;br /&gt;
  &lt;br /&gt;
 !! Put at least a blank line before/after each function/subroutine&lt;br /&gt;
  SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
  !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
  !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
    INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
    !!          ^ Always provide intent &lt;br /&gt;
    REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
    INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
    REAl, INTENT(OUT) :: out1&lt;br /&gt;
    !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
    IF (arg2 &amp;gt; arg1) THEN&lt;br /&gt;
    !!       ^ .ge., .le., etc are deprecated. Use &amp;gt;, &amp;lt;, ==, etc instead&lt;br /&gt;
      ! ...&lt;br /&gt;
    END IF&lt;br /&gt;
    !! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)&lt;br /&gt;
  END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
END MODULE my_module&lt;br /&gt;
!!       ^ always use named blocks for END&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Some comments:&lt;br /&gt;
* Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
* Limit the use of &amp;lt;code&amp;gt;include&amp;lt;/code&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=473</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=473"/>
				<updated>2024-07-18T11:16:27Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;fortran&amp;quot; line&amp;gt;&lt;br /&gt;
!! File: lmdz_mymodule.f90&lt;br /&gt;
!!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
!!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
!! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
! implementation of my_useful_stuff.&lt;br /&gt;
! ----------------------------------&lt;br /&gt;
&lt;br /&gt;
!! Unless specified otherwise, all files should contain a single module which encapsulates all their content&lt;br /&gt;
MODULE my_module&lt;br /&gt;
!!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
  USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
  !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
!!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
  IMPLICIT NONE; PRIVATE&lt;br /&gt;
  !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
  !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
  PUBLIC my_var, my_subroutine&lt;br /&gt;
&lt;br /&gt;
  REAL, PARAMETER :: my_var&lt;br /&gt;
  REAL            :: a, b, c, d, e, f&lt;br /&gt;
  !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
  !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
        &lt;br /&gt;
CONTAINS&lt;br /&gt;
  &lt;br /&gt;
 !! Put at least a blank line before/after each function/subroutine&lt;br /&gt;
  SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
  !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
  !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
    INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
    !!          ^ Always provide intent &lt;br /&gt;
    REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
    INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
    REAl, INTENT(OUT) :: out1&lt;br /&gt;
    !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
    IF (arg2 &amp;gt; arg1) THEN&lt;br /&gt;
    !!       ^ .ge., .le., etc are deprecated. Use &amp;gt;, &amp;lt;, ==, etc instead&lt;br /&gt;
      ! ...&lt;br /&gt;
    END IF&lt;br /&gt;
    !! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)&lt;br /&gt;
  END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
END MODULE my_module&lt;br /&gt;
!!       ^ always use named blocks for END&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Some comments:&lt;br /&gt;
* Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
* Limit the use of &amp;lt;include&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=472</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=472"/>
				<updated>2024-07-18T11:11:56Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 !! File: lmdz_mymodule.f90&lt;br /&gt;
 !!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
 !!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
 &lt;br /&gt;
 !! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
 ! implementation of my_useful_stuff.&lt;br /&gt;
 ! ----------------------------------&lt;br /&gt;
 &lt;br /&gt;
 !! Unless specified otherwise, all files should contain a single module which encapsulates all their content&lt;br /&gt;
 MODULE my_module&lt;br /&gt;
 !!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
   USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
   !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
 !!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
   IMPLICIT NONE; PRIVATE&lt;br /&gt;
   !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
   !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
   PUBLIC my_var, my_subroutine&lt;br /&gt;
 &lt;br /&gt;
   REAL, PARAMETER :: my_var&lt;br /&gt;
   REAL            :: a, b, c, d, e, f&lt;br /&gt;
   !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
   !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
         &lt;br /&gt;
 CONTAINS&lt;br /&gt;
   &lt;br /&gt;
  !! Put at least a blank line before/after each function/subroutine&lt;br /&gt;
   SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
   !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
   !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
     INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
     !!          ^ Always provide intent &lt;br /&gt;
     REAL, INTENT(IN)    :: arg2&lt;br /&gt;
 &lt;br /&gt;
 &lt;br /&gt;
     INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
 &lt;br /&gt;
     REAl, INTENT(OUT) :: out1&lt;br /&gt;
     !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
 &lt;br /&gt;
     ! ... body of my_subroutine&lt;br /&gt;
     IF (arg2 &amp;gt; arg1) THEN&lt;br /&gt;
     !!       ^ .ge., .le., etc are deprecated. Use &amp;gt;, &amp;lt; ==, etc instead&lt;br /&gt;
       ! ...&lt;br /&gt;
     END IF&lt;br /&gt;
     !! ^ Use END IF, END DO rather than ENDIF, ENDDO (coherence with fortran-lang.org)&lt;br /&gt;
   END SUBROUTINE my_subroutine&lt;br /&gt;
 !!         ^ always use named blocks for END&lt;br /&gt;
   &lt;br /&gt;
 &lt;br /&gt;
 END MODULE my_module&lt;br /&gt;
 !!       ^ always use named blocks for END&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Some comments:&lt;br /&gt;
* Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
* Limit the use of &amp;lt;include&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=471</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=471"/>
				<updated>2024-07-18T10:54:08Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 !! File: lmdz_mymodule.f90&lt;br /&gt;
 !!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
 !!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
 &lt;br /&gt;
 !! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
 ! implementation of my_useful_stuff.&lt;br /&gt;
 ! ----------------------------------&lt;br /&gt;
 &lt;br /&gt;
 !! Unless specified otherwise, all files should contain a single module which encapsulates all their content&lt;br /&gt;
 MODULE my_module&lt;br /&gt;
 !!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
   USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
   !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
 !!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
   IMPLICIT NONE; PRIVATE&lt;br /&gt;
   !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
   !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
   PUBLIC my_var, my_subroutine&lt;br /&gt;
 &lt;br /&gt;
   REAL, PARAMETER :: my_var&lt;br /&gt;
   REAL            :: a, b, c, d, e, f&lt;br /&gt;
   !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
   !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
         &lt;br /&gt;
 CONTAINS&lt;br /&gt;
   &lt;br /&gt;
  !! Put at least a blank line before/after each function/subroutine&lt;br /&gt;
   SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
   !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
   !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
     INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
     !!          ^ Always provide intent &lt;br /&gt;
     REAL, INTENT(IN)    :: arg2&lt;br /&gt;
 &lt;br /&gt;
 &lt;br /&gt;
     INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
 &lt;br /&gt;
     REAl, INTENT(OUT) :: out1&lt;br /&gt;
     !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
 &lt;br /&gt;
     ! ... body of my_subroutine&lt;br /&gt;
   END SUBROUTINE my_subroutine&lt;br /&gt;
 !!         ^ always use named blocks for END&lt;br /&gt;
   &lt;br /&gt;
 &lt;br /&gt;
 END MODULE my_module&lt;br /&gt;
 !!       ^ always use named blocks for END&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Some comments:&lt;br /&gt;
* Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
* Limit the use of &amp;lt;include&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=470</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=470"/>
				<updated>2024-07-18T10:53:36Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 !! File: lmdz_mymodule.f90&lt;br /&gt;
 !!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
 !!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
 &lt;br /&gt;
 !! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
 ! implementation of my_useful_stuff.&lt;br /&gt;
 ! ----------------------------------&lt;br /&gt;
 &lt;br /&gt;
 !! Unless specified otherwise, all files should contain a single module which encapsulates all their content&lt;br /&gt;
 MODULE my_module&lt;br /&gt;
 !!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
   USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
   !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
 !!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
   IMPLICIT NONE; PRIVATE&lt;br /&gt;
   !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
   !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
   PUBLIC my_var, my_subroutine&lt;br /&gt;
 &lt;br /&gt;
   REAL, PARAMETER :: my_var&lt;br /&gt;
   REAL            :: a, b, c, d, e, f&lt;br /&gt;
   !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
   !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
         &lt;br /&gt;
 CONTAINS&lt;br /&gt;
   &lt;br /&gt;
  !! Put at least a blank line before/after each function/subroutine&lt;br /&gt;
   SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
   !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
   !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
     INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
     !!          ^ Always provide intent &lt;br /&gt;
     REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
     INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
     REAl, INTENT(OUT) :: out1&lt;br /&gt;
     !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
     ! ... body of my_subroutine&lt;br /&gt;
   END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
   &lt;br /&gt;
 &lt;br /&gt;
 END MODULE my_module&lt;br /&gt;
 !!       ^ always use named blocks for END&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Some comments:&lt;br /&gt;
* Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
* Limit the use of &amp;lt;include&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=469</id>
		<title>HowTo: LMDZ code guidelines</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_LMDZ_code_guidelines&amp;diff=469"/>
				<updated>2024-07-18T10:53:19Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : (WIP)  very rough example&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\&lt;br /&gt;
&lt;br /&gt;
== Example code ==&lt;br /&gt;
&lt;br /&gt;
''Note: in this example, we added &amp;quot;meta-comments&amp;quot; indicated by &amp;lt;code&amp;gt;!!&amp;lt;/code&amp;gt;''&lt;br /&gt;
&lt;br /&gt;
''Note: of course, there's always exceptions to &amp;quot;Always&amp;quot;, but they should '''systematically''' documented by a comment, with a proper explanation.''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 !! File: lmdz_mymodule.f90&lt;br /&gt;
 !!         ^ all module files should start with their component name, (e.g. &amp;quot;lmdz&amp;quot;)&lt;br /&gt;
 !!                      ^ use &amp;quot;.f90&amp;quot; for all free-form files, unless they contain preprocessor directives (then use &amp;quot;.F90&amp;quot;).&lt;br /&gt;
 &lt;br /&gt;
 !! At the top of the file, we provide a comment to explain what this modules does&lt;br /&gt;
 ! implementation of my_useful_stuff.&lt;br /&gt;
 ! ----------------------------------&lt;br /&gt;
 &lt;br /&gt;
 !! Unless specified otherwise, all files should contain a single module which encapsulates all their content&lt;br /&gt;
 MODULE my_module&lt;br /&gt;
 !!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.&lt;br /&gt;
   USE my_other_module, ONLY: function_a, function_b&lt;br /&gt;
   !!                     ^ Always specify explicitely which functions you use from a module.&lt;br /&gt;
!!^ use indentation (2 spaces) to provide visual clarity&lt;br /&gt;
   IMPLICIT NONE; PRIVATE&lt;br /&gt;
   !!                ^ Always make your module private, and expose explicitely which functions are public&lt;br /&gt;
   !!    ^ Always use IMPLICIT NONE at the module-level&lt;br /&gt;
   PUBLIC my_var, my_subroutine&lt;br /&gt;
 &lt;br /&gt;
   REAL, PARAMETER :: my_var&lt;br /&gt;
   REAL            :: a, b, c, d, e, f&lt;br /&gt;
   !!               ^ use &amp;quot;::&amp;quot; even if it's not strictly necessary&lt;br /&gt;
   !!       ^ Alignment of &amp;quot;::&amp;quot; is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)&lt;br /&gt;
         &lt;br /&gt;
 CONTAINS&lt;br /&gt;
   &lt;br /&gt;
  !! Put at least a blank line before/after each function/subroutine&lt;br /&gt;
   SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx&lt;br /&gt;
   !!                            ^ comments should always be right before, or on the same line as what they're commenting&lt;br /&gt;
   !!                            ^ as for modules, all functions should be documented in a comment&lt;br /&gt;
     INTEGER, INTENT(IN) :: arg1&lt;br /&gt;
     !!          ^ Always provide intent &lt;br /&gt;
     REAL, INTENT(IN)    :: arg2&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
     INTEGER, INTENT(INOUT) :: arg3&lt;br /&gt;
&lt;br /&gt;
     REAl, INTENT(OUT) :: out1&lt;br /&gt;
     !!^ Group together IN, then INOUT, then OUT&lt;br /&gt;
&lt;br /&gt;
     ! ... body of my_subroutine&lt;br /&gt;
   END SUBROUTINE my_subroutine&lt;br /&gt;
!!         ^ always use named blocks for END&lt;br /&gt;
   &lt;br /&gt;
 &lt;br /&gt;
 END MODULE my_module&lt;br /&gt;
 !!       ^ always use named blocks for END&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Some comments:&lt;br /&gt;
* Limit '''to the bare minimum''' the use of preprocessor &amp;lt;code&amp;gt;#ifdef&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
* Limit the use of &amp;lt;include&amp;gt; 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 &amp;lt;code&amp;gt;ONLY: ...&amp;lt;/code&amp;gt;.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_Bind_MPI_%26_pin_OMP_threads_on_clusters&amp;diff=468</id>
		<title>HowTo: Bind MPI &amp; pin OMP threads on clusters</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_Bind_MPI_%26_pin_OMP_threads_on_clusters&amp;diff=468"/>
				<updated>2024-07-17T06:46:44Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : Add binding page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;We highly recommend reading the [https://dci.dci-gitlab.cines.fr/webextranet/porting_optimization/index.html#performance-tuning-and-monitoring Adastra documentation] on the matter for more details.&lt;br /&gt;
&lt;br /&gt;
 ''Note: As LMDZ only supports CPU for now, this page only addresses CPU binding.''&lt;br /&gt;
&lt;br /&gt;
== CPU Binding &amp;amp; Pinning ==&lt;br /&gt;
&lt;br /&gt;
=== Binding &amp;amp; Pinning: What and Why ===&lt;br /&gt;
&lt;br /&gt;
Binding / pinning refers to the action of specifying how each MPI / OMP thread is distributed on a computing node.&lt;br /&gt;
If left unspecified, the following can happen:&lt;br /&gt;
* MPI/OMP threads that communicate closely can get assigned to threads that are &amp;quot;far apart&amp;quot;, inducing significant communication overhead,&lt;br /&gt;
* MPI and OMP threads can get assigned to the same physical thread, reducing significantly performance,&lt;br /&gt;
* OMP threads can &amp;quot;move&amp;quot; during the execution, further exacerbating the two points above.&lt;br /&gt;
&lt;br /&gt;
On Intel architectures (e.g. on JeanZay), the default scheduler does a fairly good job of binding/pinning automatically. However on AMD architectures (e.g. on Adastra), this is not the case, and users should provide their own explicit binding/pinning.&lt;br /&gt;
&lt;br /&gt;
 ''Example'': on Adastra, specifying proper bindings for [[LMDZ Setup|LMDZ Setup]] results in a x4-x6 speedup !&lt;br /&gt;
&lt;br /&gt;
* ''Note'': although not &amp;quot;required&amp;quot; on JeanZay, it's still a good practice !''&lt;br /&gt;
&lt;br /&gt;
=== Binding &amp;amp; Pinning: How ===&lt;br /&gt;
&lt;br /&gt;
 ''Note: this section assumes you are running on exclusive nodes, on a SLURM cluster''&lt;br /&gt;
&lt;br /&gt;
The easiest way to &amp;quot;automatically&amp;quot; set good-enough binding/pinning is to use &amp;lt;code&amp;gt;slurm_set_cpu_binding.sh&amp;lt;/code&amp;gt; from [[LMDZ Setup|LMDZ Setup]]. This script reads the number of required MPI and OMP tasks from environment variables &amp;lt;code&amp;gt;$SLURM_NTASKS_PER_NODE, $OMP_NUM_THREADS&amp;lt;/code&amp;gt;, and from the system information creates a binding table. It then leverages &amp;lt;code&amp;gt;$OMP_PLACES&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;numactl&amp;lt;/code&amp;gt; to execute the binding.&lt;br /&gt;
&lt;br /&gt;
* ''Note: the script will automatically use hyperthreading (SMT) if you require more MPIxOMP than there are non-SMT cores on the system.''&lt;br /&gt;
&lt;br /&gt;
Since we manually set the binding, we must disable slurm's auto-binding using &amp;lt;code&amp;gt;--cpu-bind=none --mem-bind=none&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
'''Typical use: &amp;lt;code&amp;gt;srun --cpu-bind=none --mem-bind=none -- ./slurm_set_cpu_binding.sh ./gcm.e&amp;lt;/code&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
* ''Note'': Here we don't need to specify a number of tasks for &amp;lt;code&amp;gt;srun&amp;lt;/code&amp;gt;, as it will be automatically inferred from &amp;lt;code&amp;gt;$SLURM_NTASKS_PER_NODE&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== A note on SMT (hyperthreading) ===&lt;br /&gt;
&lt;br /&gt;
Thanks to this binding, we can properly investigate the effects of using SMT hyperthreading. As of 06/24, a bench using [[LMDZ Setup|LMDZ Setup]] on Adastra reveals that there's barely any performance gain in using SMT.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_Profiling_LMDZ&amp;diff=467</id>
		<title>HowTo: Profiling LMDZ</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_Profiling_LMDZ&amp;diff=467"/>
				<updated>2024-07-16T19:18:26Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : add minor details&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Profiling with gprof ==&lt;br /&gt;
&lt;br /&gt;
The legacy way to profile the model is using &amp;lt;code&amp;gt;gprof&amp;lt;/code&amp;gt;.&lt;br /&gt;
* ''Pros:'' available everywhere, easy to use&lt;br /&gt;
* ''Cons:'' old, bad handling of multithreaded applications, requires instrumentation&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;gprof&amp;lt;/code&amp;gt; is a rudimentary but simple to use tool to profile a sequential executable.&lt;br /&gt;
&lt;br /&gt;
''Note: a new tool [https://sourceware.org/pipermail/binutils/2021-August/117665.html gprofng] is currently being developed with several notable improvements including multithreading support. As of 06/24, it doesn't support Fortran yet.&lt;br /&gt;
&lt;br /&gt;
==== Instrumenting the code ====&lt;br /&gt;
&lt;br /&gt;
In the &amp;lt;code&amp;gt;.fcm&amp;lt;/code&amp;gt; arch file used, add &amp;lt;code&amp;gt;-pg&amp;lt;/code&amp;gt; to &amp;lt;code&amp;gt;BASE_FFLAGS&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;BASE_LD&amp;lt;/code&amp;gt;. Recompile the model.&lt;br /&gt;
&lt;br /&gt;
==== Collecting statistics ====&lt;br /&gt;
&lt;br /&gt;
Run the executable &amp;lt;code&amp;gt;gcm.e&amp;lt;/code&amp;gt;. This will generate a &amp;lt;code&amp;gt;gmon.out&amp;lt;/code&amp;gt; file locally.&lt;br /&gt;
&lt;br /&gt;
==== Reading results ====&lt;br /&gt;
&lt;br /&gt;
Run &amp;lt;code&amp;gt;gprof gcm.e gmon.out &amp;gt; profiling.txt&amp;lt;/code&amp;gt; to get a textual view of the profiling.&lt;br /&gt;
&lt;br /&gt;
For a graphical representation, we recommend using [https://github.com/jrfonseca/gprof2dot gprof2dot], via &amp;lt;code&amp;gt;gprof gcm.e | gprof2dot | dot -Tpng -o output.png&amp;lt;/code&amp;gt;. A typical example is shown below.&lt;br /&gt;
&lt;br /&gt;
[[Fichier:gprof.png|800px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Profiling with scorep &amp;amp; scalasca ==&lt;br /&gt;
&lt;br /&gt;
Scalasca ([https://www.scalasca.org/ home], [https://apps.fz-juelich.de/scalasca/releases/scalasca/2.6/docs/manual/ manual]) is a profiling suite developed by Technische Universität Darmstadt Laboratory for Parallel Programming. It is much more capable than &amp;lt;code&amp;gt;gprof&amp;lt;/code&amp;gt;, but also requires a heavier setup.&lt;br /&gt;
* ''Pros:'' much better overall: excellent multithreaded support with separation between USR/OMP/MPI, filtering, trace profiling, great visualisation, highly customizable&lt;br /&gt;
* ''Cons:'' requires a trickier installation, more complex&lt;br /&gt;
&lt;br /&gt;
=== Installing scalasca ===&lt;br /&gt;
&lt;br /&gt;
Some supercomputers have scalasca installed already, but for completeness here's a short guide to installing it locally (written 06/24, for v2.6.1):&lt;br /&gt;
&lt;br /&gt;
All dependencies can be downloaded from [https://www.scalasca.org/scalasca/software/scalasca-2.x/requirements.html here].&lt;br /&gt;
&lt;br /&gt;
==== Compiling CubeBundle / CubeLib ====&lt;br /&gt;
&lt;br /&gt;
''Note: If you're on your own computer, we recommend installing CubeBundle, which includes CubeGUI. This requires Qt5 and OpenGL, which are a pain to install on supercomputers without sudo. For supercomputer local install, we recommand installing CubeW+CubeLib instead, and visualizing the results on your own computer.''&lt;br /&gt;
&lt;br /&gt;
No special instruction here - simply get the sources on the link above, extract them locally, and run &amp;lt;code&amp;gt;./configure --prefix=... &amp;amp;&amp;amp; make -j 8 &amp;amp;&amp;amp; make install&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Compiling scorep ====&lt;br /&gt;
&lt;br /&gt;
Scalasca relies on &amp;lt;code&amp;gt;scorep&amp;lt;/code&amp;gt; to instrument your code for profiling.&lt;br /&gt;
&lt;br /&gt;
On clusters like Adastra, you need to make sure that &amp;lt;code&amp;gt;clang&amp;lt;/code&amp;gt; in your path points to the system install: &amp;lt;code&amp;gt;LD_LIBRARY_PATH=&amp;quot;/usr/lib64:$LD_LIBRARY_PATH&amp;quot; ./configure --prefix=... &amp;amp;&amp;amp; LD_LIBRARY_PATH=&amp;quot;/usr/lib64:$LD_LIBRARY_PATH&amp;quot; make -j 8 &amp;amp;&amp;amp; make install&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: make sure to load the right environment before compiling ! &amp;lt;code&amp;gt;scorep&amp;lt;/code&amp;gt; can only instrument compilers it has detected when configured.''&lt;br /&gt;
&lt;br /&gt;
==== Compiling scalasca ====&lt;br /&gt;
&lt;br /&gt;
Usual process: &amp;lt;code&amp;gt;./configure --prefix=... &amp;amp;&amp;amp; make -j 8 &amp;amp;&amp;amp; make install&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: Scalasca doesn't seem to like gcc-13 very much, but it doesn't need to be compiled with the same compiler as &amp;lt;code&amp;gt;scorep&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
''Note: On Adastra, you need &amp;lt;code&amp;gt;module load craype-x86-trento&amp;lt;/code&amp;gt; and we recommend &amp;lt;code&amp;gt;module load gcc/12.2.0&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
''Note: To perform traces, Scalasca requires executables in &amp;lt;code&amp;gt;$install_dir/bin/backend/&amp;lt;/code&amp;gt; to be in the path. You can safely simply copy them to &amp;lt;code&amp;gt;$install_dir/bin/&amp;lt;/code&amp;gt; and add that to the path instead.''&lt;br /&gt;
&lt;br /&gt;
=== Using scalasca ===&lt;br /&gt;
&lt;br /&gt;
''Note: in doubt, read the [https://apps.fz-juelich.de/scalasca/releases/scalasca/2.6/docs/manual/ manual], it's short and to the point.&lt;br /&gt;
&lt;br /&gt;
==== Instrumenting the code ====&lt;br /&gt;
&lt;br /&gt;
In the &amp;lt;code&amp;gt;.fcm&amp;lt;/code&amp;gt; arch file used, replace the compiler (e.g. &amp;lt;code&amp;gt;mpif90,mpicc&amp;lt;/code&amp;gt;) by &amp;lt;code&amp;gt;scorep $compiler&amp;lt;/code&amp;gt; (e.g. &amp;lt;code&amp;gt;scorep mpif90&amp;lt;/code&amp;gt;). Recompile the model.&lt;br /&gt;
&lt;br /&gt;
''Note: make sure to replace both the compiler and the linker. Do not replace the preprocessors.''&lt;br /&gt;
&lt;br /&gt;
==== Collecting statistics ====&lt;br /&gt;
&lt;br /&gt;
Run &amp;lt;code&amp;gt;scalasca -analyze $my_cmd&amp;lt;/code&amp;gt;, e.g. &amp;lt;code&amp;gt;OMP_NUM_THREADS=2 scalasca -analyze mpirun -n 4 gcm.e&amp;lt;/code&amp;gt;. This will generate a &amp;lt;code&amp;gt;scorep-gcm_4x2_sum&amp;lt;/code&amp;gt; folder locally.&lt;br /&gt;
&lt;br /&gt;
''Note: if the folder already exists, the analysis will halt.''&lt;br /&gt;
&lt;br /&gt;
==== Reading results ====&lt;br /&gt;
&lt;br /&gt;
''Note: if you are running on a cluster with CubeLib+CubeW as explained above, copy the generated folder &amp;lt;code&amp;gt;scorep-*&amp;lt;/code&amp;gt; to the machine where you installed CubeBundle for the visualization.''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Run &amp;lt;code&amp;gt;scalasca -examine scorep-*&amp;lt;/code&amp;gt;. The first time ran it will first compute some statistics, then it will open the results in CubeGUI.&lt;br /&gt;
&lt;br /&gt;
[[Fichier:scalsca-cubeGUI.png|800px]]&lt;br /&gt;
&lt;br /&gt;
[[Category:HowTo]]&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_Profiling_LMDZ&amp;diff=466</id>
		<title>HowTo: Profiling LMDZ</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_Profiling_LMDZ&amp;diff=466"/>
				<updated>2024-07-16T18:42:27Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : Add scalsca use&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Profiling with gprof ==&lt;br /&gt;
&lt;br /&gt;
The legacy way to profile the model is using &amp;lt;code&amp;gt;gprof&amp;lt;/code&amp;gt;.&lt;br /&gt;
* ''Pros:'' available everywhere, easy to use&lt;br /&gt;
* ''Cons:'' old, bad handling of multithreaded applications, requires instrumentation&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;gprof&amp;lt;/code&amp;gt; is a rudimentary but simple to use tool to profile a sequential executable.&lt;br /&gt;
&lt;br /&gt;
''Note: a new tool [https://sourceware.org/pipermail/binutils/2021-August/117665.html gprofng] is currently being developed with several notable improvements including multithreading support. As of 06/24, it doesn't support Fortran yet.&lt;br /&gt;
&lt;br /&gt;
==== Instrumenting the code ====&lt;br /&gt;
&lt;br /&gt;
In the &amp;lt;code&amp;gt;.fcm&amp;lt;/code&amp;gt; arch file used, add &amp;lt;code&amp;gt;-pg&amp;lt;/code&amp;gt; to &amp;lt;code&amp;gt;BASE_FFLAGS&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;BASE_LD&amp;lt;/code&amp;gt;. Recompile the model.&lt;br /&gt;
&lt;br /&gt;
==== Collecting statistics ====&lt;br /&gt;
&lt;br /&gt;
Run the executable &amp;lt;code&amp;gt;gcm.e&amp;lt;/code&amp;gt;. This will generate a &amp;lt;code&amp;gt;gmon.out&amp;lt;/code&amp;gt; file locally.&lt;br /&gt;
&lt;br /&gt;
==== Reading results ====&lt;br /&gt;
&lt;br /&gt;
Run &amp;lt;code&amp;gt;gprof gcm.e gmon.out &amp;gt; profiling.txt&amp;lt;/code&amp;gt; to get a textual view of the profiling.&lt;br /&gt;
&lt;br /&gt;
For a graphical representation, we recommend using [https://github.com/jrfonseca/gprof2dot gprof2dot], via &amp;lt;code&amp;gt;gprof gcm.e | gprof2dot | dot -Tpng -o output.png&amp;lt;/code&amp;gt;. A typical example is shown below.&lt;br /&gt;
&lt;br /&gt;
[[Fichier:gprof.png|800px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Profiling with scorep &amp;amp; scalasca ==&lt;br /&gt;
&lt;br /&gt;
Scalasca ([https://www.scalasca.org/ home], [https://apps.fz-juelich.de/scalasca/releases/scalasca/2.6/docs/manual/ manual]) is a profiling suite developed by Technische Universität Darmstadt Laboratory for Parallel Programming. It is much more capable than &amp;lt;code&amp;gt;gprof&amp;lt;/code&amp;gt;, but also requires a heavier setup.&lt;br /&gt;
&lt;br /&gt;
=== Installing scalasca ===&lt;br /&gt;
&lt;br /&gt;
Some supercomputers have scalasca installed already, but for completeness here's a short guide to installing it locally (written 06/24, for v2.6.1):&lt;br /&gt;
&lt;br /&gt;
All dependencies can be downloaded from [https://www.scalasca.org/scalasca/software/scalasca-2.x/requirements.html here].&lt;br /&gt;
&lt;br /&gt;
==== Compiling CubeBundle / CubeLib ====&lt;br /&gt;
&lt;br /&gt;
''Note: If you're on your own computer, we recommend installing CubeBundle, which includes CubeGUI. This requires Qt5 and OpenGL, which are a pain to install on supercomputers without sudo. For supercomputer local install, we recommand installing CubeW+CubeLib instead, and visualizing the results on your own computer.''&lt;br /&gt;
&lt;br /&gt;
No special instruction here - simply get the sources on the link above, extract them locally, and run &amp;lt;code&amp;gt;./configure --prefix=... &amp;amp;&amp;amp; make -j 8 &amp;amp;&amp;amp; make install&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Compiling scorep ====&lt;br /&gt;
&lt;br /&gt;
Scalasca relies on &amp;lt;code&amp;gt;scorep&amp;lt;/code&amp;gt; to instrument your code for profiling.&lt;br /&gt;
&lt;br /&gt;
On clusters like Adastra, you need to make sure that &amp;lt;code&amp;gt;clang&amp;lt;/code&amp;gt; in your path points to the system install: &amp;lt;code&amp;gt;LD_LIBRARY_PATH=&amp;quot;/usr/lib64:$LD_LIBRARY_PATH&amp;quot; ./configure --prefix=... &amp;amp;&amp;amp; LD_LIBRARY_PATH=&amp;quot;/usr/lib64:$LD_LIBRARY_PATH&amp;quot; make -j 8 &amp;amp;&amp;amp; make install&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: make sure to load the right environment before compiling ! &amp;lt;code&amp;gt;scorep&amp;lt;/code&amp;gt; can only instrument compilers it has detected when configured.''&lt;br /&gt;
&lt;br /&gt;
==== Compiling scalasca ====&lt;br /&gt;
&lt;br /&gt;
Usual process: &amp;lt;code&amp;gt;./configure --prefix=... &amp;amp;&amp;amp; make -j 8 &amp;amp;&amp;amp; make install&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: Scalasca doesn't seem to like gcc-13 very much, but it doesn't need to be compiled with the same compiler as &amp;lt;code&amp;gt;scorep&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
''Note: On Adastra, you need &amp;lt;code&amp;gt;module load craype-x86-trento&amp;lt;/code&amp;gt; and we recommend &amp;lt;code&amp;gt;module load gcc/12.2.0&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
''Note: To perform traces, Scalasca requires executables in &amp;lt;code&amp;gt;$install_dir/bin/backend/&amp;lt;/code&amp;gt; to be in the path. You can safely simply copy them to &amp;lt;code&amp;gt;$install_dir/bin/&amp;lt;/code&amp;gt; and add that to the path instead.''&lt;br /&gt;
&lt;br /&gt;
=== Using scalasca ===&lt;br /&gt;
&lt;br /&gt;
''Note: in doubt, read the [https://apps.fz-juelich.de/scalasca/releases/scalasca/2.6/docs/manual/ manual], it's short and to the point.&lt;br /&gt;
&lt;br /&gt;
==== Instrumenting the code ====&lt;br /&gt;
&lt;br /&gt;
In the &amp;lt;code&amp;gt;.fcm&amp;lt;/code&amp;gt; arch file used, replace the compiler (e.g. &amp;lt;code&amp;gt;mpif90,mpicc&amp;lt;/code&amp;gt;) by &amp;lt;code&amp;gt;scorep $compiler&amp;lt;/code&amp;gt; (e.g. &amp;lt;code&amp;gt;scorep mpif90&amp;lt;/code&amp;gt;). Recompile the model.&lt;br /&gt;
&lt;br /&gt;
''Note: make sure to replace both the compiler and the linker. Do not replace the preprocessors.''&lt;br /&gt;
&lt;br /&gt;
==== Collecting statistics ====&lt;br /&gt;
&lt;br /&gt;
Run &amp;lt;code&amp;gt;scalasca -analyze $my_cmd&amp;lt;/code&amp;gt;, e.g. &amp;lt;code&amp;gt;OMP_NUM_THREADS=2 scalasca -analyze mpirun -n 4 gcm.e&amp;lt;/code&amp;gt;. This will generate a &amp;lt;code&amp;gt;scorep-gcm_4x2_sum&amp;lt;/code&amp;gt; folder locally.&lt;br /&gt;
&lt;br /&gt;
''Note: if the folder already exists, the analysis will halt.''&lt;br /&gt;
&lt;br /&gt;
==== Reading results ====&lt;br /&gt;
&lt;br /&gt;
''Note: if you are running on a cluster with CubeLib+CubeW as explained above, copy the generated folder &amp;lt;code&amp;gt;scorep-*&amp;lt;/code&amp;gt; to the machine where you installed CubeBundle for the visualization.''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Run &amp;lt;code&amp;gt;scalasca -examine scorep-*&amp;lt;/code&amp;gt;. The first time ran it will first compute some statistics, then it will open the results in CubeGUI.&lt;br /&gt;
&lt;br /&gt;
[[Fichier:scalsca-cubeGUI.png|800px]]&lt;br /&gt;
&lt;br /&gt;
[[Category:HowTo]]&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Fichier:Scalsca-cubeGUI.png&amp;diff=465</id>
		<title>Fichier:Scalsca-cubeGUI.png</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Fichier:Scalsca-cubeGUI.png&amp;diff=465"/>
				<updated>2024-07-16T18:40:50Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : A typical visualization of a scalsca profile.

Ran on LMDZ_Setup on Adastra.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A typical visualization of a scalsca profile.&lt;br /&gt;
&lt;br /&gt;
Ran on LMDZ_Setup on Adastra.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_Profiling_LMDZ&amp;diff=464</id>
		<title>HowTo: Profiling LMDZ</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_Profiling_LMDZ&amp;diff=464"/>
				<updated>2024-07-16T18:29:34Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : (WIP) Add scalasca install guide&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Profiling with gprof ===&lt;br /&gt;
&lt;br /&gt;
The legacy way to profile the model is using &amp;lt;code&amp;gt;gprof&amp;lt;/code&amp;gt;.&lt;br /&gt;
* ''Pros:'' available everywhere, easy to use&lt;br /&gt;
* ''Cons:'' old, bad handling of multithreaded applications, requires instrumentation&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;gprof&amp;lt;/code&amp;gt; is a rudimentary but simple to use tool to profile a sequential executable.&lt;br /&gt;
&lt;br /&gt;
''Note: a new tool [https://sourceware.org/pipermail/binutils/2021-August/117665.html gprofng] is currently being developed with several notable improvements including multithreading support. As of 06/24, it doesn't support Fortran yet.&lt;br /&gt;
&lt;br /&gt;
==== Instrumenting the code ====&lt;br /&gt;
&lt;br /&gt;
In the &amp;lt;code&amp;gt;.fcm&amp;lt;/code&amp;gt; arch file used, add &amp;lt;code&amp;gt;-pg&amp;lt;/code&amp;gt; to &amp;lt;code&amp;gt;BASE_FFLAGS&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;BASE_LD&amp;lt;/code&amp;gt;. Recompile the model.&lt;br /&gt;
&lt;br /&gt;
==== Collecting statistics ====&lt;br /&gt;
&lt;br /&gt;
Run the executable &amp;lt;code&amp;gt;gcm.e&amp;lt;/code&amp;gt;. This will generate a &amp;lt;code&amp;gt;gmon.out&amp;lt;/code&amp;gt; file locally.&lt;br /&gt;
&lt;br /&gt;
==== Reading results ====&lt;br /&gt;
&lt;br /&gt;
Run &amp;lt;code&amp;gt;gprof gcm.e gmon.out &amp;gt; profiling.txt&amp;lt;/code&amp;gt; to get a textual view of the profiling.&lt;br /&gt;
&lt;br /&gt;
For a graphical representation, we recommend using [https://github.com/jrfonseca/gprof2dot gprof2dot], via &amp;lt;code&amp;gt;gprof gcm.e | gprof2dot | dot -Tpng -o output.png&amp;lt;/code&amp;gt;. A typical example is shown below.&lt;br /&gt;
&lt;br /&gt;
[[Fichier:gprof.png|400px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Profiling with scorep &amp;amp; scalasca ==&lt;br /&gt;
&lt;br /&gt;
Scalasca ([https://www.scalasca.org/ home], [https://apps.fz-juelich.de/scalasca/releases/scalasca/2.6/docs/manual/ manual]) is a profiling suite developed by Technische Universität Darmstadt Laboratory for Parallel Programming. It is much more capable than gprof, but also requires a heavier setup.&lt;br /&gt;
&lt;br /&gt;
==== Installing scalasca ====&lt;br /&gt;
&lt;br /&gt;
Some supercomputers have scalasca installed already, but for completeness here's a short guide to installing it locally (written 06/24, for v2.6.1):&lt;br /&gt;
&lt;br /&gt;
All dependencies can be downloaded from [https://www.scalasca.org/scalasca/software/scalasca-2.x/requirements.html here].&lt;br /&gt;
&lt;br /&gt;
===== Compiling CubeBundle / CubeLib =====&lt;br /&gt;
&lt;br /&gt;
''Note: If you're on your own computer, we recommend installing CubeBundle, which includes CubeGUI. This requires Qt5 and OpenGL, which are a pain to install on supercomputers without sudo. For supercomputer local install, we recommand installing CubeW+CubeLib instead, and visualizing the results on your own computer.''&lt;br /&gt;
&lt;br /&gt;
No special instruction here - simply get the sources on the link above, extract them locally, and run &amp;lt;code&amp;gt;./configure --prefix=... &amp;amp;&amp;amp; make -j 8 &amp;amp;&amp;amp; make install&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Compiling scorep ====&lt;br /&gt;
&lt;br /&gt;
Scalasca relies on &amp;lt;code&amp;gt;scorep&amp;lt;/code&amp;gt; to instrument your code for profiling.&lt;br /&gt;
&lt;br /&gt;
On clusters like Adastra, you need to make sure that &amp;lt;code&amp;gt;clang&amp;lt;/code&amp;gt; in your path points to the system install: &amp;lt;code&amp;gt;LD_LIBRARY_PATH=&amp;quot;/usr/lib64:$LD_LIBRARY_PATH&amp;quot; ./configure --prefix=... &amp;amp;&amp;amp; LD_LIBRARY_PATH=&amp;quot;/usr/lib64:$LD_LIBRARY_PATH&amp;quot; make -j 8 &amp;amp;&amp;amp; make install&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: make sure to load the right environment before compiling ! &amp;lt;code&amp;gt;scorep&amp;lt;/code&amp;gt; can only instrument compilers it has detected when configured.''&lt;br /&gt;
&lt;br /&gt;
==== Compiling scalasca ====&lt;br /&gt;
&lt;br /&gt;
Usual process: &amp;lt;code&amp;gt;./configure --prefix=... &amp;amp;&amp;amp; make -j 8 &amp;amp;&amp;amp; make install&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: Scalasca doesn't seem to like gcc-13 very much, but it doesn't need to be compiled with the same compiler as &amp;lt;code&amp;gt;scorep&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
''Note: On Adastra, you need &amp;lt;code&amp;gt;module load craype-x86-trento&amp;lt;/code&amp;gt; and we recommend &amp;lt;code&amp;gt;module load gcc/12.2.0&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
''Note: To perform traces, Scalasca requires executables in &amp;lt;code&amp;gt;$install_dir/bin/backend/&amp;lt;/code&amp;gt; to be in the path. You can safely simply copy them to &amp;lt;code&amp;gt;$install_dir/bin/&amp;lt;/code&amp;gt; and add that to the path instead.''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:HowTo]]&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_Profiling_LMDZ&amp;diff=463</id>
		<title>HowTo: Profiling LMDZ</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=HowTo:_Profiling_LMDZ&amp;diff=463"/>
				<updated>2024-07-16T17:57:04Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : (WIP) Add gprof guide&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Profiling with gprof ===&lt;br /&gt;
&lt;br /&gt;
The legacy way to profile the model is using &amp;lt;code&amp;gt;gprof&amp;lt;/code&amp;gt;.&lt;br /&gt;
* ''Pros:'' available everywhere, easy to use&lt;br /&gt;
* ''Cons:'' old, bad handling of multithreaded applications, requires instrumentation&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;gprof&amp;lt;/code&amp;gt; is a rudimentary but simple to use tool to profile a sequential executable.&lt;br /&gt;
&lt;br /&gt;
==== Instrumenting the code ====&lt;br /&gt;
&lt;br /&gt;
In the &amp;lt;code&amp;gt;.fcm&amp;lt;/code&amp;gt; arch file used, add &amp;lt;code&amp;gt;-pg&amp;lt;/code&amp;gt; to &amp;lt;code&amp;gt;BASE_FFLAGS&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;BASE_LD&amp;lt;/code&amp;gt;. Recompile the model.&lt;br /&gt;
&lt;br /&gt;
==== Collecting statistics ====&lt;br /&gt;
&lt;br /&gt;
Run the executable &amp;lt;code&amp;gt;gcm.e&amp;lt;/code&amp;gt;. This will generate a &amp;lt;code&amp;gt;gmon.out&amp;lt;/code&amp;gt; file locally.&lt;br /&gt;
&lt;br /&gt;
==== Reading results ====&lt;br /&gt;
&lt;br /&gt;
Run &amp;lt;code&amp;gt;gprof gcm.e gmon.out &amp;gt; profiling.txt&amp;lt;/code&amp;gt; to get a textual view of the profiling.&lt;br /&gt;
&lt;br /&gt;
For a graphical representation, we recommend using [https://github.com/jrfonseca/gprof2dot gprof2dot], via &amp;lt;code&amp;gt;gprof gcm.e | gprof2dot | dot -Tpng -o output.png&amp;lt;/code&amp;gt;. A typical example is shown below.&lt;br /&gt;
&lt;br /&gt;
[[Fichier:gprof.png|400px]]&lt;br /&gt;
&lt;br /&gt;
== Profiling with gprofng ==&lt;br /&gt;
&lt;br /&gt;
== Profiling with scorep &amp;amp; scalasca ==&lt;br /&gt;
&lt;br /&gt;
[[Category:HowTo]]&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Fichier:Gprof.png&amp;diff=462</id>
		<title>Fichier:Gprof.png</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=Fichier:Gprof.png&amp;diff=462"/>
				<updated>2024-07-16T17:55:26Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : typical gprof dot graph of the install_lmdz bench
(MPI_NUM_THREADS=1 mpirun -np 1 gcm.e)&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;typical gprof dot graph of the install_lmdz bench&lt;br /&gt;
(MPI_NUM_THREADS=1 mpirun -np 1 gcm.e)&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=461</id>
		<title>LMDZ Setup</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=461"/>
				<updated>2024-07-16T16:47:49Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : Add HowTo category&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LMDZ_Setup is a set of scripts that allows a light automatic setup of LMDZ long chained climate simulations, including the installation of the model itself.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can only be used on the Jean-Zay computer at Idris so far.&lt;br /&gt;
&lt;br /&gt;
Coming VERY soon (summer 2024) : extension to other computing centers (&amp;quot;spirit&amp;quot;, adastra) and Linux PCs&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Documentation (in French):'''&lt;br /&gt;
[https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit LMDZ_Setup_HowTo]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''To extract LMDZ_Setup :'''&lt;br /&gt;
&lt;br /&gt;
a/ Recommended : extraction from svn repository : &lt;br /&gt;
&lt;br /&gt;
    svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&lt;br /&gt;
&lt;br /&gt;
b/ Download of the &amp;quot;tar&amp;quot; archive :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&lt;br /&gt;
 &lt;br /&gt;
c/ For those used with the old name &amp;quot;tutorial_prod.tar&amp;quot; : a link with this name still exists, pointing to LMDZ_Setup.tar :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''(Text extracted from LMDZ_Setup/README0_HowTo):''&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup consists in running '''LMDZ coupled to Orchidee''' for land surface (optional), but with '''imposed sea surface temperature'''.&lt;br /&gt;
&lt;br /&gt;
The '''basic default configuration''' makes use of the IPSL-CM6A grid configuration and tuning, and runs a multi annual simulation on &amp;quot;climatological&amp;quot;&lt;br /&gt;
amip sea surface temperature (with a mean annual cycle) using a calendar with 360 days.&lt;br /&gt;
&lt;br /&gt;
Optionally : the configuration includes the '''ability to use interannually varying SST''' and to activate '''&amp;quot;nudging&amp;quot;''' by a reanalysis.&lt;br /&gt;
In both cases, the calendar is then a real one.&lt;br /&gt;
When nudging is activated, the simulation must be run on a monthly basis, while otherwise, it can be either monthly or yearly.&lt;br /&gt;
&lt;br /&gt;
Since LMDZ_Setup automatically generates its own initial files, it can be run with '''zoom configurations''' by only changing the number of grid points (&amp;quot;resol&amp;quot; in main.sh) and the DEF/gcm.def file (see bellow).&lt;br /&gt;
&lt;br /&gt;
'''Aerosols''' can be read for the year 2000 (weighted average  over 1999-2001 cf Lurton et al 2020), and instantaneous forcing with respect to 1850 can be computed as well.&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can also run LMDZ coupled with the '''SPLA model''' (SimPLe Aerosol, activated with option aerosols=spla in setup.sh).&lt;br /&gt;
Emissions of dust and sea salt are then computed interactively.&lt;br /&gt;
For the time being, SPLA-specific input files (anthropic aerosol emissions)are only available on the grid zoomed over N Africa used by J. Escribano in his PhD thesis, and by B. Diallo and H. Senghor in subsequent work on N-African dust (file DEF/gcm.def_zNAfrica_BiJe).&lt;br /&gt;
&lt;br /&gt;
A configuration with '''isotopes''' is also available since 2023-04.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Below: new LMDZ_Setup docs ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Old documentation (French): [https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c LMDZ_Setup_HowTo]''&lt;br /&gt;
&lt;br /&gt;
== User guide ==&lt;br /&gt;
&lt;br /&gt;
 ''' /!\ WARNING''' 06/2024 - (ignore if installing a new version)&lt;br /&gt;
 The JeanZay calculator, as well as Adastra, do not allow (anymore) communication from/to $STORE for running jobs on the main computing partitions.&lt;br /&gt;
 As a result, make sure to replace $STORE by $WORK in &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt; wherever relevant.&lt;br /&gt;
&lt;br /&gt;
 '''READ comments at the top of scripts ! Often your questions are answered there.'''&lt;br /&gt;
&lt;br /&gt;
 ''Note'': &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; has been tested on Adastra and Spirit, and to a lesser extent on JeanZay (legacy support only). No guarantee is made on other platforms, although it should be easy to adapt it. It can also be ran locally - for expert use only.&lt;br /&gt;
&lt;br /&gt;
=== Downloading LMDZ_Setup ===&lt;br /&gt;
&lt;br /&gt;
* ''(recommended)'' Using ''subversion'': &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(alternative)'' &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(deprecated)'' The old &amp;lt;code&amp;gt;tutorial_prod&amp;lt;/code&amp;gt; version: &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Structure ===&lt;br /&gt;
&lt;br /&gt;
Once you have downloaded &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;, you will find the following main files:&lt;br /&gt;
* &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;: the main script. It contains the basic settings you will modify.&lt;br /&gt;
* &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;: this script contains the internal workings of &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. It's where you can edit expert-level settings.&lt;br /&gt;
* &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;: this file contains platform-specific configuration, such as where to install the model, where to run the simulations, etc.&lt;br /&gt;
&lt;br /&gt;
=== How to run a simulation ===&lt;br /&gt;
&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;set_env&amp;lt;/code&amp;gt;, find the case corresponding to your supercomputer: &amp;lt;code&amp;gt;jean-)&amp;lt;/code&amp;gt; for JeanZay, &amp;lt;code&amp;gt;spiri)&amp;lt;/code&amp;gt; for Spirit, &amp;lt;code&amp;gt;adast)&amp;lt;/code&amp;gt; for Adastra. Edit the variables required for your use case. All the variables are documented in the last &amp;lt;code&amp;gt;*)&amp;lt;/code&amp;gt; case. In particular:&lt;br /&gt;
#* you must set &amp;lt;code&amp;gt;root_dir&amp;lt;/code&amp;gt; to the path where you extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;.&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;define_expert_options&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;DEF/*&amp;lt;/code&amp;gt;.''' Edit the &amp;lt;code&amp;gt;DEF/*.def&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt; files, such as &amp;lt;code&amp;gt;config.def&amp;lt;/code&amp;gt;, to your liking. ''The options you specify in main.sh/setup.sh don't require any adjustment here; such adjustments are automatically performed at runtime.''&lt;br /&gt;
# '''Launch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;'''.&lt;br /&gt;
&lt;br /&gt;
=== Miscellanous notes ===&lt;br /&gt;
&lt;br /&gt;
* Simulations run in a subdirectory of &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; with the same name as the &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder (if you have extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; and renamed it to &amp;lt;code&amp;gt;My_Setup&amp;lt;/code&amp;gt; then simulations will run in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/My_Setup&amp;lt;/code&amp;gt;). Each simulation is contained in its own folder, named after the simulation's name + a process number. As a result, '''you don't need to clean $SIMRUNBASEDIR before relaunching a simulation'''.&lt;br /&gt;
* If your simulation crashes, look directly in &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; for the relevant log.&lt;br /&gt;
* If you need a version of ORCHIDEE different from the one provided by default in the model (such as &amp;lt;code&amp;gt;CMIP6&amp;lt;/code&amp;gt;), a password is required - ask ''orchidee-help at listes.ipsl.fr'' if you need help.&lt;br /&gt;
&lt;br /&gt;
==== XIOS ====&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' Although XIOS is not ''required'' for ORCHIDEE &amp;gt;=2.2, not using it will disable some features.&lt;br /&gt;
Different sets of &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt; files are available in &amp;lt;code&amp;gt;LMDZ_Setup/DEF/XMLFiles*&amp;lt;/code&amp;gt;. However, only some common files (&amp;lt;code&amp;gt;histf, histday, histmth&amp;lt;/code&amp;gt;) have been adapted for &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. ''If you need other outputs, '''be sure to edit/check the relevant &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt;''''':&lt;br /&gt;
* replace the &amp;lt;code&amp;gt;_AUTO_&amp;lt;/code&amp;gt; for &amp;lt;code&amp;gt;output_level&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;enabled&amp;lt;/code&amp;gt; by actual values;&lt;br /&gt;
* use &amp;lt;code&amp;gt;compression_level=0&amp;lt;/code&amp;gt; instead of the default values (&amp;lt;code&amp;gt;2&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;4&amp;lt;/code&amp;gt;) (since &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; uses XIOS in attached mode rather than client-server mode, using non-zero compression levels would require running XIOS on 1+ dedicated MPI).&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' After installing the model, two files are automatically initialized in &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;context_lmdz.xml&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;field_def_lmdz.xml&amp;lt;/code&amp;gt;. Those files don't require user intervention, and must match the exact LMDZ revision used.&lt;br /&gt;
&lt;br /&gt;
==== Compilation ====&lt;br /&gt;
&lt;br /&gt;
When launching &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, before running the simulation, we first download and compile the required models. Although we call the compilation script every time, if the model has already been compiled before, the script should detect that and skip the actual compilation, and thus execute very quickly.&lt;br /&gt;
&lt;br /&gt;
''Note: on supported clusters, compilation is launched in jobs rather than on the login node. This speeds up the compilation.''&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' As written in the comments of &amp;lt;code&amp;gt;main.sh/setup.sh&amp;lt;/code&amp;gt;, '''if you change the &amp;lt;code&amp;gt;veget&amp;lt;/code&amp;gt; version or the &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt;, it is highly recommended to do so in a NEW clean &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder''' rather than recompiling in the same folder.&lt;br /&gt;
&lt;br /&gt;
=== Nudging ===&lt;br /&gt;
&lt;br /&gt;
Nudging is set via the &amp;lt;code&amp;gt;nudging&amp;lt;/code&amp;gt; variable in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. If activated, then after installing the model, &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; will prompt you to run &amp;lt;code&amp;gt;era2gcm_tuto.sh&amp;lt;/code&amp;gt;. This script fetches reanalysis data and puts it in a &amp;lt;code&amp;gt;GUIDE/&amp;lt;/code&amp;gt; folder.&lt;br /&gt;
Once this is done, simply set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and relaunch it.&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' On Adastra, the reanalysis files are not yet available.&lt;br /&gt;
&lt;br /&gt;
=== Aerosols ===&lt;br /&gt;
&lt;br /&gt;
 '''/!\ As written in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, it is highly recommended to install &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; in a new clean directory when changing aerosols options. Otherwise i.e. the &amp;lt;code&amp;gt;DEF/config.def&amp;lt;/code&amp;gt; may not get modified accordingly.'''&lt;br /&gt;
&lt;br /&gt;
When &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt; is set to anything other than &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, aerosols files will be downloaded in &amp;lt;code&amp;gt;LIMIT/&amp;lt;/code&amp;gt;, and will be interpolated to the horizontal grid resolution (vertical interpolation is performed at runtime by the GCM.)&lt;br /&gt;
&lt;br /&gt;
==== More detail ====&lt;br /&gt;
&lt;br /&gt;
The aerosols files used for the options &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt; are those used in CMIP6 with the LMDZORINCA configuration, from [https://www.lmd.jussieu.fr/~lmdz/pub/3DInputData/AerChem/ here].&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt;, we only use &amp;lt;code&amp;gt;aerosols1850_from_inca.nc&amp;lt;/code&amp;gt; (natural aerosols), interpolated as &amp;lt;code&amp;gt;aerosols.nat.nc&amp;lt;/code&amp;gt;&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt;, we also use &amp;lt;code&amp;gt;aerosols9999_from_inca.nc&amp;lt;/code&amp;gt; with the mean aerosols on 1995-2014, interpolated as &amp;lt;code&amp;gt;aerosols.clim.nc&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== ORCHIDEE ===&lt;br /&gt;
&lt;br /&gt;
The officially supported versions of ORCHIDEE supported by LMDZ_Setup are:&lt;br /&gt;
* the CMIP6 version (still using the two-layer hydrology channel)&lt;br /&gt;
* version 2.2 r7983&lt;br /&gt;
* version 4 (trunk) r7994 (corresponding to libIGCM's LMDZOR_6.4work configuration)&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' The relevant ORCHIDEE def file &amp;lt;code&amp;gt;DEF/orchidee.def_*&amp;lt;/code&amp;gt; gets copied as &amp;lt;code&amp;gt;DEF/orchidee.def&amp;lt;/code&amp;gt; at initialisation.&lt;br /&gt;
&lt;br /&gt;
==== Activating sechiba outputs ====&lt;br /&gt;
&lt;br /&gt;
Sechiba outputs are written to &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt;, but are deleted by &amp;lt;code&amp;gt;tmp_SIM&amp;lt;/code&amp;gt; before they're rebuilt. To counter that, remove the &amp;lt;code&amp;gt;sec*&amp;lt;/code&amp;gt; on the relevant line &amp;lt;code&amp;gt;set +e ; \rm out* sec* sta* list* rest* gcm.e aer* ; set -e&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Simple routing ====&lt;br /&gt;
&lt;br /&gt;
From orch 2.2 r7597 onwards, the &amp;quot;simple&amp;quot; routing scheme by Y. Meurdesoif can be activated.&lt;br /&gt;
&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/orchidee.def_6.*&amp;lt;/code&amp;gt;, set &amp;lt;code&amp;gt;RIVER_ROUTING=y&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;ROUTING_METHOD = simple&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;RIVER_DESC=y&amp;lt;/code&amp;gt; (''Note: &amp;lt;code&amp;gt;RIVER_DESC&amp;lt;/code&amp;gt; is automatically set to &amp;quot;n&amp;quot; after the first simulation period.)&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/XMLfilesOR7***/iodef.xml&amp;lt;/code&amp;gt;, add at the end of &amp;lt;code&amp;gt;context_orchidee.xml&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;&amp;lt;context id=&amp;quot;orchidee&amp;quot; src=&amp;quot;./context_routing_orchidee.xml&amp;quot;/&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
See also:[https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/UserGuide/RoutageSimple User Guide/Routage Simple] (French).&lt;br /&gt;
&lt;br /&gt;
=== Isotopes ===&lt;br /&gt;
&lt;br /&gt;
To activate isotopes, simply change the &amp;lt;code&amp;gt;lmd_phys&amp;lt;/code&amp;gt; parameter to &amp;lt;code&amp;gt;&amp;quot;lmdiso&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. This will automatically&lt;br /&gt;
* use &amp;lt;code&amp;gt;&amp;quot;phylmdiso&amp;quot;&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;&amp;quot;phylmd&amp;quot;&amp;lt;/code&amp;gt;;&lt;br /&gt;
* copy &amp;lt;code&amp;gt;DEF/PHYS/physiq.def_NPiso&amp;lt;/code&amp;gt; to &amp;lt;code&amp;gt;DEF/physiq.def&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: for isotopes, &amp;lt;code&amp;gt;iflag_ice_thermo&amp;lt;/code&amp;gt; is automatically set to &amp;lt;code&amp;gt;0&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;1&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
* ''How to relaunch a failed simulation ?''&lt;br /&gt;
&lt;br /&gt;
If the simulation ran for at least one successful period, simplys set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and rerun it. Otherwise, see the following question.&lt;br /&gt;
&lt;br /&gt;
* ''I have ran a simulation, but I messed up the parameters. I want to run a new clean simulation with the same name (e.g. &amp;lt;code&amp;gt;NPv6.3&amp;lt;/code&amp;gt;.)''&lt;br /&gt;
&lt;br /&gt;
Remove &amp;lt;code&amp;gt;INIT, LIMIT, NPv6.3&amp;lt;/code&amp;gt; and relaunch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; with &amp;lt;code&amp;gt;init=1&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
* ''How can I follow the state of a running simulation ?''&lt;br /&gt;
&lt;br /&gt;
Check the file &amp;lt;code&amp;gt;LMDZ_Setup/$SIM_NAME/etat&amp;lt;/code&amp;gt;. After each period (mo/yr), it gets updated like so:&lt;br /&gt;
 200001 a faire&lt;br /&gt;
 200001 OK&lt;br /&gt;
 200002 a faire&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To check if the simulation is still running, query your cluster's queue (e.g. &amp;lt;code&amp;gt;squeue --me&amp;lt;/code&amp;gt; on SLURM clusters). If nothing is running, read the next question.&lt;br /&gt;
&lt;br /&gt;
* ''How to investigate a crash ?''&lt;br /&gt;
&lt;br /&gt;
The job error log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/out*&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The simulation log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/$SIM_NAME*/listing&amp;lt;/code&amp;gt;. (''Note: to know which folder is the latest, run &amp;lt;code&amp;gt;ls -lat&amp;lt;/code&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Cluster-specific information ==&lt;br /&gt;
&lt;br /&gt;
=== Generic ===&lt;br /&gt;
&lt;br /&gt;
==== ORCH 4 (trunk) ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4 is currently not able to compile with &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;, and as a result can't be used. This has been reported to the relevant team, and hopefully should be fixed soon (06/2024).&lt;br /&gt;
&lt;br /&gt;
==== CDO &amp;amp; aerosols ====&lt;br /&gt;
&lt;br /&gt;
The current version of &amp;lt;code&amp;gt;cdo&amp;lt;/code&amp;gt; on Adastra (&amp;lt;code&amp;gt;2.4.0&amp;lt;/code&amp;gt;) and Spirit (&amp;lt;code&amp;gt;2.3.0&amp;lt;/code&amp;gt;) contain [https://code.mpimet.mpg.de/boards/1/topics/15752 a bug] which interferes with the script interpolating aerosols. This bug is supposedly solved in version &amp;lt;code&amp;gt;2.4.1+&amp;lt;/code&amp;gt;. This bug corrupts the aerosols files, and results in a &amp;lt;code&amp;gt;hgardfou&amp;lt;/code&amp;gt; error when running the simulation.&lt;br /&gt;
&lt;br /&gt;
=== JeanZay ===&lt;br /&gt;
&lt;br /&gt;
JeanZay was the main supported cluster of the old &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. Although the new version can be ran there, it is discouraged.&lt;br /&gt;
&lt;br /&gt;
==== Slowness ====&lt;br /&gt;
&lt;br /&gt;
Compilation of the various components of the model, in particular of LMDZ and XIOS, is extremely slow on JeanZay compared to other clusters (for unknown reasons) (~15 minutes for LMDZ+rrtm). Moreover, it seems that for uninvestigated reasons, the LMDZ model is systematically recompiled on each call to &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; (expected behavior, as on other clusters: the &amp;lt;code&amp;gt;fcm&amp;lt;/code&amp;gt; system detects that it's already compiled and avoids compiling again). As a result, the whole process of '''launching a simulation is much slower'''.&lt;br /&gt;
&lt;br /&gt;
[[Category:HowTo]]&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=WhatIs:_The_traceur.def_input_file&amp;diff=460</id>
		<title>WhatIs: The traceur.def input file</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=WhatIs:_The_traceur.def_input_file&amp;diff=460"/>
				<updated>2024-07-16T16:45:22Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : Move deprecation warning to top &amp;amp; improve formatting&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;  '''/!\ The &amp;lt;code&amp;gt;traceur.def&amp;lt;/code&amp;gt; format is now deprecated''' (but should still work fine as the code is retro-compatible). We recommend using &amp;lt;code&amp;gt;tracer.def&amp;lt;/code&amp;gt; instead, as described [[WhatIs: The tracer.def input file|here]] (03/01/2023).  &lt;br /&gt;
&lt;br /&gt;
== The traceur.def input file tells LMDZ about the tracers to advect ==&lt;br /&gt;
&lt;br /&gt;
The traceur.def is a plain text file that is read at run time by LMDZ. Its format is quite strict:&lt;br /&gt;
&lt;br /&gt;
* The first line contains the number n of tracers to advect in the dynamics&lt;br /&gt;
* The n following lines contain the following set ( two integer numbers and a string): hadv , vadv, tname . hadv and vadv are traceur advection scheme numbers and tname is the tracer name&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
'''Tracer advection schemes'''&lt;br /&gt;
&lt;br /&gt;
A few are coded, but not for the parallel case, so we only present the important (i.e. operational) ones here:&lt;br /&gt;
&lt;br /&gt;
* 0 : no advection. This tracer will not be advected by the dynamics&lt;br /&gt;
* 10: advection using a Van Leer scheme. This is the standard advection scheme to use for tracers.&lt;br /&gt;
* 14: a specific advection scheme for the water vapor tracer (i.e. &amp;quot;H2Ov&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
'''Illustrative example'''&lt;br /&gt;
&lt;br /&gt;
In practice a &amp;quot;traceur.def&amp;quot; file will look like this:&lt;br /&gt;
&lt;br /&gt;
 4&lt;br /&gt;
 14 14 H2Ov&lt;br /&gt;
 10 10 H2Ol&lt;br /&gt;
 10 10 H2Oi&lt;br /&gt;
 00 00 Aga&lt;br /&gt;
&lt;br /&gt;
In this example, there are 4 tracers, the first one is &amp;quot;H2Ov&amp;quot; (water vapor) and advected using scheme number 14, the second and third are &amp;quot;H2Ol&amp;quot; (liquid water) and &amp;quot;H2Oi&amp;quot; (water ice), and the last is called &amp;quot;Aga&amp;quot; and completely passive (i.e. untouched by the dynamics).&lt;br /&gt;
&lt;br /&gt;
[[Category:WhatIs]]&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=WhatIs:_The_install_lmdz.sh_script&amp;diff=459</id>
		<title>WhatIs: The install lmdz.sh script</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=WhatIs:_The_install_lmdz.sh_script&amp;diff=459"/>
				<updated>2024-07-11T09:31:55Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : remove obsolete part&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The ''install_lmdz.sh'' script is a Bash script that aims at being an &amp;quot;installer&amp;quot; for LMDZ of Linux machines.&lt;br /&gt;
&lt;br /&gt;
In practice it runs a succession of mandatory steps to install and run the model from scratch, namely:&lt;br /&gt;
* Download and install required libraries (NetCDF, IOIPSL and possibly XIOS)&lt;br /&gt;
* Download the source code (LMDZ and ORCHIDEE), compile it and run a test (bench) simulation&lt;br /&gt;
&lt;br /&gt;
It has many options and features; a good starting point (short of reading and digesting the Bash script itself) is to run '''install_lmdz.sh -h''' to learn about these, which should yield something like:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
install_lmdz.sh&lt;br /&gt;
    ./install_lmdz.sh [ -v version ] [ -r svn_release ]&lt;br /&gt;
           [ -parallel PARA ] [ -d GRID_RESOLUTION ] [ -bench 0/1 ]&lt;br /&gt;
           [-name LOCAL_MODEL_NAME] [-gprof] [-opt_makelmdz] [-rad RADIATIF]&lt;br /&gt;
&lt;br /&gt;
    -v       &amp;quot;version&amp;quot; like 20150828.trunk&lt;br /&gt;
             see http://www.lmd.jussieu.fr/~lmdz/Distrib/LISMOI.trunk&lt;br /&gt;
&lt;br /&gt;
    -r       &amp;quot;svn_release&amp;quot; : either the svn release number or &amp;quot;last&amp;quot;&lt;br /&gt;
    &lt;br /&gt;
    -compiler gfortran|ifort|pgf90 (default: gfortran)&lt;br /&gt;
&lt;br /&gt;
    -parallel PARA : can be mpi_omp (mpi with openMP) or none (for sequential)&lt;br /&gt;
&lt;br /&gt;
    -d        GRID_RESOLUTION should be among the available benchs if -bench 1&lt;br /&gt;
              among which : 48x36x19, 48x36x39&lt;br /&gt;
              if wanting to run a bench simulation in addition to compilation&lt;br /&gt;
              default : 48x36x19&lt;br /&gt;
&lt;br /&gt;
    -bench     activating the bench or not (0/1). Default 1&lt;br /&gt;
&lt;br /&gt;
    -name      LOCAL_MODEL_NAME : default = LMDZversion.release&lt;br /&gt;
&lt;br /&gt;
    -netcdf    PATH : full path to an existing installed NetCDF library&lt;br /&gt;
               (without -netcdf: also download and install the NetCDF library)  &lt;br /&gt;
    &lt;br /&gt;
    -xios      also download and compile the XIOS library&lt;br /&gt;
               (requires the NetCDF4-HDF5 library, also installed by default)&lt;br /&gt;
               (requires to also have -parallel mpi_omp)&lt;br /&gt;
&lt;br /&gt;
    -gprof     to compile with -pg to enable profiling with gprof&lt;br /&gt;
&lt;br /&gt;
    -cosp      to run without our with cospv1 or cospv2 [none/v1/v2]&lt;br /&gt;
 &lt;br /&gt;
    -rad RADIATIF can be old, rrtm or ecrad radiatif code&lt;br /&gt;
&lt;br /&gt;
    -nofcm     to compile without fcm&lt;br /&gt;
&lt;br /&gt;
    -SCM        install 1D version automatically&lt;br /&gt;
&lt;br /&gt;
    -debug      compile everything in debug mode&lt;br /&gt;
&lt;br /&gt;
    -opt_makelmdz     to call makelmdz or makelmdz_fcm with additional options&lt;br /&gt;
&lt;br /&gt;
    -physiq    to choose which physics package to use&lt;br /&gt;
&lt;br /&gt;
    -env_file  specify an arch.env file to overwrite the existing one&lt;br /&gt;
&lt;br /&gt;
    -veget surface model to run [NONE/CMIP6/xxxx]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Note that the ''install_lmdz.sh'' script is not the only way to install LMDZ; one can manually do the various key steps (quite possibly adapted to the specificities of the machine that is used).&lt;br /&gt;
&lt;br /&gt;
02/12/2021&lt;br /&gt;
&lt;br /&gt;
[[Category:WhatIs]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== New install_lmdz version (Amaury - 06/2024) ==&lt;br /&gt;
&lt;br /&gt;
=== Known bugs / issues ===&lt;br /&gt;
&lt;br /&gt;
==== ORCHIDEE bench ====&lt;br /&gt;
&lt;br /&gt;
Right now (06/24), only the CMIP6/orch2.0 ORCHIDEE version has a proper bench.&lt;br /&gt;
As a result, other versions (orch2.2, orch4/trunk) run in a bench that doesn't activate ORCHIDEE.&lt;br /&gt;
&lt;br /&gt;
''Todo: make a proper orch2.2 and orch4 bench, with/without xios)''&lt;br /&gt;
&lt;br /&gt;
==== Debug mode crashes ====&lt;br /&gt;
&lt;br /&gt;
When activating &amp;lt;code&amp;gt;-debug&amp;lt;/code&amp;gt;, with newer versions of NETCDF, a segfault is raised on lines such as &amp;lt;code&amp;gt;CALL err(NF90_OPEN(var,NF90_NOWRITE,fID),&amp;quot;open&amp;quot;,var)&amp;lt;/code&amp;gt;. It seems that the segfault originates from the NF90_OPEN function itself.&lt;br /&gt;
&lt;br /&gt;
''Todo: check with even newer versions of netcdf - but then we face the other documented netcdf bug...''&lt;br /&gt;
&lt;br /&gt;
==== ORCHIDEE 4/TRUNK compilation fails ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4/trunk can't be compiled with gfortran for now. This issue has been raised to the ORCHIDEE team (06/24).&lt;br /&gt;
&lt;br /&gt;
''Todo: update when orch fixes their code''&lt;br /&gt;
&lt;br /&gt;
==== &amp;lt;code&amp;gt;Error   -105 in closing file&amp;lt;/code&amp;gt; ====&lt;br /&gt;
&lt;br /&gt;
with &amp;lt;code&amp;gt;-parallel mpi_omp -veget orch2.0&amp;lt;/code&amp;gt;, at the end of a simulation, we can read in &amp;lt;code&amp;gt;listing&amp;lt;/code&amp;gt;:&lt;br /&gt;
 WARNING FROM ROUTINE restclo&lt;br /&gt;
 --&amp;gt; Error   -105 in closing file : ***&lt;br /&gt;
 --&amp;gt; sechiba_rest_out.nc&lt;br /&gt;
 --&amp;gt; &lt;br /&gt;
&lt;br /&gt;
This &amp;quot;error&amp;quot; doesn't seem to actually affect the outputs, and should be ignored; yet, its cause hasn't been investigated.&lt;br /&gt;
&lt;br /&gt;
==== COSP + orch + xios segfault ====&lt;br /&gt;
&lt;br /&gt;
With &amp;lt;code&amp;gt;-veget orch2.0 -xios -cosp v1&amp;lt;/code&amp;gt; (or &amp;lt;code&amp;gt;v2&amp;lt;/code&amp;gt;), we encounter a segfault in the bench.&lt;br /&gt;
&lt;br /&gt;
Unfortunately because of the netcdf debug bug (see above), we can't get to the actual trace....&lt;br /&gt;
&lt;br /&gt;
==== XIOS compilation failure ====&lt;br /&gt;
&lt;br /&gt;
XIOS 2.6 r2568 compilation fails randomly when compiled in parallel (&amp;lt;code&amp;gt;make_xios --job N&amp;lt;/code&amp;gt;). The stack trace:&lt;br /&gt;
&lt;br /&gt;
 mpif90 -o generic_testcase.exe /home/abarral/PycharmProjects/installLMDZ/script_install/LMDZ/modipsl/modeles/XIOS/obj/generic_testcase.o -L/home/abarral/PycharmProjects/installLMDZ/script_install/LMDZ/modipsl/modeles/XIOS/lib -l__fcm__generic_testcase -lxios -lstdc++ -L/home/abarral/Programs/zlib_mpi_hdf5_ncdf_cdo/netcdf-c-4.9.2-fortran-4.5.4-cxx-4.3.1/lib -lnetcdff -L//home/abarral/Programs/zlib_mpi_hdf5_ncdf_cdo/netcdf-c-4.9.2-fortran-4.5.4-cxx-4.3.1/lib -lnetcdf -lnetcdf -lm -Wl,-rpath=/home/abarral/Programs/zlib_mpi_hdf5_ncdf_cdo/openmpi-4.1.6/bin/../lib:/home/abarral/Programs/zlib_mpi_hdf5_ncdf_cdo/netcdf-c-4.9.2-fortran-4.5.4-cxx-4.3.1/lib -lstdc++&lt;br /&gt;
 /usr/bin/ld: cannot find -lxios: No such file or directory&lt;br /&gt;
 /usr/bin/ld: cannot find -lxios: No such file or directory&lt;br /&gt;
 collect2: error: ld returned 1 exit status&lt;br /&gt;
 fcm_internal load failed (256)&lt;br /&gt;
&lt;br /&gt;
seems to indicate a race condition in the fcm process.&lt;br /&gt;
&lt;br /&gt;
''I'm not sure if this problem has been reported to the XIOS team. We also haven't tested if it's present in newer XIOS versions.''&lt;br /&gt;
&lt;br /&gt;
'''Solution''': Restart the compilation.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=WhatIs:_The_install_lmdz.sh_script&amp;diff=458</id>
		<title>WhatIs: The install lmdz.sh script</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=WhatIs:_The_install_lmdz.sh_script&amp;diff=458"/>
				<updated>2024-07-10T10:27:52Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : add XIOS compil bug&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The ''install_lmdz.sh'' script is a Bash script that aims at being an &amp;quot;installer&amp;quot; for LMDZ of Linux machines.&lt;br /&gt;
&lt;br /&gt;
In practice it runs a succession of mandatory steps to install and run the model from scratch, namely:&lt;br /&gt;
* Download and install required libraries (NetCDF, IOIPSL and possibly XIOS)&lt;br /&gt;
* Download the source code (LMDZ and ORCHIDEE), compile it and run a test (bench) simulation&lt;br /&gt;
&lt;br /&gt;
It has many options and features; a good starting point (short of reading and digesting the Bash script itself) is to run '''install_lmdz.sh -h''' to learn about these, which should yield something like:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
install_lmdz.sh&lt;br /&gt;
    ./install_lmdz.sh [ -v version ] [ -r svn_release ]&lt;br /&gt;
           [ -parallel PARA ] [ -d GRID_RESOLUTION ] [ -bench 0/1 ]&lt;br /&gt;
           [-name LOCAL_MODEL_NAME] [-gprof] [-opt_makelmdz] [-rad RADIATIF]&lt;br /&gt;
&lt;br /&gt;
    -v       &amp;quot;version&amp;quot; like 20150828.trunk&lt;br /&gt;
             see http://www.lmd.jussieu.fr/~lmdz/Distrib/LISMOI.trunk&lt;br /&gt;
&lt;br /&gt;
    -r       &amp;quot;svn_release&amp;quot; : either the svn release number or &amp;quot;last&amp;quot;&lt;br /&gt;
    &lt;br /&gt;
    -compiler gfortran|ifort|pgf90 (default: gfortran)&lt;br /&gt;
&lt;br /&gt;
    -parallel PARA : can be mpi_omp (mpi with openMP) or none (for sequential)&lt;br /&gt;
&lt;br /&gt;
    -d        GRID_RESOLUTION should be among the available benchs if -bench 1&lt;br /&gt;
              among which : 48x36x19, 48x36x39&lt;br /&gt;
              if wanting to run a bench simulation in addition to compilation&lt;br /&gt;
              default : 48x36x19&lt;br /&gt;
&lt;br /&gt;
    -bench     activating the bench or not (0/1). Default 1&lt;br /&gt;
&lt;br /&gt;
    -name      LOCAL_MODEL_NAME : default = LMDZversion.release&lt;br /&gt;
&lt;br /&gt;
    -netcdf    PATH : full path to an existing installed NetCDF library&lt;br /&gt;
               (without -netcdf: also download and install the NetCDF library)  &lt;br /&gt;
    &lt;br /&gt;
    -xios      also download and compile the XIOS library&lt;br /&gt;
               (requires the NetCDF4-HDF5 library, also installed by default)&lt;br /&gt;
               (requires to also have -parallel mpi_omp)&lt;br /&gt;
&lt;br /&gt;
    -gprof     to compile with -pg to enable profiling with gprof&lt;br /&gt;
&lt;br /&gt;
    -cosp      to run without our with cospv1 or cospv2 [none/v1/v2]&lt;br /&gt;
 &lt;br /&gt;
    -rad RADIATIF can be old, rrtm or ecrad radiatif code&lt;br /&gt;
&lt;br /&gt;
    -nofcm     to compile without fcm&lt;br /&gt;
&lt;br /&gt;
    -SCM        install 1D version automatically&lt;br /&gt;
&lt;br /&gt;
    -debug      compile everything in debug mode&lt;br /&gt;
&lt;br /&gt;
    -opt_makelmdz     to call makelmdz or makelmdz_fcm with additional options&lt;br /&gt;
&lt;br /&gt;
    -physiq    to choose which physics package to use&lt;br /&gt;
&lt;br /&gt;
    -env_file  specify an arch.env file to overwrite the existing one&lt;br /&gt;
&lt;br /&gt;
    -veget surface model to run [NONE/CMIP6/xxxx]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Note that the ''install_lmdz.sh'' script is not the only way to install LMDZ; one can manually do the various key steps (quite possibly adapted to the specificities of the machine that is used).&lt;br /&gt;
&lt;br /&gt;
02/12/2021&lt;br /&gt;
&lt;br /&gt;
[[Category:WhatIs]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== New install_lmdz version (Amaury - 06/2024) ==&lt;br /&gt;
&lt;br /&gt;
=== Known bugs / issues ===&lt;br /&gt;
&lt;br /&gt;
==== ORCHIDEE bench ====&lt;br /&gt;
&lt;br /&gt;
Right now (06/24), only the CMIP6/orch2.0 ORCHIDEE version has a proper bench.&lt;br /&gt;
As a result, other versions (orch2.2, orch4/trunk) run in a bench that doesn't activate ORCHIDEE.&lt;br /&gt;
&lt;br /&gt;
''Todo: make a proper orch2.2 and orch4 bench, with/without xios)''&lt;br /&gt;
&lt;br /&gt;
==== Debug mode crashes ====&lt;br /&gt;
&lt;br /&gt;
When activating &amp;lt;code&amp;gt;-debug&amp;lt;/code&amp;gt;, with newer versions of NETCDF, a segfault is raised on lines such as &amp;lt;code&amp;gt;CALL err(NF90_OPEN(var,NF90_NOWRITE,fID),&amp;quot;open&amp;quot;,var)&amp;lt;/code&amp;gt;. It seems that the segfault originates from the NF90_OPEN function itself.&lt;br /&gt;
&lt;br /&gt;
''Todo: check with even newer versions of netcdf - but then we face the other documented netcdf bug...''&lt;br /&gt;
&lt;br /&gt;
==== ORCHIDEE 4/TRUNK compilation fails ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4/trunk can't be compiled with gfortran for now. This issue has been raised to the ORCHIDEE team (06/24).&lt;br /&gt;
&lt;br /&gt;
''Todo: update when orch fixes their code''&lt;br /&gt;
&lt;br /&gt;
==== &amp;lt;code&amp;gt;Error   -105 in closing file&amp;lt;/code&amp;gt; ====&lt;br /&gt;
&lt;br /&gt;
with &amp;lt;code&amp;gt;-parallel mpi_omp -veget orch2.0&amp;lt;/code&amp;gt;, at the end of a simulation, we can read in &amp;lt;code&amp;gt;listing&amp;lt;/code&amp;gt;:&lt;br /&gt;
 WARNING FROM ROUTINE restclo&lt;br /&gt;
 --&amp;gt; Error   -105 in closing file : ***&lt;br /&gt;
 --&amp;gt; sechiba_rest_out.nc&lt;br /&gt;
 --&amp;gt; &lt;br /&gt;
&lt;br /&gt;
This &amp;quot;error&amp;quot; doesn't seem to actually affect the outputs, and should be ignored; yet, its cause hasn't been investigated.&lt;br /&gt;
&lt;br /&gt;
==== Compilation with newer netcdf/hdf5 ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;install_lmdz&amp;lt;/code&amp;gt; can't be used with very recent netcdf/hdf5 libraries.&lt;br /&gt;
&lt;br /&gt;
''TODO: add specific versions, + error messages''&lt;br /&gt;
&lt;br /&gt;
==== COSP + orch + xios segfault ====&lt;br /&gt;
&lt;br /&gt;
With &amp;lt;code&amp;gt;-veget orch2.0 -xios -cosp v1&amp;lt;/code&amp;gt; (or &amp;lt;code&amp;gt;v2&amp;lt;/code&amp;gt;), we encounter a segfault in the bench.&lt;br /&gt;
&lt;br /&gt;
Unfortunately because of the netcdf debug bug (see above), we can't get to the actual trace....&lt;br /&gt;
&lt;br /&gt;
==== XIOS compilation failure ====&lt;br /&gt;
&lt;br /&gt;
XIOS 2.6 r2568 compilation fails randomly when compiled in parallel (&amp;lt;code&amp;gt;make_xios --job N&amp;lt;/code&amp;gt;). The stack trace:&lt;br /&gt;
&lt;br /&gt;
 mpif90 -o generic_testcase.exe /home/abarral/PycharmProjects/installLMDZ/script_install/LMDZ/modipsl/modeles/XIOS/obj/generic_testcase.o -L/home/abarral/PycharmProjects/installLMDZ/script_install/LMDZ/modipsl/modeles/XIOS/lib -l__fcm__generic_testcase -lxios -lstdc++ -L/home/abarral/Programs/zlib_mpi_hdf5_ncdf_cdo/netcdf-c-4.9.2-fortran-4.5.4-cxx-4.3.1/lib -lnetcdff -L//home/abarral/Programs/zlib_mpi_hdf5_ncdf_cdo/netcdf-c-4.9.2-fortran-4.5.4-cxx-4.3.1/lib -lnetcdf -lnetcdf -lm -Wl,-rpath=/home/abarral/Programs/zlib_mpi_hdf5_ncdf_cdo/openmpi-4.1.6/bin/../lib:/home/abarral/Programs/zlib_mpi_hdf5_ncdf_cdo/netcdf-c-4.9.2-fortran-4.5.4-cxx-4.3.1/lib -lstdc++&lt;br /&gt;
 /usr/bin/ld: cannot find -lxios: No such file or directory&lt;br /&gt;
 /usr/bin/ld: cannot find -lxios: No such file or directory&lt;br /&gt;
 collect2: error: ld returned 1 exit status&lt;br /&gt;
 fcm_internal load failed (256)&lt;br /&gt;
&lt;br /&gt;
seems to indicate a race condition in the fcm process.&lt;br /&gt;
&lt;br /&gt;
''I'm not sure if this problem has been reported to the XIOS team. We also haven't tested if it's present in newer XIOS versions.''&lt;br /&gt;
&lt;br /&gt;
'''Solution''': Restart the compilation.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=WhatIs:_The_install_lmdz.sh_script&amp;diff=457</id>
		<title>WhatIs: The install lmdz.sh script</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=WhatIs:_The_install_lmdz.sh_script&amp;diff=457"/>
				<updated>2024-07-10T07:24:14Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : document further bugs&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The ''install_lmdz.sh'' script is a Bash script that aims at being an &amp;quot;installer&amp;quot; for LMDZ of Linux machines.&lt;br /&gt;
&lt;br /&gt;
In practice it runs a succession of mandatory steps to install and run the model from scratch, namely:&lt;br /&gt;
* Download and install required libraries (NetCDF, IOIPSL and possibly XIOS)&lt;br /&gt;
* Download the source code (LMDZ and ORCHIDEE), compile it and run a test (bench) simulation&lt;br /&gt;
&lt;br /&gt;
It has many options and features; a good starting point (short of reading and digesting the Bash script itself) is to run '''install_lmdz.sh -h''' to learn about these, which should yield something like:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
install_lmdz.sh&lt;br /&gt;
    ./install_lmdz.sh [ -v version ] [ -r svn_release ]&lt;br /&gt;
           [ -parallel PARA ] [ -d GRID_RESOLUTION ] [ -bench 0/1 ]&lt;br /&gt;
           [-name LOCAL_MODEL_NAME] [-gprof] [-opt_makelmdz] [-rad RADIATIF]&lt;br /&gt;
&lt;br /&gt;
    -v       &amp;quot;version&amp;quot; like 20150828.trunk&lt;br /&gt;
             see http://www.lmd.jussieu.fr/~lmdz/Distrib/LISMOI.trunk&lt;br /&gt;
&lt;br /&gt;
    -r       &amp;quot;svn_release&amp;quot; : either the svn release number or &amp;quot;last&amp;quot;&lt;br /&gt;
    &lt;br /&gt;
    -compiler gfortran|ifort|pgf90 (default: gfortran)&lt;br /&gt;
&lt;br /&gt;
    -parallel PARA : can be mpi_omp (mpi with openMP) or none (for sequential)&lt;br /&gt;
&lt;br /&gt;
    -d        GRID_RESOLUTION should be among the available benchs if -bench 1&lt;br /&gt;
              among which : 48x36x19, 48x36x39&lt;br /&gt;
              if wanting to run a bench simulation in addition to compilation&lt;br /&gt;
              default : 48x36x19&lt;br /&gt;
&lt;br /&gt;
    -bench     activating the bench or not (0/1). Default 1&lt;br /&gt;
&lt;br /&gt;
    -name      LOCAL_MODEL_NAME : default = LMDZversion.release&lt;br /&gt;
&lt;br /&gt;
    -netcdf    PATH : full path to an existing installed NetCDF library&lt;br /&gt;
               (without -netcdf: also download and install the NetCDF library)  &lt;br /&gt;
    &lt;br /&gt;
    -xios      also download and compile the XIOS library&lt;br /&gt;
               (requires the NetCDF4-HDF5 library, also installed by default)&lt;br /&gt;
               (requires to also have -parallel mpi_omp)&lt;br /&gt;
&lt;br /&gt;
    -gprof     to compile with -pg to enable profiling with gprof&lt;br /&gt;
&lt;br /&gt;
    -cosp      to run without our with cospv1 or cospv2 [none/v1/v2]&lt;br /&gt;
 &lt;br /&gt;
    -rad RADIATIF can be old, rrtm or ecrad radiatif code&lt;br /&gt;
&lt;br /&gt;
    -nofcm     to compile without fcm&lt;br /&gt;
&lt;br /&gt;
    -SCM        install 1D version automatically&lt;br /&gt;
&lt;br /&gt;
    -debug      compile everything in debug mode&lt;br /&gt;
&lt;br /&gt;
    -opt_makelmdz     to call makelmdz or makelmdz_fcm with additional options&lt;br /&gt;
&lt;br /&gt;
    -physiq    to choose which physics package to use&lt;br /&gt;
&lt;br /&gt;
    -env_file  specify an arch.env file to overwrite the existing one&lt;br /&gt;
&lt;br /&gt;
    -veget surface model to run [NONE/CMIP6/xxxx]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Note that the ''install_lmdz.sh'' script is not the only way to install LMDZ; one can manually do the various key steps (quite possibly adapted to the specificities of the machine that is used).&lt;br /&gt;
&lt;br /&gt;
02/12/2021&lt;br /&gt;
&lt;br /&gt;
[[Category:WhatIs]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== New install_lmdz version (Amaury - 06/2024) ==&lt;br /&gt;
&lt;br /&gt;
=== Known bugs / issues ===&lt;br /&gt;
&lt;br /&gt;
==== ORCHIDEE bench ====&lt;br /&gt;
&lt;br /&gt;
Right now (06/24), only the CMIP6/orch2.0 ORCHIDEE version has a proper bench.&lt;br /&gt;
As a result, other versions (orch2.2, orch4/trunk) run in a bench that doesn't activate ORCHIDEE.&lt;br /&gt;
&lt;br /&gt;
''Todo: make a proper orch2.2 and orch4 bench, with/without xios)''&lt;br /&gt;
&lt;br /&gt;
==== Debug mode crashes ====&lt;br /&gt;
&lt;br /&gt;
When activating &amp;lt;code&amp;gt;-debug&amp;lt;/code&amp;gt;, with newer versions of NETCDF, a segfault is raised on lines such as &amp;lt;code&amp;gt;CALL err(NF90_OPEN(var,NF90_NOWRITE,fID),&amp;quot;open&amp;quot;,var)&amp;lt;/code&amp;gt;. It seems that the segfault originates from the NF90_OPEN function itself.&lt;br /&gt;
&lt;br /&gt;
''Todo: check with even newer versions of netcdf - but then we face the other documented netcdf bug...''&lt;br /&gt;
&lt;br /&gt;
==== ORCHIDEE 4/TRUNK compilation fails ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4/trunk can't be compiled with gfortran for now. This issue has been raised to the ORCHIDEE team (06/24).&lt;br /&gt;
&lt;br /&gt;
''Todo: update when orch fixes their code''&lt;br /&gt;
&lt;br /&gt;
==== &amp;lt;code&amp;gt;Error   -105 in closing file&amp;lt;/code&amp;gt; ====&lt;br /&gt;
&lt;br /&gt;
with &amp;lt;code&amp;gt;-parallel mpi_omp -veget orch2.0&amp;lt;/code&amp;gt;, at the end of a simulation, we can read in &amp;lt;code&amp;gt;listing&amp;lt;/code&amp;gt;:&lt;br /&gt;
 WARNING FROM ROUTINE restclo&lt;br /&gt;
 --&amp;gt; Error   -105 in closing file : ***&lt;br /&gt;
 --&amp;gt; sechiba_rest_out.nc&lt;br /&gt;
 --&amp;gt; &lt;br /&gt;
&lt;br /&gt;
This &amp;quot;error&amp;quot; doesn't seem to actually affect the outputs, and should be ignored; yet, its cause hasn't been investigated.&lt;br /&gt;
&lt;br /&gt;
==== Compilation with newer netcdf/hdf5 ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;install_lmdz&amp;lt;/code&amp;gt; can't be used with very recent netcdf/hdf5 libraries.&lt;br /&gt;
&lt;br /&gt;
''TODO: add specific versions, + error messages''&lt;br /&gt;
&lt;br /&gt;
==== COSP + orch + xios segfault ====&lt;br /&gt;
&lt;br /&gt;
With &amp;lt;code&amp;gt;-veget orch2.0 -xios -cosp v1&amp;lt;/code&amp;gt; (or &amp;lt;code&amp;gt;v2&amp;lt;/code&amp;gt;), we encounter a segfault in the bench.&lt;br /&gt;
&lt;br /&gt;
Unfortunately because of the netcdf debug bug (see above), we can't get to the actual trace....&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=WhatIs:_The_install_lmdz.sh_script&amp;diff=456</id>
		<title>WhatIs: The install lmdz.sh script</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=WhatIs:_The_install_lmdz.sh_script&amp;diff=456"/>
				<updated>2024-07-10T07:21:42Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : Add new install_lmdz know bugs&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The ''install_lmdz.sh'' script is a Bash script that aims at being an &amp;quot;installer&amp;quot; for LMDZ of Linux machines.&lt;br /&gt;
&lt;br /&gt;
In practice it runs a succession of mandatory steps to install and run the model from scratch, namely:&lt;br /&gt;
* Download and install required libraries (NetCDF, IOIPSL and possibly XIOS)&lt;br /&gt;
* Download the source code (LMDZ and ORCHIDEE), compile it and run a test (bench) simulation&lt;br /&gt;
&lt;br /&gt;
It has many options and features; a good starting point (short of reading and digesting the Bash script itself) is to run '''install_lmdz.sh -h''' to learn about these, which should yield something like:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
install_lmdz.sh&lt;br /&gt;
    ./install_lmdz.sh [ -v version ] [ -r svn_release ]&lt;br /&gt;
           [ -parallel PARA ] [ -d GRID_RESOLUTION ] [ -bench 0/1 ]&lt;br /&gt;
           [-name LOCAL_MODEL_NAME] [-gprof] [-opt_makelmdz] [-rad RADIATIF]&lt;br /&gt;
&lt;br /&gt;
    -v       &amp;quot;version&amp;quot; like 20150828.trunk&lt;br /&gt;
             see http://www.lmd.jussieu.fr/~lmdz/Distrib/LISMOI.trunk&lt;br /&gt;
&lt;br /&gt;
    -r       &amp;quot;svn_release&amp;quot; : either the svn release number or &amp;quot;last&amp;quot;&lt;br /&gt;
    &lt;br /&gt;
    -compiler gfortran|ifort|pgf90 (default: gfortran)&lt;br /&gt;
&lt;br /&gt;
    -parallel PARA : can be mpi_omp (mpi with openMP) or none (for sequential)&lt;br /&gt;
&lt;br /&gt;
    -d        GRID_RESOLUTION should be among the available benchs if -bench 1&lt;br /&gt;
              among which : 48x36x19, 48x36x39&lt;br /&gt;
              if wanting to run a bench simulation in addition to compilation&lt;br /&gt;
              default : 48x36x19&lt;br /&gt;
&lt;br /&gt;
    -bench     activating the bench or not (0/1). Default 1&lt;br /&gt;
&lt;br /&gt;
    -name      LOCAL_MODEL_NAME : default = LMDZversion.release&lt;br /&gt;
&lt;br /&gt;
    -netcdf    PATH : full path to an existing installed NetCDF library&lt;br /&gt;
               (without -netcdf: also download and install the NetCDF library)  &lt;br /&gt;
    &lt;br /&gt;
    -xios      also download and compile the XIOS library&lt;br /&gt;
               (requires the NetCDF4-HDF5 library, also installed by default)&lt;br /&gt;
               (requires to also have -parallel mpi_omp)&lt;br /&gt;
&lt;br /&gt;
    -gprof     to compile with -pg to enable profiling with gprof&lt;br /&gt;
&lt;br /&gt;
    -cosp      to run without our with cospv1 or cospv2 [none/v1/v2]&lt;br /&gt;
 &lt;br /&gt;
    -rad RADIATIF can be old, rrtm or ecrad radiatif code&lt;br /&gt;
&lt;br /&gt;
    -nofcm     to compile without fcm&lt;br /&gt;
&lt;br /&gt;
    -SCM        install 1D version automatically&lt;br /&gt;
&lt;br /&gt;
    -debug      compile everything in debug mode&lt;br /&gt;
&lt;br /&gt;
    -opt_makelmdz     to call makelmdz or makelmdz_fcm with additional options&lt;br /&gt;
&lt;br /&gt;
    -physiq    to choose which physics package to use&lt;br /&gt;
&lt;br /&gt;
    -env_file  specify an arch.env file to overwrite the existing one&lt;br /&gt;
&lt;br /&gt;
    -veget surface model to run [NONE/CMIP6/xxxx]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Note that the ''install_lmdz.sh'' script is not the only way to install LMDZ; one can manually do the various key steps (quite possibly adapted to the specificities of the machine that is used).&lt;br /&gt;
&lt;br /&gt;
02/12/2021&lt;br /&gt;
&lt;br /&gt;
[[Category:WhatIs]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== New install_lmdz version (Amaury - 06/2024) ==&lt;br /&gt;
&lt;br /&gt;
=== Known bugs / issues ===&lt;br /&gt;
&lt;br /&gt;
==== ORCHIDEE bench ====&lt;br /&gt;
&lt;br /&gt;
Right now (06/24), only the CMIP6/orch2.0 ORCHIDEE version has a proper bench.&lt;br /&gt;
As a result, other versions (orch2.2, orch4/trunk) run in a bench that doesn't activate ORCHIDEE.&lt;br /&gt;
&lt;br /&gt;
''Todo: make a proper orch2.2 and orch4 bench, with/without xios)''&lt;br /&gt;
&lt;br /&gt;
==== Debug mode crashes ====&lt;br /&gt;
&lt;br /&gt;
When activating &amp;lt;code&amp;gt;-debug&amp;lt;/code&amp;gt;, with newer versions of NETCDF, a segfault is raised on lines such as &amp;lt;code&amp;gt;CALL err(NF90_OPEN(var,NF90_NOWRITE,fID),&amp;quot;open&amp;quot;,var)&amp;lt;/code&amp;gt;. It seems that the segfault originates from the NF90_OPEN function itself.&lt;br /&gt;
&lt;br /&gt;
''Todo: check with even newer versions of netcdf - but then we face the other documented netcdf bug...''&lt;br /&gt;
&lt;br /&gt;
==== ORCHIDEE 4/TRUNK compilation fails ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4/trunk can't be compiled with gfortran for now. This issue has been raised to the ORCHIDEE team (06/24).&lt;br /&gt;
&lt;br /&gt;
''Todo: update when orch fixes their code''&lt;br /&gt;
&lt;br /&gt;
==== &amp;lt;code&amp;gt;Error   -105 in closing file&amp;lt;/code&amp;gt; ====&lt;br /&gt;
&lt;br /&gt;
with &amp;lt;code&amp;gt;-parallel mpi_omp -veget orch2.0&amp;lt;/code&amp;gt;, at the end of a simulation, we can read in &amp;lt;code&amp;gt;listing&amp;lt;/code&amp;gt;:&lt;br /&gt;
 WARNING FROM ROUTINE restclo&lt;br /&gt;
 --&amp;gt; Error   -105 in closing file : ***&lt;br /&gt;
 --&amp;gt; sechiba_rest_out.nc&lt;br /&gt;
 --&amp;gt; &lt;br /&gt;
&lt;br /&gt;
This &amp;quot;error&amp;quot; doesn't seem to actually affect the outputs, and should be ignored; yet, its cause hasn't been investigated.&lt;br /&gt;
&lt;br /&gt;
==== Compilation with newer netcdf/hdf5 ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;install_lmdz&amp;lt;/code&amp;gt; can't be used with very recent netcdf/hdf5 libraries.&lt;br /&gt;
&lt;br /&gt;
''TODO: add specific versions, + error messages''&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=455</id>
		<title>LMDZ Setup</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=455"/>
				<updated>2024-07-09T07:45:04Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : Add information regarding new LMDZ_Setup&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LMDZ_Setup is a set of scripts that allows a light automatic setup of LMDZ long chained climate simulations, including the installation of the model itself.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can only be used on the Jean-Zay computer at Idris so far.&lt;br /&gt;
&lt;br /&gt;
Coming VERY soon (summer 2024) : extension to other computing centers (&amp;quot;spirit&amp;quot;, adastra) and Linux PCs&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Documentation (in French):'''&lt;br /&gt;
[https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit LMDZ_Setup_HowTo]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''To extract LMDZ_Setup :'''&lt;br /&gt;
&lt;br /&gt;
a/ Recommended : extraction from svn repository : &lt;br /&gt;
&lt;br /&gt;
    svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&lt;br /&gt;
&lt;br /&gt;
b/ Download of the &amp;quot;tar&amp;quot; archive :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&lt;br /&gt;
 &lt;br /&gt;
c/ For those used with the old name &amp;quot;tutorial_prod.tar&amp;quot; : a link with this name still exists, pointing to LMDZ_Setup.tar :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''(Text extracted from LMDZ_Setup/README0_HowTo):''&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup consists in running '''LMDZ coupled to Orchidee''' for land surface (optional), but with '''imposed sea surface temperature'''.&lt;br /&gt;
&lt;br /&gt;
The '''basic default configuration''' makes use of the IPSL-CM6A grid configuration and tuning, and runs a multi annual simulation on &amp;quot;climatological&amp;quot;&lt;br /&gt;
amip sea surface temperature (with a mean annual cycle) using a calendar with 360 days.&lt;br /&gt;
&lt;br /&gt;
Optionally : the configuration includes the '''ability to use interannually varying SST''' and to activate '''&amp;quot;nudging&amp;quot;''' by a reanalysis.&lt;br /&gt;
In both cases, the calendar is then a real one.&lt;br /&gt;
When nudging is activated, the simulation must be run on a monthly basis, while otherwise, it can be either monthly or yearly.&lt;br /&gt;
&lt;br /&gt;
Since LMDZ_Setup automatically generates its own initial files, it can be run with '''zoom configurations''' by only changing the number of grid points (&amp;quot;resol&amp;quot; in main.sh) and the DEF/gcm.def file (see bellow).&lt;br /&gt;
&lt;br /&gt;
'''Aerosols''' can be read for the year 2000 (weighted average  over 1999-2001 cf Lurton et al 2020), and instantaneous forcing with respect to 1850 can be computed as well.&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can also run LMDZ coupled with the '''SPLA model''' (SimPLe Aerosol, activated with option aerosols=spla in setup.sh).&lt;br /&gt;
Emissions of dust and sea salt are then computed interactively.&lt;br /&gt;
For the time being, SPLA-specific input files (anthropic aerosol emissions)are only available on the grid zoomed over N Africa used by J. Escribano in his PhD thesis, and by B. Diallo and H. Senghor in subsequent work on N-African dust (file DEF/gcm.def_zNAfrica_BiJe).&lt;br /&gt;
&lt;br /&gt;
A configuration with '''isotopes''' is also available since 2023-04.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Below: new LMDZ_Setup docs ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Old documentation (French): [https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c LMDZ_Setup_HowTo]''&lt;br /&gt;
&lt;br /&gt;
== User guide ==&lt;br /&gt;
&lt;br /&gt;
 ''' /!\ WARNING''' 06/2024 - (ignore if installing a new version)&lt;br /&gt;
 The JeanZay calculator, as well as Adastra, do not allow (anymore) communication from/to $STORE for running jobs on the main computing partitions.&lt;br /&gt;
 As a result, make sure to replace $STORE by $WORK in &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt; wherever relevant.&lt;br /&gt;
&lt;br /&gt;
 '''READ comments at the top of scripts ! Often your questions are answered there.'''&lt;br /&gt;
&lt;br /&gt;
 ''Note'': &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; has been tested on Adastra and Spirit, and to a lesser extent on JeanZay (legacy support only). No guarantee is made on other platforms, although it should be easy to adapt it. It can also be ran locally - for expert use only.&lt;br /&gt;
&lt;br /&gt;
=== Downloading LMDZ_Setup ===&lt;br /&gt;
&lt;br /&gt;
* ''(recommended)'' Using ''subversion'': &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(alternative)'' &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(deprecated)'' The old &amp;lt;code&amp;gt;tutorial_prod&amp;lt;/code&amp;gt; version: &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Structure ===&lt;br /&gt;
&lt;br /&gt;
Once you have downloaded &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;, you will find the following main files:&lt;br /&gt;
* &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;: the main script. It contains the basic settings you will modify.&lt;br /&gt;
* &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;: this script contains the internal workings of &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. It's where you can edit expert-level settings.&lt;br /&gt;
* &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;: this file contains platform-specific configuration, such as where to install the model, where to run the simulations, etc.&lt;br /&gt;
&lt;br /&gt;
=== How to run a simulation ===&lt;br /&gt;
&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;set_env&amp;lt;/code&amp;gt;, find the case corresponding to your supercomputer: &amp;lt;code&amp;gt;jean-)&amp;lt;/code&amp;gt; for JeanZay, &amp;lt;code&amp;gt;spiri)&amp;lt;/code&amp;gt; for Spirit, &amp;lt;code&amp;gt;adast)&amp;lt;/code&amp;gt; for Adastra. Edit the variables required for your use case. All the variables are documented in the last &amp;lt;code&amp;gt;*)&amp;lt;/code&amp;gt; case. In particular:&lt;br /&gt;
#* you must set &amp;lt;code&amp;gt;root_dir&amp;lt;/code&amp;gt; to the path where you extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;.&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;define_expert_options&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;DEF/*&amp;lt;/code&amp;gt;.''' Edit the &amp;lt;code&amp;gt;DEF/*.def&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt; files, such as &amp;lt;code&amp;gt;config.def&amp;lt;/code&amp;gt;, to your liking. ''The options you specify in main.sh/setup.sh don't require any adjustment here; such adjustments are automatically performed at runtime.''&lt;br /&gt;
# '''Launch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;'''.&lt;br /&gt;
&lt;br /&gt;
=== Miscellanous notes ===&lt;br /&gt;
&lt;br /&gt;
* Simulations run in a subdirectory of &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; with the same name as the &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder (if you have extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; and renamed it to &amp;lt;code&amp;gt;My_Setup&amp;lt;/code&amp;gt; then simulations will run in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/My_Setup&amp;lt;/code&amp;gt;). Each simulation is contained in its own folder, named after the simulation's name + a process number. As a result, '''you don't need to clean $SIMRUNBASEDIR before relaunching a simulation'''.&lt;br /&gt;
* If your simulation crashes, look directly in &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; for the relevant log.&lt;br /&gt;
* If you need a version of ORCHIDEE different from the one provided by default in the model (such as &amp;lt;code&amp;gt;CMIP6&amp;lt;/code&amp;gt;), a password is required - ask ''orchidee-help at listes.ipsl.fr'' if you need help.&lt;br /&gt;
&lt;br /&gt;
==== XIOS ====&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' Although XIOS is not ''required'' for ORCHIDEE &amp;gt;=2.2, not using it will disable some features.&lt;br /&gt;
Different sets of &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt; files are available in &amp;lt;code&amp;gt;LMDZ_Setup/DEF/XMLFiles*&amp;lt;/code&amp;gt;. However, only some common files (&amp;lt;code&amp;gt;histf, histday, histmth&amp;lt;/code&amp;gt;) have been adapted for &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. ''If you need other outputs, '''be sure to edit/check the relevant &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt;''''':&lt;br /&gt;
* replace the &amp;lt;code&amp;gt;_AUTO_&amp;lt;/code&amp;gt; for &amp;lt;code&amp;gt;output_level&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;enabled&amp;lt;/code&amp;gt; by actual values;&lt;br /&gt;
* use &amp;lt;code&amp;gt;compression_level=0&amp;lt;/code&amp;gt; instead of the default values (&amp;lt;code&amp;gt;2&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;4&amp;lt;/code&amp;gt;) (since &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; uses XIOS in attached mode rather than client-server mode, using non-zero compression levels would require running XIOS on 1+ dedicated MPI).&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' After installing the model, two files are automatically initialized in &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;context_lmdz.xml&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;field_def_lmdz.xml&amp;lt;/code&amp;gt;. Those files don't require user intervention, and must match the exact LMDZ revision used.&lt;br /&gt;
&lt;br /&gt;
==== Compilation ====&lt;br /&gt;
&lt;br /&gt;
When launching &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, before running the simulation, we first download and compile the required models. Although we call the compilation script every time, if the model has already been compiled before, the script should detect that and skip the actual compilation, and thus execute very quickly.&lt;br /&gt;
&lt;br /&gt;
''Note: on supported clusters, compilation is launched in jobs rather than on the login node. This speeds up the compilation.''&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' As written in the comments of &amp;lt;code&amp;gt;main.sh/setup.sh&amp;lt;/code&amp;gt;, '''if you change the &amp;lt;code&amp;gt;veget&amp;lt;/code&amp;gt; version or the &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt;, it is highly recommended to do so in a NEW clean &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder''' rather than recompiling in the same folder.&lt;br /&gt;
&lt;br /&gt;
=== Nudging ===&lt;br /&gt;
&lt;br /&gt;
Nudging is set via the &amp;lt;code&amp;gt;nudging&amp;lt;/code&amp;gt; variable in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. If activated, then after installing the model, &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; will prompt you to run &amp;lt;code&amp;gt;era2gcm_tuto.sh&amp;lt;/code&amp;gt;. This script fetches reanalysis data and puts it in a &amp;lt;code&amp;gt;GUIDE/&amp;lt;/code&amp;gt; folder.&lt;br /&gt;
Once this is done, simply set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and relaunch it.&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' On Adastra, the reanalysis files are not yet available.&lt;br /&gt;
&lt;br /&gt;
=== Aerosols ===&lt;br /&gt;
&lt;br /&gt;
 '''/!\ As written in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, it is highly recommended to install &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; in a new clean directory when changing aerosols options. Otherwise i.e. the &amp;lt;code&amp;gt;DEF/config.def&amp;lt;/code&amp;gt; may not get modified accordingly.'''&lt;br /&gt;
&lt;br /&gt;
When &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt; is set to anything other than &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, aerosols files will be downloaded in &amp;lt;code&amp;gt;LIMIT/&amp;lt;/code&amp;gt;, and will be interpolated to the horizontal grid resolution (vertical interpolation is performed at runtime by the GCM.)&lt;br /&gt;
&lt;br /&gt;
==== More detail ====&lt;br /&gt;
&lt;br /&gt;
The aerosols files used for the options &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt; are those used in CMIP6 with the LMDZORINCA configuration, from [https://www.lmd.jussieu.fr/~lmdz/pub/3DInputData/AerChem/ here].&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt;, we only use &amp;lt;code&amp;gt;aerosols1850_from_inca.nc&amp;lt;/code&amp;gt; (natural aerosols), interpolated as &amp;lt;code&amp;gt;aerosols.nat.nc&amp;lt;/code&amp;gt;&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt;, we also use &amp;lt;code&amp;gt;aerosols9999_from_inca.nc&amp;lt;/code&amp;gt; with the mean aerosols on 1995-2014, interpolated as &amp;lt;code&amp;gt;aerosols.clim.nc&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== ORCHIDEE ===&lt;br /&gt;
&lt;br /&gt;
The officially supported versions of ORCHIDEE supported by LMDZ_Setup are:&lt;br /&gt;
* the CMIP6 version (still using the two-layer hydrology channel)&lt;br /&gt;
* version 2.2 r7983&lt;br /&gt;
* version 4 (trunk) r7994 (corresponding to libIGCM's LMDZOR_6.4work configuration)&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' The relevant ORCHIDEE def file &amp;lt;code&amp;gt;DEF/orchidee.def_*&amp;lt;/code&amp;gt; gets copied as &amp;lt;code&amp;gt;DEF/orchidee.def&amp;lt;/code&amp;gt; at initialisation.&lt;br /&gt;
&lt;br /&gt;
==== Activating sechiba outputs ====&lt;br /&gt;
&lt;br /&gt;
Sechiba outputs are written to &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt;, but are deleted by &amp;lt;code&amp;gt;tmp_SIM&amp;lt;/code&amp;gt; before they're rebuilt. To counter that, remove the &amp;lt;code&amp;gt;sec*&amp;lt;/code&amp;gt; on the relevant line &amp;lt;code&amp;gt;set +e ; \rm out* sec* sta* list* rest* gcm.e aer* ; set -e&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Simple routing ====&lt;br /&gt;
&lt;br /&gt;
From orch 2.2 r7597 onwards, the &amp;quot;simple&amp;quot; routing scheme by Y. Meurdesoif can be activated.&lt;br /&gt;
&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/orchidee.def_6.*&amp;lt;/code&amp;gt;, set &amp;lt;code&amp;gt;RIVER_ROUTING=y&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;ROUTING_METHOD = simple&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;RIVER_DESC=y&amp;lt;/code&amp;gt; (''Note: &amp;lt;code&amp;gt;RIVER_DESC&amp;lt;/code&amp;gt; is automatically set to &amp;quot;n&amp;quot; after the first simulation period.)&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/XMLfilesOR7***/iodef.xml&amp;lt;/code&amp;gt;, add at the end of &amp;lt;code&amp;gt;context_orchidee.xml&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;&amp;lt;context id=&amp;quot;orchidee&amp;quot; src=&amp;quot;./context_routing_orchidee.xml&amp;quot;/&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
See also:[https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/UserGuide/RoutageSimple User Guide/Routage Simple] (French).&lt;br /&gt;
&lt;br /&gt;
=== Isotopes ===&lt;br /&gt;
&lt;br /&gt;
To activate isotopes, simply change the &amp;lt;code&amp;gt;lmd_phys&amp;lt;/code&amp;gt; parameter to &amp;lt;code&amp;gt;&amp;quot;lmdiso&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. This will automatically&lt;br /&gt;
* use &amp;lt;code&amp;gt;&amp;quot;phylmdiso&amp;quot;&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;&amp;quot;phylmd&amp;quot;&amp;lt;/code&amp;gt;;&lt;br /&gt;
* copy &amp;lt;code&amp;gt;DEF/PHYS/physiq.def_NPiso&amp;lt;/code&amp;gt; to &amp;lt;code&amp;gt;DEF/physiq.def&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: for isotopes, &amp;lt;code&amp;gt;iflag_ice_thermo&amp;lt;/code&amp;gt; is automatically set to &amp;lt;code&amp;gt;0&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;1&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
* ''How to relaunch a failed simulation ?''&lt;br /&gt;
&lt;br /&gt;
If the simulation ran for at least one successful period, simplys set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and rerun it. Otherwise, see the following question.&lt;br /&gt;
&lt;br /&gt;
* ''I have ran a simulation, but I messed up the parameters. I want to run a new clean simulation with the same name (e.g. &amp;lt;code&amp;gt;NPv6.3&amp;lt;/code&amp;gt;.)''&lt;br /&gt;
&lt;br /&gt;
Remove &amp;lt;code&amp;gt;INIT, LIMIT, NPv6.3&amp;lt;/code&amp;gt; and relaunch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; with &amp;lt;code&amp;gt;init=1&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
* ''How can I follow the state of a running simulation ?''&lt;br /&gt;
&lt;br /&gt;
Check the file &amp;lt;code&amp;gt;LMDZ_Setup/$SIM_NAME/etat&amp;lt;/code&amp;gt;. After each period (mo/yr), it gets updated like so:&lt;br /&gt;
 200001 a faire&lt;br /&gt;
 200001 OK&lt;br /&gt;
 200002 a faire&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To check if the simulation is still running, query your cluster's queue (e.g. &amp;lt;code&amp;gt;squeue --me&amp;lt;/code&amp;gt; on SLURM clusters). If nothing is running, read the next question.&lt;br /&gt;
&lt;br /&gt;
* ''How to investigate a crash ?''&lt;br /&gt;
&lt;br /&gt;
The job error log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/out*&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The simulation log is in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/LMDZ_Setup/$SIM_NAME*/listing&amp;lt;/code&amp;gt;. (''Note: to know which folder is the latest, run &amp;lt;code&amp;gt;ls -lat&amp;lt;/code&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Cluster-specific information ==&lt;br /&gt;
&lt;br /&gt;
=== Generic ===&lt;br /&gt;
&lt;br /&gt;
==== ORCH 4 (trunk) ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4 is currently not able to compile with &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;, and as a result can't be used. This has been reported to the relevant team, and hopefully should be fixed soon (06/2024).&lt;br /&gt;
&lt;br /&gt;
==== CDO &amp;amp; aerosols ====&lt;br /&gt;
&lt;br /&gt;
The current version of &amp;lt;code&amp;gt;cdo&amp;lt;/code&amp;gt; on Adastra (&amp;lt;code&amp;gt;2.4.0&amp;lt;/code&amp;gt;) and Spirit (&amp;lt;code&amp;gt;2.3.0&amp;lt;/code&amp;gt;) contain [https://code.mpimet.mpg.de/boards/1/topics/15752 a bug] which interferes with the script interpolating aerosols. This bug is supposedly solved in version &amp;lt;code&amp;gt;2.4.1+&amp;lt;/code&amp;gt;. This bug corrupts the aerosols files, and results in a &amp;lt;code&amp;gt;hgardfou&amp;lt;/code&amp;gt; error when running the simulation.&lt;br /&gt;
&lt;br /&gt;
=== JeanZay ===&lt;br /&gt;
&lt;br /&gt;
JeanZay was the main supported cluster of the old &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. Although the new version can be ran there, it is discouraged.&lt;br /&gt;
&lt;br /&gt;
==== Slowness ====&lt;br /&gt;
&lt;br /&gt;
Compilation of the various components of the model, in particular of LMDZ and XIOS, is extremely slow on JeanZay compared to other clusters (for unknown reasons) (~15 minutes for LMDZ+rrtm). Moreover, it seems that for uninvestigated reasons, the LMDZ model is systematically recompiled on each call to &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; (expected behavior, as on other clusters: the &amp;lt;code&amp;gt;fcm&amp;lt;/code&amp;gt; system detects that it's already compiled and avoids compiling again). As a result, the whole process of '''launching a simulation is much slower'''.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=454</id>
		<title>LMDZ Setup</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=454"/>
				<updated>2024-07-09T07:26:04Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : (WIP) Add information regarding new LMDZ_Setup&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LMDZ_Setup is a set of scripts that allows a light automatic setup of LMDZ long chained climate simulations, including the installation of the model itself.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can only be used on the Jean-Zay computer at Idris so far.&lt;br /&gt;
&lt;br /&gt;
Coming VERY soon (summer 2024) : extension to other computing centers (&amp;quot;spirit&amp;quot;, adastra) and Linux PCs&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Documentation (in French):'''&lt;br /&gt;
[https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit LMDZ_Setup_HowTo]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''To extract LMDZ_Setup :'''&lt;br /&gt;
&lt;br /&gt;
a/ Recommended : extraction from svn repository : &lt;br /&gt;
&lt;br /&gt;
    svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&lt;br /&gt;
&lt;br /&gt;
b/ Download of the &amp;quot;tar&amp;quot; archive :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&lt;br /&gt;
 &lt;br /&gt;
c/ For those used with the old name &amp;quot;tutorial_prod.tar&amp;quot; : a link with this name still exists, pointing to LMDZ_Setup.tar :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''(Text extracted from LMDZ_Setup/README0_HowTo):''&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup consists in running '''LMDZ coupled to Orchidee''' for land surface (optional), but with '''imposed sea surface temperature'''.&lt;br /&gt;
&lt;br /&gt;
The '''basic default configuration''' makes use of the IPSL-CM6A grid configuration and tuning, and runs a multi annual simulation on &amp;quot;climatological&amp;quot;&lt;br /&gt;
amip sea surface temperature (with a mean annual cycle) using a calendar with 360 days.&lt;br /&gt;
&lt;br /&gt;
Optionally : the configuration includes the '''ability to use interannually varying SST''' and to activate '''&amp;quot;nudging&amp;quot;''' by a reanalysis.&lt;br /&gt;
In both cases, the calendar is then a real one.&lt;br /&gt;
When nudging is activated, the simulation must be run on a monthly basis, while otherwise, it can be either monthly or yearly.&lt;br /&gt;
&lt;br /&gt;
Since LMDZ_Setup automatically generates its own initial files, it can be run with '''zoom configurations''' by only changing the number of grid points (&amp;quot;resol&amp;quot; in main.sh) and the DEF/gcm.def file (see bellow).&lt;br /&gt;
&lt;br /&gt;
'''Aerosols''' can be read for the year 2000 (weighted average  over 1999-2001 cf Lurton et al 2020), and instantaneous forcing with respect to 1850 can be computed as well.&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can also run LMDZ coupled with the '''SPLA model''' (SimPLe Aerosol, activated with option aerosols=spla in setup.sh).&lt;br /&gt;
Emissions of dust and sea salt are then computed interactively.&lt;br /&gt;
For the time being, SPLA-specific input files (anthropic aerosol emissions)are only available on the grid zoomed over N Africa used by J. Escribano in his PhD thesis, and by B. Diallo and H. Senghor in subsequent work on N-African dust (file DEF/gcm.def_zNAfrica_BiJe).&lt;br /&gt;
&lt;br /&gt;
A configuration with '''isotopes''' is also available since 2023-04.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== WIP - Migration de LMDZ_Setup_HowTo + inclusion nouveau LMDZ_Setup ==&lt;br /&gt;
&lt;br /&gt;
''TODO Amaury: reprendre à &amp;quot;SSTs et SIC&amp;quot; + vérifier réponse Adriana pour xios+omp&amp;gt;2 + rajouter commentaire compilation dans jobs dans section &amp;quot;compilation&amp;quot;&lt;br /&gt;
&lt;br /&gt;
''Old documentation (French): [https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c LMDZ_Setup_HowTo]''&lt;br /&gt;
&lt;br /&gt;
== User guide ==&lt;br /&gt;
&lt;br /&gt;
 ''' /!\ WARNING''' 06/2024 - (ignore if installing a new version)&lt;br /&gt;
 The JeanZay calculator, as well as Adastra, do not allow (anymore) communication from/to $STORE for running jobs on the main computing partitions.&lt;br /&gt;
 As a result, make sure to replace $STORE by $WORK in &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt; wherever relevant.&lt;br /&gt;
&lt;br /&gt;
 '''READ comments at the top of scripts ! Often your questions are answered there.'''&lt;br /&gt;
&lt;br /&gt;
 ''Note'': &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; has been tested on Adastra and Spirit, and to a lesser extent on JeanZay (legacy support only). No guarantee is made on other platforms, although it should be easy to adapt it. It can also be ran locally - for expert use only.&lt;br /&gt;
&lt;br /&gt;
=== Downloading LMDZ_Setup ===&lt;br /&gt;
&lt;br /&gt;
* ''(recommended)'' Using ''subversion'': &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(alternative)'' &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(deprecated)'' The old &amp;lt;code&amp;gt;tutorial_prod&amp;lt;/code&amp;gt; version: &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Structure ===&lt;br /&gt;
&lt;br /&gt;
Once you have downloaded &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;, you will find the following main files:&lt;br /&gt;
* &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;: the main script. It contains the basic settings you will modify.&lt;br /&gt;
* &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;: this script contains the internal workings of &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. It's where you can edit expert-level settings.&lt;br /&gt;
* &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;: this file contains platform-specific configuration, such as where to install the model, where to run the simulations, etc.&lt;br /&gt;
&lt;br /&gt;
=== How to run a simulation ===&lt;br /&gt;
&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;set_env&amp;lt;/code&amp;gt;, find the case corresponding to your supercomputer: &amp;lt;code&amp;gt;jean-)&amp;lt;/code&amp;gt; for JeanZay, &amp;lt;code&amp;gt;spiri)&amp;lt;/code&amp;gt; for Spirit, &amp;lt;code&amp;gt;adast)&amp;lt;/code&amp;gt; for Adastra. Edit the variables required for your use case. All the variables are documented in the last &amp;lt;code&amp;gt;*)&amp;lt;/code&amp;gt; case. In particular:&lt;br /&gt;
#* you must set &amp;lt;code&amp;gt;root_dir&amp;lt;/code&amp;gt; to the path where you extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;.&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;define_expert_options&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;DEF/*&amp;lt;/code&amp;gt;.''' Edit the &amp;lt;code&amp;gt;DEF/*.def&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt; files, such as &amp;lt;code&amp;gt;config.def&amp;lt;/code&amp;gt;, to your liking. ''The options you specify in main.sh/setup.sh don't require any adjustment here; such adjustments are automatically performed at runtime.''&lt;br /&gt;
# '''Launch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;'''.&lt;br /&gt;
&lt;br /&gt;
=== Miscellanous notes ===&lt;br /&gt;
&lt;br /&gt;
* Simulations run in a subdirectory of &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; with the same name as the &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder (if you have extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; and renamed it to &amp;lt;code&amp;gt;My_Setup&amp;lt;/code&amp;gt; then simulations will run in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/My_Setup&amp;lt;/code&amp;gt;). Each simulation is contained in its own folder, named after the simulation's name + a process number. As a result, '''you don't need to clean $SIMRUNBASEDIR before relaunching a simulation'''.&lt;br /&gt;
* If your simulation crashes, look directly in &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; for the relevant log.&lt;br /&gt;
* If you need a version of ORCHIDEE different from the one provided by default in the model (such as &amp;lt;code&amp;gt;CMIP6&amp;lt;/code&amp;gt;), a password is required - ask ''orchidee-help at listes.ipsl.fr'' if you need help.&lt;br /&gt;
&lt;br /&gt;
==== XIOS ====&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' Although XIOS is not ''required'' for ORCHIDEE &amp;gt;=2.2, not using it will disable some features.&lt;br /&gt;
Different sets of &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt; files are available in &amp;lt;code&amp;gt;LMDZ_Setup/DEF/XMLFiles*&amp;lt;/code&amp;gt;. However, only some common files (&amp;lt;code&amp;gt;histf, histday, histmth&amp;lt;/code&amp;gt;) have been adapted for &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. ''If you need other outputs, '''be sure to edit/check the relevant &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt;''''':&lt;br /&gt;
* replace the &amp;lt;code&amp;gt;_AUTO_&amp;lt;/code&amp;gt; for &amp;lt;code&amp;gt;output_level&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;enabled&amp;lt;/code&amp;gt; by actual values;&lt;br /&gt;
* use &amp;lt;code&amp;gt;compression_level=0&amp;lt;/code&amp;gt; instead of the default values (&amp;lt;code&amp;gt;2&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;4&amp;lt;/code&amp;gt;) (since &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; uses XIOS in attached mode rather than client-server mode, using non-zero compression levels would require running XIOS on 1+ dedicated MPI).&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' After installing the model, two files are automatically initialized in &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;context_lmdz.xml&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;field_def_lmdz.xml&amp;lt;/code&amp;gt;. Those files don't require user intervention, and must match the exact LMDZ revision used.&lt;br /&gt;
&lt;br /&gt;
==== Compilation ====&lt;br /&gt;
&lt;br /&gt;
When launching &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, before running the simulation, we first download and compile the required models. Although we call the compilation script every time, if the model has already been compiled before, the script should detect that and skip the actual compilation, and thus execute very quickly.&lt;br /&gt;
&lt;br /&gt;
''Note: on supported clusters, compilation is launched in jobs rather than on the login node. This speeds up the compilation.''&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' As written in the comments of &amp;lt;code&amp;gt;main.sh/setup.sh&amp;lt;/code&amp;gt;, '''if you change the &amp;lt;code&amp;gt;veget&amp;lt;/code&amp;gt; version or the &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt;, it is highly recommended to do so in a NEW clean &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder''' rather than recompiling in the same folder.&lt;br /&gt;
&lt;br /&gt;
=== Nudging ===&lt;br /&gt;
&lt;br /&gt;
Nudging is set via the &amp;lt;code&amp;gt;nudging&amp;lt;/code&amp;gt; variable in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. If activated, then after installing the model, &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; will prompt you to run &amp;lt;code&amp;gt;era2gcm_tuto.sh&amp;lt;/code&amp;gt;. This script fetches reanalysis data and puts it in a &amp;lt;code&amp;gt;GUIDE/&amp;lt;/code&amp;gt; folder.&lt;br /&gt;
Once this is done, simply set &amp;lt;code&amp;gt;init=0&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; and relaunch it.&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' On Adastra, the reanalysis files are not yet available.&lt;br /&gt;
&lt;br /&gt;
=== Aerosols ===&lt;br /&gt;
&lt;br /&gt;
 '''/!\ As written in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, it is highly recommended to install &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; in a new clean directory when changing aerosols options. Otherwise i.e. the &amp;lt;code&amp;gt;DEF/config.def&amp;lt;/code&amp;gt; may not get modified accordingly.'''&lt;br /&gt;
&lt;br /&gt;
When &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt; is set to anything other than &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, aerosols files will be downloaded in &amp;lt;code&amp;gt;LIMIT/&amp;lt;/code&amp;gt;, and will be interpolated to the horizontal grid resolution (vertical interpolation is performed at runtime by the GCM.)&lt;br /&gt;
&lt;br /&gt;
==== More detail ====&lt;br /&gt;
&lt;br /&gt;
The aerosols files used for the options &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt; are those used in CMIP6 with the LMDZORINCA configuration, from [https://www.lmd.jussieu.fr/~lmdz/pub/3DInputData/AerChem/ here].&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;n&amp;quot;&amp;lt;/code&amp;gt;, we only use &amp;lt;code&amp;gt;aerosols1850_from_inca.nc&amp;lt;/code&amp;gt; (natural aerosols), interpolated as &amp;lt;code&amp;gt;aerosols.nat.nc&amp;lt;/code&amp;gt;&lt;br /&gt;
* For &amp;lt;code&amp;gt;&amp;quot;clim&amp;quot;&amp;lt;/code&amp;gt;, we also use &amp;lt;code&amp;gt;aerosols9999_from_inca.nc&amp;lt;/code&amp;gt; with the mean aerosols on 1995-2014, interpolated as &amp;lt;code&amp;gt;aerosols.clim.nc&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== ORCHIDEE ===&lt;br /&gt;
&lt;br /&gt;
The officially supported versions of ORCHIDEE supported by LMDZ_Setup are:&lt;br /&gt;
* the CMIP6 version (still using the two-layer hydrology channel)&lt;br /&gt;
* version 2.2 r7983&lt;br /&gt;
* version 4 (trunk) r7994 (corresponding to libIGCM's LMDZOR_6.4work configuration)&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' The relevant ORCHIDEE def file &amp;lt;code&amp;gt;DEF/orchidee.def_*&amp;lt;/code&amp;gt; gets copied as &amp;lt;code&amp;gt;DEF/orchidee.def&amp;lt;/code&amp;gt; at initialisation.&lt;br /&gt;
&lt;br /&gt;
==== Activating sechiba outputs ====&lt;br /&gt;
&lt;br /&gt;
Sechiba outputs are written to &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt;, but are deleted by &amp;lt;code&amp;gt;tmp_SIM&amp;lt;/code&amp;gt; before they're rebuilt. To counter that, remove the &amp;lt;code&amp;gt;sec*&amp;lt;/code&amp;gt; on the relevant line &amp;lt;code&amp;gt;set +e ; \rm out* sec* sta* list* rest* gcm.e aer* ; set -e&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Simple routing ====&lt;br /&gt;
&lt;br /&gt;
From orch 2.2 r7597 onwards, the &amp;quot;simple&amp;quot; routing scheme by Y. Meurdesoif can be activated.&lt;br /&gt;
&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/orchidee.def_6.*&amp;lt;/code&amp;gt;, set &amp;lt;code&amp;gt;RIVER_ROUTING=y&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;ROUTING_METHOD = simple&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;RIVER_DESC=y&amp;lt;/code&amp;gt; (''Note: &amp;lt;code&amp;gt;RIVER_DESC&amp;lt;/code&amp;gt; is automatically set to &amp;quot;n&amp;quot; after the first simulation period.)&lt;br /&gt;
* In &amp;lt;code&amp;gt;DEF/XMLfilesOR7***/iodef.xml&amp;lt;/code&amp;gt;, add at the end of &amp;lt;code&amp;gt;context_orchidee.xml&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;&amp;lt;context id=&amp;quot;orchidee&amp;quot; src=&amp;quot;./context_routing_orchidee.xml&amp;quot;/&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
See also:[https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/UserGuide/RoutageSimple User Guide/Routage Simple] (French).&lt;br /&gt;
&lt;br /&gt;
=== Isotopes ===&lt;br /&gt;
&lt;br /&gt;
To activate isotopes, simply change the &amp;lt;code&amp;gt;lmd_phys&amp;lt;/code&amp;gt; parameter to &amp;lt;code&amp;gt;&amp;quot;lmdiso&amp;quot;&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;. This will automatically&lt;br /&gt;
* use &amp;lt;code&amp;gt;&amp;quot;phylmdiso&amp;quot;&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;&amp;quot;phylmd&amp;quot;&amp;lt;/code&amp;gt;;&lt;br /&gt;
* copy &amp;lt;code&amp;gt;DEF/PHYS/physiq.def_NPiso&amp;lt;/code&amp;gt; to &amp;lt;code&amp;gt;DEF/physiq.def&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''Note: for isotopes, &amp;lt;code&amp;gt;iflag_ice_thermo&amp;lt;/code&amp;gt; is automatically set to &amp;lt;code&amp;gt;0&amp;lt;/code&amp;gt; instead of &amp;lt;code&amp;gt;1&amp;lt;/code&amp;gt;.''&lt;br /&gt;
&lt;br /&gt;
== Cluster-specific information ==&lt;br /&gt;
&lt;br /&gt;
=== Generic ===&lt;br /&gt;
&lt;br /&gt;
==== ORCH 4 (trunk) ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4 is currently not able to compile with &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;, and as a result can't be used. This has been reported to the relevant team, and hopefully should be fixed soon (06/2024).&lt;br /&gt;
&lt;br /&gt;
==== CDO &amp;amp; aerosols ====&lt;br /&gt;
&lt;br /&gt;
The current version of &amp;lt;code&amp;gt;cdo&amp;lt;/code&amp;gt; on Adastra (&amp;lt;code&amp;gt;2.4.0&amp;lt;/code&amp;gt;) and Spirit (&amp;lt;code&amp;gt;2.3.0&amp;lt;/code&amp;gt;) contain [https://code.mpimet.mpg.de/boards/1/topics/15752 a bug] which interferes with the script interpolating aerosols. This bug is supposedly solved in version &amp;lt;code&amp;gt;2.4.1+&amp;lt;/code&amp;gt;. This bug corrupts the aerosols files, and results in a &amp;lt;code&amp;gt;hgardfou&amp;lt;/code&amp;gt; error when running the simulation.&lt;br /&gt;
&lt;br /&gt;
=== JeanZay ===&lt;br /&gt;
&lt;br /&gt;
JeanZay was the main supported cluster of the old &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. Although the new version can be ran there, it is discouraged.&lt;br /&gt;
&lt;br /&gt;
==== Slowness ====&lt;br /&gt;
&lt;br /&gt;
Compilation of the various components of the model, in particular of LMDZ and XIOS, is extremely slow on JeanZay compared to other clusters (for unknown reasons) (~15 minutes for LMDZ+rrtm). Moreover, it seems that for uninvestigated reasons, the LMDZ model is systematically recompiled on each call to &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; (expected behavior, as on other clusters: the &amp;lt;code&amp;gt;fcm&amp;lt;/code&amp;gt; system detects that it's already compiled and avoids compiling again). As a result, the whole process of '''launching a simulation is much slower'''.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=453</id>
		<title>LMDZ Setup</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=453"/>
				<updated>2024-07-08T14:52:07Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : add todo&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LMDZ_Setup is a set of scripts that allows a light automatic setup of LMDZ long chained climate simulations, including the installation of the model itself.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can only be used on the Jean-Zay computer at Idris so far.&lt;br /&gt;
&lt;br /&gt;
Coming VERY soon (summer 2024) : extension to other computing centers (&amp;quot;spirit&amp;quot;, adastra) and Linux PCs&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Documentation (in French):'''&lt;br /&gt;
[https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit LMDZ_Setup_HowTo]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''To extract LMDZ_Setup :'''&lt;br /&gt;
&lt;br /&gt;
a/ Recommended : extraction from svn repository : &lt;br /&gt;
&lt;br /&gt;
    svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&lt;br /&gt;
&lt;br /&gt;
b/ Download of the &amp;quot;tar&amp;quot; archive :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&lt;br /&gt;
 &lt;br /&gt;
c/ For those used with the old name &amp;quot;tutorial_prod.tar&amp;quot; : a link with this name still exists, pointing to LMDZ_Setup.tar :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''(Text extracted from LMDZ_Setup/README0_HowTo):''&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup consists in running '''LMDZ coupled to Orchidee''' for land surface (optional), but with '''imposed sea surface temperature'''.&lt;br /&gt;
&lt;br /&gt;
The '''basic default configuration''' makes use of the IPSL-CM6A grid configuration and tuning, and runs a multi annual simulation on &amp;quot;climatological&amp;quot;&lt;br /&gt;
amip sea surface temperature (with a mean annual cycle) using a calendar with 360 days.&lt;br /&gt;
&lt;br /&gt;
Optionally : the configuration includes the '''ability to use interannually varying SST''' and to activate '''&amp;quot;nudging&amp;quot;''' by a reanalysis.&lt;br /&gt;
In both cases, the calendar is then a real one.&lt;br /&gt;
When nudging is activated, the simulation must be run on a monthly basis, while otherwise, it can be either monthly or yearly.&lt;br /&gt;
&lt;br /&gt;
Since LMDZ_Setup automatically generates its own initial files, it can be run with '''zoom configurations''' by only changing the number of grid points (&amp;quot;resol&amp;quot; in main.sh) and the DEF/gcm.def file (see bellow).&lt;br /&gt;
&lt;br /&gt;
'''Aerosols''' can be read for the year 2000 (weighted average  over 1999-2001 cf Lurton et al 2020), and instantaneous forcing with respect to 1850 can be computed as well.&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can also run LMDZ coupled with the '''SPLA model''' (SimPLe Aerosol, activated with option aerosols=spla in setup.sh).&lt;br /&gt;
Emissions of dust and sea salt are then computed interactively.&lt;br /&gt;
For the time being, SPLA-specific input files (anthropic aerosol emissions)are only available on the grid zoomed over N Africa used by J. Escribano in his PhD thesis, and by B. Diallo and H. Senghor in subsequent work on N-African dust (file DEF/gcm.def_zNAfrica_BiJe).&lt;br /&gt;
&lt;br /&gt;
A configuration with '''isotopes''' is also available since 2023-04.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== WIP - Migration de LMDZ_Setup_HowTo + inclusion nouveau LMDZ_Setup ==&lt;br /&gt;
&lt;br /&gt;
''TODO Amaury: reprendre à &amp;quot;SSTs et SIC&amp;quot; + vérifier réponse Adriana pour xios+omp&amp;gt;2 + rajouter commentaire compilation dans jobs dans section &amp;quot;compilation&amp;quot;&lt;br /&gt;
&lt;br /&gt;
''Old documentation (French): [https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c LMDZ_Setup_HowTo]''&lt;br /&gt;
&lt;br /&gt;
== User guide ==&lt;br /&gt;
&lt;br /&gt;
 ''' /!\ WARNING''' 06/2024 - (ignore if installing a new version)&lt;br /&gt;
 The JeanZay calculator, as well as Adastra, do not allow (anymore) communication from/to $STORE for running jobs on the main computing partitions.&lt;br /&gt;
 As a result, make sure to replace $STORE by $WORK in &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt; wherever relevant.&lt;br /&gt;
&lt;br /&gt;
 '''READ comments at the top of scripts ! Often your questions are answered there.'''&lt;br /&gt;
&lt;br /&gt;
 ''Note'': &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; has been tested on Adastra and Spirit, and to a lesser extent on JeanZay (legacy support only). No guarantee is made on other platforms, although it should be easy to adapt it. It can also be ran locally - for expert use only.&lt;br /&gt;
&lt;br /&gt;
=== Downloading LMDZ_Setup ===&lt;br /&gt;
&lt;br /&gt;
* ''(recommended)'' Using ''subversion'': &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(alternative)'' &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(deprecated)'' The old &amp;lt;code&amp;gt;tutorial_prod&amp;lt;/code&amp;gt; version: &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Structure ===&lt;br /&gt;
&lt;br /&gt;
Once you have downloaded &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;, you will find the following main files:&lt;br /&gt;
* &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;: the main script. It contains the basic settings you will modify.&lt;br /&gt;
* &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;: this script contains the internal workings of &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. It's where you can edit expert-level settings.&lt;br /&gt;
* &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;: this file contains platform-specific configuration, such as where to install the model, where to run the simulations, etc.&lt;br /&gt;
&lt;br /&gt;
=== How to run a simulation ===&lt;br /&gt;
&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;set_env&amp;lt;/code&amp;gt;, find the case corresponding to your supercomputer: &amp;lt;code&amp;gt;jean-)&amp;lt;/code&amp;gt; for JeanZay, &amp;lt;code&amp;gt;spiri)&amp;lt;/code&amp;gt; for Spirit, &amp;lt;code&amp;gt;adast)&amp;lt;/code&amp;gt; for Adastra. Edit the variables required for your use case. All the variables are documented in the last &amp;lt;code&amp;gt;*)&amp;lt;/code&amp;gt; case. In particular:&lt;br /&gt;
#* you must set &amp;lt;code&amp;gt;root_dir&amp;lt;/code&amp;gt; to the path where you extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;.&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;define_expert_options&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;DEF/*&amp;lt;/code&amp;gt;.''' Edit the &amp;lt;code&amp;gt;DEF/*.def&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt; files, such as &amp;lt;code&amp;gt;config.def&amp;lt;/code&amp;gt;, to your liking. ''The options you specify in main.sh/setup.sh don't require any adjustment here; such adjustments are automatically performed at runtime.''&lt;br /&gt;
# '''Launch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;'''.&lt;br /&gt;
&lt;br /&gt;
=== Miscellanous notes ===&lt;br /&gt;
&lt;br /&gt;
* Simulations run in a subdirectory of &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; with the same name as the &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder (if you have extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; and renamed it to &amp;lt;code&amp;gt;My_Setup&amp;lt;/code&amp;gt; then simulations will run in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/My_Setup&amp;lt;/code&amp;gt;). Each simulation is contained in its own folder, named after the simulation's name + a process number. As a result, '''you don't need to clean $SIMRUNBASEDIR before relaunching a simulation'''.&lt;br /&gt;
* If your simulation crashes, look directly in &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; for the relevant log.&lt;br /&gt;
* If you need a version of ORCHIDEE different from the one provided by default in the model (such as &amp;lt;code&amp;gt;CMIP6&amp;lt;/code&amp;gt;), a password is required - ask ''orchidee-help at listes.ipsl.fr'' if you need help.&lt;br /&gt;
&lt;br /&gt;
==== XIOS ====&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' Although XIOS is not ''required'' for ORCHIDEE &amp;gt;=2.2, not using it will disable some features.&lt;br /&gt;
Different sets of &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt; files are available in &amp;lt;code&amp;gt;LMDZ_Setup/DEF/XMLFiles*&amp;lt;/code&amp;gt;. However, only some common files (&amp;lt;code&amp;gt;histf, histday, histmth&amp;lt;/code&amp;gt;) have been adapted for &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. ''If you need other outputs, '''be sure to edit/check the relevant &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt;''''':&lt;br /&gt;
* replace the &amp;lt;code&amp;gt;_AUTO_&amp;lt;/code&amp;gt; for &amp;lt;code&amp;gt;output_level&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;enabled&amp;lt;/code&amp;gt; by actual values;&lt;br /&gt;
* use &amp;lt;code&amp;gt;compression_level=0&amp;lt;/code&amp;gt; instead of the default values (&amp;lt;code&amp;gt;2&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;4&amp;lt;/code&amp;gt;) (since &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; uses XIOS in attached mode rather than client-server mode, using non-zero compression levels would require running XIOS on 1+ dedicated MPI).&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' After installing the model, two files are automatically initialized in &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;context_lmdz.xml&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;field_def_lmdz.xml&amp;lt;/code&amp;gt;. Those files don't require user intervention, and must match the exact LMDZ revision used.&lt;br /&gt;
&lt;br /&gt;
==== Compilation ====&lt;br /&gt;
&lt;br /&gt;
When launching &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, before launching the simulation, we first download and compile the required models. Although we call the compilation script every time, if the model has already been compiled before, the script should detect that and skip the actual compilation, and thus execute very quickly.&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' As written in the comments of &amp;lt;code&amp;gt;main.sh/setup.sh&amp;lt;/code&amp;gt;, '''if you change the &amp;lt;code&amp;gt;veget&amp;lt;/code&amp;gt; version or the &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt;, it is highly recommended to do so in a NEW clean &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder''' rather than recompiling in the same folder.&lt;br /&gt;
&lt;br /&gt;
== Cluster-specific information ==&lt;br /&gt;
&lt;br /&gt;
=== Generic ===&lt;br /&gt;
&lt;br /&gt;
==== ORCH 4 (trunk) ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4 is currently not able to compile with &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;, and as a result can't be used. This has been reported to the relevant team, and hopefully should be fixed soon (06/2024).&lt;br /&gt;
&lt;br /&gt;
==== CDO &amp;amp; aerosols ====&lt;br /&gt;
&lt;br /&gt;
The current version of &amp;lt;code&amp;gt;cdo&amp;lt;/code&amp;gt; on Adastra (&amp;lt;code&amp;gt;2.4.0&amp;lt;/code&amp;gt;) and Spirit (&amp;lt;code&amp;gt;2.3.0&amp;lt;/code&amp;gt;) contain [https://code.mpimet.mpg.de/boards/1/topics/15752 a bug] which interferes with the script interpolating aerosols. This bug is supposedly solved in version &amp;lt;code&amp;gt;2.4.1+&amp;lt;/code&amp;gt;. This bug corrupts the aerosols files, and results in a &amp;lt;code&amp;gt;hgardfou&amp;lt;/code&amp;gt; error when running the simulation.&lt;br /&gt;
&lt;br /&gt;
=== JeanZay ===&lt;br /&gt;
&lt;br /&gt;
JeanZay was the main supported cluster of the old &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. Although the new version can be ran there, it is discouraged.&lt;br /&gt;
&lt;br /&gt;
==== Slowness ====&lt;br /&gt;
&lt;br /&gt;
Compilation of the various components of the model, in particular of LMDZ and XIOS, is extremely slow on JeanZay compared to other clusters (for unknown reasons) (~15 minutes for LMDZ+rrtm). Moreover, it seems that for uninvestigated reasons, the LMDZ model is systematically recompiled on each call to &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; (expected behavior, as on other clusters: the &amp;lt;code&amp;gt;fcm&amp;lt;/code&amp;gt; system detects that it's already compiled and avoids compiling again). As a result, the whole process of '''launching a simulation is much slower'''.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=452</id>
		<title>LMDZ Setup</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=452"/>
				<updated>2024-07-08T14:51:06Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : typo&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LMDZ_Setup is a set of scripts that allows a light automatic setup of LMDZ long chained climate simulations, including the installation of the model itself.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can only be used on the Jean-Zay computer at Idris so far.&lt;br /&gt;
&lt;br /&gt;
Coming VERY soon (summer 2024) : extension to other computing centers (&amp;quot;spirit&amp;quot;, adastra) and Linux PCs&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Documentation (in French):'''&lt;br /&gt;
[https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit LMDZ_Setup_HowTo]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''To extract LMDZ_Setup :'''&lt;br /&gt;
&lt;br /&gt;
a/ Recommended : extraction from svn repository : &lt;br /&gt;
&lt;br /&gt;
    svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&lt;br /&gt;
&lt;br /&gt;
b/ Download of the &amp;quot;tar&amp;quot; archive :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&lt;br /&gt;
 &lt;br /&gt;
c/ For those used with the old name &amp;quot;tutorial_prod.tar&amp;quot; : a link with this name still exists, pointing to LMDZ_Setup.tar :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''(Text extracted from LMDZ_Setup/README0_HowTo):''&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup consists in running '''LMDZ coupled to Orchidee''' for land surface (optional), but with '''imposed sea surface temperature'''.&lt;br /&gt;
&lt;br /&gt;
The '''basic default configuration''' makes use of the IPSL-CM6A grid configuration and tuning, and runs a multi annual simulation on &amp;quot;climatological&amp;quot;&lt;br /&gt;
amip sea surface temperature (with a mean annual cycle) using a calendar with 360 days.&lt;br /&gt;
&lt;br /&gt;
Optionally : the configuration includes the '''ability to use interannually varying SST''' and to activate '''&amp;quot;nudging&amp;quot;''' by a reanalysis.&lt;br /&gt;
In both cases, the calendar is then a real one.&lt;br /&gt;
When nudging is activated, the simulation must be run on a monthly basis, while otherwise, it can be either monthly or yearly.&lt;br /&gt;
&lt;br /&gt;
Since LMDZ_Setup automatically generates its own initial files, it can be run with '''zoom configurations''' by only changing the number of grid points (&amp;quot;resol&amp;quot; in main.sh) and the DEF/gcm.def file (see bellow).&lt;br /&gt;
&lt;br /&gt;
'''Aerosols''' can be read for the year 2000 (weighted average  over 1999-2001 cf Lurton et al 2020), and instantaneous forcing with respect to 1850 can be computed as well.&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can also run LMDZ coupled with the '''SPLA model''' (SimPLe Aerosol, activated with option aerosols=spla in setup.sh).&lt;br /&gt;
Emissions of dust and sea salt are then computed interactively.&lt;br /&gt;
For the time being, SPLA-specific input files (anthropic aerosol emissions)are only available on the grid zoomed over N Africa used by J. Escribano in his PhD thesis, and by B. Diallo and H. Senghor in subsequent work on N-African dust (file DEF/gcm.def_zNAfrica_BiJe).&lt;br /&gt;
&lt;br /&gt;
A configuration with '''isotopes''' is also available since 2023-04.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== WIP - Migration de LMDZ_Setup_HowTo + inclusion nouveau LMDZ_Setup ==&lt;br /&gt;
&lt;br /&gt;
''TODO Amaury: reprendre à &amp;quot;SSTs et SIC&amp;quot; + vérifier réponse Adriana pour xios+omp&amp;gt;2&lt;br /&gt;
&lt;br /&gt;
''Old documentation (French): [https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c LMDZ_Setup_HowTo]''&lt;br /&gt;
&lt;br /&gt;
== User guide ==&lt;br /&gt;
&lt;br /&gt;
 ''' /!\ WARNING''' 06/2024 - (ignore if installing a new version)&lt;br /&gt;
 The JeanZay calculator, as well as Adastra, do not allow (anymore) communication from/to $STORE for running jobs on the main computing partitions.&lt;br /&gt;
 As a result, make sure to replace $STORE by $WORK in &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt; wherever relevant.&lt;br /&gt;
&lt;br /&gt;
 '''READ comments at the top of scripts ! Often your questions are answered there.'''&lt;br /&gt;
&lt;br /&gt;
 ''Note'': &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; has been tested on Adastra and Spirit, and to a lesser extent on JeanZay (legacy support only). No guarantee is made on other platforms, although it should be easy to adapt it. It can also be ran locally - for expert use only.&lt;br /&gt;
&lt;br /&gt;
=== Downloading LMDZ_Setup ===&lt;br /&gt;
&lt;br /&gt;
* ''(recommended)'' Using ''subversion'': &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(alternative)'' &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(deprecated)'' The old &amp;lt;code&amp;gt;tutorial_prod&amp;lt;/code&amp;gt; version: &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Structure ===&lt;br /&gt;
&lt;br /&gt;
Once you have downloaded &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;, you will find the following main files:&lt;br /&gt;
* &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;: the main script. It contains the basic settings you will modify.&lt;br /&gt;
* &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;: this script contains the internal workings of &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. It's where you can edit expert-level settings.&lt;br /&gt;
* &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;: this file contains platform-specific configuration, such as where to install the model, where to run the simulations, etc.&lt;br /&gt;
&lt;br /&gt;
=== How to run a simulation ===&lt;br /&gt;
&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;set_env&amp;lt;/code&amp;gt;, find the case corresponding to your supercomputer: &amp;lt;code&amp;gt;jean-)&amp;lt;/code&amp;gt; for JeanZay, &amp;lt;code&amp;gt;spiri)&amp;lt;/code&amp;gt; for Spirit, &amp;lt;code&amp;gt;adast)&amp;lt;/code&amp;gt; for Adastra. Edit the variables required for your use case. All the variables are documented in the last &amp;lt;code&amp;gt;*)&amp;lt;/code&amp;gt; case. In particular:&lt;br /&gt;
#* you must set &amp;lt;code&amp;gt;root_dir&amp;lt;/code&amp;gt; to the path where you extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;.&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;define_expert_options&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;DEF/*&amp;lt;/code&amp;gt;.''' Edit the &amp;lt;code&amp;gt;DEF/*.def&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt; files, such as &amp;lt;code&amp;gt;config.def&amp;lt;/code&amp;gt;, to your liking. ''The options you specify in main.sh/setup.sh don't require any adjustment here; such adjustments are automatically performed at runtime.''&lt;br /&gt;
# '''Launch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;'''.&lt;br /&gt;
&lt;br /&gt;
=== Miscellanous notes ===&lt;br /&gt;
&lt;br /&gt;
* Simulations run in a subdirectory of &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; with the same name as the &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder (if you have extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; and renamed it to &amp;lt;code&amp;gt;My_Setup&amp;lt;/code&amp;gt; then simulations will run in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/My_Setup&amp;lt;/code&amp;gt;). Each simulation is contained in its own folder, named after the simulation's name + a process number. As a result, '''you don't need to clean $SIMRUNBASEDIR before relaunching a simulation'''.&lt;br /&gt;
* If your simulation crashes, look directly in &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; for the relevant log.&lt;br /&gt;
* If you need a version of ORCHIDEE different from the one provided by default in the model (such as &amp;lt;code&amp;gt;CMIP6&amp;lt;/code&amp;gt;), a password is required - ask ''orchidee-help at listes.ipsl.fr'' if you need help.&lt;br /&gt;
&lt;br /&gt;
==== XIOS ====&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' Although XIOS is not ''required'' for ORCHIDEE &amp;gt;=2.2, not using it will disable some features.&lt;br /&gt;
Different sets of &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt; files are available in &amp;lt;code&amp;gt;LMDZ_Setup/DEF/XMLFiles*&amp;lt;/code&amp;gt;. However, only some common files (&amp;lt;code&amp;gt;histf, histday, histmth&amp;lt;/code&amp;gt;) have been adapted for &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. ''If you need other outputs, '''be sure to edit/check the relevant &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt;''''':&lt;br /&gt;
* replace the &amp;lt;code&amp;gt;_AUTO_&amp;lt;/code&amp;gt; for &amp;lt;code&amp;gt;output_level&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;enabled&amp;lt;/code&amp;gt; by actual values;&lt;br /&gt;
* use &amp;lt;code&amp;gt;compression_level=0&amp;lt;/code&amp;gt; instead of the default values (&amp;lt;code&amp;gt;2&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;4&amp;lt;/code&amp;gt;) (since &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; uses XIOS in attached mode rather than client-server mode, using non-zero compression levels would require running XIOS on 1+ dedicated MPI).&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' After installing the model, two files are automatically initialized in &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;context_lmdz.xml&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;field_def_lmdz.xml&amp;lt;/code&amp;gt;. Those files don't require user intervention, and must match the exact LMDZ revision used.&lt;br /&gt;
&lt;br /&gt;
==== Compilation ====&lt;br /&gt;
&lt;br /&gt;
When launching &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, before launching the simulation, we first download and compile the required models. Although we call the compilation script every time, if the model has already been compiled before, the script should detect that and skip the actual compilation, and thus execute very quickly.&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' As written in the comments of &amp;lt;code&amp;gt;main.sh/setup.sh&amp;lt;/code&amp;gt;, '''if you change the &amp;lt;code&amp;gt;veget&amp;lt;/code&amp;gt; version or the &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt;, it is highly recommended to do so in a NEW clean &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder''' rather than recompiling in the same folder.&lt;br /&gt;
&lt;br /&gt;
== Cluster-specific information ==&lt;br /&gt;
&lt;br /&gt;
=== Generic ===&lt;br /&gt;
&lt;br /&gt;
==== ORCH 4 (trunk) ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4 is currently not able to compile with &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;, and as a result can't be used. This has been reported to the relevant team, and hopefully should be fixed soon (06/2024).&lt;br /&gt;
&lt;br /&gt;
==== CDO &amp;amp; aerosols ====&lt;br /&gt;
&lt;br /&gt;
The current version of &amp;lt;code&amp;gt;cdo&amp;lt;/code&amp;gt; on Adastra (&amp;lt;code&amp;gt;2.4.0&amp;lt;/code&amp;gt;) and Spirit (&amp;lt;code&amp;gt;2.3.0&amp;lt;/code&amp;gt;) contain [https://code.mpimet.mpg.de/boards/1/topics/15752 a bug] which interferes with the script interpolating aerosols. This bug is supposedly solved in version &amp;lt;code&amp;gt;2.4.1+&amp;lt;/code&amp;gt;. This bug corrupts the aerosols files, and results in a &amp;lt;code&amp;gt;hgardfou&amp;lt;/code&amp;gt; error when running the simulation.&lt;br /&gt;
&lt;br /&gt;
=== JeanZay ===&lt;br /&gt;
&lt;br /&gt;
JeanZay was the main supported cluster of the old &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. Although the new version can be ran there, it is discouraged.&lt;br /&gt;
&lt;br /&gt;
==== Slowness ====&lt;br /&gt;
&lt;br /&gt;
Compilation of the various components of the model, in particular of LMDZ and XIOS, is extremely slow on JeanZay compared to other clusters (for unknown reasons) (~15 minutes for LMDZ+rrtm). Moreover, it seems that for uninvestigated reasons, the LMDZ model is systematically recompiled on each call to &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; (expected behavior, as on other clusters: the &amp;lt;code&amp;gt;fcm&amp;lt;/code&amp;gt; system detects that it's already compiled and avoids compiling again). As a result, the whole process of '''launching a simulation is much slower'''.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=451</id>
		<title>LMDZ Setup</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=451"/>
				<updated>2024-07-08T14:48:13Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : (WIP) Add information regarding new LMDZ_Setup&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LMDZ_Setup is a set of scripts that allows a light automatic setup of LMDZ long chained climate simulations, including the installation of the model itself.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can only be used on the Jean-Zay computer at Idris so far.&lt;br /&gt;
&lt;br /&gt;
Coming VERY soon (summer 2024) : extension to other computing centers (&amp;quot;spirit&amp;quot;, adastra) and Linux PCs&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Documentation (in French):'''&lt;br /&gt;
[https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit LMDZ_Setup_HowTo]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''To extract LMDZ_Setup :'''&lt;br /&gt;
&lt;br /&gt;
a/ Recommended : extraction from svn repository : &lt;br /&gt;
&lt;br /&gt;
    svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&lt;br /&gt;
&lt;br /&gt;
b/ Download of the &amp;quot;tar&amp;quot; archive :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&lt;br /&gt;
 &lt;br /&gt;
c/ For those used with the old name &amp;quot;tutorial_prod.tar&amp;quot; : a link with this name still exists, pointing to LMDZ_Setup.tar :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''(Text extracted from LMDZ_Setup/README0_HowTo):''&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup consists in running '''LMDZ coupled to Orchidee''' for land surface (optional), but with '''imposed sea surface temperature'''.&lt;br /&gt;
&lt;br /&gt;
The '''basic default configuration''' makes use of the IPSL-CM6A grid configuration and tuning, and runs a multi annual simulation on &amp;quot;climatological&amp;quot;&lt;br /&gt;
amip sea surface temperature (with a mean annual cycle) using a calendar with 360 days.&lt;br /&gt;
&lt;br /&gt;
Optionally : the configuration includes the '''ability to use interannually varying SST''' and to activate '''&amp;quot;nudging&amp;quot;''' by a reanalysis.&lt;br /&gt;
In both cases, the calendar is then a real one.&lt;br /&gt;
When nudging is activated, the simulation must be run on a monthly basis, while otherwise, it can be either monthly or yearly.&lt;br /&gt;
&lt;br /&gt;
Since LMDZ_Setup automatically generates its own initial files, it can be run with '''zoom configurations''' by only changing the number of grid points (&amp;quot;resol&amp;quot; in main.sh) and the DEF/gcm.def file (see bellow).&lt;br /&gt;
&lt;br /&gt;
'''Aerosols''' can be read for the year 2000 (weighted average  over 1999-2001 cf Lurton et al 2020), and instantaneous forcing with respect to 1850 can be computed as well.&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can also run LMDZ coupled with the '''SPLA model''' (SimPLe Aerosol, activated with option aerosols=spla in setup.sh).&lt;br /&gt;
Emissions of dust and sea salt are then computed interactively.&lt;br /&gt;
For the time being, SPLA-specific input files (anthropic aerosol emissions)are only available on the grid zoomed over N Africa used by J. Escribano in his PhD thesis, and by B. Diallo and H. Senghor in subsequent work on N-African dust (file DEF/gcm.def_zNAfrica_BiJe).&lt;br /&gt;
&lt;br /&gt;
A configuration with '''isotopes''' is also available since 2023-04.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== WIP - Migration de LMDZ_Setup_HowTo + inclusion nouveau LMDZ_Setup ==&lt;br /&gt;
&lt;br /&gt;
''TODO Amaury: reprendre à &amp;quot;SSTs et SIC&amp;quot; + vérifier réponse Adriana pour xios+omp&amp;gt;2&lt;br /&gt;
&lt;br /&gt;
''Old documentation (French): [https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c LMDZ_Setup_HowTo]''&lt;br /&gt;
&lt;br /&gt;
== User guide ==&lt;br /&gt;
&lt;br /&gt;
 ''' /!\ WARNING''' 06/2024 - (ignore if installing a new version)&lt;br /&gt;
 The JeanZay calculator, as well as Adastra, do not allow (anymore) communication from/to $STORE for running jobs on the main computing partitions.&lt;br /&gt;
 As a result, make sure to replace $STORE by $WORK in &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt; wherever relevant.&lt;br /&gt;
&lt;br /&gt;
 '''READ comments at the top of scripts ! Often your questions are answered there.'''&lt;br /&gt;
&lt;br /&gt;
 ''Note'': &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; has been tested on Adastra and Spirit, and to a lesser extent on JeanZay (legacy support only). No guarantee is made on other platforms, although it should be easy to adapt it. It can also be ran locally - for expert use only.&lt;br /&gt;
&lt;br /&gt;
=== Downloading LMDZ_Setup ===&lt;br /&gt;
&lt;br /&gt;
* ''(recommended)'' Using ''subversion'': &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(alternative)'' &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(deprecated)'' The old &amp;lt;code&amp;gt;tutorial_prod&amp;lt;/code&amp;gt; version: &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Structure ===&lt;br /&gt;
&lt;br /&gt;
Once you have downloaded &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;, you will find the following main files:&lt;br /&gt;
* &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;: the main script. It contains the basic settings you will modify.&lt;br /&gt;
* &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;: this script contains the internal workings of &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. It's where you can edit expert-level settings.&lt;br /&gt;
* &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;: this file contains platform-specific configuration, such as where to install the model, where to run the simulations, etc.&lt;br /&gt;
&lt;br /&gt;
=== How to run a simulation ===&lt;br /&gt;
&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;set_env&amp;lt;/code&amp;gt;, find the case corresponding to your supercomputer: &amp;lt;code&amp;gt;jean-)&amp;lt;/code&amp;gt; for JeanZay, &amp;lt;code&amp;gt;spiri)&amp;lt;/code&amp;gt; for Spirit, &amp;lt;code&amp;gt;adast)&amp;lt;/code&amp;gt; for Adastra. Edit the variables required for your use case. All the variables are documented in the last &amp;lt;code&amp;gt;*)&amp;lt;/code&amp;gt; case. In particular:&lt;br /&gt;
#* you must set &amp;lt;code&amp;gt;root_dir&amp;lt;/code&amp;gt; to the path where you extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;.&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;define_expert_options&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;DEF/*&amp;lt;/code&amp;gt;.''' Edit the &amp;lt;code&amp;gt;DEF/*.def&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt; files, such as &amp;lt;code&amp;gt;config.def&amp;lt;/code&amp;gt;, to your liking. ''The options you specify in main.sh/setup.sh don't require any adjustment here; such adjustments are automatically performed at runtime.''&lt;br /&gt;
# '''Launch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;'''.&lt;br /&gt;
&lt;br /&gt;
=== Miscellanous notes ===&lt;br /&gt;
&lt;br /&gt;
* Simulations run in a subdirectory of &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; with the same name as the &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder (if you have extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; and renamed it to &amp;lt;code&amp;gt;My_Setup&amp;lt;/code&amp;gt; then simulations will run in &amp;lt;code&amp;gt;$SIMRUNBASEDIR/My_Setup&amp;lt;/code&amp;gt;). Each simulation is contained in its own folder, named after the simulation's name + a process number. As a result, '''you don't need to clean $SIMRUNBASEDIR before relaunching a simulation'''.&lt;br /&gt;
* If your simulation crashes, look directly in &amp;lt;code&amp;gt;$SIMRUNBASEDIR&amp;lt;/code&amp;gt; for the relevant log.&lt;br /&gt;
* If you need a version of ORCHIDEE different from the one provided by default in the model (such as &amp;lt;code&amp;gt;CMIP6&amp;lt;/code&amp;gt;), a password is required - ask ''orchidee-help at listes.ipsl.fr'' if you need help.&lt;br /&gt;
&lt;br /&gt;
==== XIOS ====&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' Although XIOS is not ''required'' for ORCHIDEE &amp;gt;=2.2, not using it will disable some features.&lt;br /&gt;
Different sets of &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt; files are available in &amp;lt;code&amp;gt;LMDZ_Setup/DEF/XMLFiles*&amp;lt;/code&amp;gt;. However, only some common files (&amp;lt;code&amp;gt;histf, histday, histmth&amp;lt;/code&amp;gt;) have been adapted for &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. ''If you need other outputs, '''be sure to edit/check the relevant &amp;lt;code&amp;gt;*.xml&amp;lt;/code&amp;gt;''''':&lt;br /&gt;
* replace the &amp;lt;code&amp;gt;_AUTO_&amp;lt;/code&amp;gt; for &amp;lt;code&amp;gt;output_level&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;enabled&amp;lt;/code&amp;gt; by actual values;&lt;br /&gt;
* use &amp;lt;code&amp;gt;compression_level=0&amp;lt;/code&amp;gt; instead of the default values (&amp;lt;code&amp;gt;2&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;4&amp;lt;/code&amp;gt;) (since &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; uses XIOS in attached mode rather than client-server mode, using non-zero compression levels would require running XIOS on 1+ dedicated MPI).&lt;br /&gt;
&lt;br /&gt;
 ''Note:'' After installing the model, two files are automatically initialized in &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt;: &amp;lt;code&amp;gt;context_lmdz.xml&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;field_def_lmdz.xml&amp;lt;/code&amp;gt;. Those files don't require user intervention, and must match the exact LMDZ revision used.&lt;br /&gt;
&lt;br /&gt;
==== Compilation ====&lt;br /&gt;
&lt;br /&gt;
When launching &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, before launching the simulation, we first download and compile the required models. Although we call the compilation script every time, if the model has already been compiled before, the script should detect that and skip the compilation, thus execute very quickly.&lt;br /&gt;
&lt;br /&gt;
 '''/!\''' As written in the comments of &amp;lt;code&amp;gt;main.sh/setup.sh&amp;lt;/code&amp;gt;, '''if you change the &amp;lt;code&amp;gt;veget&amp;lt;/code&amp;gt; version or the &amp;lt;code&amp;gt;aerosols&amp;lt;/code&amp;gt;, it is highly recommended to do so in a NEW clean &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; folder''' rather than recompiling in the same folder.&lt;br /&gt;
&lt;br /&gt;
== Cluster-specific information ==&lt;br /&gt;
&lt;br /&gt;
=== Generic ===&lt;br /&gt;
&lt;br /&gt;
==== ORCH 4 (trunk) ====&lt;br /&gt;
&lt;br /&gt;
ORCHIDEE 4 is currently not able to compile with &amp;lt;code&amp;gt;gfortran&amp;lt;/code&amp;gt;, and as a result can't be used. This has been reported to the relevant team, and hopefully should be fixed soon (06/2024).&lt;br /&gt;
&lt;br /&gt;
==== CDO &amp;amp; aerosols ====&lt;br /&gt;
&lt;br /&gt;
The current version of &amp;lt;code&amp;gt;cdo&amp;lt;/code&amp;gt; on Adastra (&amp;lt;code&amp;gt;2.4.0&amp;lt;/code&amp;gt;) and Spirit (&amp;lt;code&amp;gt;2.3.0&amp;lt;/code&amp;gt;) contain [https://code.mpimet.mpg.de/boards/1/topics/15752 a bug] which interferes with the script interpolating aerosols. This bug is supposedly solved in version &amp;lt;code&amp;gt;2.4.1+&amp;lt;/code&amp;gt;. This bug corrupts the aerosols files, and results in a &amp;lt;code&amp;gt;hgardfou&amp;lt;/code&amp;gt; error when running the simulation.&lt;br /&gt;
&lt;br /&gt;
=== JeanZay ===&lt;br /&gt;
&lt;br /&gt;
JeanZay was the main supported cluster of the old &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. Although the new version can be ran there, it is discouraged.&lt;br /&gt;
&lt;br /&gt;
==== Slowness ====&lt;br /&gt;
&lt;br /&gt;
Compilation of the various components of the model, in particular of LMDZ and XIOS, is extremely slow on JeanZay compared to other clusters (for unknown reasons) (~15 minutes for LMDZ+rrtm). Moreover, it seems that for uninvestigated reasons, the LMDZ model is systematically recompiled on each call to &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt; (expected behavior, as on other clusters: the &amp;lt;code&amp;gt;fcm&amp;lt;/code&amp;gt; system detects that it's already compiled and avoids compiling again). As a result, the whole process of '''launching a simulation is much slower'''.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	<entry>
		<id>http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=450</id>
		<title>LMDZ Setup</title>
		<link rel="alternate" type="text/html" href="http://lmdz-forge.lmd.jussieu.fr/mediawiki/LMDZPedia/index.php?title=LMDZ_Setup&amp;diff=450"/>
				<updated>2024-07-08T13:12:28Z</updated>
		
		<summary type="html">&lt;p&gt;Abarral : (WIP) Add information regarding new LMDZ_Setup&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LMDZ_Setup is a set of scripts that allows a light automatic setup of LMDZ long chained climate simulations, including the installation of the model itself.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can only be used on the Jean-Zay computer at Idris so far.&lt;br /&gt;
&lt;br /&gt;
Coming VERY soon (summer 2024) : extension to other computing centers (&amp;quot;spirit&amp;quot;, adastra) and Linux PCs&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Documentation (in French):'''&lt;br /&gt;
[https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit LMDZ_Setup_HowTo]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''To extract LMDZ_Setup :'''&lt;br /&gt;
&lt;br /&gt;
a/ Recommended : extraction from svn repository : &lt;br /&gt;
&lt;br /&gt;
    svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&lt;br /&gt;
&lt;br /&gt;
b/ Download of the &amp;quot;tar&amp;quot; archive :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&lt;br /&gt;
 &lt;br /&gt;
c/ For those used with the old name &amp;quot;tutorial_prod.tar&amp;quot; : a link with this name still exists, pointing to LMDZ_Setup.tar :&lt;br /&gt;
&lt;br /&gt;
    wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''(Text extracted from LMDZ_Setup/README0_HowTo):''&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup consists in running '''LMDZ coupled to Orchidee''' for land surface (optional), but with '''imposed sea surface temperature'''.&lt;br /&gt;
&lt;br /&gt;
The '''basic default configuration''' makes use of the IPSL-CM6A grid configuration and tuning, and runs a multi annual simulation on &amp;quot;climatological&amp;quot;&lt;br /&gt;
amip sea surface temperature (with a mean annual cycle) using a calendar with 360 days.&lt;br /&gt;
&lt;br /&gt;
Optionally : the configuration includes the '''ability to use interannually varying SST''' and to activate '''&amp;quot;nudging&amp;quot;''' by a reanalysis.&lt;br /&gt;
In both cases, the calendar is then a real one.&lt;br /&gt;
When nudging is activated, the simulation must be run on a monthly basis, while otherwise, it can be either monthly or yearly.&lt;br /&gt;
&lt;br /&gt;
Since LMDZ_Setup automatically generates its own initial files, it can be run with '''zoom configurations''' by only changing the number of grid points (&amp;quot;resol&amp;quot; in main.sh) and the DEF/gcm.def file (see bellow).&lt;br /&gt;
&lt;br /&gt;
'''Aerosols''' can be read for the year 2000 (weighted average  over 1999-2001 cf Lurton et al 2020), and instantaneous forcing with respect to 1850 can be computed as well.&lt;br /&gt;
&lt;br /&gt;
LMDZ_Setup can also run LMDZ coupled with the '''SPLA model''' (SimPLe Aerosol, activated with option aerosols=spla in setup.sh).&lt;br /&gt;
Emissions of dust and sea salt are then computed interactively.&lt;br /&gt;
For the time being, SPLA-specific input files (anthropic aerosol emissions)are only available on the grid zoomed over N Africa used by J. Escribano in his PhD thesis, and by B. Diallo and H. Senghor in subsequent work on N-African dust (file DEF/gcm.def_zNAfrica_BiJe).&lt;br /&gt;
&lt;br /&gt;
A configuration with '''isotopes''' is also available since 2023-04.&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== WIP - Migration de LMDZ_Setup_HowTo + inclusion nouveau LMDZ_Setup ==&lt;br /&gt;
&lt;br /&gt;
''Old documentation (French): [https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c LMDZ_Setup_HowTo]''&lt;br /&gt;
&lt;br /&gt;
=== Downloading LMDZ_Setup ===&lt;br /&gt;
&lt;br /&gt;
* ''(recommended)'' Using ''subversion'': &amp;lt;code&amp;gt;svn co https://svn.lmd.jussieu.fr/LMDZ/BOL/LMDZ_Setup&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(alternative)'' &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/LMDZ_Setup.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
* ''(deprecated)'' The old &amp;lt;code&amp;gt;tutorial_prod&amp;lt;/code&amp;gt; version: &amp;lt;code&amp;gt;wget https://lmdz.lmd.jussieu.fr/pub/Training/tutorial_prod.tar&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== User guide ===&lt;br /&gt;
&lt;br /&gt;
 ''' /!\ WARNING''' 06/2024&lt;br /&gt;
 The JeanZay calculator, as well as Adastra, do not allow (anymore) communication from/to $STORE for running jobs on the main computing partitions.&lt;br /&gt;
 As a result, make sure to replace $STORE by $WORK in &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt; wherever relevant.&lt;br /&gt;
&lt;br /&gt;
 '''READ comments at the top of scripts ! Often your questions are answered there.'''&lt;br /&gt;
&lt;br /&gt;
 ''Note'': &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt; has been tested on Adastra and Spirit, and to a lesser extent on JeanZay (legacy support only). No guarantee is made on other platforms, although it should be easy to adapt it. It can also be ran locally - for expert use only.&lt;br /&gt;
&lt;br /&gt;
==== Structure ====&lt;br /&gt;
&lt;br /&gt;
Once you have downloaded &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;, you will find the following main files:&lt;br /&gt;
* &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;: the main script. It contains the basic settings you will modify.&lt;br /&gt;
* &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;: this script contains the internal workings of &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;. It's where you can edit expert-level settings.&lt;br /&gt;
* &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;: this file contains platform-specific configuration, such as where to install the model, where to run the simulations, etc.&lt;br /&gt;
&lt;br /&gt;
==== How to run a simulation ====&lt;br /&gt;
&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;lmdz_env.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;set_env&amp;lt;/code&amp;gt;, find the case corresponding to your supercomputer: &amp;lt;code&amp;gt;jean-)&amp;lt;/code&amp;gt; for JeanZay, &amp;lt;code&amp;gt;spiri)&amp;lt;/code&amp;gt; for Spirit, &amp;lt;code&amp;gt;adast)&amp;lt;/code&amp;gt; for Adastra. Edit the variables required for your use case. All the variables are documented in the last &amp;lt;code&amp;gt;*)&amp;lt;/code&amp;gt; case. In particular:&lt;br /&gt;
#* you must set &amp;lt;code&amp;gt;root_dir&amp;lt;/code&amp;gt; to the path where you extracted &amp;lt;code&amp;gt;LMDZ_Setup&amp;lt;/code&amp;gt;.&lt;br /&gt;
# '''Edit &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;.''' In &amp;lt;code&amp;gt;setup.sh&amp;lt;/code&amp;gt;, in the function &amp;lt;code&amp;gt;define_expert_options&amp;lt;/code&amp;gt;, edit all relevant settings.&lt;br /&gt;
# '''''[optional]'' Edit &amp;lt;code&amp;gt;DEF/*&amp;lt;/code&amp;gt;.''' Edit the &amp;lt;code&amp;gt;DEF/*.def&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;DEF/XMLfiles*&amp;lt;/code&amp;gt; files, such as &amp;lt;code&amp;gt;config.def&amp;lt;/code&amp;gt;, to your liking. ''The options you specify in main.sh/setup.sh don't require any adjustment here; such adjustments are automatically performed at runtime.''&lt;br /&gt;
# '''Launch &amp;lt;code&amp;gt;main.sh&amp;lt;/code&amp;gt;'''.&lt;/div&gt;</summary>
		<author><name>Abarral</name></author>	</entry>

	</feed>