Planets - User contributions [en]

Other GCM Configurations worth knowing about

2023-02-23T15:45:36Z

Yjaziri: /* GCM Input Datafiles and Datasets */

== 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 Martin (I will update this case as soon as Siddharth has committed changes)

=== 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 http://www.lmd.jussieu.fr/~lmdz/planets/generic/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/aeronostd/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

TBD by Gabriella (waiting for the SVN update by Ehouarn)

=== mini-Neptune GJ1214b ===

A warm mini-Neptune

TBD 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 90f7138a60ebd3644fbbc42bc9dfa22923386385
</syntaxhighlight>

'''ICOSA_LMDZ''': the interface using to link LMDZ.GENERIC physical packages and ICOSAGCM
<syntaxhighlight lang="bash">
svn update -r 2655 -q ICOSA_LMDZ
</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 2319 -q http://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/trunk XIOS
</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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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.

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

=== rcm1d test case ===

Our 1-D forward model

TBD by Gwenael ? (you can have a look at the Generic GCM User Manual for inspiration)

=== kcm1d test case ===

Our 1-D inverse model

TBD by Guillaume or Martin

Other GCM Configurations worth knowing about

2023-02-23T14:42:06Z

Yjaziri: /* TRAPPIST-1e with photochemistry */

== 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 Martin (I will update this case as soon as Siddharth has committed changes)

=== 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 http://www.lmd.jussieu.fr/~lmdz/planets/generic/bench_trappist1e_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/aeronostd/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

TBD by Gabriella (waiting for the SVN update by Ehouarn)

=== mini-Neptune GJ1214b ===

A warm mini-Neptune

TBD 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 90f7138a60ebd3644fbbc42bc9dfa22923386385
</syntaxhighlight>

'''ICOSA_LMDZ''': the interface using to link LMDZ.GENERIC physical packages and ICOSAGCM
<syntaxhighlight lang="bash">
svn update -r 2655 -q ICOSA_LMDZ
</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 2319 -q http://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/trunk XIOS
</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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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.

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

=== rcm1d test case ===

Our 1-D forward model

TBD by Gwenael ? (you can have a look at the Generic GCM User Manual for inspiration)

=== kcm1d test case ===

Our 1-D inverse model

TBD by Guillaume or Martin

Other GCM Configurations worth knowing about

2023-02-23T14:41:46Z

Yjaziri: /* Compiling a test case (TRAPPIST-1e) */

== 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 Martin (I will update this case as soon as Siddharth has committed changes)

=== TRAPPIST-1e with photochemistry ===

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

TBD by Yassin

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 http://www.lmd.jussieu.fr/~lmdz/planets/generic/bench_trappist1e_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/aeronostd/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

TBD by Gabriella (waiting for the SVN update by Ehouarn)

=== mini-Neptune GJ1214b ===

A warm mini-Neptune

TBD 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 90f7138a60ebd3644fbbc42bc9dfa22923386385
</syntaxhighlight>

'''ICOSA_LMDZ''': the interface using to link LMDZ.GENERIC physical packages and ICOSAGCM
<syntaxhighlight lang="bash">
svn update -r 2655 -q ICOSA_LMDZ
</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 2319 -q http://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/trunk XIOS
</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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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.

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

=== rcm1d test case ===

Our 1-D forward model

TBD by Gwenael ? (you can have a look at the Generic GCM User Manual for inspiration)

=== kcm1d test case ===

Our 1-D inverse model

TBD by Guillaume or Martin

Other GCM Configurations worth knowing about

2023-02-23T14:40:54Z

Yjaziri: /* Compiling the GCM */

== 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 Martin (I will update this case as soon as Siddharth has committed changes)

=== TRAPPIST-1e with photochemistry ===

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

TBD by Yassin

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 http://www.lmd.jussieu.fr/~lmdz/planets/generic/bench_trappist1e_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/aeronostd/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

TBD by Gabriella (waiting for the SVN update by Ehouarn)

=== mini-Neptune GJ1214b ===

A warm mini-Neptune

TBD 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 90f7138a60ebd3644fbbc42bc9dfa22923386385
</syntaxhighlight>

'''ICOSA_LMDZ''': the interface using to link LMDZ.GENERIC physical packages and ICOSAGCM
<syntaxhighlight lang="bash">
svn update -r 2655 -q ICOSA_LMDZ
</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 2319 -q http://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/trunk XIOS
</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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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.

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

=== rcm1d test case ===

Our 1-D forward model

TBD by Gwenael ? (you can have a look at the Generic GCM User Manual for inspiration)

=== kcm1d test case ===

Our 1-D inverse model

TBD by Guillaume or Martin

Other GCM Configurations worth knowing about

2023-02-23T14:39:56Z

Yjaziri: /* GCM Input Datafiles and Datasets */

== 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 Martin (I will update this case as soon as Siddharth has committed changes)

=== TRAPPIST-1e with photochemistry ===

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

TBD by Yassin

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 http://www.lmd.jussieu.fr/~lmdz/planets/generic/bench_trappist1e_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/aeronostd/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

TBD by Gabriella (waiting for the SVN update by Ehouarn)

=== mini-Neptune GJ1214b ===

A warm mini-Neptune

TBD 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 90f7138a60ebd3644fbbc42bc9dfa22923386385
</syntaxhighlight>

'''ICOSA_LMDZ''': the interface using to link LMDZ.GENERIC physical packages and ICOSAGCM
<syntaxhighlight lang="bash">
svn update -r 2655 -q ICOSA_LMDZ
</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 2319 -q http://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/trunk XIOS
</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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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.

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

=== rcm1d test case ===

Our 1-D forward model

TBD by Gwenael ? (you can have a look at the Generic GCM User Manual for inspiration)

=== kcm1d test case ===

Our 1-D inverse model

TBD by Guillaume or Martin

Other GCM Configurations worth knowing about

2023-02-23T14:37:53Z

Yjaziri: /* TRAPPIST-1e with photochemistry */

== 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 Martin (I will update this case as soon as Siddharth has committed changes)

=== TRAPPIST-1e with photochemistry ===

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

TBD by Yassin

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 http://www.lmd.jussieu.fr/~lmdz/planets/generic/bench_trappist1e_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/aeronostd/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

TBD by Gabriella (waiting for the SVN update by Ehouarn)

=== mini-Neptune GJ1214b ===

A warm mini-Neptune

TBD 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 90f7138a60ebd3644fbbc42bc9dfa22923386385
</syntaxhighlight>

'''ICOSA_LMDZ''': the interface using to link LMDZ.GENERIC physical packages and ICOSAGCM
<syntaxhighlight lang="bash">
svn update -r 2655 -q ICOSA_LMDZ
</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 2319 -q http://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/trunk XIOS
</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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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 std -p_opt "-b 20x25 -s 2" -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.

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

=== rcm1d test case ===

Our 1-D forward model

TBD by Gwenael ? (you can have a look at the Generic GCM User Manual for inspiration)

=== kcm1d test case ===

Our 1-D inverse model

TBD by Guillaume or Martin

The traceur.def Input File

2022-05-11T08:59:12Z

Yjaziri:

== What is it for? ==

Tracers need to be listed in ''traceur.def''.

Characteristics of the tracers can be also specified in ''traceur.def''.

== What is a tracer? ==

Tracers are elements which will be defined at each grid point and tracked in the model. They may interact with the atmosphere in different ways.

The model may include different types of tracers:
<ul>
<li>condensed species (e.g., CO2, H2O, dust)</li>
<li>chemically active species</li>
<li>radiatively active gases (e.g., water vapor)</li>
</ul>
In the code, all tracers are stored in one three-dimensional array q, the third index of
which corresponds to each individual tracer. In input
([https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_start.nc_and_startfi.nc_input_files ''start.nc'', ''startfi.nc''])
and output files tracers are stored separately using their individual names. Loading specific
tracers requires that the approriate tracer names are set in the ''traceur.def'' file,
and specific computations for given tracers (e.g. computing the water or CO2
cycles) is controlled by setting the corresponding options in the
[https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_callphys.def_Input_File ''callphys.def''] file.

== Structure ==

Number of tracers need to be specified, followed by tracers names.

== Example ==

The following example will set up water tracers to compute water cloud and water cycle in general.

<pre>
2
h2o_vap
h2o_ice
</pre>

An update version named '''ModernTrac-v1''' need to be used with chemistry in order to set up properly the chemical tracers. This gives also the opportunity to specify for each tracers specific characteristics.

<pre>
#ModernTrac-v1
#
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# !! README !!
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Welcome, this is the modern traceur.def !
#
# ---> DON'T TOUCH/REMOVE THE FIRST LINE OF HEADER #ModernTrac-v1 <---
#
# * You can use this area to write as many comments as you want starting lines with #.
# * You cannot have comment lines in the middle nor at the end, only at the top.
#
#
# 0. Philosophy This modern version of traceur.def gather in a single file what was
# ~~~~~~~~~~~~~ previously in traceur.def AND gases.def plus some hard-coded things.
#
# 1. Structure After the header, first line is the total number of modern tracers in
# ~~~~~~~~~~~~ your file, ie not only tracers sent to dynamics, but also species that
# takes part in the composition, radiative transfer, chemistry, etc.
#
# Then, each line needs to start with the specie name ... and that's the
# only mandatory information ! But you can specify all the options you
# want in separate blocks following 'option=value', assuming this option
# is defined in traceur_h.F90 & initracer.F for physics, infotrac.F90
# for dynamics or chimiedata_h.F90 & calchim_asis.F90 for chemistry.
# Indeed this file is read once by dynamics, once by physics and once by
# chemistry who keep only the information needed.
#
# Note that by default a tracer listed below will be sent to dynamics
# except if you specify is_dyn=0. If nothing is given, then is_dyn=1.
# Not yet fully implemented.
#
# 3. Options. Implemented options listed below.
# ~~~~~~~~~~~~ For dynamic see "infotrac.F90".
# For physic see "initracer.F90".
# For chemistry see "calchim_asis.F90".
# init see "inichim_1D.F90" and "inichim_newstart.F90"
#
# Dynamic: vadv ! index of vertical trasport schema
# hadv ! index of horizontal trasport schema
# tnom_transp ! transporting fluid short name: CRisi
#
# Physic: mmol ! mole mass of tracer [g.mol-1]
# aki ! coefficient of thermal concduction
# cpi ! heat capacity [J.kg-1.K-1]
# is_chim ! 1 if tracer used in chemistry, else 0
# is_rad ! 1 if tracer used in radiative transfer, else 0
# is_recomb ! 1 if tracer used in recombining scheme, else 0
# (if 1, must have is_rad=1)
# is_recomb_qset ! 1 if tracer k-corr assume predefined vmr, else 0
# (if 1, must have is_recomb=1)
# is_recomb_qotf ! 1 if tracer recombination is done on-the-fly, else 0
# (if 1, must have is_recomb_qset=0)
#
# Chemistry: SF_mode ! 1 if surface set up value, else 2 sedimentation velocity
# SF_value ! [vmr] if SF_mode=1, else [cm.s-1]
# prod_rate ! if SF_mode=2 production flux [molecules.m-2.s-1]
#
# init: qx ! value that initialize constant profile [vmr]
# qxf ! file that initialize profile [Pa,vmr] (1 line header)
#
#
#
# Random Ex :
# 4
# n2 is_dyn=0
# co2 cpi=450.0 is_dyn=1 mmol=44.
# hdo hadv=14 vadv=10 tnom_transp=air
# h2s
#
# Insert your tracers list and options below !
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
29
h2o_ice mmol=18
co2 mmol=44 is_chim=1 SF_mode=1 SF_value=4.0e-4 is_rad=1
co mmol=28 is_chim=1
o mmol=16 is_chim=1
o1d mmol=16 is_chim=1
o2 mmol=32 is_chim=1 SF_mode=1 SF_value=2.1e-1
o3 mmol=48 is_chim=1 is_rad=1 is_recomb=1 is_recomb_qotf=1
h mmol=1 is_chim=1
h2 mmol=2 is_chim=1
oh mmol=17 is_chim=1
ho2 mmol=33 is_chim=1
h2o2 mmol=34 is_chim=1
h2o_vap mmol=18 is_chim=1 is_rad=1
ch4 mmol=16 is_chim=1 SF_mode=1 SF_value=1.8e-6 is_rad=1
ch3 mmol=15 is_chim=1
cho mmol=29 is_chim=1
ch2o mmol=30 is_chim=1
ch3o mmol=31 is_chim=1
ch3o2 mmol=47 is_chim=1
ch3o2h mmol=48 is_chim=1
n mmol=14 is_chim=1
no mmol=30 is_chim=1
no2 mmol=46 is_chim=1
n2 mmol=28 is_chim=1 is_rad=1
hno3 mmol=63 is_chim=1
hno4 mmol=79 is_chim=1
n2o mmol=44 is_chim=1 SF_mode=1 SF_value=3.3e-7
no3 mmol=62 is_chim=1
n2o5 mmol=108 is_chim=1
</pre>

Advanced Use of the GCM

2022-05-11T08:55:19Z

Yjaziri: /* How to Manage Tracers */

== Running in parallel ==

For large simulation (long run, high resolution etc...), the waiting time can becomes very long.
To overcome this issue, the model can works in parallel.
It first needs to be compiled in parallel mode and then be run with a specific command.
For all the details see the page [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Parallelism#How_to_run_in_parallel Parallelism]

== Distinctions beween ifort, mpi, etc. ==

TO BE COMPLETED
BWAAAAA

== Distinction between using IOIPSL or XIOS ==

TO BE COMPLETED

== How to Change Vertical and Horizontal Resolutions ==

To run at a different grid resolution than available initial conditions files, one needs to use the tools '''newstart.e''' and '''start2archive.e'''

For example, to create initial states at grid resolution 32×24×25 from NetCDF files start and startfi at grid resolution 64×48×32 :

* Create file ''start_archive.nc'' with '''start2archive.e''' compiled at grid resolution 64×48×32 using old file ''z2sig.def'' used previously
* Create files ''restart.nc'' and ''restartfi.nc'' with '''newstart.e''' compiled at grid resolution 32×24×25, using a new file ''z2sig.def'' (more details below on the choice of the ''z2sig.def'')

=== What you need to know about the ''z2sig.def'' file (change of vertical resolution only) ===

TO BE COMPLETED



== How to Change the Topography (or remove it) ==

The generic model can use in principle any type of surface topography, provided that the topographic data file is available in the right format, and put in the right place.

== How to Change the Opacity Tables ==

TO BE COMPLETED

== How to Manage Tracers ==

Tracers are managed thanks to the [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_traceur.def_Input_File ''traceur.def''] file.

Specific treatment of some tracers (e.g., water vapor cycle) can be added directly in the model and an option added in [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_callphys.def_Input_File ''callphys.def''] file.

Advanced Use of the GCM

2022-05-11T08:51:27Z

Yjaziri: /* How to Manage Tracers */

== Running in parallel ==

For large simulation (long run, high resolution etc...), the waiting time can becomes very long.
To overcome this issue, the model can works in parallel.
It first needs to be compiled in parallel mode and then be run with a specific command.
For all the details see the page [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Parallelism#How_to_run_in_parallel Parallelism]

== Distinctions beween ifort, mpi, etc. ==

TO BE COMPLETED
BWAAAAA

== Distinction between using IOIPSL or XIOS ==

TO BE COMPLETED

== How to Change Vertical and Horizontal Resolutions ==

To run at a different grid resolution than available initial conditions files, one needs to use the tools '''newstart.e''' and '''start2archive.e'''

For example, to create initial states at grid resolution 32×24×25 from NetCDF files start and startfi at grid resolution 64×48×32 :

* Create file ''start_archive.nc'' with '''start2archive.e''' compiled at grid resolution 64×48×32 using old file ''z2sig.def'' used previously
* Create files ''restart.nc'' and ''restartfi.nc'' with '''newstart.e''' compiled at grid resolution 32×24×25, using a new file ''z2sig.def'' (more details below on the choice of the ''z2sig.def'')

=== What you need to know about the ''z2sig.def'' file (change of vertical resolution only) ===

TO BE COMPLETED



== How to Change the Topography (or remove it) ==

The generic model can use in principle any type of surface topography, provided that the topographic data file is available in the right format, and put in the right place.

== How to Change the Opacity Tables ==

TO BE COMPLETED

== How to Manage Tracers ==

Tracers are managed thanks to the ''traceur.def'' file [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_traceur.def_Input_File].

Specific treatment of some tracers (e.g., water vapor cycle) can be added directly in the model and an option added in ''callphys.def'' file [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_callphys.def_Input_File].

The traceur.def Input File

2022-05-11T08:43:35Z

Yjaziri:

== What is it for? ==

Tracers need to be listed in ''traceur.def''.

Characteristics of the tracers can be also specified in ''traceur.def''.

== What is a tracer? ==

Tracers are elements which will be defined at each grid point and tracked in the model. They may interact with the atmosphere in different ways.

The model may include different types of tracers:
<ul>
<li>condensed species (e.g., CO2, H2O, dust)</li>
<li>chemically active species</li>
<li>radiatively active gases (e.g., water vapor)</li>
</ul>
In the code, all tracers are stored in one three-dimensional array q, the third index of
which corresponds to each individual tracer. In input (“start.nc”, “startfi.nc”)
[https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_start.nc_and_startfi.nc_input_files]
and output files tracers are stored separately using their individual names. Loading specific
tracers requires that the approriate tracer names are set in the ''traceur.def'' file,
and specific computations for given tracers (e.g. computing the water or CO2
cycles) is controlled by setting the corresponding options in the ''callphys.def'' file
[https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_callphys.def_Input_File].

== Structure ==

Number of tracers need to be specified, followed by tracers names.

== Example ==

The following example will set up water tracers to compute water cloud and water cycle in general.

<pre>
2
h2o_vap
h2o_ice
</pre>

An update version named '''ModernTrac-v1''' need to be used with chemistry in order to set up properly the chemical tracers. This gives also the opportunity to specify for each tracers specific characteristics.

<pre>
#ModernTrac-v1
#
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# !! README !!
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Welcome, this is the modern traceur.def !
#
# ---> DON'T TOUCH/REMOVE THE FIRST LINE OF HEADER #ModernTrac-v1 <---
#
# * You can use this area to write as many comments as you want starting lines with #.
# * You cannot have comment lines in the middle nor at the end, only at the top.
#
#
# 0. Philosophy This modern version of traceur.def gather in a single file what was
# ~~~~~~~~~~~~~ previously in traceur.def AND gases.def plus some hard-coded things.
#
# 1. Structure After the header, first line is the total number of modern tracers in
# ~~~~~~~~~~~~ your file, ie not only tracers sent to dynamics, but also species that
# takes part in the composition, radiative transfer, chemistry, etc.
#
# Then, each line needs to start with the specie name ... and that's the
# only mandatory information ! But you can specify all the options you
# want in separate blocks following 'option=value', assuming this option
# is defined in traceur_h.F90 & initracer.F for physics, infotrac.F90
# for dynamics or chimiedata_h.F90 & calchim_asis.F90 for chemistry.
# Indeed this file is read once by dynamics, once by physics and once by
# chemistry who keep only the information needed.
#
# Note that by default a tracer listed below will be sent to dynamics
# except if you specify is_dyn=0. If nothing is given, then is_dyn=1.
# Not yet fully implemented.
#
# 3. Options. Implemented options listed below.
# ~~~~~~~~~~~~ For dynamic see "infotrac.F90".
# For physic see "initracer.F90".
# For chemistry see "calchim_asis.F90".
# init see "inichim_1D.F90" and "inichim_newstart.F90"
#
# Dynamic: vadv ! index of vertical trasport schema
# hadv ! index of horizontal trasport schema
# tnom_transp ! transporting fluid short name: CRisi
#
# Physic: mmol ! mole mass of tracer [g.mol-1]
# aki ! coefficient of thermal concduction
# cpi ! heat capacity [J.kg-1.K-1]
# is_chim ! 1 if tracer used in chemistry, else 0
# is_rad ! 1 if tracer used in radiative transfer, else 0
# is_recomb ! 1 if tracer used in recombining scheme, else 0
# (if 1, must have is_rad=1)
# is_recomb_qset ! 1 if tracer k-corr assume predefined vmr, else 0
# (if 1, must have is_recomb=1)
# is_recomb_qotf ! 1 if tracer recombination is done on-the-fly, else 0
# (if 1, must have is_recomb_qset=0)
#
# Chemistry: SF_mode ! 1 if surface set up value, else 2 sedimentation velocity
# SF_value ! [vmr] if SF_mode=1, else [cm.s-1]
# prod_rate ! if SF_mode=2 production flux [molecules.m-2.s-1]
#
# init: qx ! value that initialize constant profile [vmr]
# qxf ! file that initialize profile [Pa,vmr] (1 line header)
#
#
#
# Random Ex :
# 4
# n2 is_dyn=0
# co2 cpi=450.0 is_dyn=1 mmol=44.
# hdo hadv=14 vadv=10 tnom_transp=air
# h2s
#
# Insert your tracers list and options below !
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
29
h2o_ice mmol=18
co2 mmol=44 is_chim=1 SF_mode=1 SF_value=4.0e-4 is_rad=1
co mmol=28 is_chim=1
o mmol=16 is_chim=1
o1d mmol=16 is_chim=1
o2 mmol=32 is_chim=1 SF_mode=1 SF_value=2.1e-1
o3 mmol=48 is_chim=1 is_rad=1 is_recomb=1 is_recomb_qotf=1
h mmol=1 is_chim=1
h2 mmol=2 is_chim=1
oh mmol=17 is_chim=1
ho2 mmol=33 is_chim=1
h2o2 mmol=34 is_chim=1
h2o_vap mmol=18 is_chim=1 is_rad=1
ch4 mmol=16 is_chim=1 SF_mode=1 SF_value=1.8e-6 is_rad=1
ch3 mmol=15 is_chim=1
cho mmol=29 is_chim=1
ch2o mmol=30 is_chim=1
ch3o mmol=31 is_chim=1
ch3o2 mmol=47 is_chim=1
ch3o2h mmol=48 is_chim=1
n mmol=14 is_chim=1
no mmol=30 is_chim=1
no2 mmol=46 is_chim=1
n2 mmol=28 is_chim=1 is_rad=1
hno3 mmol=63 is_chim=1
hno4 mmol=79 is_chim=1
n2o mmol=44 is_chim=1 SF_mode=1 SF_value=3.3e-7
no3 mmol=62 is_chim=1
n2o5 mmol=108 is_chim=1
</pre>

The traceur.def Input File

2022-05-11T08:33:05Z

Yjaziri: Created page with "== What is it for? == Tracers need to be listed in ''traceur.def''. Characteristics of the tracers can be also specified in ''traceur.def''. == What is a tracer? == Tracer..."