Planets - User contributions [en]

The rcm1d.def Input File

2026-06-12T14:16:02Z

Jbclement:

== The run.def input file and its format ==

=== some general comments and disambiguation to start with ===
This page specifically focuses on the old ''rcm1d.def'' file used by the 1D version of the Generic PCM. The new one is this one [[The_1D_run.def_Input_File|'''this one''']].
Please note that the file ''rcm1d.def'' is now only relevant for Venus and Titan, and even then, they are two very different files!

The rcm1d.def file is very similar to the [[The_run.def_Input_File|'''run.def''']] file (in fact, rcm1d.def is copied to run.def during execution of the 1D model), with the difference that the 3D options (linked to the dynamic core) are not used, and a whole bunch of new 1D-specific options (information contained in the start and startfi files) are now in the rcm1d.def file.

== Reference def files ==
Reference *.def files are provided in the LMDZ.GENERIC/deftank directory

== Outputted used_*def files ==
When the GCM run finishes, for each of the input def files *.def, an ASCII output file '''used_*.def''' is generated (in practice this would be '''used_rcm1d.def''' and '''used_callphys.def''' for the 1D simulations). These files contain, along the same format as the *.def input files, the "key = value" that were used, along with comments about whether "value" was read in the input def file or if the code default was used (i.e. the sought "keyword" was not present in the input def files).

== Example of ''rcm1d.def'' file ==

<pre>
#---------------------------------#
# Run parameters for the 1D model #
#---------------------------------#

## Planetary constants
## ~~~~~~~~~~~~~~~~~~~~~~~
## NB: those are mandatory
## ~~~~~~~~~~~~~~~~~~~~~~~
## LENGTH OF A DAY in s
daysec = 86400.
## GRAVITY in m s-2
g = 3.72
## Radius of the planet, in m
rad = 3390000
## LENGTH OF A YEAR in days
year_day = 3000
## MIN DIST STAR-PLANET in AU [periastron]
periastr = 1.0
## MAX DIST STAR-PLANET in AU [apoastron]
apoastr = 1.0
## DATE OF PERIASTRON in days
peri_day = 0.
## OBLIQUITY in deg
obliquit = 0.
## SURFACE PRESSURE in Pa
psurf = 100000.

## Time integration parameters
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Initial date (in solar days,=0 at Ls=0)
day0 = 0
# Initial local time (in hours, between 0 and 24)
time = 12
# Number of time steps per sol
day_step = 40
# Number of sols to run
ndt = 1000
# Number of steps between each writing in diagfi
diagfi_output_rate=12

## Vertical levels
## ~~~~~~~~~~~~~~~
# hybrid vertical coordinate ? (.true. for hybrid and .false. for sigma levels)
hybrid = .true.
# autocompute vertical discretisation? (useful for exoplanet runs)
autozlevs = .false.
# Ceiling pressure (Pa) ?
pceil = 0.00001

## Thermal properties
## ~~~~~~~~~~~~~~~~~~
# Simulate global averaged conditions ?
global1d = .true.
# Latitude (deg) [only used if global1d = F]
latitude = 0.0
# Solar Zenith angle (deg) [only used if global1d = T]
szangle = 60.
# Force specific heat capacity and molecular mass values
force_cpp = .false.
# Specific heat capacity in J K-1 kg-1 [only used if force_cpp = T]
cpp = 0.
# Molecular mass in g mol-1 [only used if force_cpp = T]
mugaz = 18.
# Albedo of bare ground
albedo = 0.1
# Emissivity of bare ground
emis = 1.0
# Soil thermal inertia (SI)
inertia = 1000.
# Initial CO2 ice on the surface (kg.m-2)
co2ice = 0.

## Wind profile
## ~~~~~~~~~~~~
## zonal eastward component of the geostrophic wind (m/s)
u = 10.
# meridional northward component of the geostrophic wind (m/s)
v = 0.

## Initial atmospheric temperature profile
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# Type of initial temperature profile
# ichoice=1 Constant Temperature: T=tref
# [Mars] ichoice=2 Savidjari profile (as Seiff but with dT/dz=cte)
# [Mars] ichoice=3 Lindner (polar profile)
# [Mars] ichoice=4 inversion
# [Mars] ichoice=5 Seiff (standard profile, based on Viking entry)
# ichoice=6 constant T + gaussian perturbation (levels)
# ichoice=7 constant T + gaussian perturbation (km)
# ichoice=8 Read in an ascii file "profile"
ichoice = 1
# Reference temperature tref (K)
tref = 300.
# Add a perturbation to profile if isin=1
isin = 0
# peak of gaussian perturbation (for ichoice=6 or 7)
pic = 26.522
# width of the gaussian perturbation (for ichoice=6 or 7)
largeur = 10
# height of the gaussian perturbation (for ichoice=6 or 7)
hauteur = 30.

</pre>

'''Notes''':
* Lines beginning with a hashtag are comments
* values associated to keywords may be logicals, integers, reals or even strings
* The parsing is case-sensitive : "thisparameter=" and "ThisParameter=" are identified as two distinct keywords
* The order in which the parameters are given in the file does not matter (except if a parameter is specified multiple times, clearly a bad idea, and then the last occurrence will prevail).
* Accessing a parameter and its value from ''rcm1d.def''/''run.def'' in the Fortran code is done using the '''getin_p''' routine, e.g.:
<syntaxhighlight lang="fortran">
call getin_p("keyword",val)
</syntaxhighlight>
will look for the line with "keyword = " in file ''run.def'' and extract trailing value which will be use to set the value of the '''val''' variable in the code.

[[Category:Inputs]]
[[Category:WhatIs]]

[[Category:Generic-LMDZ]]
[[Category:Generic-1D]]

The rcm1d.def Input File

2026-06-12T14:11:48Z

Jbclement: Undo revision 3277 by Jbclement (talk)

== The run.def input file and its format ==

=== some general comments and disambiguation to start with ===
This pages specifically focuses on the ''rcm1d.def'' file used by the 1D version of the Generic PCM.

The rcm1d.def file is very similar to the [[The_run.def_Input_File|'''run.def''']] file (in fact, rcm1d.def is copied to run.def during execution of the 1D model), with the difference that the 3D options (linked to the dynamic core) are not used, and a whole bunch of new 1D-specific options (information contained in the start and startfi files) are now in the rcm1d.def file.

== Reference def files ==
Reference *.def files are provided in the LMDZ.GENERIC/deftank directory

== Outputted used_*def files ==
When the GCM run finishes, for each of the input def files *.def, an ASCII output file '''used_*.def''' is generated (in practice this would be '''used_rcm1d.def''' and '''used_callphys.def''' for the 1D simulations). These files contain, along the same format as the *.def input files, the "key = value" that were used, along with comments about whether "value" was read in the input def file or if the code default was used (i.e. the sought "keyword" was not present in the input def files).

== Example of ''rcm1d.def'' file ==

<pre>
#---------------------------------#
# Run parameters for the 1D model #
#---------------------------------#

## Planetary constants
## ~~~~~~~~~~~~~~~~~~~~~~~
## NB: those are mandatory
## ~~~~~~~~~~~~~~~~~~~~~~~
## LENGTH OF A DAY in s
daysec = 86400.
## GRAVITY in m s-2
g = 3.72
## Radius of the planet, in m
rad = 3390000
## LENGTH OF A YEAR in days
year_day = 3000
## MIN DIST STAR-PLANET in AU [periastron]
periastr = 1.0
## MAX DIST STAR-PLANET in AU [apoastron]
apoastr = 1.0
## DATE OF PERIASTRON in days
peri_day = 0.
## OBLIQUITY in deg
obliquit = 0.
## SURFACE PRESSURE in Pa
psurf = 100000.

## Time integration parameters
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Initial date (in solar days,=0 at Ls=0)
day0 = 0
# Initial local time (in hours, between 0 and 24)
time = 12
# Number of time steps per sol
day_step = 40
# Number of sols to run
ndt = 1000
# Number of steps between each writing in diagfi
diagfi_output_rate=12

## Vertical levels
## ~~~~~~~~~~~~~~~
# hybrid vertical coordinate ? (.true. for hybrid and .false. for sigma levels)
hybrid = .true.
# autocompute vertical discretisation? (useful for exoplanet runs)
autozlevs = .false.
# Ceiling pressure (Pa) ?
pceil = 0.00001

## Thermal properties
## ~~~~~~~~~~~~~~~~~~
# Simulate global averaged conditions ?
global1d = .true.
# Latitude (deg) [only used if global1d = F]
latitude = 0.0
# Solar Zenith angle (deg) [only used if global1d = T]
szangle = 60.
# Force specific heat capacity and molecular mass values
force_cpp = .false.
# Specific heat capacity in J K-1 kg-1 [only used if force_cpp = T]
cpp = 0.
# Molecular mass in g mol-1 [only used if force_cpp = T]
mugaz = 18.
# Albedo of bare ground
albedo = 0.1
# Emissivity of bare ground
emis = 1.0
# Soil thermal inertia (SI)
inertia = 1000.
# Initial CO2 ice on the surface (kg.m-2)
co2ice = 0.

## Wind profile
## ~~~~~~~~~~~~
## zonal eastward component of the geostrophic wind (m/s)
u = 10.
# meridional northward component of the geostrophic wind (m/s)
v = 0.

## Initial atmospheric temperature profile
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# Type of initial temperature profile
# ichoice=1 Constant Temperature: T=tref
# [Mars] ichoice=2 Savidjari profile (as Seiff but with dT/dz=cte)
# [Mars] ichoice=3 Lindner (polar profile)
# [Mars] ichoice=4 inversion
# [Mars] ichoice=5 Seiff (standard profile, based on Viking entry)
# ichoice=6 constant T + gaussian perturbation (levels)
# ichoice=7 constant T + gaussian perturbation (km)
# ichoice=8 Read in an ascii file "profile"
ichoice = 1
# Reference temperature tref (K)
tref = 300.
# Add a perturbation to profile if isin=1
isin = 0
# peak of gaussian perturbation (for ichoice=6 or 7)
pic = 26.522
# width of the gaussian perturbation (for ichoice=6 or 7)
largeur = 10
# height of the gaussian perturbation (for ichoice=6 or 7)
hauteur = 30.

</pre>

'''Notes''':
* Lines beginning with a hashtag are comments
* values associated to keywords may be logicals, integers, reals or even strings
* The parsing is case-sensitive : "thisparameter=" and "ThisParameter=" are identified as two distinct keywords
* The order in which the parameters are given in the file does not matter (except if a parameter is specified multiple times, clearly a bad idea, and then the last occurrence will prevail).
* Accessing a parameter and its value from ''rcm1d.def''/''run.def'' in the Fortran code is done using the '''getin_p''' routine, e.g.:
<syntaxhighlight lang="fortran">
call getin_p("keyword",val)
</syntaxhighlight>
will look for the line with "keyword = " in file ''run.def'' and extract trailing value which will be use to set the value of the '''val''' variable in the code.

[[Category:Inputs]]
[[Category:WhatIs]]

[[Category:Generic-LMDZ]]
[[Category:Generic-1D]]

The rcm1d.def Input File

2026-06-12T14:11:32Z

Jbclement: Undo revision 3278 by Jbclement (talk)

== The run.def input file and its format ==

=== some general comments and disambiguation to start with ===
This pages specifically focuses on the ''run.def'' file used by the 1D version of the Generic PCM.

The run.def file is very similar to the [[The_run.def_Input_File|'''run.def''']] file, with the difference that the 3D options (linked to the dynamic core) are not used, and a whole bunch of new 1D-specific options (information contained in the start and startfi files) are now in the 1D run.def file. Especially, the 1D file has to hold the <code>run_1d=.true.</code> key.

== Reference def files ==
Reference *.def files are provided in the LMDZ.GENERIC/deftank directory

== Outputted used_*def files ==
When the GCM run finishes, for each of the input def files *.def, an ASCII output file '''used_*.def''' is generated (in practice this would be '''used_run.def''' and '''used_callphys.def''' for the 1D simulations). These files contain, along the same format as the *.def input files, the "key = value" that were used, along with comments about whether "value" was read in the input def file or if the code default was used (i.e. the sought "keyword" was not present in the input def files).

== Example of 1D ''run.def'' file ==

<pre>
#---------------------------------#
# Run parameters for the 1D model #
#---------------------------------#

run_1d=.true.

## Planetary constants
## ~~~~~~~~~~~~~~~~~~~~~~~
## NB: those are mandatory
## ~~~~~~~~~~~~~~~~~~~~~~~
## LENGTH OF A DAY in s
daysec = 86400.
## GRAVITY in m s-2
g = 3.72
## Radius of the planet, in m
rad = 3390000
## LENGTH OF A YEAR in days
year_day = 3000
## MIN DIST STAR-PLANET in AU [periastron]
periastr = 1.0
## MAX DIST STAR-PLANET in AU [apoastron]
apoastr = 1.0
## DATE OF PERIASTRON in days
peri_day = 0.
## OBLIQUITY in deg
obliquit = 0.
## SURFACE PRESSURE in Pa
psurf = 100000.

## Time integration parameters
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Initial date (in solar days,=0 at Ls=0)
day0 = 0
# Initial local time (in hours, between 0 and 24)
time = 12
# Number of time steps per sol
day_step = 40
# Number of sols to run
ndt = 1000
# Number of steps between each writing in diagfi
diagfi_output_rate=12

## Vertical levels
## ~~~~~~~~~~~~~~~
# hybrid vertical coordinate ? (.true. for hybrid and .false. for sigma levels)
hybrid = .true.
# autocompute vertical discretisation? (useful for exoplanet runs)
autozlevs = .false.
# Ceiling pressure (Pa) ?
pceil = 0.00001

## Thermal properties
## ~~~~~~~~~~~~~~~~~~
# Simulate global averaged conditions ?
global1d = .true.
# Latitude (deg) [only used if global1d = F]
latitude = 0.0
# Solar Zenith angle (deg) [only used if global1d = T]
szangle = 60.
# Force specific heat capacity and molecular mass values
force_cpp = .false.
# Specific heat capacity in J K-1 kg-1 [only used if force_cpp = T]
cpp = 0.
# Molecular mass in g mol-1 [only used if force_cpp = T]
mugaz = 18.
# Albedo of bare ground
albedo = 0.1
# Emissivity of bare ground
emis = 1.0
# Soil thermal inertia (SI)
inertia = 1000.
# Initial CO2 ice on the surface (kg.m-2)
co2ice = 0.

## Wind profile
## ~~~~~~~~~~~~
## zonal eastward component of the geostrophic wind (m/s)
u = 10.
# meridional northward component of the geostrophic wind (m/s)
v = 0.

## Initial atmospheric temperature profile
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# Type of initial temperature profile
# ichoice=1 Constant Temperature: T=tref
# [Mars] ichoice=2 Savidjari profile (as Seiff but with dT/dz=cte)
# [Mars] ichoice=3 Lindner (polar profile)
# [Mars] ichoice=4 inversion
# [Mars] ichoice=5 Seiff (standard profile, based on Viking entry)
# ichoice=6 constant T + gaussian perturbation (levels)
# ichoice=7 constant T + gaussian perturbation (km)
# ichoice=8 Read in an ascii file "profile"
ichoice = 1
# Reference temperature tref (K)
tref = 300.
# Add a perturbation to profile if isin=1
isin = 0
# peak of gaussian perturbation (for ichoice=6 or 7)
pic = 26.522
# width of the gaussian perturbation (for ichoice=6 or 7)
largeur = 10
# height of the gaussian perturbation (for ichoice=6 or 7)
hauteur = 30.

</pre>

'''Notes''':
* Lines beginning with a hashtag are comments
* values associated to keywords may be logicals, integers, reals or even strings
* The parsing is case-sensitive : "thisparameter=" and "ThisParameter=" are identified as two distinct keywords
* The order in which the parameters are given in the file does not matter (except if a parameter is specified multiple times, clearly a bad idea, and then the last occurrence will prevail).
* Accessing a parameter and its value from ''run.def'' in the Fortran code is done using the '''getin_p''' routine, e.g.:
<syntaxhighlight lang="fortran">
call getin_p("keyword",val)
</syntaxhighlight>
will look for the line with "keyword = " in file ''run.def'' and extract trailing value which will be use to set the value of the '''val''' variable in the code.

[[Category:Inputs]]
[[Category:WhatIs]]

[[Category:Generic-LMDZ]]
[[Category:Generic-1D]]

Other GCM Configurations worth knowing about

2026-06-12T14:07:26Z

Jbclement:

= 3D lon-lat LMDZ setup =

== early Mars ==

It is already described in the [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Quick_Install_and_Run ''Quick Install and Run''] section.

== Earth with slab ocean ==rcm1d

TBD by Siddharth, once all changes have been committed (also need a validation of the model on Earth to be sure)

== TRAPPIST-1e with photochemistry ==

A temperate rocky planet in synchronous rotation around a low mass star.

Here is an example to simulate the planet TRAPPIST-1e with an Earth atmosphere using the photochemical module of the GCM.

To install the model and run it, follow [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Quick_Install_and_Run ''Quick Install and Run''] but with the following changes:

=== GCM Input Datafiles and Datasets ===
Section [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php?title=Quick_Install_and_Run&action=edit&section=9 ''GCM Input Datafiles and Datasets''] download the TRAPPIST-1e files (instead of the early Mars files):
<syntaxhighlight lang="bash">
wget -nv --no-check-certificate https://web.lmd.jussieu.fr/~lmdz/planets/generic/reference_setups/bench_trappist1e_photochemistry_64x48x30_b38x36.tar.gz
</syntaxhighlight>

You can find the same type of file with the additional folder containing the chemical network file:
<syntaxhighlight lang="bash">
callphys.def gases.def startfi.nc traceur.def
datadir/ run.def start.nc z2sig.def
chemnetwork/
</syntaxhighlight>

=== Compiling the GCM ===
==== Prior to a first compilation: setting up the target architecture files ====
The chemical solver require the libraries BLAS and LAPACK which need to be specified in the '''arch*.fcm''' file:
<syntaxhighlight lang="bash">
%COMPILER gfortran
%LINK gfortran
%AR ar
%MAKE make
%FPP_FLAGS -P -traditional
%FPP_DEF NC_DOUBLE LAPACK BLAS SGEMV=DGEMV SGEMM=DGEMM
%BASE_FFLAGS -c -fdefault-real-8 -fdefault-double-8 -ffree-line-length-none -fno-align-commons
%PROD_FFLAGS -O3
%DEV_FFLAGS -O
%DEBUG_FFLAGS -ffpe-trap=invalid,zero,overflow -fbounds-check -g3 -O0 -fstack-protector-all -finit-real=snan -fbacktrace
%MPI_FFLAGS
%OMP_FFLAGS
%BASE_LD -llapack -lblas
%MPI_LD
%OMP_LD
</syntaxhighlight>

==== Specific to photochemistry: set hard coded reactions ====
In '''/LMDZ.GENERIC/libf/aeronogeneric/chimiedata_h.F90''' you can hard code reaction if needed, for instance because the reaction rate is very specific and out of the generic formula or your photochemical reaction does not use a regular cross section.

The TRAPPIST-1e test case use 3 hard coded reactions.

*Uncomment the following lines to fill reaction species indexes:
<syntaxhighlight lang="bash">
!===========================================================
! r001 : HNO3 + rain -> H2O
!===========================================================
nb_phot = nb_phot + 1
indice_phot(nb_phot) = z3spec(1.0, indexchim('hno3'), 1.0, indexchim('h2o_vap'), 0.0, 1)

!===========================================================
! e001 : CO + OH -> CO2 + H
!===========================================================
nb_reaction_4 = nb_reaction_4 + 1
indice_4(nb_reaction_4) = z4spec(1.0, indexchim('co'), 1.0, indexchim('oh'), 1.0, indexchim('co2'), 1.0, indexchim('h'))

!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
! photodissociation of NO : NO + hv -> N + O
!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
nb_phot = nb_phot + 1
indice_phot(nb_phot) = z3spec(1.0, indexchim('no'), 1.0, indexchim('n'), 1.0, indexchim('o'))
</syntaxhighlight>

*Uncomment the following lines to fill reaction rates:
<syntaxhighlight lang="bash">
!----------------------------------------------------------------------
! carbon reactions
!----------------------------------------------------------------------

!--- e001: oh + co -> co2 + h

nb_reaction_4 = nb_reaction_4 + 1

! joshi et al., 2006

do ilev = 1,nlayer
k1a0 = 1.34*2.5*dens(ilev) &
*1/(1/(3.62e-26*t(ilev)**(-2.739)*exp(-20./t(ilev))) &
+ 1/(6.48e-33*t(ilev)**(0.14)*exp(-57./t(ilev)))) ! typo in paper corrected
k1b0 = 1.17e-19*t(ilev)**(2.053)*exp(139./t(ilev)) &
+ 9.56e-12*t(ilev)**(-0.664)*exp(-167./t(ilev))
k1ainf = 1.52e-17*t(ilev)**(1.858)*exp(28.8/t(ilev)) &
+ 4.78e-8*t(ilev)**(-1.851)*exp(-318./t(ilev))
x = k1a0/(k1ainf - k1b0)
y = k1b0/(k1ainf - k1b0)
fc = 0.628*exp(-1223./t(ilev)) + (1. - 0.628)*exp(-39./t(ilev)) &
+ exp(-t(ilev)/255.)
fx = fc**(1./(1. + (alog(x))**2)) ! typo in paper corrected
k1a = k1a0*((1. + y)/(1. + x))*fx
k1b = k1b0*(1./(1.+x))*fx

v_4(ilev,nb_reaction_4) = k1a + k1b
end do

!----------------------------------------------------------------------
! washout r001 : HNO3 + rain -> H2O
!----------------------------------------------------------------------

nb_phot = nb_phot + 1

rain_h2o = 100.e-6
!rain_rate = 1.e-6 ! 10 days
rain_rate = 1.e-8

do ilev = 1,nlayer
if (c(ilev,indexchim('h2o_vap'))/dens(ilev) >= rain_h2o) then
v_phot(ilev,nb_phot) = rain_rate
else
v_phot(ilev,nb_phot) = 0.
end if
end do

!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
! photodissociation of NO
!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

nb_phot = nb_phot + 1

colo3(nlayer) = 0.
! ozone columns for other levels (molecule.cm-2)
do ilev = nlayer-1,1,-1
colo3(ilev) = colo3(ilev+1) + (c(ilev+1,indexchim('o3')) + c(ilev,indexchim('o3')))*0.5*avocado*1e-4*((press(ilev) - press(ilev+1))*100.)/(1.e-3*zmmean(ilev)*g*dens(ilev))
end do
call jno(nlayer, c(nlayer:1:-1,indexchim('no')), c(nlayer:1:-1,indexchim('o2')), colo3(nlayer:1:-1), dens(nlayer:1:-1), press(nlayer:1:-1), sza, v_phot(nlayer:1:-1,nb_phot))
</syntaxhighlight>

*Change the following lines to set the number of hard coded reactions:
<syntaxhighlight lang="bash">
integer, parameter :: nphot_hard_coding = 2
integer, parameter :: n4_hard_coding = 1
integer, parameter :: n3_hard_coding = 0
</syntaxhighlight>

=== Compiling a test case (TRAPPIST-1e) ===
Change the following compiling option:
<syntaxhighlight lang="bash">
-d 64x48x30 -b 38x36
</syntaxhighlight>

NB: option -b is mandatory to change while option -d will still run with lower or higher resolution (if '''z2sig.def''' remains coherent with the number of altitude levels, meaning at least as many altitude levels defined as the number of levels wanted).

== TRAPPIST-1c in Venus-like conditions ==

A warm rocky planet in synchronous rotation around a low mass star. Here we provide an '''example''' to simulate the atmosphere of Trappist-1c, assuming it evolved to a modern Venus-like atmosphere.

The planetary parameters are taken from [https://arxiv.org/abs/2010.01074 Algol et al. 2021] and can be found in this table [[Media:Planetary_parameters_Trappist1c.png]]

First, install the model and run it, following [[Quick Install and Run]] but instead of ''Early Mars files'', please download ''bench_trappist1c_64x48x50_b32x36'' using this command:

<syntaxhighlight lang="bash">
wget -nv --no-check-certificate https://web.lmd.jussieu.fr/~lmdz/planets/generic/reference_setups/bench_trappist1c_64x48x50_b32x36.tar.gz
</syntaxhighlight>

=== Compiling a test case (TRAPPIST-1c) ===
Change the following compiling option:
<syntaxhighlight lang="bash">
-d 64x48x50 -b 32x36
</syntaxhighlight>

You can find the same type of ASCII *def files than in the case of ''Early Mars'', but adapted to the planet's characteristics and orbital parameters of Trappist 1c.
In particular ''callphys.def'' contains the following changes:

* The planet is assumed to be in 1:1 spin-orbit resonance, therefore
diurnal = .false.
tlocked = .true.
* The planet equilibrium temperature is about 342 K
tplanet = 341.9
* The host star is TRAPPIST1, with a stellar flux at 1 AU of 0.7527 [W m-2]
stelspec_file = spectrum_TRAPPIST1_2022.dat
tstellar = 2600.
Fat1AU = 0.7527
* Fixed aerosol distribution, no radiative active tracers (no evaporation/condensation of H2O and CO2):
aerofixed = .true.
aeroco2 = .false.
aeroh2o = .false.
* No water cycle model, no water cloud formation or water precipitation, no CO2 condensation:
water = .false.
watercond = .false.
waterrain = .false.
hydrology = .false.
nonideal = .true.
co2cond = .false.
* Following [https://www.sciencedirect.com/science/article/pii/S0032063313002596?via%3Dihub Haus et al. 2015] a prescribed radiatively active cloud model is included.
It can be activated/deactivated with the flag ''aerovenus''.
aerovenus = .true.
* Mode 1, 2, 2p, 3 and the "unknown" UV absorber can be included/excluded by setting to true/false the following keywords. The characteristics of each mode (e.g. effect radius, effective variance) are based on Venus Express/ESA observations and can be found in this table [[Media:Table1 aerosolVenus trappist1c.png]]
aerovenus1 = .true.
aerovenus2 = .true.
aerovenus2p = .true.
aerovenus3 = .true.
aerovenusUV = .true.

The cloud model is prescribed from 1 to 0.037 ''bar'' pressure layers. For each mode, the top/bottom pressure can be modified by hard-coding model routine ''aerosol_opacity.F90''.
Here below an example for mode 1 particles, where the top pressure layer and bottom pressure layer are prescribed at 0.1 bar and 1 bar, respectively:

<syntaxhighlight lang="bash">

! 1. Initialization
aerosol(1:ngrid,1:nlayer,iaer)=0.0
p_bot = 1.e5 ! bottom pressure [Pa]
p_top = 1.e4
h_bot = 1.0e3 ! bottom scale height [m]
h_top = 5.0e3
</syntaxhighlight>

'''TO BE COMPLETED BY GABRIELLA'''

== mini-Neptune GJ1214b ==

A warm mini-Neptune

'''TO BE COMPLETED BY BENJAMIN'''

= 3D DYNAMICO setup =

Due to the rich dynamical activities in their atmospheres (banded zonal jets, eddies, vortices, storms, equatorial oscillations,...) resulting from multi-scale dynamic interactions, the Global Climate Modelling of the giant planet requires to resolve eddies arising from hydrodynamical instabilities to correctly establish the planetary-scaled jets regime. To this purpose, their Rossby radius deformation $$L_D$$, which is the length scale at which rotational effects become as important as buoyancy or gravity wave effects in the evolution of the flow about some disturbance, is calculated to determine the most suitable horizontal grid resolution. At mid-latitude range, for the giant planets, $$L_D$$ is of the same order of magnitude as that of the Earth. As the giant planets have a size of roughly 10 times the Earth size (i.e., Jupiter and Saturn), the modelling grid must be of a horizontal resolution of 0.5$$^{\circ}$$ over longitude and latitude (vs 5$$^{\circ}$$ for the Earth), considering 3 grid points to resolved $$L_D$$.
Moreover, to have a chance to model the equatorial oscillation, meridional cell circulations and/or a seasonal inter-hemispheric circulation, a giant planet GCM must also include a high vertical resolution. Indeed, these climate phenomena have been studied for decades for the Earth's atmosphere, and result from small- and large-scale interactions between the troposphere and stratosphere. This implies that the propagation of dynamic instabilities, waves and turbulence should be resolved as far as possible along the vertical. Contrary to horizontal resolution, it doesn't really exist a criterion (similar to $$L_D$$) to determine the most suitable vertical grid resolution and still an adjustable parameter according to the processes to be represented. However, we advise the user to set a vertical resolution of at least 5 grid points per scale height as first stage.
Finally, these atmospheres are cold, with long radiative response time which needs radiative transfer computations over decade-long years of Jupiter (given that a Jupiter year $$\approx$$ 12 Earth years), Saturn ( a Saturn year $$\approx$$ 30 Earth years), Uranus (a Uranus year $$\approx$$ 84 earth years) or Neptune (a Neptune year $$\approx$$ 169 Earth years), depending on the chosen planet.

To be able to deal with these three -- and non-exhaustive -- requirements to build a giant planet GCM, we need massive computational ressources. For this, we use a dynamical core suitable and numerically stable for massive parallel ressource computations: [[The_DYNAMICO_dynamical_core | DYNAMICO]] [Dubos et al,. 2015].

In these two following subsections, we purpose an example of installation for Jupiter and a Hot Jupiter. All the install, compiling, setting and parameters files for each giant planets could be found on: https://gitlab.in2p3.fr/aymeric.spiga/dynamico-giant (the old repo is archived as read-only https://github.com/aymeric-spiga/dynamico-giant)

The [[Dynamico-giant | DYNAMICO-giant wiki is here]]

If you have already downloaded '''LMDZ.COMMON''', '''LMDZ.GENERIC''', '''IOIPSL''', '''ARCH''', you only have to download:

'''ICOSAGCM''': the DYNAMICO dynamical core
<syntaxhighlight lang="bash">
git clone https://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico.git ICOSAGCM
cd ICOSAGCM
git checkout 110016896ae9e85e614af43223b18fe38f211020 # Version du 6 nov. 2024
</syntaxhighlight>

'''ICOSA_LMDZ''': the interface using to link LMDZ.GENERIC physical packages and ICOSAGCM
<syntaxhighlight lang="bash">
svn update -r 3729 -q ICOSA_LMDZ # Version du 18 avr. 2025
</syntaxhighlight>

'''XIOS (XML Input Output Server)''': the library to interpolate input/output fields between the icosahedral and longitude/latitude regular grids on fly
<syntaxhighlight lang="bash">
svn co -r 2626 -q http://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/trunk XIOS # Version du 22 mar. 2024
</syntaxhighlight>

If you haven't already download '''LMDZ.COMMON''', '''LMDZ.GENERIC''', '''IOIPSL''', '''ARCH''', you can use the '''install.sh''' script provided by the GitLab repository.

Once each part of the GCM is downloaded, you are able to compile it.
Firstly, you have to define your [[The_Target_Architecture_("arch")_Files | target architecture file ]] (hereafter named YOUR_ARCH_FILE) where you will fill in all the necessary information about the local environment, where libraries are located, which compiler, and compiler options will be used, etc.
Some architecture files related to specific machines are provided in the '''ARCH''' directory, which are referenced in the following lines without the prefix 'arch-' (i.e., arch-X64_IRENE-AMD.env will be referenced as X64_IRENE-AMD).

The main specificity of DYNAMICO-giant is that every main parts of the model ('''ICOSAGCM''', '''LMDZ.COMMON''' and '''LMDZ.GENERIC''') are compiled as libraries, and settings and running configuration are managed by the '''ICOSA_LMDZ''' interface.

First, you have to compile '''IOIPSL''',
<syntaxhighlight lang="bash">
cd LMDZ.COMMON/ioipsl/
./install_ioipsl_YOUR-MACHINE.bash
cd ../../
</syntaxhighlight>
then '''XIOS''' library,
<syntaxhighlight lang="bash">
cd XIOS/
./make_xios --prod --arch YOUR_ARCH_FILE --arch_path ../ARCH --job 8 --full
cd -
</syntaxhighlight>
the physics packaging,
<syntaxhighlight lang="bash">
cd LMDZ.COMMON/
./makelmdz_fcm -p generic -p_opt "-b 20x25" -prod -parallel mpi -libphy -io xios -arch YOUR_ARCH_FILE -arch_path ../ARCH -j 8 -full
cd -
</syntaxhighlight>
the dynamical core '''DYNAMICO''' (located in '''ICOSAGCM''' directory, named from the icosahedral shape of the horizontal mesh),
<syntaxhighlight lang="bash">
cd ICOSAGCM/
./make_icosa -prod -parallel mpi -external_ioipsl -with_xios -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -full
cd -
</syntaxhighlight>
and finally the '''ICOSA_LMDZ''' interface
<syntaxhighlight lang="bash">
cd ICOSA_LMDZ/
./make_icosa_lmdz -p generic -p_opt "-b 20x25" -parallel mpi -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -nodeps
</syntaxhighlight>
This last step is a bit redundant with the two previous one, hence ''make_icosa_lmdz'' will execute ''./make_icosa'' (in the '''ICOSAGCM''' directory) and ''./makelmdz_fcm'' (in the '''LMDZ.COMMON''' directory) to create and source the architecture files shared between all parts of the model, as well as create the intermediate file ''config.fcm''. As you have already compiled these two elements, ''make_icosa_lmdz'' should only create the linked architecture files, ''config.fcm'' and compile the interface. Here, ''-nodeps'' option prevents the checking of XIOS and IOIPSL compilation, which saves you from recompiling these two elements again.

Finally, your executable programs should appeared in '''ICOSA_LMDZ/bin''' subdirectory, as '''icosa_lmdz.exe''' and in '''XIOS/bin''' subdirectory, as '''xios_server.exe'''

All these compiling steps are summed up in ''make_isoca_lmdz'' program that should be adapted to your own computational settings (i.e., through you target architecture file).
<syntaxhighlight lang="bash">
./make_icosa_lmdz -p generic -p_opt "-b 20x25" -parallel mpi -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -full
</syntaxhighlight>
Here, ''-full'' option assure the compilation of each part ('''IOIPSL''', '''XIOS''', '''LMDZ.COMMON''', '''ICOSAGCM''' and '''ICOSA_LMDZ''') of the model.

Now you can move your two executable files to your working directory and start to run your own simulation of Jupiter or a Hot Jupiter, as what follows.

Note: If you are using the GitLab file architecture (https://gitlab.in2p3.fr/aymeric.spiga/dynamico-giant), you should be able to compile the model directly from your working directory (for instance ''dynamico-giant/jupiter/'') by using the ''compile_occigen.sh'' program, which has to be adapted to your machine/cluster.

''Note 2 : Depending on the compiler module you use, especially with gfortran, you may need to modify the tracers_icosa.F90 file located in the src directory in order to successfully compile ICOSAGCM. For example, if you are using GCC/11.3.0 and OpenMPI/4.1.4, you must update the insert_tracer_output subroutine as follows:''
<syntaxhighlight lang="fortran">
SUBROUTINE insert_tracer_output
USE xios_mod
USE grid_param
IMPLICIT NONE
TYPE(xios_fieldgroup) :: fieldgroup_hdl
TYPE(xios_field) :: field_hdl
INTEGER :: iq
CHARACTER(len=1000) :: tracername1
CHARACTER(len=1000) :: tracername2
CHARACTER(len=1000) :: tracername3

CALL xios_get_handle("standard_output_tracers", fieldgroup_hdl)
DO iq = 1, nqtot
tracername1 = "tracer_"//TRIM(tracers(iq)%name)
CALL xios_add_child(fieldgroup_hdl, field_hdl, tracername1)
CALL xios_set_attr(field_hdl, name=TRIM(tracers(iq)%name))
END DO

CALL xios_get_handle("standard_output_tracers_init", fieldgroup_hdl)
DO iq = 1, nqtot
tracername2 = "tracer_"//TRIM(tracers(iq)%name)//"_init"
tracername3 = TRIM(tracers(iq)%name)//"_init"
CALL xios_add_child(fieldgroup_hdl, field_hdl, tracername2)
CALL xios_set_attr(field_hdl, name=tracername3)
END DO

END SUBROUTINE insert_tracer_output
</syntaxhighlight>

== Jupiter with DYNAMICO ==
Using a new dynamical core implies new setting files, in addition or as a replacement of those relevant to '''LMDZ.COMMON''' dynamical core using.

There are two kind of setting files:

'''A first group relevant to DYNAMICO:'''

- [[The ''context_dynamico.xml'' Input File|''context_dynamico.xml'']]: Configuration file for '''DYNAMICO''' for reading and writing files using '''XIOS''', mainly used when you want to check the installation of '''ICOSAGCM''' with [[The_DYNAMICO_dynamical_core | an ''Held and Suarez'' test case]]. When your installation, compilation and run environment is fully functional, the dynamic core output files will not (necessarily) be useful and you can disable their writing.

- [[The context_input_dynamico.xml Input File|''context_input_dynamico.xml'']]:

- [[The file_def_dynamico.xml Input File|''file_def_dynamico.xml'']]: Definition of output diagnostic files which will be written into the output files only related to '''ICOSAGCM'''.

- [[The field_def_dynamico.xml Input File|''field_def_dynamico.xml'']]: Definition of all existing variables that can be output from DYNAMICO.

- [[The tracer.def Input File|''tracer.def'']]: Definition of the name and physico-chemical properties of the tracers which will be advected by the dynamical core. For now, there is two files related to tracers, we are working to harmonise it.

''' A second group relevant to LMDZ.GENERIC physical packages: '''

- [[The context_lmdz_physics.xml Input File|''context_lmdz_physics.xml'']]: File in which are defined the horizontal grid, vertical coordinate, output file(s) definition, with the setting of frequency output writing, time unit, geophysical variables to be written, etc. Each new geophysical variables added here have to be defined in the ''field_def_physics.xml'' file.

- [[The field_def_physics.xml Input File|''field_def_physics.xml'']]: Definition of all existing variables that can be output from the physical packages interfaced with '''DYNAMICO'''. This is where you will add each geophysical fields that you want to appear in the ''Xhistins.nc'' output files. For instance, related to the ''thermal plume scheme'' using for Jupiter's tropospheric dynamics, we have added the following variables:
<syntaxhighlight lang="xml" line>
<field id="h2o_vap"
long_name="Vapor mass mixing ratio"
unit="kg/kg" />
<field id="h2o_ice"
long_name="Vapor mass mixing ratio"
unit="kg/kg" />
<field id="detr"
long_name="Detrainment"
unit="kg/m2/s" />
<field id="entr"
long_name="Entrainment"
unit="kg/m2/s" />
<field id="w_plm"
long_name="Plume vertical velocity"
unit="m/s" />
</syntaxhighlight>

- [[The_callphys.def_Input_File|''callphys.def'']]: This setting file is used either with '''DYNAMICO''' or '''LMDZ.COMMON''' and allows the user to choose the physical parametrisation schemes and their appropriate main parameter values relevant to the planet being simulated. In our case of Jupiter, there are some specific parametrisations that should be added or modified from the example given as link at the beginning of this line:
<syntaxhighlight lang="bash" line>
# Diurnal cycle ? if diurnal=false, diurnally averaged solar heating
diurnal = .false. #.true.
# Seasonal cycle ? if season=false, Ls stays constant, to value set in "start"
season = .true.
# Tidally resonant orbit ? must have diurnal=false, correct rotation rate in newstart
tlocked = .false.
# Tidal resonance ratio ? ratio T_orbit to T_rotation
nres = 1
# Planet with rings?
rings_shadow = .false.
# Compute latitude-dependent gravity field??
oblate = .true.
# Include non-zero flattening (a-b)/a?
flatten = 0.06487
# Needed if oblate=.true.: J2
J2 = 0.01470
# Needed if oblate=.true.: Planet mean radius (m)
Rmean = 69911000.
# Needed if oblate=.true.: Mass of the planet (*1e24 kg)
MassPlanet = 1898.3
# use (read/write) a startfi.nc file? (default=.true.)
startphy_file = .false.
# constant value for surface albedo (if startphy_file = .false.)
surfalbedo = 0.0
# constant value for surface emissivity (if startphy_file = .false.)
surfemis = 1.0

# the rad. transfer is computed every "iradia" physical timestep
iradia = 160
# folder in which correlated-k data is stored ?
corrkdir = Jupiter_HITRAN2012_REY_ISO_NoKarko_T460K_article2019_gauss8p8_095
# Uniform absorption coefficient in radiative transfer?
graybody = .false.
# Characteristic planetary equilibrium (black body) temperature
# This is used only in the aerosol radiative transfer setup. (see aerave.F)
tplanet = 100.
# Output global radiative balance in file 'rad_bal.out' - slow for 1D!!
meanOLR = .false.
# Variable gas species: Radiatively active ?
varactive = .false.
# Computes atmospheric specific heat capacity and
# could calculated by the dynamics, set in callphys.def or calculeted from gases.def.
# You have to choose: 0 for dynamics (3d), 1 for forced in callfis (1d) or 2: computed from gases.def (1d)
# Force_cpp and check_cpp_match are now deprecated.
cpp_mugaz_mode = 0
# Specific heat capacity in J K-1 kg-1 [only used if cpp_mugaz_mode = 1]
cpp = 11500.
# Molecular mass in g mol-1 [only used if cpp_mugaz_mode = 1]
mugaz = 2.30
### DEBUG
# To not call abort when temperature is outside boundaries:
strictboundcorrk = .false.
# To not stop run when temperature is greater than 400 K for H2-H2 CIA dataset:
strictboundcia = .false.
# Add temperature sponge effect after radiative transfer?
callradsponge = .false.

Fat1AU = 1366.0

## Other physics options
## ~~~~~~~~~~~~~~~~~~~~~
# call turbulent vertical diffusion ?
calldifv = .false.
# use turbdiff instead of vdifc ?
UseTurbDiff = .true.
# call convective adjustment ?
calladj = .true.
# call thermal plume model ?
calltherm = .true.
# call thermal conduction in the soil ?
callsoil = .false.
# Internal heat flux (matters only if callsoil=F)
intheat = 7.48
# Remove lower boundary (e.g. for gas giant sims)
nosurf = .true.
#########################################################################
## extra non-standard definitions for Earth
#########################################################################

## Thermal plume model options
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~
dvimpl = .true.
r_aspect_thermals = 2.0
tau_thermals = 0.0
betalpha = 0.9
afact = 0.7
fact_epsilon = 2.e-4
alpha_max = 0.7
fomass_max = 0.5
pres_limit = 2.e5

## Tracer and aerosol options
## ~~~~~~~~~~~~~~~~~~~~~~~~~~
# Ammonia cloud (Saturn/Jupiter)?
aeronh3 = .true.
size_nh3_cloud = 10.D-6
pres_nh3_cloud = 1.1D5 # old: 9.D4
tau_nh3_cloud = 10. # old: 15.
# Radiatively active aerosol (Saturn/Jupiter)?
aeroback2lay = .true.
optprop_back2lay_vis = optprop_jupiter_vis_n20.dat
optprop_back2lay_ir = optprop_jupiter_ir_n20.dat
obs_tau_col_tropo = 4.0
size_tropo = 5.e-7
pres_bottom_tropo = 8.0D4
pres_top_tropo = 1.8D4
obs_tau_col_strato = 0.1D0
# Auroral aerosols (Saturn/Jupiter)?
aeroaurora = .false.
size_aurora = 3.e-7
obs_tau_col_aurora = 2.0

# Radiatively active CO2 aerosol?
aeroco2 = .false.
# Fixed CO2 aerosol distribution?
aerofixco2 = .false.
# Radiatively active water aerosol?
aeroh2o = .false.
# Fixed water aerosol distribution?
aerofixh2o = .false.
# basic dust opacity
dusttau = 0.0
# Varying H2O cloud fraction?
CLFvarying = .false.
# H2O cloud fraction if fixed?
CLFfixval = 0.0
# fixed radii for cloud particles?
radfixed = .false.
# number mixing ratio of CO2 ice particles
Nmix_co2 = 100000.
# number mixing ratio of water particles (for rafixed=.false.)
Nmix_h2o = 1.e7
# number mixing ratio of water ice particles (for rafixed=.false.)
Nmix_h2o_ice = 5.e5
# radius of H2O water particles (for rafixed=.true.):
rad_h2o = 10.e-6
# radius of H2O ice particles (for rafixed=.true.):
rad_h2o_ice = 35.e-6
# atm mass update due to tracer evaporation/condensation?
mass_redistrib = .false.

## Water options
## ~~~~~~~~~~~~~
# Model water cycle
water = .true.
# Model water cloud formation
watercond = .true.
# Model water precipitation (including coagulation etc.)
waterrain = .true.
# Use simple precipitation scheme?
precip_scheme = 1
# Evaporate precipitation?
evap_prec = .true.
# multiplicative constant in Boucher 95 precip scheme
Cboucher = 1.
# Include hydrology ?
hydrology = .false.
# H2O snow (and ice) albedo ?
albedosnow = 0.6
# Maximum sea ice thickness ?
maxicethick = 10.
# Freezing point of seawater (degrees C) ?
Tsaldiff = 0.0
# Evolve surface water sources ?
sourceevol = .false.

## CO2 options
## ~~~~~~~~~~~
# call CO2 condensation ?
co2cond = .false.
# Set initial temperature profile to 1 K above CO2 condensation everywhere?
nearco2cond = .false.
</syntaxhighlight>

- [[The_gases.def_Input_file|''gases.def'']]: File containing the gas composition of the atmosphere you want to model, with their molar mixing ratios.
<syntaxhighlight lang="bash" line>
# gases
5
H2_
He_
CH4
C2H2
C2H6
0.863
0.134
0.0018
1.e-7
1.e-5
# First line is number of gases
# Followed by gas names (always 3 characters)
# and then molar mixing ratios.
# mixing ratio -1 means the gas is variable.
</syntaxhighlight>

- [[The jupiter_const.def Input File|''jupiter_const.def'']]: Files that gather all orbital and physical parameters of Jupiter.

- [[The_traceur.def_Input_File|''traceur.def'']]: At this time, only two tracers are used for modelling Jupiter atmosphere, so the ''traceur.def'' file is summed up as follow
<syntaxhighlight lang="bash" line>
2
h2o_vap
h2o_ice
</syntaxhighlight>

''' Two additional files are used to set the running parameter of the simulation itself:'''

- [[The run_icosa.def Input File | ''run_icosa.def'']]: file containing parameters for '''ICOSAGCM''' to execute the simulation, use to determine the [[Advanced Use of the GCM | horizontal and vertical resolutions]], the number of processors, the number of subdivisions, the duration of the simulation, etc.

- ''run.def'': file which brings together all the setting files and will be reading by the interface '''ICOSA_LMDZ''' to link each part of the model ('''ICOSAGCM''', '''LMDZ.GENERIC''') with its particular setting file(s) when the library '''XIOS''' does not take action (through the ''.xml'' files).
<syntaxhighlight lang="bash" line>
###########################################################################
### INCLUDE OTHER DEF FILES (physics, specific settings, etc...)
###########################################################################
INCLUDEDEF=run_icosa.def

INCLUDEDEF=jupiter_const.def

INCLUDEDEF=callphys.def

prt_level=0

## iphysiq must be same as itau_physics
iphysiq=40
</syntaxhighlight>

== Hot Jupiter with DYNAMICO ==

Modelling the atmosphere of Hot Jupiter is challenging because of the extreme temperature conditions, and the fact that these planets are gas giants. Therefore, using a dynamical core such as Dynamico is strongly recommended. Here, we discuss how to perform a cloudless simulation of the Hot Jupiter WASP-43 b, using Dynamico.

'''1st step''': You need to go to the github mentionned previously for Dynamico: https://github.com/aymeric-spiga/dynamico-giant. ''Git clone'' this repo on your favorite cluster, and ''checkout'' to the "hot_jupiter" branch.

'''2nd step''': Now, run the install.sh script. This script will install '''all''' the required models ('''LMDZ.COMMON''', '''LMDZ.GENERIC''','''ICOSA_LMDZ''','''XIOS''','''FCM''','''ICOSAGCM'''). At this point, you only miss '''IOIPSL'''. To install it, go to
<syntaxhighlight lang="bash">
dynamico-giant/code/LMDZ.COMMON/ioipsl/
</syntaxhighlight>

There, you will find some examples of installations script. You need to create one that will work on your cluster, with your own arch files.
During the installation of '''IOIPSL''', you might be asked for a login/password. Contact TGCC computing center to get access.

'''3rd step''': Great, now we have all we need to get started. Navigate to the ''hot_jupiter'' folder. You will find a ''compile_mesopsl.sh'' and a ''compile_occigen.sh'' script. Use them as examples to create the compile script adapted to your own cluster, then run it.
While running, I suggest that you take a look at the ''log_compile'' file. The compilation can take a while (~ 10minutes, especially because of XIOS). On quick trick to make sure that everything went right is to check the number of ''Build command finished'' messages in ''log_compile''. If everything worked out, there should be 6 of them.

'''4th step''': Okay, the model compiled, good job ! Now we need to create the initial condition for our run. In the hot_jupiter1d folder, you already have a ''temp_profile.txt'' computed with the 1D version of the LMDZ.GENERIC (see rcm1d on this page). Thus, no need to recompute a 1D model but it will be needed if you want to model another Hot Jupiter.
Navigate to the 'makestart' folder, located at
<syntaxhighlight lang="bash">
dynamico-giant/hot_jupiter/makestart/
</syntaxhighlight>
To generate the initial conditions for the 3D run, we're gonna start the model using the temperature profile from the 1D run. to do that, you will find a "job_mpi" script. Open it, and adapt it to your cluster and launch the job. This job is using 20 procs, and it runs 5 days of simulations.
If everything goes well, you should see few netcdf files appear. The important ones are '''start_icosa0.nc''', '''startfi0.nc''' and '''Xhistins.nc'''.
If you see these files, you're all set to launch a real simulation !

'''5th step''': Go back to ''hot_jupiter'' folder. There are a bunch of script to launch your simulation. Take a look at the ''astro_fat_mpi'' script, and adapt it to your cluster. Then you can launch your simulation by doing
<syntaxhighlight lang="bash">
./run_astro_fat
</syntaxhighlight>
This will start the simulation, using 90 procs. In the same folder, check if the icosa_lmdz.out file is created. This is the logfile of the simulation, while it is running. You can check there that everything is going well.

'''Important side note''': When using the ''run_astro_fat'' script to run a simulation, it will run a chained simulation, restarting the simulation from the previous state after 100 days of simulations and generating ''Xhistins.nc'' files. This is your results file, where you will find all the variables that controls your atmosphere (temperature field, wind fields, etc..).

Good luck and enjoy the generic PCM Dynamico for Hot Jupiter !

'''2nd important side note''': These 5 steps are the basic needed steps to run a simulation. If you want to tune simulations to another planet, or change other stuff, you need to take a look at '''*.def''' and '''*.xml''' files. If you're lost in all of this, take a look at the different pages of this website and/or contact us !
Also, you might want to check the wiki on the [https://github.com/aymeric-spiga/dynamico-giant ''Github''], that explains a lot of settings for Dynamico

= 3D LES setup =

== Proxima b with LES ==

To model the subgrid atmospheric turbulence, the [[WRF dynamical core for LES/mesoscale simulations|'''WRF''']] dynamical core coupled with the LMD Generic physics package is used. The first studied conducted was to resolve the convective activity of the substellar point of Proxami-b (Lefevre et al 2021). The impact of the stellar insolation and rotation period were studied. The files for the reference case, with a stellar flux of 880 W/m2 and an 11 days rotation period, are presented

The input_* file are the used to initialize the temperature, pressure, winds and moisture of the domain.
input_souding : altitude (km), potential temperature, water vapour (kg/kg), u, v
input_therm : normalized gas constant, isobaric heat capacity, pressure, density, temperature
input_hr : SW heating, LW heating, Large-scale heating extracted from the GCM. Only the last one is used in this configuration.

The file namelist.input is used to set up the domain parameters (resolution, grid points, etc). The file levels specifies the eta-levels of the vertical domain.

Planet is used set up the atmospheric parameters, in order : gravity (m/s2), isobaric heat capacity (J/kg/K), molecular mass (g/mol), reference temperature (K), surface pressure (Pa), planet radius (m) and planet rotation rate (s-1).

The files *.def are the parameter for the physics. Compared to GCM runs, the convective adjustment in callphys.def is turned off

The file controle.txt, equivalent of the field controle in GCM start.nc, needed to initialize some physics constants.

TBC ML

= 1D setups =

== rcm1d program ==

Running the model in 1D (i.e. considering simply a column of atmosphere) is a common first step to test a new setup. To do so, you first have to compile the 1D version of the model. The command line is very similar to [[Quick_Install_and_Run#Compiling a test case (early Mars)|the one for the 3D]], except for 2 changes:
# put just the vertical resolution after the -d option ("VERT" instead of ''LON''x''LAT''x''VERT'' for the 3D case)
# at the end of the line, replace "gcm" with "rcm1d"
It will generate a file called '''rcm1d_XX_phyxxx_seq.e''', where ''XX'' and ''phyxxx'' are the vertical resolution and the physics package, respectively.

Check out the [[Generic unicolumn rcm1d program| dedicated page about rcm1d]] for more details.

Note that the '''.def''' files differ a bit from the 3D case. Indeed, the 1D run.def contains different information and needs to hold the key <code>run_1d=.true.</code>; see [[The_1D_run.def_Input_File|'''run.def''']]. In addition, the 1D model generally does not use [[The_start.nc_and_startfi.nc_input_files|'''start.nc''']] or [[The_start.nc_and_startfi.nc_input_files|'''startfi.nc''']] files to initialize. You can find examples of 1D configuration in ''LMDZ.GENERIC/deftank'' (e.g. '''run.def.earlymars1d''', '''run.def.earth1d'''), the best thing is to have a look at them.

== kcm1d program ==

Our 1-D inverse model

TBD by Guillaume or Martin

[[Category:Generic-Model]]
[[Category:Generic-LMDZ]]
[[Category:Generic-DYNAMICO]]
[[Category:Generic-WRF]]
[[Category:Generic-1D]]

Generic unicolumn rcm1d program

2026-06-12T14:06:10Z

Jbclement: /* Inputs */

It is possible to run the Gneric PCM in a uni-column (aka "single-column") configuration: this can be done via the '''rcm1d''' program; quite useful form some first studies but also when developing and testing parametrizations.

== Compilation ==
The main program '''rcm1d''' is compiled using the same compilation script, [[The makelmdz fcm GCM Compilation Script|makelmdz_fcm]], as for the 3D Generic lon-lat PCM. Nevertheless, there are few modifications:
* the ''-d'' option requires only one argument, the number of vertical levels;
* the main program to compile is ''rcm1d'' rather than ''gcm''.
So for instance to compile a case for 26 vertical levels one would run something like:
<syntaxhighlight lang="bash">
makelmdz_fcm -arch somearch -d 26 -p generic rcm1d
</syntaxhighlight>
Note that it is possible to compile and run with the XIOS library, which will require compiling in "mpi" mode (required by XIOS), even though the run will be serial:
<syntaxhighlight lang="bash">
makelmdz_fcm -arch somearch -d 26 -p generic -parallel mpi -io xios rcm1d
</syntaxhighlight>

== Inputs ==
Just like the 3D GCM, the ''rcm1d'' program needs some inputs to run. The needed files are:
* <code>z2sig.def</code> for the definition of vertical levels;
* <code>traceur.def</code> for the definition of tracers that the user wants the model to run with;
* <code>callphys.def</code> for the definition of parametrizations that the user wants the model to run with;
* <code>run.def</code> for the run configuration, which is suitable for 1D: see [[The 1D run.def Input File]]. Especially, the 1D file has to hold the key <code>run_1d=.true.</code>.

Unlike the 3D GCMs, the ''rcm1d'' program can run without any start files, which is its default (<code>restart=.false.</code>). In this setup, one can (and often needs) needs to provide initial profiles of each tracer. These consist in files called ''profile_sometracername'' containing column-wise the initial values of the considered tracer. Then, the first line corresponds to the surface tracer and the following lines correspond to the layers. At the end of a 1D simulation, ''rcm1d'' outputs a restart file '''restart.nc''' which can be used as an initial condition for a following run.

If <code>restart=.true.</code> in <code>rcm1d.def</code> then the program will look for start files '''start.nc''' and '''startfi.nc''' and use these as initial conditions.

== Outputs ==
If compiled without XIOS then ''rcm1d'' will output <code>diagfi.nc</code> and <code>stats.nc</code> files, just like the 3D GCM and the optional <code>diagfi.def</code> and <code>stats.def</code> files can be respectively added to specify which variables need be outputted.
Likewise if compiled with XIOS then ''rcm1d'' will output all files as specified in the relevant xml files, just like the 3D GCM.

As mentioned above, at the end of a simulation <code>rcm1d</code> also outputs a '''restart.nc''' file containing the final computed state.

[[Category:Generic-Model]]
[[Category:Generic-1D]]

The 1D run.def Input File

2026-06-12T14:05:44Z

Jbclement: Created page with "== The run.def input file and its format == === some general comments and disambiguation to start with === This pages specifically focuses on the ''run.def'' file used by the..."

== The run.def input file and its format ==

=== some general comments and disambiguation to start with ===
This pages specifically focuses on the ''run.def'' file used by the 1D version of the Generic PCM.

The run.def file is very similar to the [[The_run.def_Input_File|'''run.def''']] file, with the difference that the 3D options (linked to the dynamic core) are not used, and a whole bunch of new 1D-specific options (information contained in the start and startfi files) are now in the 1D run.def file. Especially, the 1D file has to hold the key <code>run_1d=.true.</code>.

== Reference def files ==
Reference *.def files are provided in the LMDZ.GENERIC/deftank directory

== Outputted used_*def files ==
When the GCM run finishes, for each of the input def files *.def, an ASCII output file '''used_*.def''' is generated (in practice this would be '''used_run.def''' and '''used_callphys.def''' for the 1D simulations). These files contain, along the same format as the *.def input files, the "key = value" that were used, along with comments about whether "value" was read in the input def file or if the code default was used (i.e. the sought "keyword" was not present in the input def files).

== Example of 1D ''run.def'' file ==

<pre>
#---------------------------------#
# Run parameters for the 1D model #
#---------------------------------#

run_1d=.true.

## Planetary constants
## ~~~~~~~~~~~~~~~~~~~~~~~
## NB: those are mandatory
## ~~~~~~~~~~~~~~~~~~~~~~~
## LENGTH OF A DAY in s
daysec = 86400.
## GRAVITY in m s-2
g = 3.72
## Radius of the planet, in m
rad = 3390000
## LENGTH OF A YEAR in days
year_day = 3000
## MIN DIST STAR-PLANET in AU [periastron]
periastr = 1.0
## MAX DIST STAR-PLANET in AU [apoastron]
apoastr = 1.0
## DATE OF PERIASTRON in days
peri_day = 0.
## OBLIQUITY in deg
obliquit = 0.
## SURFACE PRESSURE in Pa
psurf = 100000.

## Time integration parameters
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Initial date (in solar days,=0 at Ls=0)
day0 = 0
# Initial local time (in hours, between 0 and 24)
time = 12
# Number of time steps per sol
day_step = 40
# Number of sols to run
ndt = 1000
# Number of steps between each writing in diagfi
diagfi_output_rate=12

## Vertical levels
## ~~~~~~~~~~~~~~~
# hybrid vertical coordinate ? (.true. for hybrid and .false. for sigma levels)
hybrid = .true.
# autocompute vertical discretisation? (useful for exoplanet runs)
autozlevs = .false.
# Ceiling pressure (Pa) ?
pceil = 0.00001

## Thermal properties
## ~~~~~~~~~~~~~~~~~~
# Simulate global averaged conditions ?
global1d = .true.
# Latitude (deg) [only used if global1d = F]
latitude = 0.0
# Solar Zenith angle (deg) [only used if global1d = T]
szangle = 60.
# Force specific heat capacity and molecular mass values
force_cpp = .false.
# Specific heat capacity in J K-1 kg-1 [only used if force_cpp = T]
cpp = 0.
# Molecular mass in g mol-1 [only used if force_cpp = T]
mugaz = 18.
# Albedo of bare ground
albedo = 0.1
# Emissivity of bare ground
emis = 1.0
# Soil thermal inertia (SI)
inertia = 1000.
# Initial CO2 ice on the surface (kg.m-2)
co2ice = 0.

## Wind profile
## ~~~~~~~~~~~~
## zonal eastward component of the geostrophic wind (m/s)
u = 10.
# meridional northward component of the geostrophic wind (m/s)
v = 0.

## Initial atmospheric temperature profile
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# Type of initial temperature profile
# ichoice=1 Constant Temperature: T=tref
# [Mars] ichoice=2 Savidjari profile (as Seiff but with dT/dz=cte)
# [Mars] ichoice=3 Lindner (polar profile)
# [Mars] ichoice=4 inversion
# [Mars] ichoice=5 Seiff (standard profile, based on Viking entry)
# ichoice=6 constant T + gaussian perturbation (levels)
# ichoice=7 constant T + gaussian perturbation (km)
# ichoice=8 Read in an ascii file "profile"
ichoice = 1
# Reference temperature tref (K)
tref = 300.
# Add a perturbation to profile if isin=1
isin = 0
# peak of gaussian perturbation (for ichoice=6 or 7)
pic = 26.522
# width of the gaussian perturbation (for ichoice=6 or 7)
largeur = 10
# height of the gaussian perturbation (for ichoice=6 or 7)
hauteur = 30.

</pre>

'''Notes''':
* Lines beginning with a hashtag are comments
* values associated to keywords may be logicals, integers, reals or even strings
* The parsing is case-sensitive : "thisparameter=" and "ThisParameter=" are identified as two distinct keywords
* The order in which the parameters are given in the file does not matter (except if a parameter is specified multiple times, clearly a bad idea, and then the last occurrence will prevail).
* Accessing a parameter and its value from ''run.def'' in the Fortran code is done using the '''getin_p''' routine, e.g.:
<syntaxhighlight lang="fortran">
call getin_p("keyword",val)
</syntaxhighlight>
will look for the line with "keyword = " in file ''run.def'' and extract trailing value which will be use to set the value of the '''val''' variable in the code.

[[Category:Inputs]]
[[Category:WhatIs]]

[[Category:Generic-LMDZ]]
[[Category:Generic-1D]]

Dynamico-giant

2026-06-12T13:30:50Z

Jbclement: /* comment changer le bottom du modele */

[transferred from github, now active here]

= 1. Introduction =

Modeling the atmospheric circulation of giant planets of our solar System (Jupiter, Saturn, Uranus and Neptune) require high horizontal resolution grid: typically, half a degree (in latitude, longitude) for Jupiter and Saturn, and one degree for Uranus and Neptune.
For this reason, GCM runs for giant planets use the DYNAMICO dynamical core (see [[The_DYNAMICO_dynamical_core|Dynamico]]), coupled to the Generic physics (see [[Overview_of_the_Generic_PCM|Generic-PCM]]).

= 2. Installation =

== A) Fichiers d'architecture ==

=== - Modules ===

Two options:

1/ Before installation, set environment (do it once) in your .bash_profile.

Example for Ciclad:

<pre>ulimit -s unlimited
# modules
module purge
module load gnu/4.9.3
module load intel/15.0.6.233
module load openmpi/1.6.5-ifort
module load hdf5/1.8.18-parallel-ifort
module load netcdf4/4.4.1.1-parallel-ifort</pre>
Beware, if you change version of model (newer or older version), it's possible that you have to change modules...

2/ Or, in your script that launches a job, source a .env file (' source .../dynamico-giant/code/ARCH/arch-ADASTRA-gnu.env ')

=== - Installation sur un nouveau cluster ===

En pratique LMDZ.COMMON, ICOSA_LMDZ et IOIPSL peuvent utiliser exactement le même fichier arch.fcm ; mais celui pour ICOSAGCM est légèrement différent (les %FPP_DEF diffèrent, peut-être aussi le %FPP).

make_icosa_lmdz doit être lancé avec -arch_path ../ARCH puisque les arch.env et arch.path communs se trouvent dans ../ARCH (l'option -arch_path ne concerne d'ailleurs que les fichiers arch.env et arch.path; le fichier arch.fcm recherché sera toujours celui dans le "arch" de chacun des modèles. Donc il faut bien mettre pour chacun des quatre modèles (LMDZ.COMMON, ICOSA_LMDZ,IOIPSL et ICOSAGCM) le arch.fcm dans le sous-dossier arch/ du modèle correspondant.

L'installation d'IOIPSL doit se faire à partir du bon script bash. Si vous utilisez un server autre qu'occigen, il vous faut changer le nom du script à utiliser dans install_ioipsl.sh. Par exemple, il vous faudra utiliser install_ioipsl_ciclad-ifort.bash pour CICLAD.

XIOS est écrit en C++, et pas en Fortran. Le fichier arch.fcm correspondant est donc nécessairement différent de celui des quatre autres modèles. Pour créér ce arch.fcm, prendre exemple sur les fichiers .fcm déjà présent dans XIOS/arch/, avec une architecture similaire à celle du nouveau cluster. En particulier, il faut utiliser des versions de gcc/gfortran > 6+. Il faut absolument avoir une bibliothèque HDF5 compilée en parallèle, ainsi que netcdf-C et netcdf-fortran (et peut être aussi netcdf-Cxx) compilé en parallèle. Sans ça, il sera peut-être possible de compiler le modèle, mais pas de lancer une simulation en utilisant XIOS.

== B. Download ==

Download structure

Take place on a repository and git clone the model.

On occigen:

<pre>cd $SCRATCHDIR
git clone https://github.com/aymeric-spiga/dynamico-giant.git [optional different name]</pre>
== C. Install ==

Install code

<pre>cd dynamico-giant
./install.sh
./install_ioipsl.sh</pre>
A login and a password are necessary to install IOIPSL (only for the first time, after that we can save them). Please contact TGCC computing center to get the login/password.

After that, please add "$PWD"/FCM_V1.2/bin/ to PATH environment variable.

Ant that's all, we can now change parameters of files or compile the code to do a test (part 6) or eat a beautiful tartiflette (can be also do during compilation).

= 3. General parameters =

== A) Mesh grid & resolution ==

On run_icosa.def:

<pre>nbp --> number of subdivision on a main triangle: integer (default=40)
nbp = sqrt((nbr_lat x nbr_lon)/10)
nbp 20 40 80 160
T-edge length (km) 500 250 120 60
Example: nbp(128x96)=35 -> 40
nbp(256x192)=70 -> 80
nbp(360x720)=160 -> 160
nsplit_i, nsplit_j --> sub splitting of main rhombus: integer
Example: for nbp=80, nsplit_i=4,nsplit_j=6
nbp/nsplit_{i,j} = 20 > 10 & 13 > 10 --> GOOD</pre>
=== - Remapping ===

Pour le remapping, il faut aller dans context_lmdz_physics.xml changer les paramètres ni_glo et nj_glo par exemple pour remapper sur du lat/lon à 360 pts en latitude et 720 pts en longitude (0.5°).

<code><domain id="dom_regular" ni_glo="720" nj_glo="360" type="rectilinear"></code>

== B) Time ==

* ndays is number of days to simulate.
* day_step is number of dynamical time step per day
* Dynamics called every day_length(in s) / day_step per day
* 1 ts (physical timestep) = (day_length(in s)/day_step) x itau_physics
* Physics called (day_step / itau_physics) per day
* Physics called day_length(in s) / ts per day
* Radiative called every Physics x iradia physical timestep
* Radiative called every iradia/Physics days

== C) Sponge layer ==

<pre>iflag_sponge=0 for no sponge (default)
iflag_sponge=1 for sponge over 4 topmost layers
iflag_sponge=2 for sponge from top to ~1% of top layer pressure
mode_sponge=1 for u,v --> 0
mode_sponge=2 for u,v --> zonal mean
mode_sponge=3 for u,v,h --> zonal mean
tau_sponge --> damping frequency at last layer
--> e-5 medium / e-4 strong yet reasonable / e-3 very strong</pre>
Spiga et al (2020): Shaw and Shepherd (2007) showed that the inclusion of sponge-layer parameterizations that do not conserve angular momentum (which is the case for Rayleigh drag), or allow for momentum to escape to space, implies a sensitivity of the dynamical results (especially zonal wind speed) to the choice for model top or drag characteristic timescale, because of spurious downward influence when momentum conservation is violated.

Il ne faut donc pas ajouter de sponge layer pour les planètes géantes (iflag_sponge = 0)

== D) Dissipation ==

Spiga et al (2020): A subgrid-scale dissipation term is included in our Saturn DYNAMICO GCM to prevent the accumulation of energy at scales close to the grid resolution, caused by the GCM not resolving the turbulent scales at which this energy is dissipated. This hyperviscosity term is written in our Saturn DYNAMICO model as an iterated Laplacian term on a given variable. The three variables denoted are vorticity, divergence, and potential temperature, chosen to set horizontal dissipation on respectively the rotational component of the flow (e.g. Rossby waves), the divergent component of the flow (e.g. gravity waves), and the diabatic perturbations (e.g. coming from the physical packages).

<pre>tau_graddiv --> dissipation timescale of smallest wvl: u,v (gradiv) : real (default=5000)
tau_gradrot --> dissipation timescale of smallest wvl: u,v (nxgradrot) : real (default=5000)
tau_divgrad --> dissipation timescale of smallest wvl: h (divgrad) : real (default=5000)
nitergdiv --> number of iterations for gradiv operator : integer (default=1)
nitergrot --> number of iterations for nxgradrot operator : integer (default=1)
niterdivgrad --> number of iterations for divgrad operator : integer (default=1)</pre>
tau_graddiv,tau_gradrot,tau_divgrad correspondent au temps de dissipation (plus c'est petit, plus la dissipation est efficace). nitergdiv,nitergrot,niterdivgrad correspondent à l'ordre du laplacien (plus c'est grand, plus on dissipe sélectivement les petites échelles).

Attention, Trop dissiper -> instabilité numérique

Pas assez dissiper -> instabilité dynamique trop forte

L'ordre du laplacien dans les fichiers .def est suffisant. S'il faut changer la dissipation, il vaut mieux changer les temps de dissipation que l'ordre du laplacien (risque d'instabilité numérique).

=== - Facteurs de dissipation ===

A partir de ces valeurs de temps de dissipation, il est également possible d'ajouter 2 facteurs de dissipation (fac_mid et fac_up) qui permettent d'augmenter la dissipation à partir de certains niveaux. Le fac_mid permet de diminuer le temps de dissipation d'un facteur sur toute l'atmosphère jusqu'au bottom. Il y a une zone transition de quelques niveaux entre le bottom (le temp de dissipation au bottom est sans facteur) et quelques niveaux au-dessus où la valeur du temps de dissipation est avec ce facteur jusqu'au top. On ne peut donc pas choisir l'altitude et la zone de transition avec ce facteur. Quant au fac_up, il permet de diminuer le temps de dissipation d'un facteur à partir d'une altitude et d'une épaisseur de zone de transition qu'on peut choisir. On peut utiliser la combinaison des 2 ou l'un des 2. Pour ne pas prendre en compte ces facteurs de dissipation, il faut qu'il soit mis à 1.

Il existe 2 modes possibles pour le fac_up: le mode martien (en fonction de l'altitude) et le mode vénusien (en fonction de la pression). Dans le 1er cas, il faut renseigner l'altitude où démarre la zone de transition et l'épaisseur de cette zone. Dans le 2ème cas, il faut renseigner la pression où démarre la zone de transition et l'échelle de hauteur de cette zone de transition.

Il est vivement conseillé de tracer votre profil de dissipation à partir des équations (dans vert_prof_dissip_icosa_lmdz.f90) afin d'être certain de leur allure.

== E) Rayleigh Friction ==

Spiga et al 2020: This drag plays the role devoted to surface friction on terrestrial planets, which allows to close the angular momentum budget through downward control (Haynes and McIntyre, 1987; Haynes et al., 1991). This could also be regarded as a zeroth-order parameterization for Magneto-HydroDynamic (MHD) drag as a result of Lorenz forces acting on jet streams putatively extending to the depths of Saturn's interior (Liu et al., 2008; Galanti et al., 2019), much deeper than the shallow GCM's model bottom.

Comme Liu and Schneider (2010), cette couche de frottement ne s'exerce pas aux régions équatoriales car à l’extérieur du cylindre tangeant du rayon équatorial, les cylindres convectifs ne coupent pas cette couche et ne subissent pas les frottements liés aux effets de la MHD.

Le paramètre rayleigh_limlat correspond à la latitude maximale de part et d'autre de l'équateur où cette friction n'est pas observée.

Pour le temps (rayleigh_friction_tau), il est similaire à celui utilisé par Liu and Schneider (2010). Elle est fixée à 100 jours terrestres. Mais attention, on fonction de la valeur, la dynamique peut évoluer dans votre simulation.

== F) Conservation ==

Dans run_icosa.def:

<pre>check_conservation = detailed
itau_check_conserv = 320</pre>
Le itau_check_conserv est comme itau_physics pour que la contribution de la physique à AAM ne soit pas nulle. de plus il est coûteux d'appeler les diagnostics trop souvent.

S. Lebonnois, C. Covey, A. Grossman, H. Parish, G. Schubert, R. Walterscheid, P. Lauritzen, and C. Jablonowski. Angular momentum budget in General Circulation Models of superrotating atmospheres: A critical diagnostic. Journal of Geophysical Research (Planets), 117:E12004, 2012.

P. H. Lauritzen, J. T. Bacmeister, T. Dubos, S. Lebonnois, and M. A. Taylor. Held-Suarez simulations with the Community Atmosphere Model Spectral Element (CAM-SE) dynamical core: A global axial angular momentum analysis using Eulerian and floating Lagrangian vertical coordinates. Journal of Advances in Modeling Earth Systems, 6:129-140, 2014.

== G) Traceur ==

=== - Branche master version du 04/04/2022 dans le dossier Jupiter (traceur) ===

La version actuelle des fichiers de réglage dans le dossier Jupiter est réglée pour utiliser des traceurs. Si vous souhaiter utiliser le modèle sans traceur, il vous faut modifier les fichiers suivants :

run_icosa.def

<pre> nqtot = 0</pre>
traceur.def

<pre> 0</pre>
context_dynamico.xml (ligne 125)

<pre> <field id="q_start" name="q" grid_ref="grid_q_start" prec="8"/> </pre>
== H) Bottom du modèle ==

* refaire tourner le 1D
** changer la pression <code>psurf</code> dans run.def
** changer <code>ichoice=1</code> et changer <code>tref</code> (ex: 10b: 330K)
* refaire tourner le 3D (avec makestart) en changeant <code>preff</code> dans <code>[nom_de_la_planète]_const.def</code>

= 4. Physical parameterizations =

== A) Cycle diurne ==

<code>diurnal = .false.</code> Car le temps radiatif est beaucoup plus long sur les planètes géantes.

== B) Anneaux ==

[Pour saturne uniquement] Il est possible d'ajouter l'ombre des anneaux dans le callphys.def:

<code>rings_shadow = .true.</code>

== C) Collision-induced absorption data ==

L'absorption induite par collision est importante dans le transfet radiatif sur les planètes géantes, notamment celle provenant de H2. Cependant, le rapport ortho-para du H2 est différent selon les planètes et peut modifier fortement le chauffage sur ces planètes. Pour le cas des géantes gazeuses, le rapport ortho-para est normal (rapport 3:1). Mais pour le cas des géantes glacées, le rapport ortho-para est à l'équilibre. Par défaut, le rapport ortho-para est normal (H2orthopara_mixture = normal). Pour les géantes glacées, il faut mettre H2orthopara_mixture = equilibrium .

Si vous voulez modifier le fichier utilisé dans un cas de CIA, il faut aller dans le code (dynamico-giant/code/LMDZ.GENERIC/libf/phygeneric/interpolate????.F90) et changer le nom du fichier (assurez-vous que ce fichier soit dans votre répertoire DATAGENERIC/continuum_data).

Dans la version actuelle, il n'existe pas d'option qui permet de ne pas utiliser certaines contributions de CIA. Par exemple, si votre atmosphère est composé de H2, He et CH4 et que vous ne voulez pas des contributions venant du CH4, il vous faut commenter dans le modèle ces contributions.

== D) K-correlated data ==

Les fichiers k-corrélées doivent se situer dans votre répertoire DATAGENERIC/corrk_data .

== E) Cpp mode ==

cpp_mugaz_mode=0 pour que la valeur de cpp et de mugaz proviennent de la dynamique. cpp_mugaz_mode=1 pour forcer la valeur de cpp et de mugaz dans le callphys.def (à utiliser dans le makestart uniquement) cpp_mugaz_mode=2 pour calculer automatiquement à partir de données de références à 300 K et du gases.def (à éviter)

== F) Generic n-layer aerosols (replaces the former 2-layer and NH3 cloud) ==

Ce mode permet de créer des couches d'aérosols/nuages ayant une opacité (aeronlay_tauref) à une longueur d'onde donnée (aeronlay_lamref), un rayon de particule fixe (aeronlay_size) situés à une pression fixe et en fonction des propriétés optiques des particules (optprop_aeronlay_vis et optprop_aeronlay_ir). Pour le cas de l'altitude, on peut choisir soit (aeronlay_choice = 1) une pression max (aeronlay_ptop) et une pression min (aeronlay_pbot), soit (aeronlay_choice = 2) une pression min (aeronlay_pbot) et une échelle de hauteur (aeronlay_sclhght). On peut également choisir la variance effective pour les rayons de particules.

Le nombre de couche de nuage (nlayero) est égal au nombre de scatterers dans la compilation (option -s ).

Les fichiers de propriétés optiques doivent être dans votre DATAGENERIC.

Un exemple pour 3 couches:

<pre>aeronlay = .true.
nlayaero = 3
aeronlay_tauref = 2.5 0.04 0.1
aeronlay_lamref = 0.8e-6 0.8e-6 0.16e-6
aeronlay_choice = 2 2 1
aeronlay_pbot = 1.5e5 1.6e5 20.
aeronlay_ptop = 1.1e5 1. 1.
aeronlay_sclhght = 0.1 2.0 1
aeronlay_size = 0.5e-6 0.05e-6 0.5e-6
aeronlay_nueff = 0.3 0.3 0.3
optprop_aeronlay_vis = optprop_aerosol2_vis.dat optprop_aerosol3_vis.dat optprop_carbon4_vis.dat
optprop_aeronlay_ir = optprop_aerosol2_ir.dat optprop_aerosol3_ir.dat optprop_carbon4_ir.dat</pre>
== G) Panaches thermiques ==

# Comme pour toutes nouvelles simulations, il faut commencer par un run 1D de plusieurs décennies permettant d'obtenir un profil de température (<code>temp_profile.txt</code>) et les coefficients ap et bp (<code>apbp.txt</code>) en équilibre radiatif-convectif pour la planète que l'on étudie. Ce run 1D s'effectue dans les dossiers jupiter1d, saturn1d, neptune1d et/ou uranus1d, avec ces options pour le callphys.def :

callrad = true calladj = true tous les autres mots clés à false (y compris <code>calltherm</code>).

<ol start="2" style="list-style-type: decimal;">
<li>Faire un "makestart" run : permet d'obtenir les fichiers restart à partir du profil de température initial. Il s'agit du run dont l'état initial est le profil de température créé par run 1D (<code>temp_profile.txt</code> est appliquer à chaque point de grille horizontale du modèle). L'état initial est ainsi une planète isotherme horizontalement mais qui varie verticalement. Pour ce run, aucun traceur ne va être utilisé dans le modèle. Néanmoins, il faut renseigner au modèle le nombre de traceurs que nous souhaitons utiliser avec le schéma des panaches thermiques afin qu'il puisse créer la dimension nq et le champ q dans les fichiers <code>restart_icosa.nc</code> et <code>restartfi.nc</code>. dans '''callphys.def''' :
<pre> traceur = true</pre>
dans '''run_icosa.def''' : <code>nqtot = 2</code> (par exemple, h2o_vap et h2o_ice) dans '''traceur.def''' :
<pre> 2
h2o_vap
h2o_ice</pre></li>
<li>Ajout des quantités pour chaque traceur. Ici, nous ajoutons les profils pour chacun des traceurs dans les fichiers <code>restart_icosa.nc</code> et <code>restartfi.nc</code> "à la main" en utilisant le programme python <code>/processing_codes/tracer_settings.py</code> pour obtenir des fichiers restart avec la bonne abondance d'eau dans le cas présent.</li>
<li>Commencer la simulation : Il ne reste plus qu'à lancer la simulation 3D avec les nouveaux fichiers restart et les réglages suivant : dans '''callphys.def''' :
<pre> traceur = true
calltherm = true
# thermal plume model options:
divmpl = true
r_aspect_thermals = 2.0
tau_thermals = 0.0
betalpha = 0.9
afact = 0.7
fact_epsilon = 2.e-4
alpha_max = 0.7
fomass_max = 0.5
pres_limit = 2.e5
water = true
watercond = true
waterain = true
evap_prec = true</pre></li></ol>

dans '''run_icosa.def''' : <code>nqtot = 2</code> dans '''traceur.def''' :

<pre> 2
h2o_vap
h2o_ice</pre>
Enfin, ajouter la déclaration et l'écriture des variables relatives à l'utilisation du schéma des thermiques (<code>h2o_vap</code>, <code>h2o_ice</code>, <code>w_plm</code>) dans les fichiers XML de la physique.

== H) Rotation ==

Dans [name_of_planet]_const.def, changer le taux de rotation.

Cela n'a jamais été testé avec 0, mais cela pourrait créer des problèmes (ex: beta). ''vérifier que omega dans saturn_const.def n'intervient pas dans la physique LMDZ.GENERIC/libf/phygeneric/''

== I) Appel à la physique ==

Il faut changer à ''deux endroits'' en réglant la même valeur: - dans run_icosa.def, changer itau_physics ; - dans run.def, changer iphysiq. Ces paramètres sont exprimés en pas de temps dynamique. Pour appeler la physique à chaque pas de temps dynamique, régler ces paramètres à 1.

'''Attention: ''' Lorsque l'on change dans le ''run_icosa.def'' la valeur de itau_physics, faire bien attention à la valeur du champ itau_adv (qui controle la frequence d'advection des traceurs par la dynamique, compté en pas de temps dynamique). Il faut que itau_physics soit un multiple de itau_adv. Cela veut dire, que l'on advecte notre champ de traceurs plus souvent (ou autant de fois) que l'on appelle la physique, qui peut transformer ces traceurs.

= 5. Ecriture des fichiers =

== A) Nombre d'écriture dans chaque Xhistins.nc ==

Prenons l'exemple de l'écriture d'un fichier sur une simu Uranus pour 1000j

Nombre d'écriture = day_step X ndays/(itau_physics X output_freq)

* ndays = 1000
* day_step = 200
* itau_physics = 50
* output_freq = 200

On a 20 sorties tous les 1000 jours.

Globalement, il est conseillé d'avoir 800 à 1000 sorties minimum par année planétaire (voir beaucoup plus en fonction de votre étude).

== B) Ajouter une variable ==

Pour ajouter une variable dans le fichier de sortie Xhistins.nc, il faut l'ajouter dans le field_group correspondant et s'assurer que cette variable est présente en tant que variable de sortie dans dynamico-giant/code/LMDZ.GENERIC/libf/phygeneric/physiq_mod.F90. Si ce n'est pas le cas, il faut faire un call writediagfi de la variable puis l'ajouter dans un call send_xios_field.

== C) Forcer XIOS à écrire tous les .... ==

Il faut utiliser l'attribut (ici par ex pour forcer l'écriture tous les ts (==time step) ; d'autres délais doivent être possible): <code>sync_freq="1ts"</code> dans le <code><file id=... .... ></code> concerné.

== D) XIOS server ou client ==

# XIOS client <code>use_server=False</code> Broadwell 24 processeurs sur 28
# XIOS server <code>use_server=true</code> Broadwell 24 processurs sur 28 + 4 processeurs pour XIOS

Le cas 1 est 3 min plus lent que le cas 2 -- sur 2h20...(!) parce qu'on fait peu de sorties.

= 6. Running the model =

== A) Compilation ==

Pour compiler le modèle, il suffit d'aller dans le dossier avec vos fichiers .def et .xml et d'utiliser le script compile_occigen.sh si on est sur occigen ou compile_ciclad.sh si on est sur ciclad

<code>./compile_occigen.sh</code>

Les options qui peuvent être modifiées/ajoutées sont - -s : le nombre de scatterers - -parallel: mpi ou mpi_omp - -arch: le nom du ficher d'architecture - -arch_path: le chemin vers ce fichier - -job: 8 (conseillé) - -full: compile le code entièrement - -debug: pour trouver un éventuel bug. A ENLEVER obligatoirement s'il n'y a plus de bug car multiplie par 5 votre temp de calcul.

En 1D, d'autres options sont nécessaires: - -t: nombre de traceurs - -d: nombre de niveaux verticaux - -parallel: none (en 1D uniquement)

=== - Versions fonctionnelles de dynamico-giant ===

'''Jupiter''' - XIOS revision 1583 
- ICOSAGCM revision 756 
- IOIPSL revision 339 
- FCM_V1.2 revision 12 
- Physics revision 2228 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

but check Physics version 2142 and 2180

'''Saturne (référence Spiga 2020, à vérifier)''' - DYNAMICO --> Revision: 756 - PHYSICS --> Revision: 2005 - XIOS --> Revision: 1583 - IOIPSL --> Revision: 310?

'''Saturne (simulation de référence sur 61 niveaux, Bardet et al. Icarus 2021)''' - XIOS revision 1583 
- ICOSAGCM revision 765 
- IOIPSL revision 310 
- FCM_V1.2 revision 12 
- Physics revision 2005 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Saturne (simulation avec la GWD paramétrisation sur 61 niveaux, chapitre 6 PhD Bardet)''' - XIOS revision 1583 
- ICOSAGCM revision 765 
- IOIPSL revision 310 
- FCM_V1.2 revision 12 
- Physics revision 2213 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Saturne (simulation sur 96 niveaux, Bardet et al. Nature Astronomy 2022)''' - XIOS revision 1583 
- ICOSAGCM revision 765 
- IOIPSL revision 431 
- FCM_V1.2 revision 12 
- Physics revision 2305 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Saturne (simulation avec la GWD paramétrisation sur 96 niveaux, chapitre 6 PhD Bardet)''' - XIOS revision 1583 
- ICOSAGCM revision 765 
- IOIPSL revision 431 
- FCM_V1.2 revision 12 
- Physics revision 2403 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Uranus & Neptune (old version)''' - XIOS revision 1944 - ICOSAGCM revision 765 - IOIPSL revision 431 - FCM_V1.2 revision 12 
- Physics revision 2413 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Uranus & Neptune (new version)''' - XIOS revision 2203 - ICOSAGCM revision (20/08/2021) - IOIPSL revision 450 - FCM_V1.2 revision 12 
- Physics revision 2555 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Jupiter, Saturne, Uranus & Neptune [OCCIGEN VERSION]''' - XIOS revision 2319 - ICOSAGCM revision (90f7138a60ebd3644fbbc42bc9dfa22923386385) - IOIPSL revision 453 - FCM_V1.2 revision 12 
- Physics revision 2655 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Jupiter, Saturne, Uranus & Neptune [IRENE VERSION]''' - XIOS revision 2399 - ICOSAGCM revision (4fbd393a9051fd9c1a5b662683f6ad8d0dc2867c) - IOIPSL revision 6234 - FCM_V1.2 revision 12 
- Physics revision 2842 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

== B) Run 1D ==

Pour une simulation 1D, 1 seul CPU suffit.

To run on Occigen:

<code>sbatch job_mpi</code>

To run on Irene:

<code>ccc_msub job_mpi</code>

To see evolution of your job on Occigen:

<code>squeue -u username</code>

To see evolution of your job on Irene:

<code>ccc_mpp -u username</code>

To kill your job on Occigen:

<code>scancel id_of_your_job</code>

To kill your job on Irene:

<code>ccc_mdel id_of_your_job</code>

Une fois que votre simulation est fini, lancer le script python printapbp.py qui vous permettra d'obtenir les fichiers apbp.txt et temp_profile.txt nécessaires pour les simulations en 3D.

== C) Run 3D ==

Pour lancer une première simulation, il faut tout d'abord le faire une seule fois dans le dossier makestart de l'un des dossiers jupiter, saturne, uranus ou neptune. Ce dernier permettra de créer les premiers fichiers restart_icosa.nc et restartfi.nc. Ensuite, il suffit revenir dans le dossier parent (jupiter, saturne, uranus, neptune) et de lancer ses simulations.

=== - MPI ===

Avant de lancer une simulation, il est nécessaire de déterminer - le nombre de procs - le nombre de noeuds

Il faut avant tout savoir qu'il y a 10 x nsplit_i x nsplit_j domaines. Ces domaines sont divisés en plusieurs cellules. Il y a (nbp)²/(nsplit_i x nsplit_j) cellules par domaine. Ce nombre est égal au nombre de MPI process.

Il est important de ne pas faire des tuiles "trop petites" et donc de garder nsplit_i et nsplit_j tels que nbp/nsplit_{i,j} >=10-15 (plutôt 15). Car il y a des calculs "redondants" faits sur les bords du domaine. Admettons que ton domaine soit 10 x 10 (100 cellules par domaine). Le nombre de cellules au bord du domaine est égal à 2 x nsplit_i + 2 x nsplit_j - 4. Dans ce cas, le nombre de cellules au bord est de 36. Cela signifie que le bord du domaine correspond à 36% du domaine (36 points sur 100). Si le domaine est 15 x 15, alors le bord du domaine n'est plus que de 24.8 %. On aimerait avoir des domaines les plus grands possibles mais il faut aussi voir que chaque cellule correspond à une colonne à résoudre... Et c'est là ou il faut expérimenter un peu pour trouver l'optimum entre le nombre total de proc à employer et le gain effectif (temps total "facturé" au vu du nombre de procs monopolisés pour une simu donnée). Ehouarn

Il faut au total que le nombre de procs soit égal à 10 x nsplit_i x nsplit_j qu'il faut répartir entre les noeuds.

Pour les noeuds, il faut tenir compte qu'un noeud sur Occigen, c'est 24 (ou 28) procs. Disons 24. Quand on demande N procs, le système te donne M noeuds, soit M X 24 procs (les noeuds ne sont pas partagés avec d'autres applications). Et bien sûr on te facturera ces M noeuds, même si tu n'utilises pas tous les procs. Donc il faut s'efforcer de tomber juste et demander un multiple de 24 procs. Même raisonement si tu demandes à utiliser des noeuds de 28 procs.

Par exemple, nsplit_i = 4 et nsplit_j = 6. 4 x 6 est égal à 24. On utilisera donc 10 noeuds pour avoir 240 nprocs.

Prenons un autre exemple. nsplit_i = 5 et nsplit_j = 6. 5x6 = 30 Or il y a 24 procs par noeuds. Il faudra utiliser 13 noeuds. Et ce ne sont pas 300 procs qui seront facturés au total mais 312.

Mais comme vu plus haut, en fonction de la configuration de tes domaines, il est possible que le 2nd exemple coûte moins cher en heure CPU que le 1er exemple car il sera plus rapide.

=== - OpenMP / MPI ===

Dans le cas mixte OpenMP/MPI, il est nécessaire de renseigner le nombre de tâche OpenMP et de MPI threads. Dans le script pour le job, on a :

cpus-per-task et OMP_NUM_THREADS correspondent au nombre de tâche OpenMP ntask-per-node correspond au nombre de tâche par noeud

Pour déterminer la configuration à utiliser en OpenMP/MPI, il faut respecter ces règles: - ntask-per-node x nodes correspond au nombre total de MPI threads qu'il devrait y avoir (c'est-à-dire dans le cas MPI seul). - cpus-per-task x ntask-per-node doit être égale ou inférieur au nombre de procs par noeuds (24 ou 28- sur Occigen) - cpus-per-task devrait être ~égal au nombre de niveaux verticaux / 10 - OMP_NUM_THREADS doit être égal au cpus-per-task - omp_level_size (dans le fichier run_icosa.def) devrait être ~égal au nombre de cpus-per-task. (dans le cas MPI seul, il faut le laisser égal à 1)

Au total, le nombre total de nprocs est égal à cpus-per-task x ntask-per-node x nodes

En reprenant le premier exemple MPI (on suppose qu'on a 40 niveaux verticaux), on aura - cpus-per-task = 4 - ntask-per-norde = 6 On a bien cpus-per-task x ntask-per-norde <= 24. Le nombre de noeuds doit être égal à 40 car 6x40 = 240 nprocs MPI Le nombre de procs qu'on utilisera au total sera de 960.

=== - Comment déterminer le nombre d'heure CPU (consommation en heure)? ===

Heures CPU = durée_de_la_simu X nombre de procs total facturé

Si on veut connaître le nombre d'heure CPU qu'on consommera à partir d'un test, voici le calcul

Heures CPU = durée_de_la_simu_test X nombre de procs total facturé X nombre de jour qu'on veut simulé / (nombre de jour simulées pendant la simu test)

== D) Optimisation ==

Pour savoir quelle est la meilleure configuration en MPI seul, en OpenMP/MPI et entre les 2, des tests ont été effectués. Ces tests ont été réalisés sur Uranus à nbp80 sur les noeuds Broadwell (28 procs par noeud). 1000 jours uraniens ont été simulés à chaque fois.

'''MPI:''' [[File:fig1.png]]

'''OpenMP/MPI:''' [[File:fig2.png]]

La comparaison du MPI seul et du mixte OpenMP/MPI permet de tirer la conclusion que le mixte OpenMP/MPI est beaucoup plus rapide (facteur 2.5 à 3) mais consomme plus (facteur 1.1 à 1.7).

[[File:fig3.png]]

== E) Visualizing the output files ==

=== - Comment comparer deux fichiers? file1.nc file2.nc ===

ncdiff file1.nc file2.nc output.nc

=== - Comment coller plusieurs fichiers file1.nc file2.nc file3.nc ===

ncrcat file1.nc file2.nc file3.nc output.nc

Avec juste la vitesse u et v: ncrcat -v u -v v file1.nc file2.nc file3.nc output.nc

Avec tous les fichiers fileXXX.nc disponibles ncrcat file*.nc output.nc

=== - Comment tracer les champs et divers diagnostics en moyenne zonale? ===

<ul>
<li>mettre à jour planetoplot et planets</li>
<li>utiliser precast.py dans planetoplot/examples/ppclass_additional/dynanalysis</li>
<li>changer les options au début (il y a des exemples), exemple pour Saturne
<source lang="python">fileAP="Xhistins_42.nc"
p_upper,p_lower,nlev = 4.0e2,2.5e5,40
targetp1d = np.logspace(np.log10(p_lower),np.log10(p_upper),nlev)
myp = planets.Saturn
day_per_year = 24430.
short = False
includels = False
charx = "0,360"
ispressure = False
vartemp = "temperature"
outfile = "precast.nc"
nopole = True</source></li>
<li>Il faut que apbp.txt soit présent !</li>
<li>Le résultat se trouve dans le fichier indiqué dans outfile.</li></ul>

== F) Debug ==

=== - Pour debugger ===

Réglez <code>info_level</code> à <code>100</code> dans le fichier <code>iodef.xml</code> .

=== - Erreur en début de run, SEGMENTATION FAULT dans la routine <code>advect.f90</code> (ICOSAGCM/ppsrc/transport) au niveau de l'appel à <code>cross_product2</code> ===

La routine <code>cross_product2</code> effectue des produits vectoriels. Cette erreur vient du fait qu'en essayant de faire des optimisations de calcul, le compilateur se prend "les pieds dans le tapis" et ne sait plus faire le produit vectoriel. Pour empêcher le compilateur de faire des optimisations trop poussées, il faut ajouter l'option <code>-fp-model strict</code> au niveau du mot-clé <code>%BASE_FFLAGS</code> dans tous les fichiers <code>.fcm</code> du modèle (LMDZ.COMMON / ICOSAGCM / ICOSA_LMDZ).

== G) Pas de radiatif et perturbations ==

<ul>
<li>faire descendre le modèle</li>
<li>modifier le code pour perturbations vitesse et pas température</li>
<li>compiler (voir README.md)</li>
<li>changer dans callphys.def (dans saturn/makestart)
<pre>surfalbedo = 1.0
surfemis = 0.0</pre></li>
<li>changer dans callphys.def (dans saturn '''et''' saturn/makestart)
<pre>corrk = .false.
enertest = .true.
randompert = 1</pre></li>
<li>voir si on garde le flux interne ou non (<code>intheat</code>)</li>
<li>refaire les états initiaux (dans makestart)</li>
<li>faire un run court pour voir sur les spectres l'injection d'Ek</li></ul>

== H) PROFILING with DYNAMICO-Giant ==

<code>-pg</code>: Generate extra code to write profile information suitable for analysis program <code>gprof</code>. You must use this option when compiling the sources files you want data about and you must '''also use it when linking'''. 1. For DYNAMICO-Giant: in the arch.fcm file of each part of the model (ICOSAGCM, ICOSA_LMDZ, LMDZ.COMMON and XIOS), you have to add the option <code>-pg</code> to <code>%PROD_FFLAGS</code> and <code>%BASE_LD</code> 2. Compile as usual 3. Execute your code as usual 4. Run <code>gprof</code> tool:

<pre> gprof icosa_lmdz.exe goon.out > analysis.txt</pre>

= OLD WIKI (DEPRECATED, JUST FOR REFERENCE/INFORMATION) =

``Welcome to the dynamico-giant wiki!

== pour debugger ==

régler <code>info_level</code> à <code>100</code> dans le fichier <code>iodef.xml</code>

== pourquoi diurnal=.false. ==

le temps radiatif est beaucoup plus long sur les géantes

== comment changer la fréquence d'appel à la physique? ==

il faut changer à ''deux endroits'' en réglant la même valeur - dans run_icosa.def, changer itau_physics - dans run.def, changer iphysiq ces paramètres sont exprimés en pas de temps dynamique. pour appeler la physique à chaque pas de temps dynamique, régler ces paramètres à 1

== comment changer la résolution ==

[https://github.com/aymeric-spiga/dynamico-giant/commit/f39e3b651c19cefb26da72ab77933520ff8f27f5 voir lien ici]

== comment choisir le nombre de processeurs pour la résolution ==

voir commentaires sur run_icosa.def

<pre>###########################################
## There must be less MPIxOpenMP processes than the 10 x nsplit_i x nsplit_j tiles
## typically for pure MPI runs, let nproc = 10 x nsplit_i x nsplit_j
## it is better to have nbp/split >~ 10
###########################################
#### 40 noeuds de 24 processeurs = 960 procs
nsplit_i=12
nsplit_j=8</pre>
Ehouarn: ''Une règle à suivre est de ne pas faire des tuiles "trop petites" et donc de garder nbsplit_i et nbsplit_j tels que nbp/nbsplit >=10-15 (plutôt 15). Car il y a des calculs "redondants" faits sur les bords du domaine. Or si ton domaine est 10''10, le bord du domaine c'est 38% du domaine (38 points sur le bord pour 100 points en tout) alors que si ton domaine est 15''15, le bord du domaine n'est plus que 56/(15''15) = 25.7%. 56=2''15+2''13 (pour ne pas compter 2 fois les coins). On voudrait du coup des domaine les plus grand possible, clairement, mais il faut aussi voir que chaque domaine c'est nbp''nbp colonnes à résoudre sur ce même proc... Et c'est là ou il faut expérimenter un peu pour trouver l'optimum entre le nombre total de proc à employer et le gain effectif (temps total "facturé" au vu du nombre de procs monopolisés pour une simu donnée).''

_Pour les noeuds, il faut tenir compte qu'un noeud sur Occigen, c'est 24 (ou 28) procs. Disons 24. Quand on demande N procs, le système te donne M noeuds, soit M*24 procs (les noeuds ne sont pas partagés avec d'autres applications). Et bien sûr on te facturera ces M noeuds, même si tu n'utilises pas tous les procs. Donc il faut s'efforcer de tomber juste et demander un multiple de 24 procs. Même raisonement si tu demandes à utiliser des noeuds de 28 procs._

== comment changer la rotation? ==

dans saturn_const.def, changer le taux de rotation jamais testé avec 0, mais pourrait créer des problèmes (ex: beta) ''vérifier que omega dans saturn_const.def n'intervient pas dans la physique LMDZ.GENERIC/libf/phygeneric/''

== la dissipation c'est où? ==

laplacien itéré: hyperviscosity - tau_graddiv,tau_gradrot,tau_divgrad: periode (plus c'est petit, plus la dissipation est efficace) - nitergdiv,nitergrot,niterdivgrad: ordre du laplacien (plus c'est grand, plus on dissipe sélectivement les petites échelles)

== comment changer la grille cible du remapping on-the-fly ==

dans context_lmdz_physics.xml changer les paramètres ni_glo et nj_glo par exemple pour remapper sur du lat/lon à 360 pts en latitude et 720 pts en longitude (0.5°) <domain id="dom_regular" ni_glo="720" nj_glo="360" type="rectilinear">

== Forcer XIOS à écrire tous les .... ==

Il faut utiliser l'attribut (ici par ex pour forcer l'écriture tous les ts (==time step) ; d'autres délais doivent être possible): <code>sync_freq="1ts"</code> dans le <code><file id=... .... ></code> concerné.

== comment changer le bottom du modele ==

* refaire tourner le 1D
** changer la pression <code>psurf</code> dans run.def
** changer <code>ichoice=1</code> et changer <code>tref</code> (ex: 10b: 330K)
* refaire tourner le 3D (avec makestart) en changeant <code>preff</code> dans <code>saturn_const.def</code>

== comment changer la fréquence de sortie des Xhistins.nc ==

les commandes XIOS sont appelées depuis la physique (dans la config présente) dans context_lmdz_physics.xml il suffit de changer output_freq ''attention'' ts se comprend comme le pas de temps physique (voir donc dans run_icosa.def les paramètres dt et itau_physics pour le connaître) par exemple, pour des sorties tous les 20 jours Saturne

<source lang="xml"><file id="histins"
name="Xhistins"
output_freq="40ts"
type="one_file"
enabled=".true."></source>
== pas de radiatif et perturbations ==

<ul>
<li>faire descendre le modèle</li>
<li>modifier le code pour perturbations vitesse et pas température</li>
<li>compiler (voir README.md)</li>
<li>changer dans callphys.def (dans saturn/makestart)
<pre>surfalbedo = 1.0
surfemis = 0.0</pre></li>
<li>changer dans callphys.def (dans saturn '''et''' saturn/makestart)
<pre>corrk = .false.
enertest = .true.
randompert = 1</pre></li>
<li>voir si on garde le flux interne ou non (<code>intheat</code>)</li>
<li>refaire les états initiaux (dans makestart)</li>
<li>faire un run court pour voir sur les spectres l'injection d'Ek</li></ul>

== comment comparer deux fichiers? file1.nc file2.nc ==

ncdiff file1.nc file2.nc output.nc

== comment coller plusieurs fichiers file1.nc file2.nc file3.nc ==

ncrcat file1.nc file2.nc file3.nc output.nc avec juste la vitesse u et v ncrcat -v u -v v file1.nc file2.nc file3.nc output.nc avec tous les fichiers fileXXX.nc disponibles ncrcat file*.nc output.nc

== comment tracer les champs et divers diagnostics en moyenne zonale? ==

<ul>
<li>mettre à jour planetoplot et planets</li>
<li>utiliser precast.py dans planetoplot/examples/ppclass_additional/dynanalysis</li>
<li>changer les options au début (il y a des exemples), exemple pour Saturne
<source lang="python">fileAP="Xhistins_42.nc"
p_upper,p_lower,nlev = 4.0e2,2.5e5,40
targetp1d = np.logspace(np.log10(p_lower),np.log10(p_upper),nlev)
myp = planets.Saturn
day_per_year = 24430.
short = False
includels = False
charx = "0,360"
ispressure = False
vartemp = "temperature"
outfile = "precast.nc"
nopole = True</source></li>
<li>Il faut que apbp.txt soit présent !</li>
<li>le résultat se trouve dans le fichier indiqué dans outfile</li></ul>

== bilan de moment cinétique ==

dans run_icosa.def

<pre>check_conservation = detailed
itau_check_conserv = 160</pre>
le itau_check_conserv est comme itau_physics pour que la contribution de la physique à AAM ne soit pas nulle. de plus il est coûteux d'appeler les diagnostics trop souvent.

S. Lebonnois, C. Covey, A. Grossman, H. Parish, G. Schubert, R. Walterscheid, P. Lauritzen, and C. Jablonowski. Angular momentum budget in General Circulation Models of superrotating atmospheres: A critical diagnostic. Journal of Geophysical Research (Planets), 117:E12004, 2012.

P. H. Lauritzen, J. T. Bacmeister, T. Dubos, S. Lebonnois, and M. A. Taylor. Held-Suarez simulations with the Community Atmosphere Model Spectral Element (CAM-SE) dynamical core: A global axial angular momentum analysis using Eulerian and floating Lagrangian vertical coordinates. Journal of Advances in Modeling Earth Systems, 6:129-140, 2014.

== XIOS server ou client ==

# XIOS client <code>use_server=False</code> Broadwell 24 processeurs sur 28
# XIOS server <code>use_server=true</code> Broadwell 24 processurs sur 28 + 4 processeurs pour XIOS

cas 1 est 3 min plus lent que cas 2 -- sur 2h20...! parce qu'on fait peu de sorties

== Optimisation ==

# 40 noeuds au lieu de 50 noeuds, même temps de calcul...! Testé dans la branche https://github.com/aymeric-spiga/dynamico-giant/tree/work_61levels
# <code>sync_freq=40ts</code> (ou multiple de, si 40ts est la fréquence d'écriture) dans context_lmdz_physics.xml doit être inclus sinon il n'est pas réglé et XIOS transfère tout à la fin du run ce qui prend du temps (et peut occasionner des problèmes de mémoire)

== Versions fonctionnelles de dynamico-giant ==

=== Jupiter ===

* XIOS revision 1583 

* ICOSAGCM revision 756 

* IOIPSL revision 339 

* FCM_V1.2 revision 12 

* Physics revision 2228 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

but check Physics version 2142 and 2180

=== Saturne (référence Spiga 2020, à vérifier) ===

* DYNAMICO --> Revision: 756
* PHYSICS --> Revision: 2005
* XIOS --> Revision: 1583
* IOIPSL --> Revision: 310?

=== Saturne (simulation de référence sur 61 niveaux, Bardet et al. Icarus 2021) ===

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 310 

* FCM_V1.2 revision 12 

* Physics revision 2005 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

=== Saturne (simulation avec la GWD paramétrisation sur 61 niveaux, chapitre 6 PhD Bardet) ===

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 310 

* FCM_V1.2 revision 12 

* Physics revision 2213 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

=== Saturne (simulation sur 96 niveaux, Bardet et al. Nature Astronomy 2022) ===

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 431 

* FCM_V1.2 revision 12 

* Physics revision 2305 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

=== Saturne (simulation avec la GWD paramétrisation sur 96 niveaux, chapitre 6 PhD Bardet) ===

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 431 

* FCM_V1.2 revision 12 

* Physics revision 2403 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

=== Uranus & Neptune (old version) ===

* XIOS revision 1944
* ICOSAGCM revision 765
* IOIPSL revision 431
* FCM_V1.2 revision 12 

* Physics revision 2413 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

=== Uranus & Neptune (new version) ===

* XIOS revision 2203
* ICOSAGCM revision (20/08/2021)
* IOIPSL revision 450
* FCM_V1.2 revision 12 

* Physics revision 2555 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

works on 03/03/2022 for all HEAD

== Les fichiers d'architecture (Installation sur un nouveau cluster) ==

En pratique LMDZ.COMMON, ICOSA_LMDZ et IOIPSL peuvent utiliser exactement le même fichier arch.fcm ; mais celui pour ICOSAGCM est légèrement différent (les %FPP_DEF diffèrent, peut-être aussi le %FPP).

make_icosa_lmdz doit être lancé avec -arch_path ../ARCH puisque les arch.env et arch.path communs se trouvent dans ../ARCH (l'option -arch_path ne concerne d'ailleurs que les fichiers arch.env et arch.path; le fichier arch.fcm recherché sera toujours celui dans le "arch" de chacun des modèles. Donc il faut bien mettre pour chacun des quatre modèles (LMDZ.COMMON, ICOSA_LMDZ,IOIPSL et ICOSAGCM) le arch.fcm dans le sous-dossier arch/ du modèle correspondant.

XIOS est écrit en C++, et pas en Fortran. Le fichier arch.fcm correspondant est donc nécessairement différent de celui des quatre autres modèles. Pour créér ce arch.fcm, prendre exemple sur les fichiers .fcm déjà présent dans XIOS/arch/, avec une architecture similaire à celle du nouveau cluster. En particulier, il faut utiliser des versions de gcc/gfortran > 6+. Il faut absolument avoir une bibliothèque HDF5 compilée en parallèle, ainsi que netcdf-C et netcdf-fortran (et peut être aussi netcdf-Cxx) compilé en parallèle. Sans ça, il sera peut-être possible de compiler le modèle, mais pas de lancer une simulation en utilisant XIOS.

== Commencer une nouvelle simulation en utilisant le schéma des panaches thermiques ==

# Comme pour toutes nouvelles simulations, il faut commencer par un run 1D de plusieurs décennies permettant d'obtenir un profil de température (<code>temp_profile.txt</code>) et les coefficients ap et bp (<code>apbp.txt</code>) en équilibre radiatif-convectif pour la planète que l'on étudie. Ce run 1D s'effectue dans les dossiers jupiter1d, saturn1d, neptune1d et/ou uranus1d, avec ces options pour le callphys.def :

callrad = true calladj = true tous les autres mots clés à false (y compris <code>calltherm</code>).

<ol start="2" style="list-style-type: decimal;">
<li>Faire un "makestart" run : permet d'obtenir les fichiers restart à partir du profil de température initial. Il s'agit du run dont l'état initial est le profil de température créé par run 1D (<code>temp_profile.txt</code> est appliquer à chaque point de grille horizontale du modèle). L'état initial est ainsi une planète isotherme horizontalement mais qui varie verticalement. Pour ce run, aucun traceur ne va être utilisé dans le modèle. Néanmoins, il faut renseigner au modèle le nombre de traceurs que nous souhaitons utiliser avec le schéma des panaches thermiques afin qu'il puisse créer la dimension nq et le champ q dans les fichiers <code>restart_icosa.nc</code> et <code>restartfi.nc</code>. dans '''callphys.def''' :
<pre> traceur = true</pre>
dans '''run_icosa.def''' : <code>nqtot = 2</code> (par exemple, h2o_vap et h2o_ice) dans '''traceur.def''' :
<pre> 2
h2o_vap
h2o_ice</pre></li>
<li>Ajout des quantités pour chaque traceur. Ici, nous ajoutons les profils pour chacun des traceurs dans les fichiers <code>restart_icosa.nc</code> et <code>restartfi.nc</code> "à la main" en utilisant le programme python <code>/processing_codes/tracer_settings.py</code> pour obtenir des fichiers restart avec la bonne abondance d'eau dans le cas présent.</li>
<li>Commencer la simulation : Il ne reste plus qu'à lancer la simulation 3D avec les nouveaux fichiers restart et les réglages suivant : dans '''callphys.def''' :
<pre> traceur = true
calltherm = true
# thermal plume model options:
divmpl = true
r_aspect_thermals = 2.0
tau_thermals = 0.0
betalpha = 0.9
afact = 0.7
fact_epsilon = 2.e-4
alpha_max = 0.7
fomass_max = 0.5
pres_limit = 2.e5
water = true
watercond = true
waterain = true
evap_prec = true</pre></li></ol>

dans '''run_icosa.def''' : <code>nqtot = 2</code> dans '''traceur.def''' :

<pre> 2
h2o_vap
h2o_ice</pre>
Enfin, ajouter la déclaration et l'écriture des variables relatives à l'utilisation du schéma des thermiques (<code>h2o_vap</code>, <code>h2o_ice</code>, <code>w_plm</code>) dans les fichiers XML de la physique.

== Erreur en début de run, SEGMENTATION FAULT dans la routine <code>advect.f90</code> (ICOSAGCM/ppsrc/transport) au niveau de l'appel à <code>cross_product2</code>. ==

La routine <code>cross_product2</code> effectue des produits vectoriels. Cette erreur vient du fait qu'en essayant de faire des optimisations de calcul, le compilateur se prend "les pieds dans le tapis" et ne sait plus faire le produit vectoriel. Pour empêcher le compilateur de faire des optimisations trop poussées, il faut ajouter l'option <code>-fp-model strict</code> au niveau du mot-clé <code>%BASE_FFLAGS</code> dans tous les fichiers <code>.fcm</code> du modèle (LMDZ.COMMON / ICOSAGCM / ICOSA_LMDZ)

== Branche master version du 04/04/2022 dans le dossier Jupiter ==

La version actuelle des fichiers de réglage dans le dossier Jupiter sont réglés pour utiliser des traceurs. Si vous souhaiter utiliser le modèle sans traceur, il vous faut modifier les fichiers suivants :

run_icosa.def

<pre> nqtot = 0</pre>
traceur.def

<pre> 0</pre>
context_dynamico.xml (ligne 125)

<pre> <field id="q_start" name="q" grid_ref="grid_q_start" prec="8"/> </pre>
== PROFILING with DYNAMICO-Giant: ==

<code>-pg</code>: Generate extra code to write profile information suitable for analysis program <code>gprof</code>. You must use this option when compiling the sources files you want data about and you must '''also use it when linking'''. 1. For DYNAMICO-Giant: in the arch.fcm file of each part of the model (ICOSAGCM, ICOSA_LMDZ, LMDZ.COMMON and XIOS), you have to add the option <code>-pg</code> to <code>%PROD_FFLAGS</code> and <code>%BASE_LD</code> 2. Compile as usual 3. Execute your code as usual 4. Run <code>gprof</code> tool:

<pre> gprof icosa_lmdz.exe goon.out > analysis.txt</pre>

[[Category:DYNAMICO]]
[[Category:Generic-DYNAMICO]]

Dynamico-giant

2026-06-12T13:30:37Z

Jbclement: /* H) Bottom du modèle */

[transferred from github, now active here]

= 1. Introduction =

Modeling the atmospheric circulation of giant planets of our solar System (Jupiter, Saturn, Uranus and Neptune) require high horizontal resolution grid: typically, half a degree (in latitude, longitude) for Jupiter and Saturn, and one degree for Uranus and Neptune.
For this reason, GCM runs for giant planets use the DYNAMICO dynamical core (see [[The_DYNAMICO_dynamical_core|Dynamico]]), coupled to the Generic physics (see [[Overview_of_the_Generic_PCM|Generic-PCM]]).

= 2. Installation =

== A) Fichiers d'architecture ==

=== - Modules ===

Two options:

1/ Before installation, set environment (do it once) in your .bash_profile.

Example for Ciclad:

<pre>ulimit -s unlimited
# modules
module purge
module load gnu/4.9.3
module load intel/15.0.6.233
module load openmpi/1.6.5-ifort
module load hdf5/1.8.18-parallel-ifort
module load netcdf4/4.4.1.1-parallel-ifort</pre>
Beware, if you change version of model (newer or older version), it's possible that you have to change modules...

2/ Or, in your script that launches a job, source a .env file (' source .../dynamico-giant/code/ARCH/arch-ADASTRA-gnu.env ')

=== - Installation sur un nouveau cluster ===

En pratique LMDZ.COMMON, ICOSA_LMDZ et IOIPSL peuvent utiliser exactement le même fichier arch.fcm ; mais celui pour ICOSAGCM est légèrement différent (les %FPP_DEF diffèrent, peut-être aussi le %FPP).

make_icosa_lmdz doit être lancé avec -arch_path ../ARCH puisque les arch.env et arch.path communs se trouvent dans ../ARCH (l'option -arch_path ne concerne d'ailleurs que les fichiers arch.env et arch.path; le fichier arch.fcm recherché sera toujours celui dans le "arch" de chacun des modèles. Donc il faut bien mettre pour chacun des quatre modèles (LMDZ.COMMON, ICOSA_LMDZ,IOIPSL et ICOSAGCM) le arch.fcm dans le sous-dossier arch/ du modèle correspondant.

L'installation d'IOIPSL doit se faire à partir du bon script bash. Si vous utilisez un server autre qu'occigen, il vous faut changer le nom du script à utiliser dans install_ioipsl.sh. Par exemple, il vous faudra utiliser install_ioipsl_ciclad-ifort.bash pour CICLAD.

XIOS est écrit en C++, et pas en Fortran. Le fichier arch.fcm correspondant est donc nécessairement différent de celui des quatre autres modèles. Pour créér ce arch.fcm, prendre exemple sur les fichiers .fcm déjà présent dans XIOS/arch/, avec une architecture similaire à celle du nouveau cluster. En particulier, il faut utiliser des versions de gcc/gfortran > 6+. Il faut absolument avoir une bibliothèque HDF5 compilée en parallèle, ainsi que netcdf-C et netcdf-fortran (et peut être aussi netcdf-Cxx) compilé en parallèle. Sans ça, il sera peut-être possible de compiler le modèle, mais pas de lancer une simulation en utilisant XIOS.

== B. Download ==

Download structure

Take place on a repository and git clone the model.

On occigen:

<pre>cd $SCRATCHDIR
git clone https://github.com/aymeric-spiga/dynamico-giant.git [optional different name]</pre>
== C. Install ==

Install code

<pre>cd dynamico-giant
./install.sh
./install_ioipsl.sh</pre>
A login and a password are necessary to install IOIPSL (only for the first time, after that we can save them). Please contact TGCC computing center to get the login/password.

After that, please add "$PWD"/FCM_V1.2/bin/ to PATH environment variable.

Ant that's all, we can now change parameters of files or compile the code to do a test (part 6) or eat a beautiful tartiflette (can be also do during compilation).

= 3. General parameters =

== A) Mesh grid & resolution ==

On run_icosa.def:

<pre>nbp --> number of subdivision on a main triangle: integer (default=40)
nbp = sqrt((nbr_lat x nbr_lon)/10)
nbp 20 40 80 160
T-edge length (km) 500 250 120 60
Example: nbp(128x96)=35 -> 40
nbp(256x192)=70 -> 80
nbp(360x720)=160 -> 160
nsplit_i, nsplit_j --> sub splitting of main rhombus: integer
Example: for nbp=80, nsplit_i=4,nsplit_j=6
nbp/nsplit_{i,j} = 20 > 10 & 13 > 10 --> GOOD</pre>
=== - Remapping ===

Pour le remapping, il faut aller dans context_lmdz_physics.xml changer les paramètres ni_glo et nj_glo par exemple pour remapper sur du lat/lon à 360 pts en latitude et 720 pts en longitude (0.5°).

<code><domain id="dom_regular" ni_glo="720" nj_glo="360" type="rectilinear"></code>

== B) Time ==

* ndays is number of days to simulate.
* day_step is number of dynamical time step per day
* Dynamics called every day_length(in s) / day_step per day
* 1 ts (physical timestep) = (day_length(in s)/day_step) x itau_physics
* Physics called (day_step / itau_physics) per day
* Physics called day_length(in s) / ts per day
* Radiative called every Physics x iradia physical timestep
* Radiative called every iradia/Physics days

== C) Sponge layer ==

<pre>iflag_sponge=0 for no sponge (default)
iflag_sponge=1 for sponge over 4 topmost layers
iflag_sponge=2 for sponge from top to ~1% of top layer pressure
mode_sponge=1 for u,v --> 0
mode_sponge=2 for u,v --> zonal mean
mode_sponge=3 for u,v,h --> zonal mean
tau_sponge --> damping frequency at last layer
--> e-5 medium / e-4 strong yet reasonable / e-3 very strong</pre>
Spiga et al (2020): Shaw and Shepherd (2007) showed that the inclusion of sponge-layer parameterizations that do not conserve angular momentum (which is the case for Rayleigh drag), or allow for momentum to escape to space, implies a sensitivity of the dynamical results (especially zonal wind speed) to the choice for model top or drag characteristic timescale, because of spurious downward influence when momentum conservation is violated.

Il ne faut donc pas ajouter de sponge layer pour les planètes géantes (iflag_sponge = 0)

== D) Dissipation ==

Spiga et al (2020): A subgrid-scale dissipation term is included in our Saturn DYNAMICO GCM to prevent the accumulation of energy at scales close to the grid resolution, caused by the GCM not resolving the turbulent scales at which this energy is dissipated. This hyperviscosity term is written in our Saturn DYNAMICO model as an iterated Laplacian term on a given variable. The three variables denoted are vorticity, divergence, and potential temperature, chosen to set horizontal dissipation on respectively the rotational component of the flow (e.g. Rossby waves), the divergent component of the flow (e.g. gravity waves), and the diabatic perturbations (e.g. coming from the physical packages).

<pre>tau_graddiv --> dissipation timescale of smallest wvl: u,v (gradiv) : real (default=5000)
tau_gradrot --> dissipation timescale of smallest wvl: u,v (nxgradrot) : real (default=5000)
tau_divgrad --> dissipation timescale of smallest wvl: h (divgrad) : real (default=5000)
nitergdiv --> number of iterations for gradiv operator : integer (default=1)
nitergrot --> number of iterations for nxgradrot operator : integer (default=1)
niterdivgrad --> number of iterations for divgrad operator : integer (default=1)</pre>
tau_graddiv,tau_gradrot,tau_divgrad correspondent au temps de dissipation (plus c'est petit, plus la dissipation est efficace). nitergdiv,nitergrot,niterdivgrad correspondent à l'ordre du laplacien (plus c'est grand, plus on dissipe sélectivement les petites échelles).

Attention, Trop dissiper -> instabilité numérique

Pas assez dissiper -> instabilité dynamique trop forte

L'ordre du laplacien dans les fichiers .def est suffisant. S'il faut changer la dissipation, il vaut mieux changer les temps de dissipation que l'ordre du laplacien (risque d'instabilité numérique).

=== - Facteurs de dissipation ===

A partir de ces valeurs de temps de dissipation, il est également possible d'ajouter 2 facteurs de dissipation (fac_mid et fac_up) qui permettent d'augmenter la dissipation à partir de certains niveaux. Le fac_mid permet de diminuer le temps de dissipation d'un facteur sur toute l'atmosphère jusqu'au bottom. Il y a une zone transition de quelques niveaux entre le bottom (le temp de dissipation au bottom est sans facteur) et quelques niveaux au-dessus où la valeur du temps de dissipation est avec ce facteur jusqu'au top. On ne peut donc pas choisir l'altitude et la zone de transition avec ce facteur. Quant au fac_up, il permet de diminuer le temps de dissipation d'un facteur à partir d'une altitude et d'une épaisseur de zone de transition qu'on peut choisir. On peut utiliser la combinaison des 2 ou l'un des 2. Pour ne pas prendre en compte ces facteurs de dissipation, il faut qu'il soit mis à 1.

Il existe 2 modes possibles pour le fac_up: le mode martien (en fonction de l'altitude) et le mode vénusien (en fonction de la pression). Dans le 1er cas, il faut renseigner l'altitude où démarre la zone de transition et l'épaisseur de cette zone. Dans le 2ème cas, il faut renseigner la pression où démarre la zone de transition et l'échelle de hauteur de cette zone de transition.

Il est vivement conseillé de tracer votre profil de dissipation à partir des équations (dans vert_prof_dissip_icosa_lmdz.f90) afin d'être certain de leur allure.

== E) Rayleigh Friction ==

Spiga et al 2020: This drag plays the role devoted to surface friction on terrestrial planets, which allows to close the angular momentum budget through downward control (Haynes and McIntyre, 1987; Haynes et al., 1991). This could also be regarded as a zeroth-order parameterization for Magneto-HydroDynamic (MHD) drag as a result of Lorenz forces acting on jet streams putatively extending to the depths of Saturn's interior (Liu et al., 2008; Galanti et al., 2019), much deeper than the shallow GCM's model bottom.

Comme Liu and Schneider (2010), cette couche de frottement ne s'exerce pas aux régions équatoriales car à l’extérieur du cylindre tangeant du rayon équatorial, les cylindres convectifs ne coupent pas cette couche et ne subissent pas les frottements liés aux effets de la MHD.

Le paramètre rayleigh_limlat correspond à la latitude maximale de part et d'autre de l'équateur où cette friction n'est pas observée.

Pour le temps (rayleigh_friction_tau), il est similaire à celui utilisé par Liu and Schneider (2010). Elle est fixée à 100 jours terrestres. Mais attention, on fonction de la valeur, la dynamique peut évoluer dans votre simulation.

== F) Conservation ==

Dans run_icosa.def:

<pre>check_conservation = detailed
itau_check_conserv = 320</pre>
Le itau_check_conserv est comme itau_physics pour que la contribution de la physique à AAM ne soit pas nulle. de plus il est coûteux d'appeler les diagnostics trop souvent.

S. Lebonnois, C. Covey, A. Grossman, H. Parish, G. Schubert, R. Walterscheid, P. Lauritzen, and C. Jablonowski. Angular momentum budget in General Circulation Models of superrotating atmospheres: A critical diagnostic. Journal of Geophysical Research (Planets), 117:E12004, 2012.

P. H. Lauritzen, J. T. Bacmeister, T. Dubos, S. Lebonnois, and M. A. Taylor. Held-Suarez simulations with the Community Atmosphere Model Spectral Element (CAM-SE) dynamical core: A global axial angular momentum analysis using Eulerian and floating Lagrangian vertical coordinates. Journal of Advances in Modeling Earth Systems, 6:129-140, 2014.

== G) Traceur ==

=== - Branche master version du 04/04/2022 dans le dossier Jupiter (traceur) ===

La version actuelle des fichiers de réglage dans le dossier Jupiter est réglée pour utiliser des traceurs. Si vous souhaiter utiliser le modèle sans traceur, il vous faut modifier les fichiers suivants :

run_icosa.def

<pre> nqtot = 0</pre>
traceur.def

<pre> 0</pre>
context_dynamico.xml (ligne 125)

<pre> <field id="q_start" name="q" grid_ref="grid_q_start" prec="8"/> </pre>
== H) Bottom du modèle ==

* refaire tourner le 1D
** changer la pression <code>psurf</code> dans run.def
** changer <code>ichoice=1</code> et changer <code>tref</code> (ex: 10b: 330K)
* refaire tourner le 3D (avec makestart) en changeant <code>preff</code> dans <code>[nom_de_la_planète]_const.def</code>

= 4. Physical parameterizations =

== A) Cycle diurne ==

<code>diurnal = .false.</code> Car le temps radiatif est beaucoup plus long sur les planètes géantes.

== B) Anneaux ==

[Pour saturne uniquement] Il est possible d'ajouter l'ombre des anneaux dans le callphys.def:

<code>rings_shadow = .true.</code>

== C) Collision-induced absorption data ==

L'absorption induite par collision est importante dans le transfet radiatif sur les planètes géantes, notamment celle provenant de H2. Cependant, le rapport ortho-para du H2 est différent selon les planètes et peut modifier fortement le chauffage sur ces planètes. Pour le cas des géantes gazeuses, le rapport ortho-para est normal (rapport 3:1). Mais pour le cas des géantes glacées, le rapport ortho-para est à l'équilibre. Par défaut, le rapport ortho-para est normal (H2orthopara_mixture = normal). Pour les géantes glacées, il faut mettre H2orthopara_mixture = equilibrium .

Si vous voulez modifier le fichier utilisé dans un cas de CIA, il faut aller dans le code (dynamico-giant/code/LMDZ.GENERIC/libf/phygeneric/interpolate????.F90) et changer le nom du fichier (assurez-vous que ce fichier soit dans votre répertoire DATAGENERIC/continuum_data).

Dans la version actuelle, il n'existe pas d'option qui permet de ne pas utiliser certaines contributions de CIA. Par exemple, si votre atmosphère est composé de H2, He et CH4 et que vous ne voulez pas des contributions venant du CH4, il vous faut commenter dans le modèle ces contributions.

== D) K-correlated data ==

Les fichiers k-corrélées doivent se situer dans votre répertoire DATAGENERIC/corrk_data .

== E) Cpp mode ==

cpp_mugaz_mode=0 pour que la valeur de cpp et de mugaz proviennent de la dynamique. cpp_mugaz_mode=1 pour forcer la valeur de cpp et de mugaz dans le callphys.def (à utiliser dans le makestart uniquement) cpp_mugaz_mode=2 pour calculer automatiquement à partir de données de références à 300 K et du gases.def (à éviter)

== F) Generic n-layer aerosols (replaces the former 2-layer and NH3 cloud) ==

Ce mode permet de créer des couches d'aérosols/nuages ayant une opacité (aeronlay_tauref) à une longueur d'onde donnée (aeronlay_lamref), un rayon de particule fixe (aeronlay_size) situés à une pression fixe et en fonction des propriétés optiques des particules (optprop_aeronlay_vis et optprop_aeronlay_ir). Pour le cas de l'altitude, on peut choisir soit (aeronlay_choice = 1) une pression max (aeronlay_ptop) et une pression min (aeronlay_pbot), soit (aeronlay_choice = 2) une pression min (aeronlay_pbot) et une échelle de hauteur (aeronlay_sclhght). On peut également choisir la variance effective pour les rayons de particules.

Le nombre de couche de nuage (nlayero) est égal au nombre de scatterers dans la compilation (option -s ).

Les fichiers de propriétés optiques doivent être dans votre DATAGENERIC.

Un exemple pour 3 couches:

<pre>aeronlay = .true.
nlayaero = 3
aeronlay_tauref = 2.5 0.04 0.1
aeronlay_lamref = 0.8e-6 0.8e-6 0.16e-6
aeronlay_choice = 2 2 1
aeronlay_pbot = 1.5e5 1.6e5 20.
aeronlay_ptop = 1.1e5 1. 1.
aeronlay_sclhght = 0.1 2.0 1
aeronlay_size = 0.5e-6 0.05e-6 0.5e-6
aeronlay_nueff = 0.3 0.3 0.3
optprop_aeronlay_vis = optprop_aerosol2_vis.dat optprop_aerosol3_vis.dat optprop_carbon4_vis.dat
optprop_aeronlay_ir = optprop_aerosol2_ir.dat optprop_aerosol3_ir.dat optprop_carbon4_ir.dat</pre>
== G) Panaches thermiques ==

# Comme pour toutes nouvelles simulations, il faut commencer par un run 1D de plusieurs décennies permettant d'obtenir un profil de température (<code>temp_profile.txt</code>) et les coefficients ap et bp (<code>apbp.txt</code>) en équilibre radiatif-convectif pour la planète que l'on étudie. Ce run 1D s'effectue dans les dossiers jupiter1d, saturn1d, neptune1d et/ou uranus1d, avec ces options pour le callphys.def :

callrad = true calladj = true tous les autres mots clés à false (y compris <code>calltherm</code>).

<ol start="2" style="list-style-type: decimal;">
<li>Faire un "makestart" run : permet d'obtenir les fichiers restart à partir du profil de température initial. Il s'agit du run dont l'état initial est le profil de température créé par run 1D (<code>temp_profile.txt</code> est appliquer à chaque point de grille horizontale du modèle). L'état initial est ainsi une planète isotherme horizontalement mais qui varie verticalement. Pour ce run, aucun traceur ne va être utilisé dans le modèle. Néanmoins, il faut renseigner au modèle le nombre de traceurs que nous souhaitons utiliser avec le schéma des panaches thermiques afin qu'il puisse créer la dimension nq et le champ q dans les fichiers <code>restart_icosa.nc</code> et <code>restartfi.nc</code>. dans '''callphys.def''' :
<pre> traceur = true</pre>
dans '''run_icosa.def''' : <code>nqtot = 2</code> (par exemple, h2o_vap et h2o_ice) dans '''traceur.def''' :
<pre> 2
h2o_vap
h2o_ice</pre></li>
<li>Ajout des quantités pour chaque traceur. Ici, nous ajoutons les profils pour chacun des traceurs dans les fichiers <code>restart_icosa.nc</code> et <code>restartfi.nc</code> "à la main" en utilisant le programme python <code>/processing_codes/tracer_settings.py</code> pour obtenir des fichiers restart avec la bonne abondance d'eau dans le cas présent.</li>
<li>Commencer la simulation : Il ne reste plus qu'à lancer la simulation 3D avec les nouveaux fichiers restart et les réglages suivant : dans '''callphys.def''' :
<pre> traceur = true
calltherm = true
# thermal plume model options:
divmpl = true
r_aspect_thermals = 2.0
tau_thermals = 0.0
betalpha = 0.9
afact = 0.7
fact_epsilon = 2.e-4
alpha_max = 0.7
fomass_max = 0.5
pres_limit = 2.e5
water = true
watercond = true
waterain = true
evap_prec = true</pre></li></ol>

dans '''run_icosa.def''' : <code>nqtot = 2</code> dans '''traceur.def''' :

<pre> 2
h2o_vap
h2o_ice</pre>
Enfin, ajouter la déclaration et l'écriture des variables relatives à l'utilisation du schéma des thermiques (<code>h2o_vap</code>, <code>h2o_ice</code>, <code>w_plm</code>) dans les fichiers XML de la physique.

== H) Rotation ==

Dans [name_of_planet]_const.def, changer le taux de rotation.

Cela n'a jamais été testé avec 0, mais cela pourrait créer des problèmes (ex: beta). ''vérifier que omega dans saturn_const.def n'intervient pas dans la physique LMDZ.GENERIC/libf/phygeneric/''

== I) Appel à la physique ==

Il faut changer à ''deux endroits'' en réglant la même valeur: - dans run_icosa.def, changer itau_physics ; - dans run.def, changer iphysiq. Ces paramètres sont exprimés en pas de temps dynamique. Pour appeler la physique à chaque pas de temps dynamique, régler ces paramètres à 1.

'''Attention: ''' Lorsque l'on change dans le ''run_icosa.def'' la valeur de itau_physics, faire bien attention à la valeur du champ itau_adv (qui controle la frequence d'advection des traceurs par la dynamique, compté en pas de temps dynamique). Il faut que itau_physics soit un multiple de itau_adv. Cela veut dire, que l'on advecte notre champ de traceurs plus souvent (ou autant de fois) que l'on appelle la physique, qui peut transformer ces traceurs.

= 5. Ecriture des fichiers =

== A) Nombre d'écriture dans chaque Xhistins.nc ==

Prenons l'exemple de l'écriture d'un fichier sur une simu Uranus pour 1000j

Nombre d'écriture = day_step X ndays/(itau_physics X output_freq)

* ndays = 1000
* day_step = 200
* itau_physics = 50
* output_freq = 200

On a 20 sorties tous les 1000 jours.

Globalement, il est conseillé d'avoir 800 à 1000 sorties minimum par année planétaire (voir beaucoup plus en fonction de votre étude).

== B) Ajouter une variable ==

Pour ajouter une variable dans le fichier de sortie Xhistins.nc, il faut l'ajouter dans le field_group correspondant et s'assurer que cette variable est présente en tant que variable de sortie dans dynamico-giant/code/LMDZ.GENERIC/libf/phygeneric/physiq_mod.F90. Si ce n'est pas le cas, il faut faire un call writediagfi de la variable puis l'ajouter dans un call send_xios_field.

== C) Forcer XIOS à écrire tous les .... ==

Il faut utiliser l'attribut (ici par ex pour forcer l'écriture tous les ts (==time step) ; d'autres délais doivent être possible): <code>sync_freq="1ts"</code> dans le <code><file id=... .... ></code> concerné.

== D) XIOS server ou client ==

# XIOS client <code>use_server=False</code> Broadwell 24 processeurs sur 28
# XIOS server <code>use_server=true</code> Broadwell 24 processurs sur 28 + 4 processeurs pour XIOS

Le cas 1 est 3 min plus lent que le cas 2 -- sur 2h20...(!) parce qu'on fait peu de sorties.

= 6. Running the model =

== A) Compilation ==

Pour compiler le modèle, il suffit d'aller dans le dossier avec vos fichiers .def et .xml et d'utiliser le script compile_occigen.sh si on est sur occigen ou compile_ciclad.sh si on est sur ciclad

<code>./compile_occigen.sh</code>

Les options qui peuvent être modifiées/ajoutées sont - -s : le nombre de scatterers - -parallel: mpi ou mpi_omp - -arch: le nom du ficher d'architecture - -arch_path: le chemin vers ce fichier - -job: 8 (conseillé) - -full: compile le code entièrement - -debug: pour trouver un éventuel bug. A ENLEVER obligatoirement s'il n'y a plus de bug car multiplie par 5 votre temp de calcul.

En 1D, d'autres options sont nécessaires: - -t: nombre de traceurs - -d: nombre de niveaux verticaux - -parallel: none (en 1D uniquement)

=== - Versions fonctionnelles de dynamico-giant ===

'''Jupiter''' - XIOS revision 1583 
- ICOSAGCM revision 756 
- IOIPSL revision 339 
- FCM_V1.2 revision 12 
- Physics revision 2228 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

but check Physics version 2142 and 2180

'''Saturne (référence Spiga 2020, à vérifier)''' - DYNAMICO --> Revision: 756 - PHYSICS --> Revision: 2005 - XIOS --> Revision: 1583 - IOIPSL --> Revision: 310?

'''Saturne (simulation de référence sur 61 niveaux, Bardet et al. Icarus 2021)''' - XIOS revision 1583 
- ICOSAGCM revision 765 
- IOIPSL revision 310 
- FCM_V1.2 revision 12 
- Physics revision 2005 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Saturne (simulation avec la GWD paramétrisation sur 61 niveaux, chapitre 6 PhD Bardet)''' - XIOS revision 1583 
- ICOSAGCM revision 765 
- IOIPSL revision 310 
- FCM_V1.2 revision 12 
- Physics revision 2213 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Saturne (simulation sur 96 niveaux, Bardet et al. Nature Astronomy 2022)''' - XIOS revision 1583 
- ICOSAGCM revision 765 
- IOIPSL revision 431 
- FCM_V1.2 revision 12 
- Physics revision 2305 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Saturne (simulation avec la GWD paramétrisation sur 96 niveaux, chapitre 6 PhD Bardet)''' - XIOS revision 1583 
- ICOSAGCM revision 765 
- IOIPSL revision 431 
- FCM_V1.2 revision 12 
- Physics revision 2403 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Uranus & Neptune (old version)''' - XIOS revision 1944 - ICOSAGCM revision 765 - IOIPSL revision 431 - FCM_V1.2 revision 12 
- Physics revision 2413 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Uranus & Neptune (new version)''' - XIOS revision 2203 - ICOSAGCM revision (20/08/2021) - IOIPSL revision 450 - FCM_V1.2 revision 12 
- Physics revision 2555 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Jupiter, Saturne, Uranus & Neptune [OCCIGEN VERSION]''' - XIOS revision 2319 - ICOSAGCM revision (90f7138a60ebd3644fbbc42bc9dfa22923386385) - IOIPSL revision 453 - FCM_V1.2 revision 12 
- Physics revision 2655 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

'''Jupiter, Saturne, Uranus & Neptune [IRENE VERSION]''' - XIOS revision 2399 - ICOSAGCM revision (4fbd393a9051fd9c1a5b662683f6ad8d0dc2867c) - IOIPSL revision 6234 - FCM_V1.2 revision 12 
- Physics revision 2842 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

== B) Run 1D ==

Pour une simulation 1D, 1 seul CPU suffit.

To run on Occigen:

<code>sbatch job_mpi</code>

To run on Irene:

<code>ccc_msub job_mpi</code>

To see evolution of your job on Occigen:

<code>squeue -u username</code>

To see evolution of your job on Irene:

<code>ccc_mpp -u username</code>

To kill your job on Occigen:

<code>scancel id_of_your_job</code>

To kill your job on Irene:

<code>ccc_mdel id_of_your_job</code>

Une fois que votre simulation est fini, lancer le script python printapbp.py qui vous permettra d'obtenir les fichiers apbp.txt et temp_profile.txt nécessaires pour les simulations en 3D.

== C) Run 3D ==

Pour lancer une première simulation, il faut tout d'abord le faire une seule fois dans le dossier makestart de l'un des dossiers jupiter, saturne, uranus ou neptune. Ce dernier permettra de créer les premiers fichiers restart_icosa.nc et restartfi.nc. Ensuite, il suffit revenir dans le dossier parent (jupiter, saturne, uranus, neptune) et de lancer ses simulations.

=== - MPI ===

Avant de lancer une simulation, il est nécessaire de déterminer - le nombre de procs - le nombre de noeuds

Il faut avant tout savoir qu'il y a 10 x nsplit_i x nsplit_j domaines. Ces domaines sont divisés en plusieurs cellules. Il y a (nbp)²/(nsplit_i x nsplit_j) cellules par domaine. Ce nombre est égal au nombre de MPI process.

Il est important de ne pas faire des tuiles "trop petites" et donc de garder nsplit_i et nsplit_j tels que nbp/nsplit_{i,j} >=10-15 (plutôt 15). Car il y a des calculs "redondants" faits sur les bords du domaine. Admettons que ton domaine soit 10 x 10 (100 cellules par domaine). Le nombre de cellules au bord du domaine est égal à 2 x nsplit_i + 2 x nsplit_j - 4. Dans ce cas, le nombre de cellules au bord est de 36. Cela signifie que le bord du domaine correspond à 36% du domaine (36 points sur 100). Si le domaine est 15 x 15, alors le bord du domaine n'est plus que de 24.8 %. On aimerait avoir des domaines les plus grands possibles mais il faut aussi voir que chaque cellule correspond à une colonne à résoudre... Et c'est là ou il faut expérimenter un peu pour trouver l'optimum entre le nombre total de proc à employer et le gain effectif (temps total "facturé" au vu du nombre de procs monopolisés pour une simu donnée). Ehouarn

Il faut au total que le nombre de procs soit égal à 10 x nsplit_i x nsplit_j qu'il faut répartir entre les noeuds.

Pour les noeuds, il faut tenir compte qu'un noeud sur Occigen, c'est 24 (ou 28) procs. Disons 24. Quand on demande N procs, le système te donne M noeuds, soit M X 24 procs (les noeuds ne sont pas partagés avec d'autres applications). Et bien sûr on te facturera ces M noeuds, même si tu n'utilises pas tous les procs. Donc il faut s'efforcer de tomber juste et demander un multiple de 24 procs. Même raisonement si tu demandes à utiliser des noeuds de 28 procs.

Par exemple, nsplit_i = 4 et nsplit_j = 6. 4 x 6 est égal à 24. On utilisera donc 10 noeuds pour avoir 240 nprocs.

Prenons un autre exemple. nsplit_i = 5 et nsplit_j = 6. 5x6 = 30 Or il y a 24 procs par noeuds. Il faudra utiliser 13 noeuds. Et ce ne sont pas 300 procs qui seront facturés au total mais 312.

Mais comme vu plus haut, en fonction de la configuration de tes domaines, il est possible que le 2nd exemple coûte moins cher en heure CPU que le 1er exemple car il sera plus rapide.

=== - OpenMP / MPI ===

Dans le cas mixte OpenMP/MPI, il est nécessaire de renseigner le nombre de tâche OpenMP et de MPI threads. Dans le script pour le job, on a :

cpus-per-task et OMP_NUM_THREADS correspondent au nombre de tâche OpenMP ntask-per-node correspond au nombre de tâche par noeud

Pour déterminer la configuration à utiliser en OpenMP/MPI, il faut respecter ces règles: - ntask-per-node x nodes correspond au nombre total de MPI threads qu'il devrait y avoir (c'est-à-dire dans le cas MPI seul). - cpus-per-task x ntask-per-node doit être égale ou inférieur au nombre de procs par noeuds (24 ou 28- sur Occigen) - cpus-per-task devrait être ~égal au nombre de niveaux verticaux / 10 - OMP_NUM_THREADS doit être égal au cpus-per-task - omp_level_size (dans le fichier run_icosa.def) devrait être ~égal au nombre de cpus-per-task. (dans le cas MPI seul, il faut le laisser égal à 1)

Au total, le nombre total de nprocs est égal à cpus-per-task x ntask-per-node x nodes

En reprenant le premier exemple MPI (on suppose qu'on a 40 niveaux verticaux), on aura - cpus-per-task = 4 - ntask-per-norde = 6 On a bien cpus-per-task x ntask-per-norde <= 24. Le nombre de noeuds doit être égal à 40 car 6x40 = 240 nprocs MPI Le nombre de procs qu'on utilisera au total sera de 960.

=== - Comment déterminer le nombre d'heure CPU (consommation en heure)? ===

Heures CPU = durée_de_la_simu X nombre de procs total facturé

Si on veut connaître le nombre d'heure CPU qu'on consommera à partir d'un test, voici le calcul

Heures CPU = durée_de_la_simu_test X nombre de procs total facturé X nombre de jour qu'on veut simulé / (nombre de jour simulées pendant la simu test)

== D) Optimisation ==

Pour savoir quelle est la meilleure configuration en MPI seul, en OpenMP/MPI et entre les 2, des tests ont été effectués. Ces tests ont été réalisés sur Uranus à nbp80 sur les noeuds Broadwell (28 procs par noeud). 1000 jours uraniens ont été simulés à chaque fois.

'''MPI:''' [[File:fig1.png]]

'''OpenMP/MPI:''' [[File:fig2.png]]

La comparaison du MPI seul et du mixte OpenMP/MPI permet de tirer la conclusion que le mixte OpenMP/MPI est beaucoup plus rapide (facteur 2.5 à 3) mais consomme plus (facteur 1.1 à 1.7).

[[File:fig3.png]]

== E) Visualizing the output files ==

=== - Comment comparer deux fichiers? file1.nc file2.nc ===

ncdiff file1.nc file2.nc output.nc

=== - Comment coller plusieurs fichiers file1.nc file2.nc file3.nc ===

ncrcat file1.nc file2.nc file3.nc output.nc

Avec juste la vitesse u et v: ncrcat -v u -v v file1.nc file2.nc file3.nc output.nc

Avec tous les fichiers fileXXX.nc disponibles ncrcat file*.nc output.nc

=== - Comment tracer les champs et divers diagnostics en moyenne zonale? ===

<ul>
<li>mettre à jour planetoplot et planets</li>
<li>utiliser precast.py dans planetoplot/examples/ppclass_additional/dynanalysis</li>
<li>changer les options au début (il y a des exemples), exemple pour Saturne
<source lang="python">fileAP="Xhistins_42.nc"
p_upper,p_lower,nlev = 4.0e2,2.5e5,40
targetp1d = np.logspace(np.log10(p_lower),np.log10(p_upper),nlev)
myp = planets.Saturn
day_per_year = 24430.
short = False
includels = False
charx = "0,360"
ispressure = False
vartemp = "temperature"
outfile = "precast.nc"
nopole = True</source></li>
<li>Il faut que apbp.txt soit présent !</li>
<li>Le résultat se trouve dans le fichier indiqué dans outfile.</li></ul>

== F) Debug ==

=== - Pour debugger ===

Réglez <code>info_level</code> à <code>100</code> dans le fichier <code>iodef.xml</code> .

=== - Erreur en début de run, SEGMENTATION FAULT dans la routine <code>advect.f90</code> (ICOSAGCM/ppsrc/transport) au niveau de l'appel à <code>cross_product2</code> ===

La routine <code>cross_product2</code> effectue des produits vectoriels. Cette erreur vient du fait qu'en essayant de faire des optimisations de calcul, le compilateur se prend "les pieds dans le tapis" et ne sait plus faire le produit vectoriel. Pour empêcher le compilateur de faire des optimisations trop poussées, il faut ajouter l'option <code>-fp-model strict</code> au niveau du mot-clé <code>%BASE_FFLAGS</code> dans tous les fichiers <code>.fcm</code> du modèle (LMDZ.COMMON / ICOSAGCM / ICOSA_LMDZ).

== G) Pas de radiatif et perturbations ==

<ul>
<li>faire descendre le modèle</li>
<li>modifier le code pour perturbations vitesse et pas température</li>
<li>compiler (voir README.md)</li>
<li>changer dans callphys.def (dans saturn/makestart)
<pre>surfalbedo = 1.0
surfemis = 0.0</pre></li>
<li>changer dans callphys.def (dans saturn '''et''' saturn/makestart)
<pre>corrk = .false.
enertest = .true.
randompert = 1</pre></li>
<li>voir si on garde le flux interne ou non (<code>intheat</code>)</li>
<li>refaire les états initiaux (dans makestart)</li>
<li>faire un run court pour voir sur les spectres l'injection d'Ek</li></ul>

== H) PROFILING with DYNAMICO-Giant ==

<code>-pg</code>: Generate extra code to write profile information suitable for analysis program <code>gprof</code>. You must use this option when compiling the sources files you want data about and you must '''also use it when linking'''. 1. For DYNAMICO-Giant: in the arch.fcm file of each part of the model (ICOSAGCM, ICOSA_LMDZ, LMDZ.COMMON and XIOS), you have to add the option <code>-pg</code> to <code>%PROD_FFLAGS</code> and <code>%BASE_LD</code> 2. Compile as usual 3. Execute your code as usual 4. Run <code>gprof</code> tool:

<pre> gprof icosa_lmdz.exe goon.out > analysis.txt</pre>

= OLD WIKI (DEPRECATED, JUST FOR REFERENCE/INFORMATION) =

``Welcome to the dynamico-giant wiki!

== pour debugger ==

régler <code>info_level</code> à <code>100</code> dans le fichier <code>iodef.xml</code>

== pourquoi diurnal=.false. ==

le temps radiatif est beaucoup plus long sur les géantes

== comment changer la fréquence d'appel à la physique? ==

il faut changer à ''deux endroits'' en réglant la même valeur - dans run_icosa.def, changer itau_physics - dans run.def, changer iphysiq ces paramètres sont exprimés en pas de temps dynamique. pour appeler la physique à chaque pas de temps dynamique, régler ces paramètres à 1

== comment changer la résolution ==

[https://github.com/aymeric-spiga/dynamico-giant/commit/f39e3b651c19cefb26da72ab77933520ff8f27f5 voir lien ici]

== comment choisir le nombre de processeurs pour la résolution ==

voir commentaires sur run_icosa.def

<pre>###########################################
## There must be less MPIxOpenMP processes than the 10 x nsplit_i x nsplit_j tiles
## typically for pure MPI runs, let nproc = 10 x nsplit_i x nsplit_j
## it is better to have nbp/split >~ 10
###########################################
#### 40 noeuds de 24 processeurs = 960 procs
nsplit_i=12
nsplit_j=8</pre>
Ehouarn: ''Une règle à suivre est de ne pas faire des tuiles "trop petites" et donc de garder nbsplit_i et nbsplit_j tels que nbp/nbsplit >=10-15 (plutôt 15). Car il y a des calculs "redondants" faits sur les bords du domaine. Or si ton domaine est 10''10, le bord du domaine c'est 38% du domaine (38 points sur le bord pour 100 points en tout) alors que si ton domaine est 15''15, le bord du domaine n'est plus que 56/(15''15) = 25.7%. 56=2''15+2''13 (pour ne pas compter 2 fois les coins). On voudrait du coup des domaine les plus grand possible, clairement, mais il faut aussi voir que chaque domaine c'est nbp''nbp colonnes à résoudre sur ce même proc... Et c'est là ou il faut expérimenter un peu pour trouver l'optimum entre le nombre total de proc à employer et le gain effectif (temps total "facturé" au vu du nombre de procs monopolisés pour une simu donnée).''

_Pour les noeuds, il faut tenir compte qu'un noeud sur Occigen, c'est 24 (ou 28) procs. Disons 24. Quand on demande N procs, le système te donne M noeuds, soit M*24 procs (les noeuds ne sont pas partagés avec d'autres applications). Et bien sûr on te facturera ces M noeuds, même si tu n'utilises pas tous les procs. Donc il faut s'efforcer de tomber juste et demander un multiple de 24 procs. Même raisonement si tu demandes à utiliser des noeuds de 28 procs._

== comment changer la rotation? ==

dans saturn_const.def, changer le taux de rotation jamais testé avec 0, mais pourrait créer des problèmes (ex: beta) ''vérifier que omega dans saturn_const.def n'intervient pas dans la physique LMDZ.GENERIC/libf/phygeneric/''

== la dissipation c'est où? ==

laplacien itéré: hyperviscosity - tau_graddiv,tau_gradrot,tau_divgrad: periode (plus c'est petit, plus la dissipation est efficace) - nitergdiv,nitergrot,niterdivgrad: ordre du laplacien (plus c'est grand, plus on dissipe sélectivement les petites échelles)

== comment changer la grille cible du remapping on-the-fly ==

dans context_lmdz_physics.xml changer les paramètres ni_glo et nj_glo par exemple pour remapper sur du lat/lon à 360 pts en latitude et 720 pts en longitude (0.5°) <domain id="dom_regular" ni_glo="720" nj_glo="360" type="rectilinear">

== Forcer XIOS à écrire tous les .... ==

Il faut utiliser l'attribut (ici par ex pour forcer l'écriture tous les ts (==time step) ; d'autres délais doivent être possible): <code>sync_freq="1ts"</code> dans le <code><file id=... .... ></code> concerné.

== comment changer le bottom du modele ==

* refaire tourner le 1D
** changer la pression <code>psurf</code> dans rcm1d.def
** changer <code>ichoice=1</code> et changer <code>tref</code> (ex: 10b: 330K)
* refaire tourner le 3D (avec makestart) en changeant <code>preff</code> dans <code>saturn_const.def</code>

== comment changer la fréquence de sortie des Xhistins.nc ==

les commandes XIOS sont appelées depuis la physique (dans la config présente) dans context_lmdz_physics.xml il suffit de changer output_freq ''attention'' ts se comprend comme le pas de temps physique (voir donc dans run_icosa.def les paramètres dt et itau_physics pour le connaître) par exemple, pour des sorties tous les 20 jours Saturne

<source lang="xml"><file id="histins"
name="Xhistins"
output_freq="40ts"
type="one_file"
enabled=".true."></source>
== pas de radiatif et perturbations ==

<ul>
<li>faire descendre le modèle</li>
<li>modifier le code pour perturbations vitesse et pas température</li>
<li>compiler (voir README.md)</li>
<li>changer dans callphys.def (dans saturn/makestart)
<pre>surfalbedo = 1.0
surfemis = 0.0</pre></li>
<li>changer dans callphys.def (dans saturn '''et''' saturn/makestart)
<pre>corrk = .false.
enertest = .true.
randompert = 1</pre></li>
<li>voir si on garde le flux interne ou non (<code>intheat</code>)</li>
<li>refaire les états initiaux (dans makestart)</li>
<li>faire un run court pour voir sur les spectres l'injection d'Ek</li></ul>

== comment comparer deux fichiers? file1.nc file2.nc ==

ncdiff file1.nc file2.nc output.nc

== comment coller plusieurs fichiers file1.nc file2.nc file3.nc ==

ncrcat file1.nc file2.nc file3.nc output.nc avec juste la vitesse u et v ncrcat -v u -v v file1.nc file2.nc file3.nc output.nc avec tous les fichiers fileXXX.nc disponibles ncrcat file*.nc output.nc

== comment tracer les champs et divers diagnostics en moyenne zonale? ==

<ul>
<li>mettre à jour planetoplot et planets</li>
<li>utiliser precast.py dans planetoplot/examples/ppclass_additional/dynanalysis</li>
<li>changer les options au début (il y a des exemples), exemple pour Saturne
<source lang="python">fileAP="Xhistins_42.nc"
p_upper,p_lower,nlev = 4.0e2,2.5e5,40
targetp1d = np.logspace(np.log10(p_lower),np.log10(p_upper),nlev)
myp = planets.Saturn
day_per_year = 24430.
short = False
includels = False
charx = "0,360"
ispressure = False
vartemp = "temperature"
outfile = "precast.nc"
nopole = True</source></li>
<li>Il faut que apbp.txt soit présent !</li>
<li>le résultat se trouve dans le fichier indiqué dans outfile</li></ul>

== bilan de moment cinétique ==

dans run_icosa.def

<pre>check_conservation = detailed
itau_check_conserv = 160</pre>
le itau_check_conserv est comme itau_physics pour que la contribution de la physique à AAM ne soit pas nulle. de plus il est coûteux d'appeler les diagnostics trop souvent.

S. Lebonnois, C. Covey, A. Grossman, H. Parish, G. Schubert, R. Walterscheid, P. Lauritzen, and C. Jablonowski. Angular momentum budget in General Circulation Models of superrotating atmospheres: A critical diagnostic. Journal of Geophysical Research (Planets), 117:E12004, 2012.

P. H. Lauritzen, J. T. Bacmeister, T. Dubos, S. Lebonnois, and M. A. Taylor. Held-Suarez simulations with the Community Atmosphere Model Spectral Element (CAM-SE) dynamical core: A global axial angular momentum analysis using Eulerian and floating Lagrangian vertical coordinates. Journal of Advances in Modeling Earth Systems, 6:129-140, 2014.

== XIOS server ou client ==

# XIOS client <code>use_server=False</code> Broadwell 24 processeurs sur 28
# XIOS server <code>use_server=true</code> Broadwell 24 processurs sur 28 + 4 processeurs pour XIOS

cas 1 est 3 min plus lent que cas 2 -- sur 2h20...! parce qu'on fait peu de sorties

== Optimisation ==

# 40 noeuds au lieu de 50 noeuds, même temps de calcul...! Testé dans la branche https://github.com/aymeric-spiga/dynamico-giant/tree/work_61levels
# <code>sync_freq=40ts</code> (ou multiple de, si 40ts est la fréquence d'écriture) dans context_lmdz_physics.xml doit être inclus sinon il n'est pas réglé et XIOS transfère tout à la fin du run ce qui prend du temps (et peut occasionner des problèmes de mémoire)

== Versions fonctionnelles de dynamico-giant ==

=== Jupiter ===

* XIOS revision 1583 

* ICOSAGCM revision 756 

* IOIPSL revision 339 

* FCM_V1.2 revision 12 

* Physics revision 2228 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

but check Physics version 2142 and 2180

=== Saturne (référence Spiga 2020, à vérifier) ===

* DYNAMICO --> Revision: 756
* PHYSICS --> Revision: 2005
* XIOS --> Revision: 1583
* IOIPSL --> Revision: 310?

=== Saturne (simulation de référence sur 61 niveaux, Bardet et al. Icarus 2021) ===

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 310 

* FCM_V1.2 revision 12 

* Physics revision 2005 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

=== Saturne (simulation avec la GWD paramétrisation sur 61 niveaux, chapitre 6 PhD Bardet) ===

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 310 

* FCM_V1.2 revision 12 

* Physics revision 2213 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

=== Saturne (simulation sur 96 niveaux, Bardet et al. Nature Astronomy 2022) ===

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 431 

* FCM_V1.2 revision 12 

* Physics revision 2305 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

=== Saturne (simulation avec la GWD paramétrisation sur 96 niveaux, chapitre 6 PhD Bardet) ===

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 431 

* FCM_V1.2 revision 12 

* Physics revision 2403 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

=== Uranus & Neptune (old version) ===

* XIOS revision 1944
* ICOSAGCM revision 765
* IOIPSL revision 431
* FCM_V1.2 revision 12 

* Physics revision 2413 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

=== Uranus & Neptune (new version) ===

* XIOS revision 2203
* ICOSAGCM revision (20/08/2021)
* IOIPSL revision 450
* FCM_V1.2 revision 12 

* Physics revision 2555 (LMDZ.COMMON, LMDZ.GENERIC, ICOSA_LMDZ, ARCH)

works on 03/03/2022 for all HEAD

== Les fichiers d'architecture (Installation sur un nouveau cluster) ==

En pratique LMDZ.COMMON, ICOSA_LMDZ et IOIPSL peuvent utiliser exactement le même fichier arch.fcm ; mais celui pour ICOSAGCM est légèrement différent (les %FPP_DEF diffèrent, peut-être aussi le %FPP).

make_icosa_lmdz doit être lancé avec -arch_path ../ARCH puisque les arch.env et arch.path communs se trouvent dans ../ARCH (l'option -arch_path ne concerne d'ailleurs que les fichiers arch.env et arch.path; le fichier arch.fcm recherché sera toujours celui dans le "arch" de chacun des modèles. Donc il faut bien mettre pour chacun des quatre modèles (LMDZ.COMMON, ICOSA_LMDZ,IOIPSL et ICOSAGCM) le arch.fcm dans le sous-dossier arch/ du modèle correspondant.

XIOS est écrit en C++, et pas en Fortran. Le fichier arch.fcm correspondant est donc nécessairement différent de celui des quatre autres modèles. Pour créér ce arch.fcm, prendre exemple sur les fichiers .fcm déjà présent dans XIOS/arch/, avec une architecture similaire à celle du nouveau cluster. En particulier, il faut utiliser des versions de gcc/gfortran > 6+. Il faut absolument avoir une bibliothèque HDF5 compilée en parallèle, ainsi que netcdf-C et netcdf-fortran (et peut être aussi netcdf-Cxx) compilé en parallèle. Sans ça, il sera peut-être possible de compiler le modèle, mais pas de lancer une simulation en utilisant XIOS.

== Commencer une nouvelle simulation en utilisant le schéma des panaches thermiques ==

# Comme pour toutes nouvelles simulations, il faut commencer par un run 1D de plusieurs décennies permettant d'obtenir un profil de température (<code>temp_profile.txt</code>) et les coefficients ap et bp (<code>apbp.txt</code>) en équilibre radiatif-convectif pour la planète que l'on étudie. Ce run 1D s'effectue dans les dossiers jupiter1d, saturn1d, neptune1d et/ou uranus1d, avec ces options pour le callphys.def :

callrad = true calladj = true tous les autres mots clés à false (y compris <code>calltherm</code>).

<ol start="2" style="list-style-type: decimal;">
<li>Faire un "makestart" run : permet d'obtenir les fichiers restart à partir du profil de température initial. Il s'agit du run dont l'état initial est le profil de température créé par run 1D (<code>temp_profile.txt</code> est appliquer à chaque point de grille horizontale du modèle). L'état initial est ainsi une planète isotherme horizontalement mais qui varie verticalement. Pour ce run, aucun traceur ne va être utilisé dans le modèle. Néanmoins, il faut renseigner au modèle le nombre de traceurs que nous souhaitons utiliser avec le schéma des panaches thermiques afin qu'il puisse créer la dimension nq et le champ q dans les fichiers <code>restart_icosa.nc</code> et <code>restartfi.nc</code>. dans '''callphys.def''' :
<pre> traceur = true</pre>
dans '''run_icosa.def''' : <code>nqtot = 2</code> (par exemple, h2o_vap et h2o_ice) dans '''traceur.def''' :
<pre> 2
h2o_vap
h2o_ice</pre></li>
<li>Ajout des quantités pour chaque traceur. Ici, nous ajoutons les profils pour chacun des traceurs dans les fichiers <code>restart_icosa.nc</code> et <code>restartfi.nc</code> "à la main" en utilisant le programme python <code>/processing_codes/tracer_settings.py</code> pour obtenir des fichiers restart avec la bonne abondance d'eau dans le cas présent.</li>
<li>Commencer la simulation : Il ne reste plus qu'à lancer la simulation 3D avec les nouveaux fichiers restart et les réglages suivant : dans '''callphys.def''' :
<pre> traceur = true
calltherm = true
# thermal plume model options:
divmpl = true
r_aspect_thermals = 2.0
tau_thermals = 0.0
betalpha = 0.9
afact = 0.7
fact_epsilon = 2.e-4
alpha_max = 0.7
fomass_max = 0.5
pres_limit = 2.e5
water = true
watercond = true
waterain = true
evap_prec = true</pre></li></ol>

dans '''run_icosa.def''' : <code>nqtot = 2</code> dans '''traceur.def''' :

<pre> 2
h2o_vap
h2o_ice</pre>
Enfin, ajouter la déclaration et l'écriture des variables relatives à l'utilisation du schéma des thermiques (<code>h2o_vap</code>, <code>h2o_ice</code>, <code>w_plm</code>) dans les fichiers XML de la physique.

== Erreur en début de run, SEGMENTATION FAULT dans la routine <code>advect.f90</code> (ICOSAGCM/ppsrc/transport) au niveau de l'appel à <code>cross_product2</code>. ==

La routine <code>cross_product2</code> effectue des produits vectoriels. Cette erreur vient du fait qu'en essayant de faire des optimisations de calcul, le compilateur se prend "les pieds dans le tapis" et ne sait plus faire le produit vectoriel. Pour empêcher le compilateur de faire des optimisations trop poussées, il faut ajouter l'option <code>-fp-model strict</code> au niveau du mot-clé <code>%BASE_FFLAGS</code> dans tous les fichiers <code>.fcm</code> du modèle (LMDZ.COMMON / ICOSAGCM / ICOSA_LMDZ)

== Branche master version du 04/04/2022 dans le dossier Jupiter ==

La version actuelle des fichiers de réglage dans le dossier Jupiter sont réglés pour utiliser des traceurs. Si vous souhaiter utiliser le modèle sans traceur, il vous faut modifier les fichiers suivants :

run_icosa.def

<pre> nqtot = 0</pre>
traceur.def

<pre> 0</pre>
context_dynamico.xml (ligne 125)

<pre> <field id="q_start" name="q" grid_ref="grid_q_start" prec="8"/> </pre>
== PROFILING with DYNAMICO-Giant: ==

<code>-pg</code>: Generate extra code to write profile information suitable for analysis program <code>gprof</code>. You must use this option when compiling the sources files you want data about and you must '''also use it when linking'''. 1. For DYNAMICO-Giant: in the arch.fcm file of each part of the model (ICOSAGCM, ICOSA_LMDZ, LMDZ.COMMON and XIOS), you have to add the option <code>-pg</code> to <code>%PROD_FFLAGS</code> and <code>%BASE_LD</code> 2. Compile as usual 3. Execute your code as usual 4. Run <code>gprof</code> tool:

<pre> gprof icosa_lmdz.exe goon.out > analysis.txt</pre>

[[Category:DYNAMICO]]
[[Category:Generic-DYNAMICO]]

Other GCM Configurations worth knowing about

2026-06-12T13:30:08Z

Jbclement: /* rcm1d program */

= 3D lon-lat LMDZ setup =

== early Mars ==

It is already described in the [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Quick_Install_and_Run ''Quick Install and Run''] section.

== Earth with slab ocean ==

TBD by Siddharth, once all changes have been committed (also need a validation of the model on Earth to be sure)

== TRAPPIST-1e with photochemistry ==

A temperate rocky planet in synchronous rotation around a low mass star.

Here is an example to simulate the planet TRAPPIST-1e with an Earth atmosphere using the photochemical module of the GCM.

To install the model and run it, follow [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Quick_Install_and_Run ''Quick Install and Run''] but with the following changes:

=== GCM Input Datafiles and Datasets ===
Section [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php?title=Quick_Install_and_Run&action=edit&section=9 ''GCM Input Datafiles and Datasets''] download the TRAPPIST-1e files (instead of the early Mars files):
<syntaxhighlight lang="bash">
wget -nv --no-check-certificate https://web.lmd.jussieu.fr/~lmdz/planets/generic/reference_setups/bench_trappist1e_photochemistry_64x48x30_b38x36.tar.gz
</syntaxhighlight>

You can find the same type of file with the additional folder containing the chemical network file:
<syntaxhighlight lang="bash">
callphys.def gases.def startfi.nc traceur.def
datadir/ run.def start.nc z2sig.def
chemnetwork/
</syntaxhighlight>

=== Compiling the GCM ===
==== Prior to a first compilation: setting up the target architecture files ====
The chemical solver require the libraries BLAS and LAPACK which need to be specified in the '''arch*.fcm''' file:
<syntaxhighlight lang="bash">
%COMPILER gfortran
%LINK gfortran
%AR ar
%MAKE make
%FPP_FLAGS -P -traditional
%FPP_DEF NC_DOUBLE LAPACK BLAS SGEMV=DGEMV SGEMM=DGEMM
%BASE_FFLAGS -c -fdefault-real-8 -fdefault-double-8 -ffree-line-length-none -fno-align-commons
%PROD_FFLAGS -O3
%DEV_FFLAGS -O
%DEBUG_FFLAGS -ffpe-trap=invalid,zero,overflow -fbounds-check -g3 -O0 -fstack-protector-all -finit-real=snan -fbacktrace
%MPI_FFLAGS
%OMP_FFLAGS
%BASE_LD -llapack -lblas
%MPI_LD
%OMP_LD
</syntaxhighlight>

==== Specific to photochemistry: set hard coded reactions ====
In '''/LMDZ.GENERIC/libf/aeronogeneric/chimiedata_h.F90''' you can hard code reaction if needed, for instance because the reaction rate is very specific and out of the generic formula or your photochemical reaction does not use a regular cross section.

The TRAPPIST-1e test case use 3 hard coded reactions.

*Uncomment the following lines to fill reaction species indexes:
<syntaxhighlight lang="bash">
!===========================================================
! r001 : HNO3 + rain -> H2O
!===========================================================
nb_phot = nb_phot + 1
indice_phot(nb_phot) = z3spec(1.0, indexchim('hno3'), 1.0, indexchim('h2o_vap'), 0.0, 1)

!===========================================================
! e001 : CO + OH -> CO2 + H
!===========================================================
nb_reaction_4 = nb_reaction_4 + 1
indice_4(nb_reaction_4) = z4spec(1.0, indexchim('co'), 1.0, indexchim('oh'), 1.0, indexchim('co2'), 1.0, indexchim('h'))

!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
! photodissociation of NO : NO + hv -> N + O
!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
nb_phot = nb_phot + 1
indice_phot(nb_phot) = z3spec(1.0, indexchim('no'), 1.0, indexchim('n'), 1.0, indexchim('o'))
</syntaxhighlight>

*Uncomment the following lines to fill reaction rates:
<syntaxhighlight lang="bash">
!----------------------------------------------------------------------
! carbon reactions
!----------------------------------------------------------------------

!--- e001: oh + co -> co2 + h

nb_reaction_4 = nb_reaction_4 + 1

! joshi et al., 2006

do ilev = 1,nlayer
k1a0 = 1.34*2.5*dens(ilev) &
*1/(1/(3.62e-26*t(ilev)**(-2.739)*exp(-20./t(ilev))) &
+ 1/(6.48e-33*t(ilev)**(0.14)*exp(-57./t(ilev)))) ! typo in paper corrected
k1b0 = 1.17e-19*t(ilev)**(2.053)*exp(139./t(ilev)) &
+ 9.56e-12*t(ilev)**(-0.664)*exp(-167./t(ilev))
k1ainf = 1.52e-17*t(ilev)**(1.858)*exp(28.8/t(ilev)) &
+ 4.78e-8*t(ilev)**(-1.851)*exp(-318./t(ilev))
x = k1a0/(k1ainf - k1b0)
y = k1b0/(k1ainf - k1b0)
fc = 0.628*exp(-1223./t(ilev)) + (1. - 0.628)*exp(-39./t(ilev)) &
+ exp(-t(ilev)/255.)
fx = fc**(1./(1. + (alog(x))**2)) ! typo in paper corrected
k1a = k1a0*((1. + y)/(1. + x))*fx
k1b = k1b0*(1./(1.+x))*fx

v_4(ilev,nb_reaction_4) = k1a + k1b
end do

!----------------------------------------------------------------------
! washout r001 : HNO3 + rain -> H2O
!----------------------------------------------------------------------

nb_phot = nb_phot + 1

rain_h2o = 100.e-6
!rain_rate = 1.e-6 ! 10 days
rain_rate = 1.e-8

do ilev = 1,nlayer
if (c(ilev,indexchim('h2o_vap'))/dens(ilev) >= rain_h2o) then
v_phot(ilev,nb_phot) = rain_rate
else
v_phot(ilev,nb_phot) = 0.
end if
end do

!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
! photodissociation of NO
!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

nb_phot = nb_phot + 1

colo3(nlayer) = 0.
! ozone columns for other levels (molecule.cm-2)
do ilev = nlayer-1,1,-1
colo3(ilev) = colo3(ilev+1) + (c(ilev+1,indexchim('o3')) + c(ilev,indexchim('o3')))*0.5*avocado*1e-4*((press(ilev) - press(ilev+1))*100.)/(1.e-3*zmmean(ilev)*g*dens(ilev))
end do
call jno(nlayer, c(nlayer:1:-1,indexchim('no')), c(nlayer:1:-1,indexchim('o2')), colo3(nlayer:1:-1), dens(nlayer:1:-1), press(nlayer:1:-1), sza, v_phot(nlayer:1:-1,nb_phot))
</syntaxhighlight>

*Change the following lines to set the number of hard coded reactions:
<syntaxhighlight lang="bash">
integer, parameter :: nphot_hard_coding = 2
integer, parameter :: n4_hard_coding = 1
integer, parameter :: n3_hard_coding = 0
</syntaxhighlight>

=== Compiling a test case (TRAPPIST-1e) ===
Change the following compiling option:
<syntaxhighlight lang="bash">
-d 64x48x30 -b 38x36
</syntaxhighlight>

NB: option -b is mandatory to change while option -d will still run with lower or higher resolution (if '''z2sig.def''' remains coherent with the number of altitude levels, meaning at least as many altitude levels defined as the number of levels wanted).

== TRAPPIST-1c in Venus-like conditions ==

A warm rocky planet in synchronous rotation around a low mass star. Here we provide an '''example''' to simulate the atmosphere of Trappist-1c, assuming it evolved to a modern Venus-like atmosphere.

The planetary parameters are taken from [https://arxiv.org/abs/2010.01074 Algol et al. 2021] and can be found in this table [[Media:Planetary_parameters_Trappist1c.png]]

First, install the model and run it, following [[Quick Install and Run]] but instead of ''Early Mars files'', please download ''bench_trappist1c_64x48x50_b32x36'' using this command:

<syntaxhighlight lang="bash">
wget -nv --no-check-certificate https://web.lmd.jussieu.fr/~lmdz/planets/generic/reference_setups/bench_trappist1c_64x48x50_b32x36.tar.gz
</syntaxhighlight>

=== Compiling a test case (TRAPPIST-1c) ===
Change the following compiling option:
<syntaxhighlight lang="bash">
-d 64x48x50 -b 32x36
</syntaxhighlight>

You can find the same type of ASCII *def files than in the case of ''Early Mars'', but adapted to the planet's characteristics and orbital parameters of Trappist 1c.
In particular ''callphys.def'' contains the following changes:

* The planet is assumed to be in 1:1 spin-orbit resonance, therefore
diurnal = .false.
tlocked = .true.
* The planet equilibrium temperature is about 342 K
tplanet = 341.9
* The host star is TRAPPIST1, with a stellar flux at 1 AU of 0.7527 [W m-2]
stelspec_file = spectrum_TRAPPIST1_2022.dat
tstellar = 2600.
Fat1AU = 0.7527
* Fixed aerosol distribution, no radiative active tracers (no evaporation/condensation of H2O and CO2):
aerofixed = .true.
aeroco2 = .false.
aeroh2o = .false.
* No water cycle model, no water cloud formation or water precipitation, no CO2 condensation:
water = .false.
watercond = .false.
waterrain = .false.
hydrology = .false.
nonideal = .true.
co2cond = .false.
* Following [https://www.sciencedirect.com/science/article/pii/S0032063313002596?via%3Dihub Haus et al. 2015] a prescribed radiatively active cloud model is included.
It can be activated/deactivated with the flag ''aerovenus''.
aerovenus = .true.
* Mode 1, 2, 2p, 3 and the "unknown" UV absorber can be included/excluded by setting to true/false the following keywords. The characteristics of each mode (e.g. effect radius, effective variance) are based on Venus Express/ESA observations and can be found in this table [[Media:Table1 aerosolVenus trappist1c.png]]
aerovenus1 = .true.
aerovenus2 = .true.
aerovenus2p = .true.
aerovenus3 = .true.
aerovenusUV = .true.

The cloud model is prescribed from 1 to 0.037 ''bar'' pressure layers. For each mode, the top/bottom pressure can be modified by hard-coding model routine ''aerosol_opacity.F90''.
Here below an example for mode 1 particles, where the top pressure layer and bottom pressure layer are prescribed at 0.1 bar and 1 bar, respectively:

<syntaxhighlight lang="bash">

! 1. Initialization
aerosol(1:ngrid,1:nlayer,iaer)=0.0
p_bot = 1.e5 ! bottom pressure [Pa]
p_top = 1.e4
h_bot = 1.0e3 ! bottom scale height [m]
h_top = 5.0e3
</syntaxhighlight>

'''TO BE COMPLETED BY GABRIELLA'''

== mini-Neptune GJ1214b ==

A warm mini-Neptune

'''TO BE COMPLETED BY BENJAMIN'''

= 3D DYNAMICO setup =

Due to the rich dynamical activities in their atmospheres (banded zonal jets, eddies, vortices, storms, equatorial oscillations,...) resulting from multi-scale dynamic interactions, the Global Climate Modelling of the giant planet requires to resolve eddies arising from hydrodynamical instabilities to correctly establish the planetary-scaled jets regime. To this purpose, their Rossby radius deformation $$L_D$$, which is the length scale at which rotational effects become as important as buoyancy or gravity wave effects in the evolution of the flow about some disturbance, is calculated to determine the most suitable horizontal grid resolution. At mid-latitude range, for the giant planets, $$L_D$$ is of the same order of magnitude as that of the Earth. As the giant planets have a size of roughly 10 times the Earth size (i.e., Jupiter and Saturn), the modelling grid must be of a horizontal resolution of 0.5$$^{\circ}$$ over longitude and latitude (vs 5$$^{\circ}$$ for the Earth), considering 3 grid points to resolved $$L_D$$.
Moreover, to have a chance to model the equatorial oscillation, meridional cell circulations and/or a seasonal inter-hemispheric circulation, a giant planet GCM must also include a high vertical resolution. Indeed, these climate phenomena have been studied for decades for the Earth's atmosphere, and result from small- and large-scale interactions between the troposphere and stratosphere. This implies that the propagation of dynamic instabilities, waves and turbulence should be resolved as far as possible along the vertical. Contrary to horizontal resolution, it doesn't really exist a criterion (similar to $$L_D$$) to determine the most suitable vertical grid resolution and still an adjustable parameter according to the processes to be represented. However, we advise the user to set a vertical resolution of at least 5 grid points per scale height as first stage.
Finally, these atmospheres are cold, with long radiative response time which needs radiative transfer computations over decade-long years of Jupiter (given that a Jupiter year $$\approx$$ 12 Earth years), Saturn ( a Saturn year $$\approx$$ 30 Earth years), Uranus (a Uranus year $$\approx$$ 84 earth years) or Neptune (a Neptune year $$\approx$$ 169 Earth years), depending on the chosen planet.

To be able to deal with these three -- and non-exhaustive -- requirements to build a giant planet GCM, we need massive computational ressources. For this, we use a dynamical core suitable and numerically stable for massive parallel ressource computations: [[The_DYNAMICO_dynamical_core | DYNAMICO]] [Dubos et al,. 2015].

In these two following subsections, we purpose an example of installation for Jupiter and a Hot Jupiter. All the install, compiling, setting and parameters files for each giant planets could be found on: https://gitlab.in2p3.fr/aymeric.spiga/dynamico-giant (the old repo is archived as read-only https://github.com/aymeric-spiga/dynamico-giant)

The [[Dynamico-giant | DYNAMICO-giant wiki is here]]

If you have already downloaded '''LMDZ.COMMON''', '''LMDZ.GENERIC''', '''IOIPSL''', '''ARCH''', you only have to download:

'''ICOSAGCM''': the DYNAMICO dynamical core
<syntaxhighlight lang="bash">
git clone https://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico.git ICOSAGCM
cd ICOSAGCM
git checkout 110016896ae9e85e614af43223b18fe38f211020 # Version du 6 nov. 2024
</syntaxhighlight>

'''ICOSA_LMDZ''': the interface using to link LMDZ.GENERIC physical packages and ICOSAGCM
<syntaxhighlight lang="bash">
svn update -r 3729 -q ICOSA_LMDZ # Version du 18 avr. 2025
</syntaxhighlight>

'''XIOS (XML Input Output Server)''': the library to interpolate input/output fields between the icosahedral and longitude/latitude regular grids on fly
<syntaxhighlight lang="bash">
svn co -r 2626 -q http://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/trunk XIOS # Version du 22 mar. 2024
</syntaxhighlight>

If you haven't already download '''LMDZ.COMMON''', '''LMDZ.GENERIC''', '''IOIPSL''', '''ARCH''', you can use the '''install.sh''' script provided by the GitLab repository.

Once each part of the GCM is downloaded, you are able to compile it.
Firstly, you have to define your [[The_Target_Architecture_("arch")_Files | target architecture file ]] (hereafter named YOUR_ARCH_FILE) where you will fill in all the necessary information about the local environment, where libraries are located, which compiler, and compiler options will be used, etc.
Some architecture files related to specific machines are provided in the '''ARCH''' directory, which are referenced in the following lines without the prefix 'arch-' (i.e., arch-X64_IRENE-AMD.env will be referenced as X64_IRENE-AMD).

The main specificity of DYNAMICO-giant is that every main parts of the model ('''ICOSAGCM''', '''LMDZ.COMMON''' and '''LMDZ.GENERIC''') are compiled as libraries, and settings and running configuration are managed by the '''ICOSA_LMDZ''' interface.

First, you have to compile '''IOIPSL''',
<syntaxhighlight lang="bash">
cd LMDZ.COMMON/ioipsl/
./install_ioipsl_YOUR-MACHINE.bash
cd ../../
</syntaxhighlight>
then '''XIOS''' library,
<syntaxhighlight lang="bash">
cd XIOS/
./make_xios --prod --arch YOUR_ARCH_FILE --arch_path ../ARCH --job 8 --full
cd -
</syntaxhighlight>
the physics packaging,
<syntaxhighlight lang="bash">
cd LMDZ.COMMON/
./makelmdz_fcm -p generic -p_opt "-b 20x25" -prod -parallel mpi -libphy -io xios -arch YOUR_ARCH_FILE -arch_path ../ARCH -j 8 -full
cd -
</syntaxhighlight>
the dynamical core '''DYNAMICO''' (located in '''ICOSAGCM''' directory, named from the icosahedral shape of the horizontal mesh),
<syntaxhighlight lang="bash">
cd ICOSAGCM/
./make_icosa -prod -parallel mpi -external_ioipsl -with_xios -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -full
cd -
</syntaxhighlight>
and finally the '''ICOSA_LMDZ''' interface
<syntaxhighlight lang="bash">
cd ICOSA_LMDZ/
./make_icosa_lmdz -p generic -p_opt "-b 20x25" -parallel mpi -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -nodeps
</syntaxhighlight>
This last step is a bit redundant with the two previous one, hence ''make_icosa_lmdz'' will execute ''./make_icosa'' (in the '''ICOSAGCM''' directory) and ''./makelmdz_fcm'' (in the '''LMDZ.COMMON''' directory) to create and source the architecture files shared between all parts of the model, as well as create the intermediate file ''config.fcm''. As you have already compiled these two elements, ''make_icosa_lmdz'' should only create the linked architecture files, ''config.fcm'' and compile the interface. Here, ''-nodeps'' option prevents the checking of XIOS and IOIPSL compilation, which saves you from recompiling these two elements again.

Finally, your executable programs should appeared in '''ICOSA_LMDZ/bin''' subdirectory, as '''icosa_lmdz.exe''' and in '''XIOS/bin''' subdirectory, as '''xios_server.exe'''

All these compiling steps are summed up in ''make_isoca_lmdz'' program that should be adapted to your own computational settings (i.e., through you target architecture file).
<syntaxhighlight lang="bash">
./make_icosa_lmdz -p generic -p_opt "-b 20x25" -parallel mpi -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -full
</syntaxhighlight>
Here, ''-full'' option assure the compilation of each part ('''IOIPSL''', '''XIOS''', '''LMDZ.COMMON''', '''ICOSAGCM''' and '''ICOSA_LMDZ''') of the model.

Now you can move your two executable files to your working directory and start to run your own simulation of Jupiter or a Hot Jupiter, as what follows.

Note: If you are using the GitLab file architecture (https://gitlab.in2p3.fr/aymeric.spiga/dynamico-giant), you should be able to compile the model directly from your working directory (for instance ''dynamico-giant/jupiter/'') by using the ''compile_occigen.sh'' program, which has to be adapted to your machine/cluster.

''Note 2 : Depending on the compiler module you use, especially with gfortran, you may need to modify the tracers_icosa.F90 file located in the src directory in order to successfully compile ICOSAGCM. For example, if you are using GCC/11.3.0 and OpenMPI/4.1.4, you must update the insert_tracer_output subroutine as follows:''
<syntaxhighlight lang="fortran">
SUBROUTINE insert_tracer_output
USE xios_mod
USE grid_param
IMPLICIT NONE
TYPE(xios_fieldgroup) :: fieldgroup_hdl
TYPE(xios_field) :: field_hdl
INTEGER :: iq
CHARACTER(len=1000) :: tracername1
CHARACTER(len=1000) :: tracername2
CHARACTER(len=1000) :: tracername3

CALL xios_get_handle("standard_output_tracers", fieldgroup_hdl)
DO iq = 1, nqtot
tracername1 = "tracer_"//TRIM(tracers(iq)%name)
CALL xios_add_child(fieldgroup_hdl, field_hdl, tracername1)
CALL xios_set_attr(field_hdl, name=TRIM(tracers(iq)%name))
END DO

CALL xios_get_handle("standard_output_tracers_init", fieldgroup_hdl)
DO iq = 1, nqtot
tracername2 = "tracer_"//TRIM(tracers(iq)%name)//"_init"
tracername3 = TRIM(tracers(iq)%name)//"_init"
CALL xios_add_child(fieldgroup_hdl, field_hdl, tracername2)
CALL xios_set_attr(field_hdl, name=tracername3)
END DO

END SUBROUTINE insert_tracer_output
</syntaxhighlight>

== Jupiter with DYNAMICO ==
Using a new dynamical core implies new setting files, in addition or as a replacement of those relevant to '''LMDZ.COMMON''' dynamical core using.

There are two kind of setting files:

'''A first group relevant to DYNAMICO:'''

- [[The ''context_dynamico.xml'' Input File|''context_dynamico.xml'']]: Configuration file for '''DYNAMICO''' for reading and writing files using '''XIOS''', mainly used when you want to check the installation of '''ICOSAGCM''' with [[The_DYNAMICO_dynamical_core | an ''Held and Suarez'' test case]]. When your installation, compilation and run environment is fully functional, the dynamic core output files will not (necessarily) be useful and you can disable their writing.

- [[The context_input_dynamico.xml Input File|''context_input_dynamico.xml'']]:

- [[The file_def_dynamico.xml Input File|''file_def_dynamico.xml'']]: Definition of output diagnostic files which will be written into the output files only related to '''ICOSAGCM'''.

- [[The field_def_dynamico.xml Input File|''field_def_dynamico.xml'']]: Definition of all existing variables that can be output from DYNAMICO.

- [[The tracer.def Input File|''tracer.def'']]: Definition of the name and physico-chemical properties of the tracers which will be advected by the dynamical core. For now, there is two files related to tracers, we are working to harmonise it.

''' A second group relevant to LMDZ.GENERIC physical packages: '''

- [[The context_lmdz_physics.xml Input File|''context_lmdz_physics.xml'']]: File in which are defined the horizontal grid, vertical coordinate, output file(s) definition, with the setting of frequency output writing, time unit, geophysical variables to be written, etc. Each new geophysical variables added here have to be defined in the ''field_def_physics.xml'' file.

- [[The field_def_physics.xml Input File|''field_def_physics.xml'']]: Definition of all existing variables that can be output from the physical packages interfaced with '''DYNAMICO'''. This is where you will add each geophysical fields that you want to appear in the ''Xhistins.nc'' output files. For instance, related to the ''thermal plume scheme'' using for Jupiter's tropospheric dynamics, we have added the following variables:
<syntaxhighlight lang="xml" line>
<field id="h2o_vap"
long_name="Vapor mass mixing ratio"
unit="kg/kg" />
<field id="h2o_ice"
long_name="Vapor mass mixing ratio"
unit="kg/kg" />
<field id="detr"
long_name="Detrainment"
unit="kg/m2/s" />
<field id="entr"
long_name="Entrainment"
unit="kg/m2/s" />
<field id="w_plm"
long_name="Plume vertical velocity"
unit="m/s" />
</syntaxhighlight>

- [[The_callphys.def_Input_File|''callphys.def'']]: This setting file is used either with '''DYNAMICO''' or '''LMDZ.COMMON''' and allows the user to choose the physical parametrisation schemes and their appropriate main parameter values relevant to the planet being simulated. In our case of Jupiter, there are some specific parametrisations that should be added or modified from the example given as link at the beginning of this line:
<syntaxhighlight lang="bash" line>
# Diurnal cycle ? if diurnal=false, diurnally averaged solar heating
diurnal = .false. #.true.
# Seasonal cycle ? if season=false, Ls stays constant, to value set in "start"
season = .true.
# Tidally resonant orbit ? must have diurnal=false, correct rotation rate in newstart
tlocked = .false.
# Tidal resonance ratio ? ratio T_orbit to T_rotation
nres = 1
# Planet with rings?
rings_shadow = .false.
# Compute latitude-dependent gravity field??
oblate = .true.
# Include non-zero flattening (a-b)/a?
flatten = 0.06487
# Needed if oblate=.true.: J2
J2 = 0.01470
# Needed if oblate=.true.: Planet mean radius (m)
Rmean = 69911000.
# Needed if oblate=.true.: Mass of the planet (*1e24 kg)
MassPlanet = 1898.3
# use (read/write) a startfi.nc file? (default=.true.)
startphy_file = .false.
# constant value for surface albedo (if startphy_file = .false.)
surfalbedo = 0.0
# constant value for surface emissivity (if startphy_file = .false.)
surfemis = 1.0

# the rad. transfer is computed every "iradia" physical timestep
iradia = 160
# folder in which correlated-k data is stored ?
corrkdir = Jupiter_HITRAN2012_REY_ISO_NoKarko_T460K_article2019_gauss8p8_095
# Uniform absorption coefficient in radiative transfer?
graybody = .false.
# Characteristic planetary equilibrium (black body) temperature
# This is used only in the aerosol radiative transfer setup. (see aerave.F)
tplanet = 100.
# Output global radiative balance in file 'rad_bal.out' - slow for 1D!!
meanOLR = .false.
# Variable gas species: Radiatively active ?
varactive = .false.
# Computes atmospheric specific heat capacity and
# could calculated by the dynamics, set in callphys.def or calculeted from gases.def.
# You have to choose: 0 for dynamics (3d), 1 for forced in callfis (1d) or 2: computed from gases.def (1d)
# Force_cpp and check_cpp_match are now deprecated.
cpp_mugaz_mode = 0
# Specific heat capacity in J K-1 kg-1 [only used if cpp_mugaz_mode = 1]
cpp = 11500.
# Molecular mass in g mol-1 [only used if cpp_mugaz_mode = 1]
mugaz = 2.30
### DEBUG
# To not call abort when temperature is outside boundaries:
strictboundcorrk = .false.
# To not stop run when temperature is greater than 400 K for H2-H2 CIA dataset:
strictboundcia = .false.
# Add temperature sponge effect after radiative transfer?
callradsponge = .false.

Fat1AU = 1366.0

## Other physics options
## ~~~~~~~~~~~~~~~~~~~~~
# call turbulent vertical diffusion ?
calldifv = .false.
# use turbdiff instead of vdifc ?
UseTurbDiff = .true.
# call convective adjustment ?
calladj = .true.
# call thermal plume model ?
calltherm = .true.
# call thermal conduction in the soil ?
callsoil = .false.
# Internal heat flux (matters only if callsoil=F)
intheat = 7.48
# Remove lower boundary (e.g. for gas giant sims)
nosurf = .true.
#########################################################################
## extra non-standard definitions for Earth
#########################################################################

## Thermal plume model options
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~
dvimpl = .true.
r_aspect_thermals = 2.0
tau_thermals = 0.0
betalpha = 0.9
afact = 0.7
fact_epsilon = 2.e-4
alpha_max = 0.7
fomass_max = 0.5
pres_limit = 2.e5

## Tracer and aerosol options
## ~~~~~~~~~~~~~~~~~~~~~~~~~~
# Ammonia cloud (Saturn/Jupiter)?
aeronh3 = .true.
size_nh3_cloud = 10.D-6
pres_nh3_cloud = 1.1D5 # old: 9.D4
tau_nh3_cloud = 10. # old: 15.
# Radiatively active aerosol (Saturn/Jupiter)?
aeroback2lay = .true.
optprop_back2lay_vis = optprop_jupiter_vis_n20.dat
optprop_back2lay_ir = optprop_jupiter_ir_n20.dat
obs_tau_col_tropo = 4.0
size_tropo = 5.e-7
pres_bottom_tropo = 8.0D4
pres_top_tropo = 1.8D4
obs_tau_col_strato = 0.1D0
# Auroral aerosols (Saturn/Jupiter)?
aeroaurora = .false.
size_aurora = 3.e-7
obs_tau_col_aurora = 2.0

# Radiatively active CO2 aerosol?
aeroco2 = .false.
# Fixed CO2 aerosol distribution?
aerofixco2 = .false.
# Radiatively active water aerosol?
aeroh2o = .false.
# Fixed water aerosol distribution?
aerofixh2o = .false.
# basic dust opacity
dusttau = 0.0
# Varying H2O cloud fraction?
CLFvarying = .false.
# H2O cloud fraction if fixed?
CLFfixval = 0.0
# fixed radii for cloud particles?
radfixed = .false.
# number mixing ratio of CO2 ice particles
Nmix_co2 = 100000.
# number mixing ratio of water particles (for rafixed=.false.)
Nmix_h2o = 1.e7
# number mixing ratio of water ice particles (for rafixed=.false.)
Nmix_h2o_ice = 5.e5
# radius of H2O water particles (for rafixed=.true.):
rad_h2o = 10.e-6
# radius of H2O ice particles (for rafixed=.true.):
rad_h2o_ice = 35.e-6
# atm mass update due to tracer evaporation/condensation?
mass_redistrib = .false.

## Water options
## ~~~~~~~~~~~~~
# Model water cycle
water = .true.
# Model water cloud formation
watercond = .true.
# Model water precipitation (including coagulation etc.)
waterrain = .true.
# Use simple precipitation scheme?
precip_scheme = 1
# Evaporate precipitation?
evap_prec = .true.
# multiplicative constant in Boucher 95 precip scheme
Cboucher = 1.
# Include hydrology ?
hydrology = .false.
# H2O snow (and ice) albedo ?
albedosnow = 0.6
# Maximum sea ice thickness ?
maxicethick = 10.
# Freezing point of seawater (degrees C) ?
Tsaldiff = 0.0
# Evolve surface water sources ?
sourceevol = .false.

## CO2 options
## ~~~~~~~~~~~
# call CO2 condensation ?
co2cond = .false.
# Set initial temperature profile to 1 K above CO2 condensation everywhere?
nearco2cond = .false.
</syntaxhighlight>

- [[The_gases.def_Input_file|''gases.def'']]: File containing the gas composition of the atmosphere you want to model, with their molar mixing ratios.
<syntaxhighlight lang="bash" line>
# gases
5
H2_
He_
CH4
C2H2
C2H6
0.863
0.134
0.0018
1.e-7
1.e-5
# First line is number of gases
# Followed by gas names (always 3 characters)
# and then molar mixing ratios.
# mixing ratio -1 means the gas is variable.
</syntaxhighlight>

- [[The jupiter_const.def Input File|''jupiter_const.def'']]: Files that gather all orbital and physical parameters of Jupiter.

- [[The_traceur.def_Input_File|''traceur.def'']]: At this time, only two tracers are used for modelling Jupiter atmosphere, so the ''traceur.def'' file is summed up as follow
<syntaxhighlight lang="bash" line>
2
h2o_vap
h2o_ice
</syntaxhighlight>

''' Two additional files are used to set the running parameter of the simulation itself:'''

- [[The run_icosa.def Input File | ''run_icosa.def'']]: file containing parameters for '''ICOSAGCM''' to execute the simulation, use to determine the [[Advanced Use of the GCM | horizontal and vertical resolutions]], the number of processors, the number of subdivisions, the duration of the simulation, etc.

- ''run.def'': file which brings together all the setting files and will be reading by the interface '''ICOSA_LMDZ''' to link each part of the model ('''ICOSAGCM''', '''LMDZ.GENERIC''') with its particular setting file(s) when the library '''XIOS''' does not take action (through the ''.xml'' files).
<syntaxhighlight lang="bash" line>
###########################################################################
### INCLUDE OTHER DEF FILES (physics, specific settings, etc...)
###########################################################################
INCLUDEDEF=run_icosa.def

INCLUDEDEF=jupiter_const.def

INCLUDEDEF=callphys.def

prt_level=0

## iphysiq must be same as itau_physics
iphysiq=40
</syntaxhighlight>

== Hot Jupiter with DYNAMICO ==

Modelling the atmosphere of Hot Jupiter is challenging because of the extreme temperature conditions, and the fact that these planets are gas giants. Therefore, using a dynamical core such as Dynamico is strongly recommended. Here, we discuss how to perform a cloudless simulation of the Hot Jupiter WASP-43 b, using Dynamico.

'''1st step''': You need to go to the github mentionned previously for Dynamico: https://github.com/aymeric-spiga/dynamico-giant. ''Git clone'' this repo on your favorite cluster, and ''checkout'' to the "hot_jupiter" branch.

'''2nd step''': Now, run the install.sh script. This script will install '''all''' the required models ('''LMDZ.COMMON''', '''LMDZ.GENERIC''','''ICOSA_LMDZ''','''XIOS''','''FCM''','''ICOSAGCM'''). At this point, you only miss '''IOIPSL'''. To install it, go to
<syntaxhighlight lang="bash">
dynamico-giant/code/LMDZ.COMMON/ioipsl/
</syntaxhighlight>

There, you will find some examples of installations script. You need to create one that will work on your cluster, with your own arch files.
During the installation of '''IOIPSL''', you might be asked for a login/password. Contact TGCC computing center to get access.

'''3rd step''': Great, now we have all we need to get started. Navigate to the ''hot_jupiter'' folder. You will find a ''compile_mesopsl.sh'' and a ''compile_occigen.sh'' script. Use them as examples to create the compile script adapted to your own cluster, then run it.
While running, I suggest that you take a look at the ''log_compile'' file. The compilation can take a while (~ 10minutes, especially because of XIOS). On quick trick to make sure that everything went right is to check the number of ''Build command finished'' messages in ''log_compile''. If everything worked out, there should be 6 of them.

'''4th step''': Okay, the model compiled, good job ! Now we need to create the initial condition for our run. In the hot_jupiter1d folder, you already have a ''temp_profile.txt'' computed with the 1D version of the LMDZ.GENERIC (see rcm1d on this page). Thus, no need to recompute a 1D model but it will be needed if you want to model another Hot Jupiter.
Navigate to the 'makestart' folder, located at
<syntaxhighlight lang="bash">
dynamico-giant/hot_jupiter/makestart/
</syntaxhighlight>
To generate the initial conditions for the 3D run, we're gonna start the model using the temperature profile from the 1D run. to do that, you will find a "job_mpi" script. Open it, and adapt it to your cluster and launch the job. This job is using 20 procs, and it runs 5 days of simulations.
If everything goes well, you should see few netcdf files appear. The important ones are '''start_icosa0.nc''', '''startfi0.nc''' and '''Xhistins.nc'''.
If you see these files, you're all set to launch a real simulation !

'''5th step''': Go back to ''hot_jupiter'' folder. There are a bunch of script to launch your simulation. Take a look at the ''astro_fat_mpi'' script, and adapt it to your cluster. Then you can launch your simulation by doing
<syntaxhighlight lang="bash">
./run_astro_fat
</syntaxhighlight>
This will start the simulation, using 90 procs. In the same folder, check if the icosa_lmdz.out file is created. This is the logfile of the simulation, while it is running. You can check there that everything is going well.

'''Important side note''': When using the ''run_astro_fat'' script to run a simulation, it will run a chained simulation, restarting the simulation from the previous state after 100 days of simulations and generating ''Xhistins.nc'' files. This is your results file, where you will find all the variables that controls your atmosphere (temperature field, wind fields, etc..).

Good luck and enjoy the generic PCM Dynamico for Hot Jupiter !

'''2nd important side note''': These 5 steps are the basic needed steps to run a simulation. If you want to tune simulations to another planet, or change other stuff, you need to take a look at '''*.def''' and '''*.xml''' files. If you're lost in all of this, take a look at the different pages of this website and/or contact us !
Also, you might want to check the wiki on the [https://github.com/aymeric-spiga/dynamico-giant ''Github''], that explains a lot of settings for Dynamico

= 3D LES setup =

== Proxima b with LES ==

To model the subgrid atmospheric turbulence, the [[WRF dynamical core for LES/mesoscale simulations|'''WRF''']] dynamical core coupled with the LMD Generic physics package is used. The first studied conducted was to resolve the convective activity of the substellar point of Proxami-b (Lefevre et al 2021). The impact of the stellar insolation and rotation period were studied. The files for the reference case, with a stellar flux of 880 W/m2 and an 11 days rotation period, are presented

The input_* file are the used to initialize the temperature, pressure, winds and moisture of the domain.
input_souding : altitude (km), potential temperature, water vapour (kg/kg), u, v
input_therm : normalized gas constant, isobaric heat capacity, pressure, density, temperature
input_hr : SW heating, LW heating, Large-scale heating extracted from the GCM. Only the last one is used in this configuration.

The file namelist.input is used to set up the domain parameters (resolution, grid points, etc). The file levels specifies the eta-levels of the vertical domain.

Planet is used set up the atmospheric parameters, in order : gravity (m/s2), isobaric heat capacity (J/kg/K), molecular mass (g/mol), reference temperature (K), surface pressure (Pa), planet radius (m) and planet rotation rate (s-1).

The files *.def are the parameter for the physics. Compared to GCM runs, the convective adjustment in callphys.def is turned off

The file controle.txt, equivalent of the field controle in GCM start.nc, needed to initialize some physics constants.

TBC ML

= 1D setups =

== rcm1d program ==

Running the model in 1D (i.e. considering simply a column of atmosphere) is a common first step to test a new setup. To do so, you first have to compile the 1D version of the model. The command line is very similar to [[Quick_Install_and_Run#Compiling a test case (early Mars)|the one for the 3D]], except for 2 changes:
# put just the vertical resolution after the -d option ("VERT" instead of ''LON''x''LAT''x''VERT'' for the 3D case)
# at the end of the line, replace "gcm" with "rcm1d"
It will generate a file called '''rcm1d_XX_phyxxx_seq.e''', where ''XX'' and ''phyxxx'' are the vertical resolution and the physics package, respectively.

Check out the [[Generic unicolumn rcm1d program| dedicated page about rcm1d]] for more details.

Note that the '''.def''' files differ a bit from the 3D case. Indeed, the 1D run.def contains different information and needs to hold the key <code>run_1d=.true.</code>; see [[The_rcm1d.def_Input_File|'''run.def''']]. In addition, the 1D model generally does not use [[The_start.nc_and_startfi.nc_input_files|'''start.nc''']] or [[The_start.nc_and_startfi.nc_input_files|'''startfi.nc''']] files to initialize. You can find examples of 1D configuration in ''LMDZ.GENERIC/deftank'' (e.g. '''run.def.earlymars1d''', '''run.def.earth1d'''), the best thing is to have a look at them.

== kcm1d program ==

Our 1-D inverse model

TBD by Guillaume or Martin

[[Category:Generic-Model]]
[[Category:Generic-LMDZ]]
[[Category:Generic-DYNAMICO]]
[[Category:Generic-WRF]]
[[Category:Generic-1D]]

Other GCM Configurations worth knowing about

2026-06-12T13:29:19Z

Jbclement: /* rcm1d program */

= 3D lon-lat LMDZ setup =

== early Mars ==

It is already described in the [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Quick_Install_and_Run ''Quick Install and Run''] section.

== Earth with slab ocean ==

TBD by Siddharth, once all changes have been committed (also need a validation of the model on Earth to be sure)

== TRAPPIST-1e with photochemistry ==

A temperate rocky planet in synchronous rotation around a low mass star.

Here is an example to simulate the planet TRAPPIST-1e with an Earth atmosphere using the photochemical module of the GCM.

To install the model and run it, follow [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Quick_Install_and_Run ''Quick Install and Run''] but with the following changes:

=== GCM Input Datafiles and Datasets ===
Section [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php?title=Quick_Install_and_Run&action=edit&section=9 ''GCM Input Datafiles and Datasets''] download the TRAPPIST-1e files (instead of the early Mars files):
<syntaxhighlight lang="bash">
wget -nv --no-check-certificate https://web.lmd.jussieu.fr/~lmdz/planets/generic/reference_setups/bench_trappist1e_photochemistry_64x48x30_b38x36.tar.gz
</syntaxhighlight>

You can find the same type of file with the additional folder containing the chemical network file:
<syntaxhighlight lang="bash">
callphys.def gases.def startfi.nc traceur.def
datadir/ run.def start.nc z2sig.def
chemnetwork/
</syntaxhighlight>

=== Compiling the GCM ===
==== Prior to a first compilation: setting up the target architecture files ====
The chemical solver require the libraries BLAS and LAPACK which need to be specified in the '''arch*.fcm''' file:
<syntaxhighlight lang="bash">
%COMPILER gfortran
%LINK gfortran
%AR ar
%MAKE make
%FPP_FLAGS -P -traditional
%FPP_DEF NC_DOUBLE LAPACK BLAS SGEMV=DGEMV SGEMM=DGEMM
%BASE_FFLAGS -c -fdefault-real-8 -fdefault-double-8 -ffree-line-length-none -fno-align-commons
%PROD_FFLAGS -O3
%DEV_FFLAGS -O
%DEBUG_FFLAGS -ffpe-trap=invalid,zero,overflow -fbounds-check -g3 -O0 -fstack-protector-all -finit-real=snan -fbacktrace
%MPI_FFLAGS
%OMP_FFLAGS
%BASE_LD -llapack -lblas
%MPI_LD
%OMP_LD
</syntaxhighlight>

==== Specific to photochemistry: set hard coded reactions ====
In '''/LMDZ.GENERIC/libf/aeronogeneric/chimiedata_h.F90''' you can hard code reaction if needed, for instance because the reaction rate is very specific and out of the generic formula or your photochemical reaction does not use a regular cross section.

The TRAPPIST-1e test case use 3 hard coded reactions.

*Uncomment the following lines to fill reaction species indexes:
<syntaxhighlight lang="bash">
!===========================================================
! r001 : HNO3 + rain -> H2O
!===========================================================
nb_phot = nb_phot + 1
indice_phot(nb_phot) = z3spec(1.0, indexchim('hno3'), 1.0, indexchim('h2o_vap'), 0.0, 1)

!===========================================================
! e001 : CO + OH -> CO2 + H
!===========================================================
nb_reaction_4 = nb_reaction_4 + 1
indice_4(nb_reaction_4) = z4spec(1.0, indexchim('co'), 1.0, indexchim('oh'), 1.0, indexchim('co2'), 1.0, indexchim('h'))

!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
! photodissociation of NO : NO + hv -> N + O
!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
nb_phot = nb_phot + 1
indice_phot(nb_phot) = z3spec(1.0, indexchim('no'), 1.0, indexchim('n'), 1.0, indexchim('o'))
</syntaxhighlight>

*Uncomment the following lines to fill reaction rates:
<syntaxhighlight lang="bash">
!----------------------------------------------------------------------
! carbon reactions
!----------------------------------------------------------------------

!--- e001: oh + co -> co2 + h

nb_reaction_4 = nb_reaction_4 + 1

! joshi et al., 2006

do ilev = 1,nlayer
k1a0 = 1.34*2.5*dens(ilev) &
*1/(1/(3.62e-26*t(ilev)**(-2.739)*exp(-20./t(ilev))) &
+ 1/(6.48e-33*t(ilev)**(0.14)*exp(-57./t(ilev)))) ! typo in paper corrected
k1b0 = 1.17e-19*t(ilev)**(2.053)*exp(139./t(ilev)) &
+ 9.56e-12*t(ilev)**(-0.664)*exp(-167./t(ilev))
k1ainf = 1.52e-17*t(ilev)**(1.858)*exp(28.8/t(ilev)) &
+ 4.78e-8*t(ilev)**(-1.851)*exp(-318./t(ilev))
x = k1a0/(k1ainf - k1b0)
y = k1b0/(k1ainf - k1b0)
fc = 0.628*exp(-1223./t(ilev)) + (1. - 0.628)*exp(-39./t(ilev)) &
+ exp(-t(ilev)/255.)
fx = fc**(1./(1. + (alog(x))**2)) ! typo in paper corrected
k1a = k1a0*((1. + y)/(1. + x))*fx
k1b = k1b0*(1./(1.+x))*fx

v_4(ilev,nb_reaction_4) = k1a + k1b
end do

!----------------------------------------------------------------------
! washout r001 : HNO3 + rain -> H2O
!----------------------------------------------------------------------

nb_phot = nb_phot + 1

rain_h2o = 100.e-6
!rain_rate = 1.e-6 ! 10 days
rain_rate = 1.e-8

do ilev = 1,nlayer
if (c(ilev,indexchim('h2o_vap'))/dens(ilev) >= rain_h2o) then
v_phot(ilev,nb_phot) = rain_rate
else
v_phot(ilev,nb_phot) = 0.
end if
end do

!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
! photodissociation of NO
!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

nb_phot = nb_phot + 1

colo3(nlayer) = 0.
! ozone columns for other levels (molecule.cm-2)
do ilev = nlayer-1,1,-1
colo3(ilev) = colo3(ilev+1) + (c(ilev+1,indexchim('o3')) + c(ilev,indexchim('o3')))*0.5*avocado*1e-4*((press(ilev) - press(ilev+1))*100.)/(1.e-3*zmmean(ilev)*g*dens(ilev))
end do
call jno(nlayer, c(nlayer:1:-1,indexchim('no')), c(nlayer:1:-1,indexchim('o2')), colo3(nlayer:1:-1), dens(nlayer:1:-1), press(nlayer:1:-1), sza, v_phot(nlayer:1:-1,nb_phot))
</syntaxhighlight>

*Change the following lines to set the number of hard coded reactions:
<syntaxhighlight lang="bash">
integer, parameter :: nphot_hard_coding = 2
integer, parameter :: n4_hard_coding = 1
integer, parameter :: n3_hard_coding = 0
</syntaxhighlight>

=== Compiling a test case (TRAPPIST-1e) ===
Change the following compiling option:
<syntaxhighlight lang="bash">
-d 64x48x30 -b 38x36
</syntaxhighlight>

NB: option -b is mandatory to change while option -d will still run with lower or higher resolution (if '''z2sig.def''' remains coherent with the number of altitude levels, meaning at least as many altitude levels defined as the number of levels wanted).

== TRAPPIST-1c in Venus-like conditions ==

A warm rocky planet in synchronous rotation around a low mass star. Here we provide an '''example''' to simulate the atmosphere of Trappist-1c, assuming it evolved to a modern Venus-like atmosphere.

The planetary parameters are taken from [https://arxiv.org/abs/2010.01074 Algol et al. 2021] and can be found in this table [[Media:Planetary_parameters_Trappist1c.png]]

First, install the model and run it, following [[Quick Install and Run]] but instead of ''Early Mars files'', please download ''bench_trappist1c_64x48x50_b32x36'' using this command:

<syntaxhighlight lang="bash">
wget -nv --no-check-certificate https://web.lmd.jussieu.fr/~lmdz/planets/generic/reference_setups/bench_trappist1c_64x48x50_b32x36.tar.gz
</syntaxhighlight>

=== Compiling a test case (TRAPPIST-1c) ===
Change the following compiling option:
<syntaxhighlight lang="bash">
-d 64x48x50 -b 32x36
</syntaxhighlight>

You can find the same type of ASCII *def files than in the case of ''Early Mars'', but adapted to the planet's characteristics and orbital parameters of Trappist 1c.
In particular ''callphys.def'' contains the following changes:

* The planet is assumed to be in 1:1 spin-orbit resonance, therefore
diurnal = .false.
tlocked = .true.
* The planet equilibrium temperature is about 342 K
tplanet = 341.9
* The host star is TRAPPIST1, with a stellar flux at 1 AU of 0.7527 [W m-2]
stelspec_file = spectrum_TRAPPIST1_2022.dat
tstellar = 2600.
Fat1AU = 0.7527
* Fixed aerosol distribution, no radiative active tracers (no evaporation/condensation of H2O and CO2):
aerofixed = .true.
aeroco2 = .false.
aeroh2o = .false.
* No water cycle model, no water cloud formation or water precipitation, no CO2 condensation:
water = .false.
watercond = .false.
waterrain = .false.
hydrology = .false.
nonideal = .true.
co2cond = .false.
* Following [https://www.sciencedirect.com/science/article/pii/S0032063313002596?via%3Dihub Haus et al. 2015] a prescribed radiatively active cloud model is included.
It can be activated/deactivated with the flag ''aerovenus''.
aerovenus = .true.
* Mode 1, 2, 2p, 3 and the "unknown" UV absorber can be included/excluded by setting to true/false the following keywords. The characteristics of each mode (e.g. effect radius, effective variance) are based on Venus Express/ESA observations and can be found in this table [[Media:Table1 aerosolVenus trappist1c.png]]
aerovenus1 = .true.
aerovenus2 = .true.
aerovenus2p = .true.
aerovenus3 = .true.
aerovenusUV = .true.

The cloud model is prescribed from 1 to 0.037 ''bar'' pressure layers. For each mode, the top/bottom pressure can be modified by hard-coding model routine ''aerosol_opacity.F90''.
Here below an example for mode 1 particles, where the top pressure layer and bottom pressure layer are prescribed at 0.1 bar and 1 bar, respectively:

<syntaxhighlight lang="bash">

! 1. Initialization
aerosol(1:ngrid,1:nlayer,iaer)=0.0
p_bot = 1.e5 ! bottom pressure [Pa]
p_top = 1.e4
h_bot = 1.0e3 ! bottom scale height [m]
h_top = 5.0e3
</syntaxhighlight>

'''TO BE COMPLETED BY GABRIELLA'''

== mini-Neptune GJ1214b ==

A warm mini-Neptune

'''TO BE COMPLETED BY BENJAMIN'''

= 3D DYNAMICO setup =

Due to the rich dynamical activities in their atmospheres (banded zonal jets, eddies, vortices, storms, equatorial oscillations,...) resulting from multi-scale dynamic interactions, the Global Climate Modelling of the giant planet requires to resolve eddies arising from hydrodynamical instabilities to correctly establish the planetary-scaled jets regime. To this purpose, their Rossby radius deformation $$L_D$$, which is the length scale at which rotational effects become as important as buoyancy or gravity wave effects in the evolution of the flow about some disturbance, is calculated to determine the most suitable horizontal grid resolution. At mid-latitude range, for the giant planets, $$L_D$$ is of the same order of magnitude as that of the Earth. As the giant planets have a size of roughly 10 times the Earth size (i.e., Jupiter and Saturn), the modelling grid must be of a horizontal resolution of 0.5$$^{\circ}$$ over longitude and latitude (vs 5$$^{\circ}$$ for the Earth), considering 3 grid points to resolved $$L_D$$.
Moreover, to have a chance to model the equatorial oscillation, meridional cell circulations and/or a seasonal inter-hemispheric circulation, a giant planet GCM must also include a high vertical resolution. Indeed, these climate phenomena have been studied for decades for the Earth's atmosphere, and result from small- and large-scale interactions between the troposphere and stratosphere. This implies that the propagation of dynamic instabilities, waves and turbulence should be resolved as far as possible along the vertical. Contrary to horizontal resolution, it doesn't really exist a criterion (similar to $$L_D$$) to determine the most suitable vertical grid resolution and still an adjustable parameter according to the processes to be represented. However, we advise the user to set a vertical resolution of at least 5 grid points per scale height as first stage.
Finally, these atmospheres are cold, with long radiative response time which needs radiative transfer computations over decade-long years of Jupiter (given that a Jupiter year $$\approx$$ 12 Earth years), Saturn ( a Saturn year $$\approx$$ 30 Earth years), Uranus (a Uranus year $$\approx$$ 84 earth years) or Neptune (a Neptune year $$\approx$$ 169 Earth years), depending on the chosen planet.

To be able to deal with these three -- and non-exhaustive -- requirements to build a giant planet GCM, we need massive computational ressources. For this, we use a dynamical core suitable and numerically stable for massive parallel ressource computations: [[The_DYNAMICO_dynamical_core | DYNAMICO]] [Dubos et al,. 2015].

In these two following subsections, we purpose an example of installation for Jupiter and a Hot Jupiter. All the install, compiling, setting and parameters files for each giant planets could be found on: https://gitlab.in2p3.fr/aymeric.spiga/dynamico-giant (the old repo is archived as read-only https://github.com/aymeric-spiga/dynamico-giant)

The [[Dynamico-giant | DYNAMICO-giant wiki is here]]

If you have already downloaded '''LMDZ.COMMON''', '''LMDZ.GENERIC''', '''IOIPSL''', '''ARCH''', you only have to download:

'''ICOSAGCM''': the DYNAMICO dynamical core
<syntaxhighlight lang="bash">
git clone https://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico.git ICOSAGCM
cd ICOSAGCM
git checkout 110016896ae9e85e614af43223b18fe38f211020 # Version du 6 nov. 2024
</syntaxhighlight>

'''ICOSA_LMDZ''': the interface using to link LMDZ.GENERIC physical packages and ICOSAGCM
<syntaxhighlight lang="bash">
svn update -r 3729 -q ICOSA_LMDZ # Version du 18 avr. 2025
</syntaxhighlight>

'''XIOS (XML Input Output Server)''': the library to interpolate input/output fields between the icosahedral and longitude/latitude regular grids on fly
<syntaxhighlight lang="bash">
svn co -r 2626 -q http://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/trunk XIOS # Version du 22 mar. 2024
</syntaxhighlight>

If you haven't already download '''LMDZ.COMMON''', '''LMDZ.GENERIC''', '''IOIPSL''', '''ARCH''', you can use the '''install.sh''' script provided by the GitLab repository.

Once each part of the GCM is downloaded, you are able to compile it.
Firstly, you have to define your [[The_Target_Architecture_("arch")_Files | target architecture file ]] (hereafter named YOUR_ARCH_FILE) where you will fill in all the necessary information about the local environment, where libraries are located, which compiler, and compiler options will be used, etc.
Some architecture files related to specific machines are provided in the '''ARCH''' directory, which are referenced in the following lines without the prefix 'arch-' (i.e., arch-X64_IRENE-AMD.env will be referenced as X64_IRENE-AMD).

The main specificity of DYNAMICO-giant is that every main parts of the model ('''ICOSAGCM''', '''LMDZ.COMMON''' and '''LMDZ.GENERIC''') are compiled as libraries, and settings and running configuration are managed by the '''ICOSA_LMDZ''' interface.

First, you have to compile '''IOIPSL''',
<syntaxhighlight lang="bash">
cd LMDZ.COMMON/ioipsl/
./install_ioipsl_YOUR-MACHINE.bash
cd ../../
</syntaxhighlight>
then '''XIOS''' library,
<syntaxhighlight lang="bash">
cd XIOS/
./make_xios --prod --arch YOUR_ARCH_FILE --arch_path ../ARCH --job 8 --full
cd -
</syntaxhighlight>
the physics packaging,
<syntaxhighlight lang="bash">
cd LMDZ.COMMON/
./makelmdz_fcm -p generic -p_opt "-b 20x25" -prod -parallel mpi -libphy -io xios -arch YOUR_ARCH_FILE -arch_path ../ARCH -j 8 -full
cd -
</syntaxhighlight>
the dynamical core '''DYNAMICO''' (located in '''ICOSAGCM''' directory, named from the icosahedral shape of the horizontal mesh),
<syntaxhighlight lang="bash">
cd ICOSAGCM/
./make_icosa -prod -parallel mpi -external_ioipsl -with_xios -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -full
cd -
</syntaxhighlight>
and finally the '''ICOSA_LMDZ''' interface
<syntaxhighlight lang="bash">
cd ICOSA_LMDZ/
./make_icosa_lmdz -p generic -p_opt "-b 20x25" -parallel mpi -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -nodeps
</syntaxhighlight>
This last step is a bit redundant with the two previous one, hence ''make_icosa_lmdz'' will execute ''./make_icosa'' (in the '''ICOSAGCM''' directory) and ''./makelmdz_fcm'' (in the '''LMDZ.COMMON''' directory) to create and source the architecture files shared between all parts of the model, as well as create the intermediate file ''config.fcm''. As you have already compiled these two elements, ''make_icosa_lmdz'' should only create the linked architecture files, ''config.fcm'' and compile the interface. Here, ''-nodeps'' option prevents the checking of XIOS and IOIPSL compilation, which saves you from recompiling these two elements again.

Finally, your executable programs should appeared in '''ICOSA_LMDZ/bin''' subdirectory, as '''icosa_lmdz.exe''' and in '''XIOS/bin''' subdirectory, as '''xios_server.exe'''

All these compiling steps are summed up in ''make_isoca_lmdz'' program that should be adapted to your own computational settings (i.e., through you target architecture file).
<syntaxhighlight lang="bash">
./make_icosa_lmdz -p generic -p_opt "-b 20x25" -parallel mpi -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -full
</syntaxhighlight>
Here, ''-full'' option assure the compilation of each part ('''IOIPSL''', '''XIOS''', '''LMDZ.COMMON''', '''ICOSAGCM''' and '''ICOSA_LMDZ''') of the model.

Now you can move your two executable files to your working directory and start to run your own simulation of Jupiter or a Hot Jupiter, as what follows.

Note: If you are using the GitLab file architecture (https://gitlab.in2p3.fr/aymeric.spiga/dynamico-giant), you should be able to compile the model directly from your working directory (for instance ''dynamico-giant/jupiter/'') by using the ''compile_occigen.sh'' program, which has to be adapted to your machine/cluster.

''Note 2 : Depending on the compiler module you use, especially with gfortran, you may need to modify the tracers_icosa.F90 file located in the src directory in order to successfully compile ICOSAGCM. For example, if you are using GCC/11.3.0 and OpenMPI/4.1.4, you must update the insert_tracer_output subroutine as follows:''
<syntaxhighlight lang="fortran">
SUBROUTINE insert_tracer_output
USE xios_mod
USE grid_param
IMPLICIT NONE
TYPE(xios_fieldgroup) :: fieldgroup_hdl
TYPE(xios_field) :: field_hdl
INTEGER :: iq
CHARACTER(len=1000) :: tracername1
CHARACTER(len=1000) :: tracername2
CHARACTER(len=1000) :: tracername3

CALL xios_get_handle("standard_output_tracers", fieldgroup_hdl)
DO iq = 1, nqtot
tracername1 = "tracer_"//TRIM(tracers(iq)%name)
CALL xios_add_child(fieldgroup_hdl, field_hdl, tracername1)
CALL xios_set_attr(field_hdl, name=TRIM(tracers(iq)%name))
END DO

CALL xios_get_handle("standard_output_tracers_init", fieldgroup_hdl)
DO iq = 1, nqtot
tracername2 = "tracer_"//TRIM(tracers(iq)%name)//"_init"
tracername3 = TRIM(tracers(iq)%name)//"_init"
CALL xios_add_child(fieldgroup_hdl, field_hdl, tracername2)
CALL xios_set_attr(field_hdl, name=tracername3)
END DO

END SUBROUTINE insert_tracer_output
</syntaxhighlight>

== Jupiter with DYNAMICO ==
Using a new dynamical core implies new setting files, in addition or as a replacement of those relevant to '''LMDZ.COMMON''' dynamical core using.

There are two kind of setting files:

'''A first group relevant to DYNAMICO:'''

- [[The ''context_dynamico.xml'' Input File|''context_dynamico.xml'']]: Configuration file for '''DYNAMICO''' for reading and writing files using '''XIOS''', mainly used when you want to check the installation of '''ICOSAGCM''' with [[The_DYNAMICO_dynamical_core | an ''Held and Suarez'' test case]]. When your installation, compilation and run environment is fully functional, the dynamic core output files will not (necessarily) be useful and you can disable their writing.

- [[The context_input_dynamico.xml Input File|''context_input_dynamico.xml'']]:

- [[The file_def_dynamico.xml Input File|''file_def_dynamico.xml'']]: Definition of output diagnostic files which will be written into the output files only related to '''ICOSAGCM'''.

- [[The field_def_dynamico.xml Input File|''field_def_dynamico.xml'']]: Definition of all existing variables that can be output from DYNAMICO.

- [[The tracer.def Input File|''tracer.def'']]: Definition of the name and physico-chemical properties of the tracers which will be advected by the dynamical core. For now, there is two files related to tracers, we are working to harmonise it.

''' A second group relevant to LMDZ.GENERIC physical packages: '''

- [[The context_lmdz_physics.xml Input File|''context_lmdz_physics.xml'']]: File in which are defined the horizontal grid, vertical coordinate, output file(s) definition, with the setting of frequency output writing, time unit, geophysical variables to be written, etc. Each new geophysical variables added here have to be defined in the ''field_def_physics.xml'' file.

- [[The field_def_physics.xml Input File|''field_def_physics.xml'']]: Definition of all existing variables that can be output from the physical packages interfaced with '''DYNAMICO'''. This is where you will add each geophysical fields that you want to appear in the ''Xhistins.nc'' output files. For instance, related to the ''thermal plume scheme'' using for Jupiter's tropospheric dynamics, we have added the following variables:
<syntaxhighlight lang="xml" line>
<field id="h2o_vap"
long_name="Vapor mass mixing ratio"
unit="kg/kg" />
<field id="h2o_ice"
long_name="Vapor mass mixing ratio"
unit="kg/kg" />
<field id="detr"
long_name="Detrainment"
unit="kg/m2/s" />
<field id="entr"
long_name="Entrainment"
unit="kg/m2/s" />
<field id="w_plm"
long_name="Plume vertical velocity"
unit="m/s" />
</syntaxhighlight>

- [[The_callphys.def_Input_File|''callphys.def'']]: This setting file is used either with '''DYNAMICO''' or '''LMDZ.COMMON''' and allows the user to choose the physical parametrisation schemes and their appropriate main parameter values relevant to the planet being simulated. In our case of Jupiter, there are some specific parametrisations that should be added or modified from the example given as link at the beginning of this line:
<syntaxhighlight lang="bash" line>
# Diurnal cycle ? if diurnal=false, diurnally averaged solar heating
diurnal = .false. #.true.
# Seasonal cycle ? if season=false, Ls stays constant, to value set in "start"
season = .true.
# Tidally resonant orbit ? must have diurnal=false, correct rotation rate in newstart
tlocked = .false.
# Tidal resonance ratio ? ratio T_orbit to T_rotation
nres = 1
# Planet with rings?
rings_shadow = .false.
# Compute latitude-dependent gravity field??
oblate = .true.
# Include non-zero flattening (a-b)/a?
flatten = 0.06487
# Needed if oblate=.true.: J2
J2 = 0.01470
# Needed if oblate=.true.: Planet mean radius (m)
Rmean = 69911000.
# Needed if oblate=.true.: Mass of the planet (*1e24 kg)
MassPlanet = 1898.3
# use (read/write) a startfi.nc file? (default=.true.)
startphy_file = .false.
# constant value for surface albedo (if startphy_file = .false.)
surfalbedo = 0.0
# constant value for surface emissivity (if startphy_file = .false.)
surfemis = 1.0

# the rad. transfer is computed every "iradia" physical timestep
iradia = 160
# folder in which correlated-k data is stored ?
corrkdir = Jupiter_HITRAN2012_REY_ISO_NoKarko_T460K_article2019_gauss8p8_095
# Uniform absorption coefficient in radiative transfer?
graybody = .false.
# Characteristic planetary equilibrium (black body) temperature
# This is used only in the aerosol radiative transfer setup. (see aerave.F)
tplanet = 100.
# Output global radiative balance in file 'rad_bal.out' - slow for 1D!!
meanOLR = .false.
# Variable gas species: Radiatively active ?
varactive = .false.
# Computes atmospheric specific heat capacity and
# could calculated by the dynamics, set in callphys.def or calculeted from gases.def.
# You have to choose: 0 for dynamics (3d), 1 for forced in callfis (1d) or 2: computed from gases.def (1d)
# Force_cpp and check_cpp_match are now deprecated.
cpp_mugaz_mode = 0
# Specific heat capacity in J K-1 kg-1 [only used if cpp_mugaz_mode = 1]
cpp = 11500.
# Molecular mass in g mol-1 [only used if cpp_mugaz_mode = 1]
mugaz = 2.30
### DEBUG
# To not call abort when temperature is outside boundaries:
strictboundcorrk = .false.
# To not stop run when temperature is greater than 400 K for H2-H2 CIA dataset:
strictboundcia = .false.
# Add temperature sponge effect after radiative transfer?
callradsponge = .false.

Fat1AU = 1366.0

## Other physics options
## ~~~~~~~~~~~~~~~~~~~~~
# call turbulent vertical diffusion ?
calldifv = .false.
# use turbdiff instead of vdifc ?
UseTurbDiff = .true.
# call convective adjustment ?
calladj = .true.
# call thermal plume model ?
calltherm = .true.
# call thermal conduction in the soil ?
callsoil = .false.
# Internal heat flux (matters only if callsoil=F)
intheat = 7.48
# Remove lower boundary (e.g. for gas giant sims)
nosurf = .true.
#########################################################################
## extra non-standard definitions for Earth
#########################################################################

## Thermal plume model options
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~
dvimpl = .true.
r_aspect_thermals = 2.0
tau_thermals = 0.0
betalpha = 0.9
afact = 0.7
fact_epsilon = 2.e-4
alpha_max = 0.7
fomass_max = 0.5
pres_limit = 2.e5

## Tracer and aerosol options
## ~~~~~~~~~~~~~~~~~~~~~~~~~~
# Ammonia cloud (Saturn/Jupiter)?
aeronh3 = .true.
size_nh3_cloud = 10.D-6
pres_nh3_cloud = 1.1D5 # old: 9.D4
tau_nh3_cloud = 10. # old: 15.
# Radiatively active aerosol (Saturn/Jupiter)?
aeroback2lay = .true.
optprop_back2lay_vis = optprop_jupiter_vis_n20.dat
optprop_back2lay_ir = optprop_jupiter_ir_n20.dat
obs_tau_col_tropo = 4.0
size_tropo = 5.e-7
pres_bottom_tropo = 8.0D4
pres_top_tropo = 1.8D4
obs_tau_col_strato = 0.1D0
# Auroral aerosols (Saturn/Jupiter)?
aeroaurora = .false.
size_aurora = 3.e-7
obs_tau_col_aurora = 2.0

# Radiatively active CO2 aerosol?
aeroco2 = .false.
# Fixed CO2 aerosol distribution?
aerofixco2 = .false.
# Radiatively active water aerosol?
aeroh2o = .false.
# Fixed water aerosol distribution?
aerofixh2o = .false.
# basic dust opacity
dusttau = 0.0
# Varying H2O cloud fraction?
CLFvarying = .false.
# H2O cloud fraction if fixed?
CLFfixval = 0.0
# fixed radii for cloud particles?
radfixed = .false.
# number mixing ratio of CO2 ice particles
Nmix_co2 = 100000.
# number mixing ratio of water particles (for rafixed=.false.)
Nmix_h2o = 1.e7
# number mixing ratio of water ice particles (for rafixed=.false.)
Nmix_h2o_ice = 5.e5
# radius of H2O water particles (for rafixed=.true.):
rad_h2o = 10.e-6
# radius of H2O ice particles (for rafixed=.true.):
rad_h2o_ice = 35.e-6
# atm mass update due to tracer evaporation/condensation?
mass_redistrib = .false.

## Water options
## ~~~~~~~~~~~~~
# Model water cycle
water = .true.
# Model water cloud formation
watercond = .true.
# Model water precipitation (including coagulation etc.)
waterrain = .true.
# Use simple precipitation scheme?
precip_scheme = 1
# Evaporate precipitation?
evap_prec = .true.
# multiplicative constant in Boucher 95 precip scheme
Cboucher = 1.
# Include hydrology ?
hydrology = .false.
# H2O snow (and ice) albedo ?
albedosnow = 0.6
# Maximum sea ice thickness ?
maxicethick = 10.
# Freezing point of seawater (degrees C) ?
Tsaldiff = 0.0
# Evolve surface water sources ?
sourceevol = .false.

## CO2 options
## ~~~~~~~~~~~
# call CO2 condensation ?
co2cond = .false.
# Set initial temperature profile to 1 K above CO2 condensation everywhere?
nearco2cond = .false.
</syntaxhighlight>

- [[The_gases.def_Input_file|''gases.def'']]: File containing the gas composition of the atmosphere you want to model, with their molar mixing ratios.
<syntaxhighlight lang="bash" line>
# gases
5
H2_
He_
CH4
C2H2
C2H6
0.863
0.134
0.0018
1.e-7
1.e-5
# First line is number of gases
# Followed by gas names (always 3 characters)
# and then molar mixing ratios.
# mixing ratio -1 means the gas is variable.
</syntaxhighlight>

- [[The jupiter_const.def Input File|''jupiter_const.def'']]: Files that gather all orbital and physical parameters of Jupiter.

- [[The_traceur.def_Input_File|''traceur.def'']]: At this time, only two tracers are used for modelling Jupiter atmosphere, so the ''traceur.def'' file is summed up as follow
<syntaxhighlight lang="bash" line>
2
h2o_vap
h2o_ice
</syntaxhighlight>

''' Two additional files are used to set the running parameter of the simulation itself:'''

- [[The run_icosa.def Input File | ''run_icosa.def'']]: file containing parameters for '''ICOSAGCM''' to execute the simulation, use to determine the [[Advanced Use of the GCM | horizontal and vertical resolutions]], the number of processors, the number of subdivisions, the duration of the simulation, etc.

- ''run.def'': file which brings together all the setting files and will be reading by the interface '''ICOSA_LMDZ''' to link each part of the model ('''ICOSAGCM''', '''LMDZ.GENERIC''') with its particular setting file(s) when the library '''XIOS''' does not take action (through the ''.xml'' files).
<syntaxhighlight lang="bash" line>
###########################################################################
### INCLUDE OTHER DEF FILES (physics, specific settings, etc...)
###########################################################################
INCLUDEDEF=run_icosa.def

INCLUDEDEF=jupiter_const.def

INCLUDEDEF=callphys.def

prt_level=0

## iphysiq must be same as itau_physics
iphysiq=40
</syntaxhighlight>

== Hot Jupiter with DYNAMICO ==

Modelling the atmosphere of Hot Jupiter is challenging because of the extreme temperature conditions, and the fact that these planets are gas giants. Therefore, using a dynamical core such as Dynamico is strongly recommended. Here, we discuss how to perform a cloudless simulation of the Hot Jupiter WASP-43 b, using Dynamico.

'''1st step''': You need to go to the github mentionned previously for Dynamico: https://github.com/aymeric-spiga/dynamico-giant. ''Git clone'' this repo on your favorite cluster, and ''checkout'' to the "hot_jupiter" branch.

'''2nd step''': Now, run the install.sh script. This script will install '''all''' the required models ('''LMDZ.COMMON''', '''LMDZ.GENERIC''','''ICOSA_LMDZ''','''XIOS''','''FCM''','''ICOSAGCM'''). At this point, you only miss '''IOIPSL'''. To install it, go to
<syntaxhighlight lang="bash">
dynamico-giant/code/LMDZ.COMMON/ioipsl/
</syntaxhighlight>

There, you will find some examples of installations script. You need to create one that will work on your cluster, with your own arch files.
During the installation of '''IOIPSL''', you might be asked for a login/password. Contact TGCC computing center to get access.

'''3rd step''': Great, now we have all we need to get started. Navigate to the ''hot_jupiter'' folder. You will find a ''compile_mesopsl.sh'' and a ''compile_occigen.sh'' script. Use them as examples to create the compile script adapted to your own cluster, then run it.
While running, I suggest that you take a look at the ''log_compile'' file. The compilation can take a while (~ 10minutes, especially because of XIOS). On quick trick to make sure that everything went right is to check the number of ''Build command finished'' messages in ''log_compile''. If everything worked out, there should be 6 of them.

'''4th step''': Okay, the model compiled, good job ! Now we need to create the initial condition for our run. In the hot_jupiter1d folder, you already have a ''temp_profile.txt'' computed with the 1D version of the LMDZ.GENERIC (see rcm1d on this page). Thus, no need to recompute a 1D model but it will be needed if you want to model another Hot Jupiter.
Navigate to the 'makestart' folder, located at
<syntaxhighlight lang="bash">
dynamico-giant/hot_jupiter/makestart/
</syntaxhighlight>
To generate the initial conditions for the 3D run, we're gonna start the model using the temperature profile from the 1D run. to do that, you will find a "job_mpi" script. Open it, and adapt it to your cluster and launch the job. This job is using 20 procs, and it runs 5 days of simulations.
If everything goes well, you should see few netcdf files appear. The important ones are '''start_icosa0.nc''', '''startfi0.nc''' and '''Xhistins.nc'''.
If you see these files, you're all set to launch a real simulation !

'''5th step''': Go back to ''hot_jupiter'' folder. There are a bunch of script to launch your simulation. Take a look at the ''astro_fat_mpi'' script, and adapt it to your cluster. Then you can launch your simulation by doing
<syntaxhighlight lang="bash">
./run_astro_fat
</syntaxhighlight>
This will start the simulation, using 90 procs. In the same folder, check if the icosa_lmdz.out file is created. This is the logfile of the simulation, while it is running. You can check there that everything is going well.

'''Important side note''': When using the ''run_astro_fat'' script to run a simulation, it will run a chained simulation, restarting the simulation from the previous state after 100 days of simulations and generating ''Xhistins.nc'' files. This is your results file, where you will find all the variables that controls your atmosphere (temperature field, wind fields, etc..).

Good luck and enjoy the generic PCM Dynamico for Hot Jupiter !

'''2nd important side note''': These 5 steps are the basic needed steps to run a simulation. If you want to tune simulations to another planet, or change other stuff, you need to take a look at '''*.def''' and '''*.xml''' files. If you're lost in all of this, take a look at the different pages of this website and/or contact us !
Also, you might want to check the wiki on the [https://github.com/aymeric-spiga/dynamico-giant ''Github''], that explains a lot of settings for Dynamico

= 3D LES setup =

== Proxima b with LES ==

To model the subgrid atmospheric turbulence, the [[WRF dynamical core for LES/mesoscale simulations|'''WRF''']] dynamical core coupled with the LMD Generic physics package is used. The first studied conducted was to resolve the convective activity of the substellar point of Proxami-b (Lefevre et al 2021). The impact of the stellar insolation and rotation period were studied. The files for the reference case, with a stellar flux of 880 W/m2 and an 11 days rotation period, are presented

The input_* file are the used to initialize the temperature, pressure, winds and moisture of the domain.
input_souding : altitude (km), potential temperature, water vapour (kg/kg), u, v
input_therm : normalized gas constant, isobaric heat capacity, pressure, density, temperature
input_hr : SW heating, LW heating, Large-scale heating extracted from the GCM. Only the last one is used in this configuration.

The file namelist.input is used to set up the domain parameters (resolution, grid points, etc). The file levels specifies the eta-levels of the vertical domain.

Planet is used set up the atmospheric parameters, in order : gravity (m/s2), isobaric heat capacity (J/kg/K), molecular mass (g/mol), reference temperature (K), surface pressure (Pa), planet radius (m) and planet rotation rate (s-1).

The files *.def are the parameter for the physics. Compared to GCM runs, the convective adjustment in callphys.def is turned off

The file controle.txt, equivalent of the field controle in GCM start.nc, needed to initialize some physics constants.

TBC ML

= 1D setups =

== rcm1d program ==

Running the model in 1D (i.e. considering simply a column of atmosphere) is a common first step to test a new setup. To do so, you first have to compile the 1D version of the model. The command line is very similar to [[Quick_Install_and_Run#Compiling a test case (early Mars)|the one for the 3D]], except for 2 changes:
# put just the vertical resolution after the -d option ("VERT" instead of ''LON''x''LAT''x''VERT'' for the 3D case)
# at the end of the line, replace "gcm" with "rcm1d"
It will generate a file called '''rcm1d_XX_phyxxx_seq.e''', where ''XX'' and ''phyxxx'' are the vertical resolution and the physics package, respectively.

Check out the [[Generic unicolumn rcm1d program| dedicated page about rcm1d]] for more details.

Note that the '''.def''' files differ a bit from the 3D case. Indeed, [[The_run.def_Input_File|'''run.def''']] contains different information and needs to hold the key <code>run_1d=.true.</code>; see [[The_rcm1d.def_Input_File|'''run.def''']]. In addition, the 1D model generally does not use [[The_start.nc_and_startfi.nc_input_files|'''start.nc''']] or [[The_start.nc_and_startfi.nc_input_files|'''startfi.nc''']] files to initialize. You can find examples of 1D configuration in ''LMDZ.GENERIC/deftank'' (e.g. '''run.def.earlymars1d''', '''run.def.earth1d'''), the best thing is to have a look at them.

== kcm1d program ==

Our 1-D inverse model

TBD by Guillaume or Martin

[[Category:Generic-Model]]
[[Category:Generic-LMDZ]]
[[Category:Generic-DYNAMICO]]
[[Category:Generic-WRF]]
[[Category:Generic-1D]]

Generic unicolumn rcm1d program

2026-06-12T13:17:56Z

Jbclement: /* Inputs */

It is possible to run the Gneric PCM in a uni-column (aka "single-column") configuration: this can be done via the '''rcm1d''' program; quite useful form some first studies but also when developing and testing parametrizations.

== Compilation ==
The main program '''rcm1d''' is compiled using the same compilation script, [[The makelmdz fcm GCM Compilation Script|makelmdz_fcm]], as for the 3D Generic lon-lat PCM. Nevertheless, there are few modifications:
* the ''-d'' option requires only one argument, the number of vertical levels;
* the main program to compile is ''rcm1d'' rather than ''gcm''.
So for instance to compile a case for 26 vertical levels one would run something like:
<syntaxhighlight lang="bash">
makelmdz_fcm -arch somearch -d 26 -p generic rcm1d
</syntaxhighlight>
Note that it is possible to compile and run with the XIOS library, which will require compiling in "mpi" mode (required by XIOS), even though the run will be serial:
<syntaxhighlight lang="bash">
makelmdz_fcm -arch somearch -d 26 -p generic -parallel mpi -io xios rcm1d
</syntaxhighlight>

== Inputs ==
Just like the 3D GCM, the ''rcm1d'' program needs some inputs to run. The needed files are:
* <code>z2sig.def</code> for the definition of vertical levels;
* <code>traceur.def</code> for the definition of tracers that the user wants the model to run with;
* <code>callphys.def</code> for the definition of parametrizations that the user wants the model to run with;
* <code>run.def</code> for the run configuration, which is suitable for 1D: see [[The rcm1d.def Input File]]. Especially, the 1D file has to hold the key <code>run_1d=.true.</code>.

Unlike the 3D GCMs, the ''rcm1d'' program can run without any start files, which is its default (<code>restart=.false.</code>). In this setup, one can (and often needs) needs to provide initial profiles of each tracer. These consist in files called ''profile_sometracername'' containing column-wise the initial values of the considered tracer. Then, the first line corresponds to the surface tracer and the following lines correspond to the layers. At the end of a 1D simulation, ''rcm1d'' outputs a restart file '''restart.nc''' which can be used as an initial condition for a following run.

If <code>restart=.true.</code> in <code>rcm1d.def</code> then the program will look for start files '''start.nc''' and '''startfi.nc''' and use these as initial conditions.

== Outputs ==
If compiled without XIOS then ''rcm1d'' will output <code>diagfi.nc</code> and <code>stats.nc</code> files, just like the 3D GCM and the optional <code>diagfi.def</code> and <code>stats.def</code> files can be respectively added to specify which variables need be outputted.
Likewise if compiled with XIOS then ''rcm1d'' will output all files as specified in the relevant xml files, just like the 3D GCM.

As mentioned above, at the end of a simulation <code>rcm1d</code> also outputs a '''restart.nc''' file containing the final computed state.

[[Category:Generic-Model]]
[[Category:Generic-1D]]

Other GCM Configurations worth knowing about

2026-06-12T13:17:26Z

Jbclement: /* 1D setups */

= 3D lon-lat LMDZ setup =

== early Mars ==

It is already described in the [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Quick_Install_and_Run ''Quick Install and Run''] section.

== Earth with slab ocean ==

TBD by Siddharth, once all changes have been committed (also need a validation of the model on Earth to be sure)

== TRAPPIST-1e with photochemistry ==

A temperate rocky planet in synchronous rotation around a low mass star.

Here is an example to simulate the planet TRAPPIST-1e with an Earth atmosphere using the photochemical module of the GCM.

To install the model and run it, follow [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Quick_Install_and_Run ''Quick Install and Run''] but with the following changes:

=== GCM Input Datafiles and Datasets ===
Section [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php?title=Quick_Install_and_Run&action=edit&section=9 ''GCM Input Datafiles and Datasets''] download the TRAPPIST-1e files (instead of the early Mars files):
<syntaxhighlight lang="bash">
wget -nv --no-check-certificate https://web.lmd.jussieu.fr/~lmdz/planets/generic/reference_setups/bench_trappist1e_photochemistry_64x48x30_b38x36.tar.gz
</syntaxhighlight>

You can find the same type of file with the additional folder containing the chemical network file:
<syntaxhighlight lang="bash">
callphys.def gases.def startfi.nc traceur.def
datadir/ run.def start.nc z2sig.def
chemnetwork/
</syntaxhighlight>

=== Compiling the GCM ===
==== Prior to a first compilation: setting up the target architecture files ====
The chemical solver require the libraries BLAS and LAPACK which need to be specified in the '''arch*.fcm''' file:
<syntaxhighlight lang="bash">
%COMPILER gfortran
%LINK gfortran
%AR ar
%MAKE make
%FPP_FLAGS -P -traditional
%FPP_DEF NC_DOUBLE LAPACK BLAS SGEMV=DGEMV SGEMM=DGEMM
%BASE_FFLAGS -c -fdefault-real-8 -fdefault-double-8 -ffree-line-length-none -fno-align-commons
%PROD_FFLAGS -O3
%DEV_FFLAGS -O
%DEBUG_FFLAGS -ffpe-trap=invalid,zero,overflow -fbounds-check -g3 -O0 -fstack-protector-all -finit-real=snan -fbacktrace
%MPI_FFLAGS
%OMP_FFLAGS
%BASE_LD -llapack -lblas
%MPI_LD
%OMP_LD
</syntaxhighlight>

==== Specific to photochemistry: set hard coded reactions ====
In '''/LMDZ.GENERIC/libf/aeronogeneric/chimiedata_h.F90''' you can hard code reaction if needed, for instance because the reaction rate is very specific and out of the generic formula or your photochemical reaction does not use a regular cross section.

The TRAPPIST-1e test case use 3 hard coded reactions.

*Uncomment the following lines to fill reaction species indexes:
<syntaxhighlight lang="bash">
!===========================================================
! r001 : HNO3 + rain -> H2O
!===========================================================
nb_phot = nb_phot + 1
indice_phot(nb_phot) = z3spec(1.0, indexchim('hno3'), 1.0, indexchim('h2o_vap'), 0.0, 1)

!===========================================================
! e001 : CO + OH -> CO2 + H
!===========================================================
nb_reaction_4 = nb_reaction_4 + 1
indice_4(nb_reaction_4) = z4spec(1.0, indexchim('co'), 1.0, indexchim('oh'), 1.0, indexchim('co2'), 1.0, indexchim('h'))

!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
! photodissociation of NO : NO + hv -> N + O
!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
nb_phot = nb_phot + 1
indice_phot(nb_phot) = z3spec(1.0, indexchim('no'), 1.0, indexchim('n'), 1.0, indexchim('o'))
</syntaxhighlight>

*Uncomment the following lines to fill reaction rates:
<syntaxhighlight lang="bash">
!----------------------------------------------------------------------
! carbon reactions
!----------------------------------------------------------------------

!--- e001: oh + co -> co2 + h

nb_reaction_4 = nb_reaction_4 + 1

! joshi et al., 2006

do ilev = 1,nlayer
k1a0 = 1.34*2.5*dens(ilev) &
*1/(1/(3.62e-26*t(ilev)**(-2.739)*exp(-20./t(ilev))) &
+ 1/(6.48e-33*t(ilev)**(0.14)*exp(-57./t(ilev)))) ! typo in paper corrected
k1b0 = 1.17e-19*t(ilev)**(2.053)*exp(139./t(ilev)) &
+ 9.56e-12*t(ilev)**(-0.664)*exp(-167./t(ilev))
k1ainf = 1.52e-17*t(ilev)**(1.858)*exp(28.8/t(ilev)) &
+ 4.78e-8*t(ilev)**(-1.851)*exp(-318./t(ilev))
x = k1a0/(k1ainf - k1b0)
y = k1b0/(k1ainf - k1b0)
fc = 0.628*exp(-1223./t(ilev)) + (1. - 0.628)*exp(-39./t(ilev)) &
+ exp(-t(ilev)/255.)
fx = fc**(1./(1. + (alog(x))**2)) ! typo in paper corrected
k1a = k1a0*((1. + y)/(1. + x))*fx
k1b = k1b0*(1./(1.+x))*fx

v_4(ilev,nb_reaction_4) = k1a + k1b
end do

!----------------------------------------------------------------------
! washout r001 : HNO3 + rain -> H2O
!----------------------------------------------------------------------

nb_phot = nb_phot + 1

rain_h2o = 100.e-6
!rain_rate = 1.e-6 ! 10 days
rain_rate = 1.e-8

do ilev = 1,nlayer
if (c(ilev,indexchim('h2o_vap'))/dens(ilev) >= rain_h2o) then
v_phot(ilev,nb_phot) = rain_rate
else
v_phot(ilev,nb_phot) = 0.
end if
end do

!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
! photodissociation of NO
!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

nb_phot = nb_phot + 1

colo3(nlayer) = 0.
! ozone columns for other levels (molecule.cm-2)
do ilev = nlayer-1,1,-1
colo3(ilev) = colo3(ilev+1) + (c(ilev+1,indexchim('o3')) + c(ilev,indexchim('o3')))*0.5*avocado*1e-4*((press(ilev) - press(ilev+1))*100.)/(1.e-3*zmmean(ilev)*g*dens(ilev))
end do
call jno(nlayer, c(nlayer:1:-1,indexchim('no')), c(nlayer:1:-1,indexchim('o2')), colo3(nlayer:1:-1), dens(nlayer:1:-1), press(nlayer:1:-1), sza, v_phot(nlayer:1:-1,nb_phot))
</syntaxhighlight>

*Change the following lines to set the number of hard coded reactions:
<syntaxhighlight lang="bash">
integer, parameter :: nphot_hard_coding = 2
integer, parameter :: n4_hard_coding = 1
integer, parameter :: n3_hard_coding = 0
</syntaxhighlight>

=== Compiling a test case (TRAPPIST-1e) ===
Change the following compiling option:
<syntaxhighlight lang="bash">
-d 64x48x30 -b 38x36
</syntaxhighlight>

NB: option -b is mandatory to change while option -d will still run with lower or higher resolution (if '''z2sig.def''' remains coherent with the number of altitude levels, meaning at least as many altitude levels defined as the number of levels wanted).

== TRAPPIST-1c in Venus-like conditions ==

A warm rocky planet in synchronous rotation around a low mass star. Here we provide an '''example''' to simulate the atmosphere of Trappist-1c, assuming it evolved to a modern Venus-like atmosphere.

The planetary parameters are taken from [https://arxiv.org/abs/2010.01074 Algol et al. 2021] and can be found in this table [[Media:Planetary_parameters_Trappist1c.png]]

First, install the model and run it, following [[Quick Install and Run]] but instead of ''Early Mars files'', please download ''bench_trappist1c_64x48x50_b32x36'' using this command:

<syntaxhighlight lang="bash">
wget -nv --no-check-certificate https://web.lmd.jussieu.fr/~lmdz/planets/generic/reference_setups/bench_trappist1c_64x48x50_b32x36.tar.gz
</syntaxhighlight>

=== Compiling a test case (TRAPPIST-1c) ===
Change the following compiling option:
<syntaxhighlight lang="bash">
-d 64x48x50 -b 32x36
</syntaxhighlight>

You can find the same type of ASCII *def files than in the case of ''Early Mars'', but adapted to the planet's characteristics and orbital parameters of Trappist 1c.
In particular ''callphys.def'' contains the following changes:

* The planet is assumed to be in 1:1 spin-orbit resonance, therefore
diurnal = .false.
tlocked = .true.
* The planet equilibrium temperature is about 342 K
tplanet = 341.9
* The host star is TRAPPIST1, with a stellar flux at 1 AU of 0.7527 [W m-2]
stelspec_file = spectrum_TRAPPIST1_2022.dat
tstellar = 2600.
Fat1AU = 0.7527
* Fixed aerosol distribution, no radiative active tracers (no evaporation/condensation of H2O and CO2):
aerofixed = .true.
aeroco2 = .false.
aeroh2o = .false.
* No water cycle model, no water cloud formation or water precipitation, no CO2 condensation:
water = .false.
watercond = .false.
waterrain = .false.
hydrology = .false.
nonideal = .true.
co2cond = .false.
* Following [https://www.sciencedirect.com/science/article/pii/S0032063313002596?via%3Dihub Haus et al. 2015] a prescribed radiatively active cloud model is included.
It can be activated/deactivated with the flag ''aerovenus''.
aerovenus = .true.
* Mode 1, 2, 2p, 3 and the "unknown" UV absorber can be included/excluded by setting to true/false the following keywords. The characteristics of each mode (e.g. effect radius, effective variance) are based on Venus Express/ESA observations and can be found in this table [[Media:Table1 aerosolVenus trappist1c.png]]
aerovenus1 = .true.
aerovenus2 = .true.
aerovenus2p = .true.
aerovenus3 = .true.
aerovenusUV = .true.

The cloud model is prescribed from 1 to 0.037 ''bar'' pressure layers. For each mode, the top/bottom pressure can be modified by hard-coding model routine ''aerosol_opacity.F90''.
Here below an example for mode 1 particles, where the top pressure layer and bottom pressure layer are prescribed at 0.1 bar and 1 bar, respectively:

<syntaxhighlight lang="bash">

! 1. Initialization
aerosol(1:ngrid,1:nlayer,iaer)=0.0
p_bot = 1.e5 ! bottom pressure [Pa]
p_top = 1.e4
h_bot = 1.0e3 ! bottom scale height [m]
h_top = 5.0e3
</syntaxhighlight>

'''TO BE COMPLETED BY GABRIELLA'''

== mini-Neptune GJ1214b ==

A warm mini-Neptune

'''TO BE COMPLETED BY BENJAMIN'''

= 3D DYNAMICO setup =

Due to the rich dynamical activities in their atmospheres (banded zonal jets, eddies, vortices, storms, equatorial oscillations,...) resulting from multi-scale dynamic interactions, the Global Climate Modelling of the giant planet requires to resolve eddies arising from hydrodynamical instabilities to correctly establish the planetary-scaled jets regime. To this purpose, their Rossby radius deformation $$L_D$$, which is the length scale at which rotational effects become as important as buoyancy or gravity wave effects in the evolution of the flow about some disturbance, is calculated to determine the most suitable horizontal grid resolution. At mid-latitude range, for the giant planets, $$L_D$$ is of the same order of magnitude as that of the Earth. As the giant planets have a size of roughly 10 times the Earth size (i.e., Jupiter and Saturn), the modelling grid must be of a horizontal resolution of 0.5$$^{\circ}$$ over longitude and latitude (vs 5$$^{\circ}$$ for the Earth), considering 3 grid points to resolved $$L_D$$.
Moreover, to have a chance to model the equatorial oscillation, meridional cell circulations and/or a seasonal inter-hemispheric circulation, a giant planet GCM must also include a high vertical resolution. Indeed, these climate phenomena have been studied for decades for the Earth's atmosphere, and result from small- and large-scale interactions between the troposphere and stratosphere. This implies that the propagation of dynamic instabilities, waves and turbulence should be resolved as far as possible along the vertical. Contrary to horizontal resolution, it doesn't really exist a criterion (similar to $$L_D$$) to determine the most suitable vertical grid resolution and still an adjustable parameter according to the processes to be represented. However, we advise the user to set a vertical resolution of at least 5 grid points per scale height as first stage.
Finally, these atmospheres are cold, with long radiative response time which needs radiative transfer computations over decade-long years of Jupiter (given that a Jupiter year $$\approx$$ 12 Earth years), Saturn ( a Saturn year $$\approx$$ 30 Earth years), Uranus (a Uranus year $$\approx$$ 84 earth years) or Neptune (a Neptune year $$\approx$$ 169 Earth years), depending on the chosen planet.

To be able to deal with these three -- and non-exhaustive -- requirements to build a giant planet GCM, we need massive computational ressources. For this, we use a dynamical core suitable and numerically stable for massive parallel ressource computations: [[The_DYNAMICO_dynamical_core | DYNAMICO]] [Dubos et al,. 2015].

In these two following subsections, we purpose an example of installation for Jupiter and a Hot Jupiter. All the install, compiling, setting and parameters files for each giant planets could be found on: https://gitlab.in2p3.fr/aymeric.spiga/dynamico-giant (the old repo is archived as read-only https://github.com/aymeric-spiga/dynamico-giant)

The [[Dynamico-giant | DYNAMICO-giant wiki is here]]

If you have already downloaded '''LMDZ.COMMON''', '''LMDZ.GENERIC''', '''IOIPSL''', '''ARCH''', you only have to download:

'''ICOSAGCM''': the DYNAMICO dynamical core
<syntaxhighlight lang="bash">
git clone https://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico.git ICOSAGCM
cd ICOSAGCM
git checkout 110016896ae9e85e614af43223b18fe38f211020 # Version du 6 nov. 2024
</syntaxhighlight>

'''ICOSA_LMDZ''': the interface using to link LMDZ.GENERIC physical packages and ICOSAGCM
<syntaxhighlight lang="bash">
svn update -r 3729 -q ICOSA_LMDZ # Version du 18 avr. 2025
</syntaxhighlight>

'''XIOS (XML Input Output Server)''': the library to interpolate input/output fields between the icosahedral and longitude/latitude regular grids on fly
<syntaxhighlight lang="bash">
svn co -r 2626 -q http://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/trunk XIOS # Version du 22 mar. 2024
</syntaxhighlight>

If you haven't already download '''LMDZ.COMMON''', '''LMDZ.GENERIC''', '''IOIPSL''', '''ARCH''', you can use the '''install.sh''' script provided by the GitLab repository.

Once each part of the GCM is downloaded, you are able to compile it.
Firstly, you have to define your [[The_Target_Architecture_("arch")_Files | target architecture file ]] (hereafter named YOUR_ARCH_FILE) where you will fill in all the necessary information about the local environment, where libraries are located, which compiler, and compiler options will be used, etc.
Some architecture files related to specific machines are provided in the '''ARCH''' directory, which are referenced in the following lines without the prefix 'arch-' (i.e., arch-X64_IRENE-AMD.env will be referenced as X64_IRENE-AMD).

The main specificity of DYNAMICO-giant is that every main parts of the model ('''ICOSAGCM''', '''LMDZ.COMMON''' and '''LMDZ.GENERIC''') are compiled as libraries, and settings and running configuration are managed by the '''ICOSA_LMDZ''' interface.

First, you have to compile '''IOIPSL''',
<syntaxhighlight lang="bash">
cd LMDZ.COMMON/ioipsl/
./install_ioipsl_YOUR-MACHINE.bash
cd ../../
</syntaxhighlight>
then '''XIOS''' library,
<syntaxhighlight lang="bash">
cd XIOS/
./make_xios --prod --arch YOUR_ARCH_FILE --arch_path ../ARCH --job 8 --full
cd -
</syntaxhighlight>
the physics packaging,
<syntaxhighlight lang="bash">
cd LMDZ.COMMON/
./makelmdz_fcm -p generic -p_opt "-b 20x25" -prod -parallel mpi -libphy -io xios -arch YOUR_ARCH_FILE -arch_path ../ARCH -j 8 -full
cd -
</syntaxhighlight>
the dynamical core '''DYNAMICO''' (located in '''ICOSAGCM''' directory, named from the icosahedral shape of the horizontal mesh),
<syntaxhighlight lang="bash">
cd ICOSAGCM/
./make_icosa -prod -parallel mpi -external_ioipsl -with_xios -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -full
cd -
</syntaxhighlight>
and finally the '''ICOSA_LMDZ''' interface
<syntaxhighlight lang="bash">
cd ICOSA_LMDZ/
./make_icosa_lmdz -p generic -p_opt "-b 20x25" -parallel mpi -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -nodeps
</syntaxhighlight>
This last step is a bit redundant with the two previous one, hence ''make_icosa_lmdz'' will execute ''./make_icosa'' (in the '''ICOSAGCM''' directory) and ''./makelmdz_fcm'' (in the '''LMDZ.COMMON''' directory) to create and source the architecture files shared between all parts of the model, as well as create the intermediate file ''config.fcm''. As you have already compiled these two elements, ''make_icosa_lmdz'' should only create the linked architecture files, ''config.fcm'' and compile the interface. Here, ''-nodeps'' option prevents the checking of XIOS and IOIPSL compilation, which saves you from recompiling these two elements again.

Finally, your executable programs should appeared in '''ICOSA_LMDZ/bin''' subdirectory, as '''icosa_lmdz.exe''' and in '''XIOS/bin''' subdirectory, as '''xios_server.exe'''

All these compiling steps are summed up in ''make_isoca_lmdz'' program that should be adapted to your own computational settings (i.e., through you target architecture file).
<syntaxhighlight lang="bash">
./make_icosa_lmdz -p generic -p_opt "-b 20x25" -parallel mpi -arch YOUR_ARCH_FILE -arch_path ../ARCH -job 8 -full
</syntaxhighlight>
Here, ''-full'' option assure the compilation of each part ('''IOIPSL''', '''XIOS''', '''LMDZ.COMMON''', '''ICOSAGCM''' and '''ICOSA_LMDZ''') of the model.

Now you can move your two executable files to your working directory and start to run your own simulation of Jupiter or a Hot Jupiter, as what follows.

Note: If you are using the GitLab file architecture (https://gitlab.in2p3.fr/aymeric.spiga/dynamico-giant), you should be able to compile the model directly from your working directory (for instance ''dynamico-giant/jupiter/'') by using the ''compile_occigen.sh'' program, which has to be adapted to your machine/cluster.

''Note 2 : Depending on the compiler module you use, especially with gfortran, you may need to modify the tracers_icosa.F90 file located in the src directory in order to successfully compile ICOSAGCM. For example, if you are using GCC/11.3.0 and OpenMPI/4.1.4, you must update the insert_tracer_output subroutine as follows:''
<syntaxhighlight lang="fortran">
SUBROUTINE insert_tracer_output
USE xios_mod
USE grid_param
IMPLICIT NONE
TYPE(xios_fieldgroup) :: fieldgroup_hdl
TYPE(xios_field) :: field_hdl
INTEGER :: iq
CHARACTER(len=1000) :: tracername1
CHARACTER(len=1000) :: tracername2
CHARACTER(len=1000) :: tracername3

CALL xios_get_handle("standard_output_tracers", fieldgroup_hdl)
DO iq = 1, nqtot
tracername1 = "tracer_"//TRIM(tracers(iq)%name)
CALL xios_add_child(fieldgroup_hdl, field_hdl, tracername1)
CALL xios_set_attr(field_hdl, name=TRIM(tracers(iq)%name))
END DO

CALL xios_get_handle("standard_output_tracers_init", fieldgroup_hdl)
DO iq = 1, nqtot
tracername2 = "tracer_"//TRIM(tracers(iq)%name)//"_init"
tracername3 = TRIM(tracers(iq)%name)//"_init"
CALL xios_add_child(fieldgroup_hdl, field_hdl, tracername2)
CALL xios_set_attr(field_hdl, name=tracername3)
END DO

END SUBROUTINE insert_tracer_output
</syntaxhighlight>

== Jupiter with DYNAMICO ==
Using a new dynamical core implies new setting files, in addition or as a replacement of those relevant to '''LMDZ.COMMON''' dynamical core using.

There are two kind of setting files:

'''A first group relevant to DYNAMICO:'''

- [[The ''context_dynamico.xml'' Input File|''context_dynamico.xml'']]: Configuration file for '''DYNAMICO''' for reading and writing files using '''XIOS''', mainly used when you want to check the installation of '''ICOSAGCM''' with [[The_DYNAMICO_dynamical_core | an ''Held and Suarez'' test case]]. When your installation, compilation and run environment is fully functional, the dynamic core output files will not (necessarily) be useful and you can disable their writing.

- [[The context_input_dynamico.xml Input File|''context_input_dynamico.xml'']]:

- [[The file_def_dynamico.xml Input File|''file_def_dynamico.xml'']]: Definition of output diagnostic files which will be written into the output files only related to '''ICOSAGCM'''.

- [[The field_def_dynamico.xml Input File|''field_def_dynamico.xml'']]: Definition of all existing variables that can be output from DYNAMICO.

- [[The tracer.def Input File|''tracer.def'']]: Definition of the name and physico-chemical properties of the tracers which will be advected by the dynamical core. For now, there is two files related to tracers, we are working to harmonise it.

''' A second group relevant to LMDZ.GENERIC physical packages: '''

- [[The context_lmdz_physics.xml Input File|''context_lmdz_physics.xml'']]: File in which are defined the horizontal grid, vertical coordinate, output file(s) definition, with the setting of frequency output writing, time unit, geophysical variables to be written, etc. Each new geophysical variables added here have to be defined in the ''field_def_physics.xml'' file.

- [[The field_def_physics.xml Input File|''field_def_physics.xml'']]: Definition of all existing variables that can be output from the physical packages interfaced with '''DYNAMICO'''. This is where you will add each geophysical fields that you want to appear in the ''Xhistins.nc'' output files. For instance, related to the ''thermal plume scheme'' using for Jupiter's tropospheric dynamics, we have added the following variables:
<syntaxhighlight lang="xml" line>
<field id="h2o_vap"
long_name="Vapor mass mixing ratio"
unit="kg/kg" />
<field id="h2o_ice"
long_name="Vapor mass mixing ratio"
unit="kg/kg" />
<field id="detr"
long_name="Detrainment"
unit="kg/m2/s" />
<field id="entr"
long_name="Entrainment"
unit="kg/m2/s" />
<field id="w_plm"
long_name="Plume vertical velocity"
unit="m/s" />
</syntaxhighlight>

- [[The_callphys.def_Input_File|''callphys.def'']]: This setting file is used either with '''DYNAMICO''' or '''LMDZ.COMMON''' and allows the user to choose the physical parametrisation schemes and their appropriate main parameter values relevant to the planet being simulated. In our case of Jupiter, there are some specific parametrisations that should be added or modified from the example given as link at the beginning of this line:
<syntaxhighlight lang="bash" line>
# Diurnal cycle ? if diurnal=false, diurnally averaged solar heating
diurnal = .false. #.true.
# Seasonal cycle ? if season=false, Ls stays constant, to value set in "start"
season = .true.
# Tidally resonant orbit ? must have diurnal=false, correct rotation rate in newstart
tlocked = .false.
# Tidal resonance ratio ? ratio T_orbit to T_rotation
nres = 1
# Planet with rings?
rings_shadow = .false.
# Compute latitude-dependent gravity field??
oblate = .true.
# Include non-zero flattening (a-b)/a?
flatten = 0.06487
# Needed if oblate=.true.: J2
J2 = 0.01470
# Needed if oblate=.true.: Planet mean radius (m)
Rmean = 69911000.
# Needed if oblate=.true.: Mass of the planet (*1e24 kg)
MassPlanet = 1898.3
# use (read/write) a startfi.nc file? (default=.true.)
startphy_file = .false.
# constant value for surface albedo (if startphy_file = .false.)
surfalbedo = 0.0
# constant value for surface emissivity (if startphy_file = .false.)
surfemis = 1.0

# the rad. transfer is computed every "iradia" physical timestep
iradia = 160
# folder in which correlated-k data is stored ?
corrkdir = Jupiter_HITRAN2012_REY_ISO_NoKarko_T460K_article2019_gauss8p8_095
# Uniform absorption coefficient in radiative transfer?
graybody = .false.
# Characteristic planetary equilibrium (black body) temperature
# This is used only in the aerosol radiative transfer setup. (see aerave.F)
tplanet = 100.
# Output global radiative balance in file 'rad_bal.out' - slow for 1D!!
meanOLR = .false.
# Variable gas species: Radiatively active ?
varactive = .false.
# Computes atmospheric specific heat capacity and
# could calculated by the dynamics, set in callphys.def or calculeted from gases.def.
# You have to choose: 0 for dynamics (3d), 1 for forced in callfis (1d) or 2: computed from gases.def (1d)
# Force_cpp and check_cpp_match are now deprecated.
cpp_mugaz_mode = 0
# Specific heat capacity in J K-1 kg-1 [only used if cpp_mugaz_mode = 1]
cpp = 11500.
# Molecular mass in g mol-1 [only used if cpp_mugaz_mode = 1]
mugaz = 2.30
### DEBUG
# To not call abort when temperature is outside boundaries:
strictboundcorrk = .false.
# To not stop run when temperature is greater than 400 K for H2-H2 CIA dataset:
strictboundcia = .false.
# Add temperature sponge effect after radiative transfer?
callradsponge = .false.

Fat1AU = 1366.0

## Other physics options
## ~~~~~~~~~~~~~~~~~~~~~
# call turbulent vertical diffusion ?
calldifv = .false.
# use turbdiff instead of vdifc ?
UseTurbDiff = .true.
# call convective adjustment ?
calladj = .true.
# call thermal plume model ?
calltherm = .true.
# call thermal conduction in the soil ?
callsoil = .false.
# Internal heat flux (matters only if callsoil=F)
intheat = 7.48
# Remove lower boundary (e.g. for gas giant sims)
nosurf = .true.
#########################################################################
## extra non-standard definitions for Earth
#########################################################################

## Thermal plume model options
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~
dvimpl = .true.
r_aspect_thermals = 2.0
tau_thermals = 0.0
betalpha = 0.9
afact = 0.7
fact_epsilon = 2.e-4
alpha_max = 0.7
fomass_max = 0.5
pres_limit = 2.e5

## Tracer and aerosol options
## ~~~~~~~~~~~~~~~~~~~~~~~~~~
# Ammonia cloud (Saturn/Jupiter)?
aeronh3 = .true.
size_nh3_cloud = 10.D-6
pres_nh3_cloud = 1.1D5 # old: 9.D4
tau_nh3_cloud = 10. # old: 15.
# Radiatively active aerosol (Saturn/Jupiter)?
aeroback2lay = .true.
optprop_back2lay_vis = optprop_jupiter_vis_n20.dat
optprop_back2lay_ir = optprop_jupiter_ir_n20.dat
obs_tau_col_tropo = 4.0
size_tropo = 5.e-7
pres_bottom_tropo = 8.0D4
pres_top_tropo = 1.8D4
obs_tau_col_strato = 0.1D0
# Auroral aerosols (Saturn/Jupiter)?
aeroaurora = .false.
size_aurora = 3.e-7
obs_tau_col_aurora = 2.0

# Radiatively active CO2 aerosol?
aeroco2 = .false.
# Fixed CO2 aerosol distribution?
aerofixco2 = .false.
# Radiatively active water aerosol?
aeroh2o = .false.
# Fixed water aerosol distribution?
aerofixh2o = .false.
# basic dust opacity
dusttau = 0.0
# Varying H2O cloud fraction?
CLFvarying = .false.
# H2O cloud fraction if fixed?
CLFfixval = 0.0
# fixed radii for cloud particles?
radfixed = .false.
# number mixing ratio of CO2 ice particles
Nmix_co2 = 100000.
# number mixing ratio of water particles (for rafixed=.false.)
Nmix_h2o = 1.e7
# number mixing ratio of water ice particles (for rafixed=.false.)
Nmix_h2o_ice = 5.e5
# radius of H2O water particles (for rafixed=.true.):
rad_h2o = 10.e-6
# radius of H2O ice particles (for rafixed=.true.):
rad_h2o_ice = 35.e-6
# atm mass update due to tracer evaporation/condensation?
mass_redistrib = .false.

## Water options
## ~~~~~~~~~~~~~
# Model water cycle
water = .true.
# Model water cloud formation
watercond = .true.
# Model water precipitation (including coagulation etc.)
waterrain = .true.
# Use simple precipitation scheme?
precip_scheme = 1
# Evaporate precipitation?
evap_prec = .true.
# multiplicative constant in Boucher 95 precip scheme
Cboucher = 1.
# Include hydrology ?
hydrology = .false.
# H2O snow (and ice) albedo ?
albedosnow = 0.6
# Maximum sea ice thickness ?
maxicethick = 10.
# Freezing point of seawater (degrees C) ?
Tsaldiff = 0.0
# Evolve surface water sources ?
sourceevol = .false.

## CO2 options
## ~~~~~~~~~~~
# call CO2 condensation ?
co2cond = .false.
# Set initial temperature profile to 1 K above CO2 condensation everywhere?
nearco2cond = .false.
</syntaxhighlight>

- [[The_gases.def_Input_file|''gases.def'']]: File containing the gas composition of the atmosphere you want to model, with their molar mixing ratios.
<syntaxhighlight lang="bash" line>
# gases
5
H2_
He_
CH4
C2H2
C2H6
0.863
0.134
0.0018
1.e-7
1.e-5
# First line is number of gases
# Followed by gas names (always 3 characters)
# and then molar mixing ratios.
# mixing ratio -1 means the gas is variable.
</syntaxhighlight>

- [[The jupiter_const.def Input File|''jupiter_const.def'']]: Files that gather all orbital and physical parameters of Jupiter.

- [[The_traceur.def_Input_File|''traceur.def'']]: At this time, only two tracers are used for modelling Jupiter atmosphere, so the ''traceur.def'' file is summed up as follow
<syntaxhighlight lang="bash" line>
2
h2o_vap
h2o_ice
</syntaxhighlight>

''' Two additional files are used to set the running parameter of the simulation itself:'''

- [[The run_icosa.def Input File | ''run_icosa.def'']]: file containing parameters for '''ICOSAGCM''' to execute the simulation, use to determine the [[Advanced Use of the GCM | horizontal and vertical resolutions]], the number of processors, the number of subdivisions, the duration of the simulation, etc.

- ''run.def'': file which brings together all the setting files and will be reading by the interface '''ICOSA_LMDZ''' to link each part of the model ('''ICOSAGCM''', '''LMDZ.GENERIC''') with its particular setting file(s) when the library '''XIOS''' does not take action (through the ''.xml'' files).
<syntaxhighlight lang="bash" line>
###########################################################################
### INCLUDE OTHER DEF FILES (physics, specific settings, etc...)
###########################################################################
INCLUDEDEF=run_icosa.def

INCLUDEDEF=jupiter_const.def

INCLUDEDEF=callphys.def

prt_level=0

## iphysiq must be same as itau_physics
iphysiq=40
</syntaxhighlight>

== Hot Jupiter with DYNAMICO ==

Modelling the atmosphere of Hot Jupiter is challenging because of the extreme temperature conditions, and the fact that these planets are gas giants. Therefore, using a dynamical core such as Dynamico is strongly recommended. Here, we discuss how to perform a cloudless simulation of the Hot Jupiter WASP-43 b, using Dynamico.

'''1st step''': You need to go to the github mentionned previously for Dynamico: https://github.com/aymeric-spiga/dynamico-giant. ''Git clone'' this repo on your favorite cluster, and ''checkout'' to the "hot_jupiter" branch.

'''2nd step''': Now, run the install.sh script. This script will install '''all''' the required models ('''LMDZ.COMMON''', '''LMDZ.GENERIC''','''ICOSA_LMDZ''','''XIOS''','''FCM''','''ICOSAGCM'''). At this point, you only miss '''IOIPSL'''. To install it, go to
<syntaxhighlight lang="bash">
dynamico-giant/code/LMDZ.COMMON/ioipsl/
</syntaxhighlight>

There, you will find some examples of installations script. You need to create one that will work on your cluster, with your own arch files.
During the installation of '''IOIPSL''', you might be asked for a login/password. Contact TGCC computing center to get access.

'''3rd step''': Great, now we have all we need to get started. Navigate to the ''hot_jupiter'' folder. You will find a ''compile_mesopsl.sh'' and a ''compile_occigen.sh'' script. Use them as examples to create the compile script adapted to your own cluster, then run it.
While running, I suggest that you take a look at the ''log_compile'' file. The compilation can take a while (~ 10minutes, especially because of XIOS). On quick trick to make sure that everything went right is to check the number of ''Build command finished'' messages in ''log_compile''. If everything worked out, there should be 6 of them.

'''4th step''': Okay, the model compiled, good job ! Now we need to create the initial condition for our run. In the hot_jupiter1d folder, you already have a ''temp_profile.txt'' computed with the 1D version of the LMDZ.GENERIC (see rcm1d on this page). Thus, no need to recompute a 1D model but it will be needed if you want to model another Hot Jupiter.
Navigate to the 'makestart' folder, located at
<syntaxhighlight lang="bash">
dynamico-giant/hot_jupiter/makestart/
</syntaxhighlight>
To generate the initial conditions for the 3D run, we're gonna start the model using the temperature profile from the 1D run. to do that, you will find a "job_mpi" script. Open it, and adapt it to your cluster and launch the job. This job is using 20 procs, and it runs 5 days of simulations.
If everything goes well, you should see few netcdf files appear. The important ones are '''start_icosa0.nc''', '''startfi0.nc''' and '''Xhistins.nc'''.
If you see these files, you're all set to launch a real simulation !

'''5th step''': Go back to ''hot_jupiter'' folder. There are a bunch of script to launch your simulation. Take a look at the ''astro_fat_mpi'' script, and adapt it to your cluster. Then you can launch your simulation by doing
<syntaxhighlight lang="bash">
./run_astro_fat
</syntaxhighlight>
This will start the simulation, using 90 procs. In the same folder, check if the icosa_lmdz.out file is created. This is the logfile of the simulation, while it is running. You can check there that everything is going well.

'''Important side note''': When using the ''run_astro_fat'' script to run a simulation, it will run a chained simulation, restarting the simulation from the previous state after 100 days of simulations and generating ''Xhistins.nc'' files. This is your results file, where you will find all the variables that controls your atmosphere (temperature field, wind fields, etc..).

Good luck and enjoy the generic PCM Dynamico for Hot Jupiter !

'''2nd important side note''': These 5 steps are the basic needed steps to run a simulation. If you want to tune simulations to another planet, or change other stuff, you need to take a look at '''*.def''' and '''*.xml''' files. If you're lost in all of this, take a look at the different pages of this website and/or contact us !
Also, you might want to check the wiki on the [https://github.com/aymeric-spiga/dynamico-giant ''Github''], that explains a lot of settings for Dynamico

= 3D LES setup =

== Proxima b with LES ==

To model the subgrid atmospheric turbulence, the [[WRF dynamical core for LES/mesoscale simulations|'''WRF''']] dynamical core coupled with the LMD Generic physics package is used. The first studied conducted was to resolve the convective activity of the substellar point of Proxami-b (Lefevre et al 2021). The impact of the stellar insolation and rotation period were studied. The files for the reference case, with a stellar flux of 880 W/m2 and an 11 days rotation period, are presented

The input_* file are the used to initialize the temperature, pressure, winds and moisture of the domain.
input_souding : altitude (km), potential temperature, water vapour (kg/kg), u, v
input_therm : normalized gas constant, isobaric heat capacity, pressure, density, temperature
input_hr : SW heating, LW heating, Large-scale heating extracted from the GCM. Only the last one is used in this configuration.

The file namelist.input is used to set up the domain parameters (resolution, grid points, etc). The file levels specifies the eta-levels of the vertical domain.

Planet is used set up the atmospheric parameters, in order : gravity (m/s2), isobaric heat capacity (J/kg/K), molecular mass (g/mol), reference temperature (K), surface pressure (Pa), planet radius (m) and planet rotation rate (s-1).

The files *.def are the parameter for the physics. Compared to GCM runs, the convective adjustment in callphys.def is turned off

The file controle.txt, equivalent of the field controle in GCM start.nc, needed to initialize some physics constants.

TBC ML

= 1D setups =

== rcm1d program ==

Running the model in 1D (i.e. considering simply a column of atmosphere) is a common first step to test a new setup. To do so, you first have to compile the 1D version of the model. The command line is very similar to [[Quick_Install_and_Run#Compiling a test case (early Mars)|the one for the 3D]], except for 2 changes:
# put just the vertical resolution after the -d option ("VERT" instead of ''LON''x''LAT''x''VERT'' for the 3D case)
# at the end of the line, replace "gcm" with "rcm1d"
It will generate a file called '''rcm1d_XX_phyxxx_seq.e''', where ''XX'' and ''phyxxx'' are the vertical resolution and the physics package, respectively.

Check out the [[Generic unicolumn rcm1d program| dedicated page about rcm1d]] for more details.

Note that the '''.def''' files differ a bit from the 3D case. Indeed, [[The_run.def_Input_File|'''run.def''']] contains different information and needs to hold the key <code>run_1d=.true.</code>; see [[The_rcm1d.def_Input_File|'''rcm1d.def''']]. In addition, the 1D model generally does not use [[The_start.nc_and_startfi.nc_input_files|'''start.nc''']] or [[The_start.nc_and_startfi.nc_input_files|'''startfi.nc''']] files to initialize. You can find examples of 1D configuration in ''LMDZ.GENERIC/deftank'' (e.g. '''run.def.earlymars1d''', '''run.def.earth1d'''), the best thing is to have a look at them.

== kcm1d program ==

Our 1-D inverse model

TBD by Guillaume or Martin

[[Category:Generic-Model]]
[[Category:Generic-LMDZ]]
[[Category:Generic-DYNAMICO]]
[[Category:Generic-WRF]]
[[Category:Generic-1D]]

The rcm1d.def Input File

2026-06-12T13:16:22Z

Jbclement: /* some general comments and disambiguation to start with */

== The run.def input file and its format ==

=== some general comments and disambiguation to start with ===
This pages specifically focuses on the ''run.def'' file used by the 1D version of the Generic PCM.

The run.def file is very similar to the [[The_run.def_Input_File|'''run.def''']] file, with the difference that the 3D options (linked to the dynamic core) are not used, and a whole bunch of new 1D-specific options (information contained in the start and startfi files) are now in the 1D run.def file. Especially, the 1D file has to hold the key <code>run_1d=.true.</code>.

== Reference def files ==
Reference *.def files are provided in the LMDZ.GENERIC/deftank directory

== Outputted used_*def files ==
When the GCM run finishes, for each of the input def files *.def, an ASCII output file '''used_*.def''' is generated (in practice this would be '''used_run.def''' and '''used_callphys.def''' for the 1D simulations). These files contain, along the same format as the *.def input files, the "key = value" that were used, along with comments about whether "value" was read in the input def file or if the code default was used (i.e. the sought "keyword" was not present in the input def files).

== Example of 1D ''run.def'' file ==

<pre>
#---------------------------------#
# Run parameters for the 1D model #
#---------------------------------#

run_1d=.true.

## Planetary constants
## ~~~~~~~~~~~~~~~~~~~~~~~
## NB: those are mandatory
## ~~~~~~~~~~~~~~~~~~~~~~~
## LENGTH OF A DAY in s
daysec = 86400.
## GRAVITY in m s-2
g = 3.72
## Radius of the planet, in m
rad = 3390000
## LENGTH OF A YEAR in days
year_day = 3000
## MIN DIST STAR-PLANET in AU [periastron]
periastr = 1.0
## MAX DIST STAR-PLANET in AU [apoastron]
apoastr = 1.0
## DATE OF PERIASTRON in days
peri_day = 0.
## OBLIQUITY in deg
obliquit = 0.
## SURFACE PRESSURE in Pa
psurf = 100000.

## Time integration parameters
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Initial date (in solar days,=0 at Ls=0)
day0 = 0
# Initial local time (in hours, between 0 and 24)
time = 12
# Number of time steps per sol
day_step = 40
# Number of sols to run
ndt = 1000
# Number of steps between each writing in diagfi
diagfi_output_rate=12

## Vertical levels
## ~~~~~~~~~~~~~~~
# hybrid vertical coordinate ? (.true. for hybrid and .false. for sigma levels)
hybrid = .true.
# autocompute vertical discretisation? (useful for exoplanet runs)
autozlevs = .false.
# Ceiling pressure (Pa) ?
pceil = 0.00001

## Thermal properties
## ~~~~~~~~~~~~~~~~~~
# Simulate global averaged conditions ?
global1d = .true.
# Latitude (deg) [only used if global1d = F]
latitude = 0.0
# Solar Zenith angle (deg) [only used if global1d = T]
szangle = 60.
# Force specific heat capacity and molecular mass values
force_cpp = .false.
# Specific heat capacity in J K-1 kg-1 [only used if force_cpp = T]
cpp = 0.
# Molecular mass in g mol-1 [only used if force_cpp = T]
mugaz = 18.
# Albedo of bare ground
albedo = 0.1
# Emissivity of bare ground
emis = 1.0
# Soil thermal inertia (SI)
inertia = 1000.
# Initial CO2 ice on the surface (kg.m-2)
co2ice = 0.

## Wind profile
## ~~~~~~~~~~~~
## zonal eastward component of the geostrophic wind (m/s)
u = 10.
# meridional northward component of the geostrophic wind (m/s)
v = 0.

## Initial atmospheric temperature profile
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# Type of initial temperature profile
# ichoice=1 Constant Temperature: T=tref
# [Mars] ichoice=2 Savidjari profile (as Seiff but with dT/dz=cte)
# [Mars] ichoice=3 Lindner (polar profile)
# [Mars] ichoice=4 inversion
# [Mars] ichoice=5 Seiff (standard profile, based on Viking entry)
# ichoice=6 constant T + gaussian perturbation (levels)
# ichoice=7 constant T + gaussian perturbation (km)
# ichoice=8 Read in an ascii file "profile"
ichoice = 1
# Reference temperature tref (K)
tref = 300.
# Add a perturbation to profile if isin=1
isin = 0
# peak of gaussian perturbation (for ichoice=6 or 7)
pic = 26.522
# width of the gaussian perturbation (for ichoice=6 or 7)
largeur = 10
# height of the gaussian perturbation (for ichoice=6 or 7)
hauteur = 30.

</pre>

'''Notes''':
* Lines beginning with a hashtag are comments
* values associated to keywords may be logicals, integers, reals or even strings
* The parsing is case-sensitive : "thisparameter=" and "ThisParameter=" are identified as two distinct keywords
* The order in which the parameters are given in the file does not matter (except if a parameter is specified multiple times, clearly a bad idea, and then the last occurrence will prevail).
* Accessing a parameter and its value from ''run.def'' in the Fortran code is done using the '''getin_p''' routine, e.g.:
<syntaxhighlight lang="fortran">
call getin_p("keyword",val)
</syntaxhighlight>
will look for the line with "keyword = " in file ''run.def'' and extract trailing value which will be use to set the value of the '''val''' variable in the code.

[[Category:Inputs]]
[[Category:WhatIs]]

[[Category:Generic-LMDZ]]
[[Category:Generic-1D]]

2025-10-23T15:11:15Z

Jbclement: /* Merging the PEM outputs (post-processing) */

There are few tools provided along the PEM which can be found in the directory <code>LMDZ.COMMON/libf/evolution/deftank/</code>. A <code>README</code> text file gives information about the different files that this directory contains.

The current tools available for the PEM in this directory are:
* <code>clean.sh </code>
* <code>concat_pem.py </code>
* <code>inipem_orbit.sh </code>
* <code>modify_startfi_orbit.sh </code>
* <code>modify_startfi_var.sh </code>
* <code>multiple_exec.sh </code>
* <code>visu_evol_layering.py </code>
* <code>visu_layering.py </code>

The purpose of these tools is described in the sections below. Their usage is quite straightforward and all the parameters to be modified by the user are always gathered at the beginning of the file, in the header, with short explanations.

== Cleaning of files (post-processing) ==

The bash script file <code>clean.sh</code> cleans the folder after a PEM simulation and reset the initial starting files to prepare a new simulation.

== Merging the PEM outputs (post-processing) ==

The Python script <code>concat_pem.py</code> allows to concatenate along the variable 'Time' all the "diagpem" files (PEM outputs) into one NetCDF file. 'Time' is re-indexed with the numbering of Martian years simulated by the PEM run. It is useful if one wants to visualize and analyse the evolution of variables during all the PEM runs of the chained simulation.

== Initialization of orbital parameters (pre-processing) ==

The bash script file <code>inipem_orbit.sh</code> sets the orbital parameters of a file "startfi.nc" from Laskar's data contained in "obl_ecc_lsp.asc" according to the initial date 'year_earth_bp_ini' defined in "run_PEM.def". See also <code>modify_startfi_orbit.sh</code>.

== Setting the orbital parameters (pre-processing) ==

The bash script file <code>modify_startfi_orbit.sh</code> allows to modify orbital parameters in the file "startfi.nc". They should be consistent with Laskar's data in "obl_ecc_lsp.asc" at the same date if orbital parameters are meant to vary during the simulation. See also <code>inipem_orbit.sh</code>.

== Setting a variable in a NetCDF file (pre-processing) ==

The bash script file <code>modify_startfi_var.sh</code> modifies the value of a variable in a file "startfi.nc".

== Lauching multiple simulations (pre-processing) ==

The bash script <code>modify_startfi_var.sh</code> executes multiple scripts in subdirectories. It is useful to launch multiple simulations at once.

== Layering visualization overged time (post-processing) ==

The Python script file <code>visu_evol_layering.py</code> outputs the stratification data over time from the "startpem.nc" files.

== Layering visualization (post-processing) ==

The Python script file <code>visu_layering.py</code> outputs the stratification data from the "startpem.nc" files.

[[Category:Planetary-Evolution-Model]]