Planets - User contributions [en]

Installing Mars mesoscale model on spirit

2023-02-21T21:28:00Z

Aspiga: /* A more detailed run */

== Set up environment ==

Add this in your ~/.bashrc then source the file

<syntaxhighlight lang="Bash">
module purge
module load intel/2021.4.0
module load intel-mkl/2020.4.304
module load openmpi/4.0.7
module load hdf5/1.10.7-mpi
module load netcdf-fortran/4.5.3-mpi
module load netcdf-c/4.7.4-mpi
declare -x WHERE_MPI=/net/nfs/tools/u20/22.3/PrgEnv/intel/linux-ubuntu20.04-zen2/openmpi/4.0.7-intel-2021.4.0-43fdcnab3ydwu7ycrplnzlp6xieusuz7/bin/
declare -x NETCDF=/scratchu/spiga/les_mars_project_spirit/netcdf_hacks/SPIRIT
declare -x NCDFLIB=$NETCDF/lib
declare -x NCDFINC=$NETCDF/include
</syntaxhighlight>

Do not forget to declare the local directory in PATH by adding this to your ~/.bashrc

<syntaxhighlight lang="Bash">
declare -x PATH=./:$PATH
</syntaxhighlight>

It is necessary to unlimit the stacksize to avoit unwanted segmentation faults by adding this to your ~/.bashrc

<syntaxhighlight lang="Bash">
ulimit -s unlimited
</syntaxhighlight>

In the end, source the .bashrc file!

== Set up the installer ==

Go to your 'data' directory (cd /homedata/_MY_LOGIN_ ''or'' cd /data/_MY_LOGIN_) and download the installer with the following command
<syntaxhighlight lang="Bash">
svn co https://svn.lmd.jussieu.fr/Planeto/trunk/MESOSCALE/LMD_MM_MARS/SIMU
</syntaxhighlight>

Make sure the installer can be executed
<syntaxhighlight lang="Bash">
chmod 755 SIMU/meso_install.sh
</syntaxhighlight>

Make a link (e.g. where you are, in the parent directory of /data) to the main script in this SIMU directory
<syntaxhighlight lang="Bash">
ln -sf SIMU/meso_install.sh .
</syntaxhighlight>

Run the installer with a simple display of possible options
<syntaxhighlight lang="Bash">
./meso_install.sh -h
</syntaxhighlight>

== Install the code ==

Update to the latest version of installer
<syntaxhighlight lang="Bash">
cd SIMU
svn update
chmod 755 meso_install.sh
cd ..
</syntaxhighlight>

Run the installer by providing a name for your specific directory
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT
</syntaxhighlight>

''Special case'': In case you do not have a gitlab account, ask for an archive (tar.gz) of the code.
Let us assume the name is git-trunk-mesoscale-compile-run-spirit.tar.gz
and the file is in the current directory (for instance in /homedata/_MY_LOGIN_)
then run the installer with the following command
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT -a git-trunk-mesoscale-compile-run-spirit
</syntaxhighlight>

''Weird!'' fcm is not working interactively. It only works if being declared in the environment file by adding
<syntaxhighlight lang="Bash">
declare -x PATH=/homedata/_MY_LOGIN_/DESCRIBE_YOUR_RESEARCH_PROJECT/code/LMDZ.COMMON/FCM_V1.2/bin/:$PATH
</syntaxhighlight>
then recompile the GCM compiling (which had failed previously) by doing
<syntaxhighlight lang="Bash">
cd /homedata/_MY_LOGIN_/DESCRIBE_YOUR_RESEARCH_PROJECT/
./compile_gcm.sh
</syntaxhighlight>
and recreate start files from a sample start_archive.nc by doing
<syntaxhighlight lang="Bash">
./mini_startbase.sh
</syntaxhighlight>

== Run the full workflow GCM + initialization + mesoscale model ==

Have a look in the script named launch just for info or to change the number of processors or the step at which you start. Send the launch job to the cluster by typing
<syntaxhighlight lang="Bash">
sbatch launch
</syntaxhighlight>
You can check the status of the run by typing
<syntaxhighlight lang="Bash">
squeueme
</syntaxhighlight>

== A more detailed run ==

The best is probably to use a more complete startbase than the minimal one that was created. For instance, to get a more complete startbase, link 'data_gcm' to point towards '/data/spiga/2021_STARTBASES_rev2460/MY35'

To use the tyler cap setting in namelist.wps, download the tylerall archive here 'https://web.lmd.jussieu.fr/~aslmd/mesoscale_model/data_static/' and extract the content in the folder named data_static

Installing Mars mesoscale model on spirit

2023-02-21T21:23:00Z

Aspiga: /* Run the full workflow GCM + initialization + mesoscale model */

Installing Mars mesoscale model on spirit

2023-01-26T11:39:48Z

Aspiga: /* Run the full workflow GCM + initialization + mesoscale model */

Installing Mars mesoscale model on spirit

2023-01-26T11:39:38Z

Aspiga: /* Run the full workflow GCM + initialization + mesoscale model */

Installing Mars mesoscale model on spirit

2023-01-26T11:38:17Z

Aspiga: /* Install the code */

Installing Mars mesoscale model on spirit

2023-01-26T11:32:53Z

Aspiga: /* Install the code */

== Set up environment ==

Add this in your ~/.bashrc then source the file

<syntaxhighlight lang="Bash">
module purge
module load intel/2021.4.0
module load intel-mkl/2020.4.304
module load openmpi/4.0.7
module load hdf5/1.10.7-mpi
module load netcdf-fortran/4.5.3-mpi
module load netcdf-c/4.7.4-mpi
declare -x WHERE_MPI=/net/nfs/tools/u20/22.3/PrgEnv/intel/linux-ubuntu20.04-zen2/openmpi/4.0.7-intel-2021.4.0-43fdcnab3ydwu7ycrplnzlp6xieusuz7/bin/
declare -x NETCDF=/scratchu/spiga/les_mars_project_spirit/netcdf_hacks/SPIRIT
declare -x NCDFLIB=$NETCDF/lib
declare -x NCDFINC=$NETCDF/include
</syntaxhighlight>

Do not forget to declare the local directory in PATH by adding this to your ~/.bashrc

<syntaxhighlight lang="Bash">
declare -x PATH=./:$PATH
</syntaxhighlight>

It is necessary to unlimit the stacksize to avoit unwanted segmentation faults by adding this to your ~/.bashrc

<syntaxhighlight lang="Bash">
ulimit -s unlimited
</syntaxhighlight>

In the end, source the .bashrc file!

== Set up the installer ==

Go to your 'data' directory (cd /homedata/_MY_LOGIN_ ''or'' cd /data/_MY_LOGIN_) and download the installer with the following command
<syntaxhighlight lang="Bash">
svn co https://svn.lmd.jussieu.fr/Planeto/trunk/MESOSCALE/LMD_MM_MARS/SIMU
</syntaxhighlight>

Make sure the installer can be executed
<syntaxhighlight lang="Bash">
chmod 755 SIMU/meso_install.sh
</syntaxhighlight>

Make a link (e.g. where you are, in the parent directory of /data) to the main script in this SIMU directory
<syntaxhighlight lang="Bash">
ln -sf SIMU/meso_install.sh .
</syntaxhighlight>

Run the installer with a simple display of possible options
<syntaxhighlight lang="Bash">
./meso_install.sh -h
</syntaxhighlight>

== Install the code ==

Update to the latest version of installer
<syntaxhighlight lang="Bash">
cd SIMU
svn update
chmod 755 meso_install.sh
cd ..
</syntaxhighlight>

Run the installer by providing a name for your specific directory
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT
</syntaxhighlight>

''Special case'': In case you do not have a gitlab account, ask for an archive (tar.gz) of the code.
Let us assume the name is git-trunk-mesoscale-compile-run-spirit.tar.gz
and the file is in the current directory (for instance in /homedata/_MY_LOGIN_)
then run the installer with the following command
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT -a git-trunk-mesoscale-compile-run-spirit
</syntaxhighlight>

''Weird!'' fcm is not working interactively. It only works if being declared in the environment file by adding
<syntaxhighlight lang="Bash">
declare -x PATH=/homedata/_MY_LOGIN_/DESCRIBE_YOUR_RESEARCH_PROJECT/code/LMDZ.COMMON/FCM_V1.2/bin/:$PATH
</syntaxhighlight>
then recompile the GCM compiling (which had failed previously by doing
<syntaxhighlight lang="Bash">
cd /homedata/_MY_LOGIN_/DESCRIBE_YOUR_RESEARCH_PROJECT/
./compile_gcm.sh
</syntaxhighlight>

== Run the full workflow GCM + initialization + mesoscale model ==

Have a look in the script named launch just for info or to change the number of processors or the step at which you start. Send the launch job to the cluster by typing
<syntaxhighlight lang="Bash">
sbatch launch
</syntaxhighlight>

Other GCM Configurations worth knowing about

2023-01-24T22:20:44Z

Aspiga: /* 3D DYNAMICO setup */

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

=== 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 Github 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 GitHub file architecture (https://github.com/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-01-24T22:20:03Z

Aspiga: /* 3D DYNAMICO setup */

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

=== 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 wiki is here | Dynamico-giant]]

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 Github 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 GitHub file architecture (https://github.com/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

Dynamico-giant

2023-01-24T10:25:46Z

Aspiga:

[transferred from github, now active here]

= 1. Introduction =

"Welcome to the dynamico-giant wiki"

Dynamico-giant est un dépôt git qui permet d'installer le modèle Dynamico avec les fichiers de configs propres aux planètes géantes gazeuses et géantes glacées. Ci-dessous, vous trouverez presque (car nous ne sommes pas parfaits) toutes les informations sur l'installation, la compilation du modèle et les paramètres que vous pouvez modifier pour faire tourner le modèle.

"Allons-y!"

= 2. Installation =

== A) Fichiers d'architecture ==

=== - Modules ===

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

Modules used on Occigen:

<pre>ulimit -s unlimited
# modules
module purge
module load intel/17.0
module load intelmpi/2017.0.098
module load hdf5/1.8.17
module load netcdf/4.4.0_fortran-4.4.2
module load ncview
module load nco
module load qt
module load python</pre>
Modules used on Ciclad:

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

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

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

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

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

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

== B. Download ==

Download structure

Take place on a repository and git clone the model.

On occigen:

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

Install code

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

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

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

= 3. General parameters =

== A) Mesh grid & resolution ==

On run_icosa.def:

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

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

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

== B) Time ==

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

== C) Sponge layer ==

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

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

== D) Dissipation ==

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

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

Attention, Trop dissiper -> instabilité numérique

Pas assez dissiper -> instabilité dynamique trop forte

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

=== - Facteurs de dissipation ===

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

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

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

== E) Rayleigh Friction ==

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

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

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

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

== F) Conservation ==

Dans run_icosa.def:

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

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

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

== G) Traceur ==

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

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

run_icosa.def

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

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

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

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

= 4. Physical parameterizations =

== A) Cycle diurne ==

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

== B) Anneaux ==

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

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

== C) Collision-induced absorption data ==

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

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

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

== D) K-correlated data ==

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

== E) Cpp mode ==

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

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

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

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

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

Un exemple pour 3 couches:

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

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

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

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

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

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

== H) Rotation ==

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

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

== I) Appel à la physique ==

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

= 5. Ecriture des fichiers =

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

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

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

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

On a 20 sorties tous les 1000 jours.

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

== B) Ajouter une variable ==

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

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

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

== D) XIOS server ou client ==

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

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

= 6. Running the model =

== A) Compilation ==

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

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

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

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

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

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

but check Physics version 2142 and 2180

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

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

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

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

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

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

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

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

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

== B) Run 1D ==

Pour une simulation 1D, 1 seul CPU suffit.

To run on Occigen:

<code>sbatch job_mpi</code>

To run on Irene:

<code>ccc_msub job_mpi</code>

To see evolution of your job on Occigen:

<code>squeue -u username</code>

To see evolution of your job on Irene:

<code>ccc_mpp -u username</code>

To kill your job on Occigen:

<code>scancel id_of_your_job</code>

To kill your job on Irene:

<code>ccc_mdel id_of_your_job</code>

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

== C) Run 3D ==

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

=== - MPI ===

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

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

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

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

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

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

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

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

=== - OpenMP / MPI ===

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

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

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

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

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

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

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

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

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

== D) Optimisation ==

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

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

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

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

[[File:fig3.png]]

== E) Visualizing the output files ==

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

ncdiff file1.nc file2.nc output.nc

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

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

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

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

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

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

== F) Debug ==

=== - Pour debugger ===

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

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

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

== G) Pas de radiatif et perturbations ==

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

== H) PROFILING with DYNAMICO-Giant ==

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

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

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

``Welcome to the dynamico-giant wiki!

== pour debugger ==

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

== pourquoi diurnal=.false. ==

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

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

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

== comment changer la résolution ==

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

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

voir commentaires sur run_icosa.def

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

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

== comment changer la rotation? ==

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

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

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

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

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

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

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

== comment changer le bottom du modele ==

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

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

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

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

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

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

ncdiff file1.nc file2.nc output.nc

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

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

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

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

== bilan de moment cinétique ==

dans run_icosa.def

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

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

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

== XIOS server ou client ==

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

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

== Optimisation ==

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

== Versions fonctionnelles de dynamico-giant ==

=== Jupiter ===

* XIOS revision 1583 

* ICOSAGCM revision 756 

* IOIPSL revision 339 

* FCM_V1.2 revision 12 

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

but check Physics version 2142 and 2180

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

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

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

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 310 

* FCM_V1.2 revision 12 

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

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

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 310 

* FCM_V1.2 revision 12 

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

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

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 431 

* FCM_V1.2 revision 12 

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

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

* XIOS revision 1583 

* ICOSAGCM revision 765 

* IOIPSL revision 431 

* FCM_V1.2 revision 12 

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

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

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

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

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

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

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

works on 03/03/2022 for all HEAD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

run_icosa.def

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

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

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

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

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

File:Fig3.png

2023-01-24T10:22:48Z

Aspiga:

File:Fig2.png

2023-01-24T10:22:30Z

Aspiga:

File:Fig1.png

2023-01-24T10:22:09Z

Aspiga:

Dynamico-giant

2023-01-24T10:21:24Z

Aspiga: /* D) Optimisation */

Dynamico-giant

2023-01-24T10:18:25Z

Aspiga:

Dynamico-giant

2023-01-24T10:17:04Z

Aspiga: Created page with "[transferred from github, now active here] # 1. Introduction "Welcome to the dynamico-giant wiki" Dynamico-giant est un dépôt git qui permet d'installer le modèle Dynami..."

[transferred from github, now active here]

# 1. Introduction

"Welcome to the dynamico-giant wiki"

Dynamico-giant est un dépôt git qui permet d'installer le modèle Dynamico avec les fichiers de configs propres aux planètes géantes gazeuses et géantes glacées. Ci-dessous, vous trouverez presque (car nous ne sommes pas parfaits) toutes les informations sur l'installation, la compilation du modèle et les paramètres que vous pouvez modifier pour faire tourner le modèle.

"Allons-y!"

# 2. Installation

## A) Fichiers d'architecture

### - Modules

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

Modules used on Occigen:
```
ulimit -s unlimited
# modules
module purge
module load intel/17.0
module load intelmpi/2017.0.098
module load hdf5/1.8.17
module load netcdf/4.4.0_fortran-4.4.2
module load ncview
module load nco
module load qt
module load python
```

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

### - Installation sur un nouveau cluster

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

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

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

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

## B. Download

Download structure

Take place on a repository and git clone the model.

On occigen:
```
cd $SCRATCHDIR
git clone https://github.com/aymeric-spiga/dynamico-giant.git [optional different name]
```

## C. Install

Install code
```
cd dynamico-giant
./install.sh
./install_ioipsl.sh
```

A login and a password are necessary to install IOIPSL (only for the first time, after that we can save them). Please contact TGCC computing center to get the login/password.

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

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

# 3. General parameters
## A) Mesh grid & resolution

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

### - Remapping

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

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

## B) Time

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

## C) Sponge layer

```
iflag_sponge=0 for no sponge (default)
iflag_sponge=1 for sponge over 4 topmost layers
iflag_sponge=2 for sponge from top to ~1% of top layer pressure
mode_sponge=1 for u,v --> 0
mode_sponge=2 for u,v --> zonal mean
mode_sponge=3 for u,v,h --> zonal mean
tau_sponge --> damping frequency at last layer
--> e-5 medium / e-4 strong yet reasonable / e-3 very strong
```

Spiga et al (2020): Shaw and Shepherd (2007) showed that the inclusion of sponge-layer parameterizations that do not conserve angular momentum (which is the case for Rayleigh drag), or allow for momentum to escape to space, implies a sensitivity of the dynamical results (especially zonal wind speed) to the choice for model top or drag characteristic timescale, because of spurious downward influence when momentum conservation is violated.

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

## D) Dissipation

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

```
tau_graddiv --> dissipation timescale of smallest wvl: u,v (gradiv) : real (default=5000)
tau_gradrot --> dissipation timescale of smallest wvl: u,v (nxgradrot) : real (default=5000)
tau_divgrad --> dissipation timescale of smallest wvl: h (divgrad) : real (default=5000)
nitergdiv --> number of iterations for gradiv operator : integer (default=1)
nitergrot --> number of iterations for nxgradrot operator : integer (default=1)
niterdivgrad --> number of iterations for divgrad operator : integer (default=1)
```

tau_graddiv,tau_gradrot,tau_divgrad correspondent au temps de dissipation (plus c'est petit, plus la dissipation est efficace).
nitergdiv,nitergrot,niterdivgrad correspondent à l'ordre du laplacien (plus c'est grand, plus on dissipe sélectivement les petites échelles).

Attention, Trop dissiper -> instabilité numérique

Pas assez dissiper -> instabilité dynamique trop forte

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

### - Facteurs de dissipation

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

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

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

## E) Rayleigh Friction

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

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

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

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

## F) Conservation

Dans run_icosa.def:

```
check_conservation = detailed
itau_check_conserv = 320
```

Le itau_check_conserv est comme itau_physics pour que la contribution de la physique à AAM ne soit pas nulle. de plus il est coûteux d'appeler les diagnostics trop souvent.

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

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

## G) Traceur

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

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

run_icosa.def

nqtot = 0

traceur.def

0

context_dynamico.xml (ligne 125)

<field id="q_start" name="q" grid_ref="grid_q_start" prec="8"/>

## H) Bottom du modèle

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

# 4. Physical parameterizations
## A) Cycle diurne

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

## B) Anneaux

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

`rings_shadow = .true.`

## C) Collision-induced absorption data

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

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

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

## D) K-correlated data

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

## E) Cpp mode

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

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

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

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

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

Un exemple pour 3 couches:
```
aeronlay = .true.
nlayaero = 3
aeronlay_tauref = 2.5 0.04 0.1
aeronlay_lamref = 0.8e-6 0.8e-6 0.16e-6
aeronlay_choice = 2 2 1
aeronlay_pbot = 1.5e5 1.6e5 20.
aeronlay_ptop = 1.1e5 1. 1.
aeronlay_sclhght = 0.1 2.0 1
aeronlay_size = 0.5e-6 0.05e-6 0.5e-6
aeronlay_nueff = 0.3 0.3 0.3
optprop_aeronlay_vis = optprop_aerosol2_vis.dat optprop_aerosol3_vis.dat optprop_carbon4_vis.dat
optprop_aeronlay_ir = optprop_aerosol2_ir.dat optprop_aerosol3_ir.dat optprop_carbon4_ir.dat
```

## G) Panaches thermiques

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

callrad = true
calladj = true
tous les autres mots clés à false (y compris `calltherm`).

2) Faire un "makestart" run : permet d'obtenir les fichiers restart à partir du profil de température initial.
Il s'agit du run dont l'état initial est le profil de température créé par run 1D (`temp_profile.txt` est appliquer à chaque point de grille horizontale du modèle). L'état initial est ainsi une planète isotherme horizontalement mais qui varie verticalement.
Pour ce run, aucun traceur ne va être utilisé dans le modèle. Néanmoins, il faut renseigner au modèle le nombre de traceurs que nous souhaitons utiliser avec le schéma des panaches thermiques afin qu'il puisse créer la dimension nq et le champ q dans les fichiers `restart_icosa.nc` et `restartfi.nc`.
dans **callphys.def** :

traceur = true
dans **run_icosa.def** : `nqtot = 2` (par exemple, h2o_vap et h2o_ice)
dans **traceur.def** :

2
h2o_vap
h2o_ice

3) Ajout des quantités pour chaque traceur.
Ici, nous ajoutons les profils pour chacun des traceurs dans les fichiers `restart_icosa.nc` et `restartfi.nc` "à la main" en utilisant le programme python `/processing_codes/tracer_settings.py` pour obtenir des fichiers restart avec la bonne abondance d'eau dans le cas présent.

4) Commencer la simulation :
Il ne reste plus qu'à lancer la simulation 3D avec les nouveaux fichiers restart et les réglages suivant :
dans **callphys.def** :

traceur = true
calltherm = true
# thermal plume model options:
divmpl = true
r_aspect_thermals = 2.0
tau_thermals = 0.0
betalpha = 0.9
afact = 0.7
fact_epsilon = 2.e-4
alpha_max = 0.7
fomass_max = 0.5
pres_limit = 2.e5
water = true
watercond = true
waterain = true
evap_prec = true

dans **run_icosa.def** : `nqtot = 2`
dans **traceur.def** :

2
h2o_vap
h2o_ice

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

## H) Rotation

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

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

## I) Appel à la physique

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

# 5. Ecriture des fichiers
## A) Nombre d'écriture dans chaque Xhistins.nc

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

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

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

On a 20 sorties tous les 1000 jours.

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

## B) Ajouter une variable

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

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

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

## D) XIOS server ou client

1) XIOS client `use_server=False`
Broadwell 24 processeurs sur 28

2) XIOS server `use_server=true`
Broadwell 24 processurs sur 28 + 4 processeurs pour XIOS

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

# 6. Running the model
## A) Compilation

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

`./compile_occigen.sh`

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

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

### - Versions fonctionnelles de dynamico-giant

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

but check Physics version 2142 and 2180

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

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

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

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

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

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

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

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

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

## B) Run 1D

Pour une simulation 1D, 1 seul CPU suffit.

To run on Occigen:

`sbatch job_mpi`

To run on Irene:

`ccc_msub job_mpi`

To see evolution of your job on Occigen:

`squeue -u username`

To see evolution of your job on Irene:

`ccc_mpp -u username`

To kill your job on Occigen:

`scancel id_of_your_job`

To kill your job on Irene:

`ccc_mdel id_of_your_job`

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

## C) Run 3D

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

### - MPI

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

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

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

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

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

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

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

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

### - OpenMP / MPI

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

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

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

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

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

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

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

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

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

## D) Optimisation

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

**MPI:**
![](https://web.lmd.jussieu.fr/~gmilcareck/mpi_uranus_occigen_broadwell.png)

**OpenMP/MPI:**
![](https://web.lmd.jussieu.fr/~gmilcareck/ompmpi_uranus_occigen_broadwell.png)

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

![](https://web.lmd.jussieu.fr/~gmilcareck/comparaison_uranus_occigen_broadwell.png)

## E) Visualizing the output files

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

ncdiff file1.nc file2.nc output.nc

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

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

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

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

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

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

## F) Debug

### - Pour debugger

Réglez `info_level` à `100` dans le fichier `iodef.xml` .

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

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

## G) Pas de radiatif et perturbations

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

## H) PROFILING with DYNAMICO-Giant

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

gprof icosa_lmdz.exe goon.out > analysis.txt

Installing Mars mesoscale model on spirit

2023-01-23T16:24:35Z

Aspiga: /* Set up environment */

== Set up environment ==

Add this in your ~/.bashrc then source the file

<syntaxhighlight lang="Bash">
module purge
module load intel/2021.4.0
module load intel-mkl/2020.4.304
module load openmpi/4.0.7
module load hdf5/1.10.7-mpi
module load netcdf-fortran/4.5.3-mpi
module load netcdf-c/4.7.4-mpi
declare -x WHERE_MPI=/net/nfs/tools/u20/22.3/PrgEnv/intel/linux-ubuntu20.04-zen2/openmpi/4.0.7-intel-2021.4.0-43fdcnab3ydwu7ycrplnzlp6xieusuz7/bin/
declare -x NETCDF=/scratchu/spiga/les_mars_project_spirit/netcdf_hacks/SPIRIT
declare -x NCDFLIB=$NETCDF/lib
declare -x NCDFINC=$NETCDF/include
</syntaxhighlight>

Do not forget to declare the local directory in PATH by adding this to your ~/.bashrc

<syntaxhighlight lang="Bash">
declare -x PATH=./:$PATH
</syntaxhighlight>

It is necessary to unlimit the stacksize to avoit unwanted segmentation faults by adding this to your ~/.bashrc

<syntaxhighlight lang="Bash">
ulimit -s unlimited
</syntaxhighlight>

In the end, source the .bashrc file!

== Set up the installer ==

Go to your 'data' directory (cd /homedata/_MY_LOGIN_ ''or'' cd /data/_MY_LOGIN_) and download the installer with the following command
<syntaxhighlight lang="Bash">
svn co https://svn.lmd.jussieu.fr/Planeto/trunk/MESOSCALE/LMD_MM_MARS/SIMU
</syntaxhighlight>

Make sure the installer can be executed
<syntaxhighlight lang="Bash">
chmod 755 SIMU/meso_install.sh
</syntaxhighlight>

Make a link (e.g. where you are, in the parent directory of /data) to the main script in this SIMU directory
<syntaxhighlight lang="Bash">
ln -sf SIMU/meso_install.sh .
</syntaxhighlight>

Run the installer with a simple display of possible options
<syntaxhighlight lang="Bash">
./meso_install.sh -h
</syntaxhighlight>

== Install the code ==

Update to the latest version of installer
<syntaxhighlight lang="Bash">
cd SIMU
svn update
chmod 755 meso_install.sh
cd ..
</syntaxhighlight>

Run the installer by providing a name for your specific directory
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT
</syntaxhighlight>

''Special case'': In case you do not have a gitlab account, ask for an archive (tar.gz) of the code.
Let us assume the name is git-trunk-mesoscale-compile-run-spirit.tar.gz
and the file is in the current directory (for instance in /homedata/_MY_LOGIN_)
then run the installer with the following command
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT -a git-trunk-mesoscale-compile-run-spirit
</syntaxhighlight>

''Weird!'' fcm is not working interactively. It only works if being declared in the environment file by adding
<syntaxhighlight lang="Bash">
declare -x PATH=/homedata/_MY_LOGIN_/DESCRIBE_YOUR_RESEARCH_PROJECT/code/LMDZ.COMMON/FCM_V1.2/bin/:$PATH
</syntaxhighlight>
then recompile the GCM compiling (which had failed previously by doing
<syntaxhighlight lang="Bash">
cd /homedata/_MY_LOGIN_/DESCRIBE_YOUR_RESEARCH_PROJECT/
./compile_gcm.sh
</syntaxhighlight>

Installing Mars mesoscale model on spirit

2023-01-23T16:22:58Z

Aspiga: /* Set up environment */

== Set up environment ==

Add this in your ~/.bashrc then source the file

<syntaxhighlight lang="Bash">
module purge
module load intel/2021.4.0
module load intel-mkl/2020.4.304
module load openmpi/4.0.7
module load hdf5/1.10.7-mpi
module load netcdf-fortran/4.5.3-mpi
module load netcdf-c/4.7.4-mpi
declare -x WHERE_MPI=/net/nfs/tools/u20/22.3/PrgEnv/intel/linux-ubuntu20.04-zen2/openmpi/4.0.7-intel-2021.4.0-43fdcnab3ydwu7ycrplnzlp6xieusuz7/bin/
declare -x NETCDF=/scratchu/spiga/les_mars_project_spirit/netcdf_hacks/SPIRIT
declare -x NCDFLIB=$NETCDF/lib
declare -x NCDFINC=$NETCDF/include
</syntaxhighlight>

Do not forget to declare the local directory in PATH by adding this to your ~/.bashrc

<syntaxhighlight lang="Bash">
declare -x PATH=./:$PATH
</syntaxhighlight>

It is necessary to unlimit the stacksize to avoit unwanted segmentation faults by adding this to your ~/.bashrc

<syntaxhighlight lang="Bash">
ulimit -s unlimited
</syntaxhighlight>

== Set up the installer ==

Go to your 'data' directory (cd /homedata/_MY_LOGIN_ ''or'' cd /data/_MY_LOGIN_) and download the installer with the following command
<syntaxhighlight lang="Bash">
svn co https://svn.lmd.jussieu.fr/Planeto/trunk/MESOSCALE/LMD_MM_MARS/SIMU
</syntaxhighlight>

Make sure the installer can be executed
<syntaxhighlight lang="Bash">
chmod 755 SIMU/meso_install.sh
</syntaxhighlight>

Make a link (e.g. where you are, in the parent directory of /data) to the main script in this SIMU directory
<syntaxhighlight lang="Bash">
ln -sf SIMU/meso_install.sh .
</syntaxhighlight>

Run the installer with a simple display of possible options
<syntaxhighlight lang="Bash">
./meso_install.sh -h
</syntaxhighlight>

== Install the code ==

Update to the latest version of installer
<syntaxhighlight lang="Bash">
cd SIMU
svn update
chmod 755 meso_install.sh
cd ..
</syntaxhighlight>

Run the installer by providing a name for your specific directory
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT
</syntaxhighlight>

''Special case'': In case you do not have a gitlab account, ask for an archive (tar.gz) of the code.
Let us assume the name is git-trunk-mesoscale-compile-run-spirit.tar.gz
and the file is in the current directory (for instance in /homedata/_MY_LOGIN_)
then run the installer with the following command
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT -a git-trunk-mesoscale-compile-run-spirit
</syntaxhighlight>

''Weird!'' fcm is not working interactively. It only works if being declared in the environment file by adding
<syntaxhighlight lang="Bash">
declare -x PATH=/homedata/_MY_LOGIN_/DESCRIBE_YOUR_RESEARCH_PROJECT/code/LMDZ.COMMON/FCM_V1.2/bin/:$PATH
</syntaxhighlight>
then recompile the GCM compiling (which had failed previously by doing
<syntaxhighlight lang="Bash">
cd /homedata/_MY_LOGIN_/DESCRIBE_YOUR_RESEARCH_PROJECT/
./compile_gcm.sh
</syntaxhighlight>

Installing Mars mesoscale model on spirit

2023-01-23T16:11:06Z

Aspiga: /* Install the code */

Installing Mars mesoscale model on spirit

2023-01-23T16:08:55Z

Aspiga: /* Install the code */

Installing Mars mesoscale model on spirit

2023-01-23T15:42:53Z

Aspiga: /* Set up environment */

Installing Mars mesoscale model on spirit

2023-01-23T15:42:25Z

Aspiga: /* Set up environment */

== Set up environment ==

Add this in your ~/.bashrc then source the file

<syntaxhighlight lang="Bash" line>
module purge
module load intel/2021.4.0
module load intel-mkl/2020.4.304
module load openmpi/4.0.7
module load hdf5/1.10.7-mpi
module load netcdf-fortran/4.5.3-mpi
module load netcdf-c/4.7.4-mpi
declare -x WHERE_MPI=/net/nfs/tools/u20/22.3/PrgEnv/intel/linux-ubuntu20.04-zen2/openmpi/4.0.7-intel-2021.4.0-43fdcnab3ydwu7ycrplnzlp6xieusuz7/bin/
declare -x NETCDF=/scratchu/spiga/les_mars_project_spirit/netcdf_hacks/SPIRIT
declare -x NCDFLIB=$NETCDF/lib
declare -x NCDFINC=$NETCDF/include
</syntaxhighlight>

Do not forget to declare the local directory in PATH

<syntaxhighlight lang="Bash" line>
declare -x PATH=./:$PATH
</syntaxhighlight>

== Set up the installer ==

Go to your 'data' directory (cd /homedata/_MY_LOGIN_ ''or'' cd /data/_MY_LOGIN_) and download the installer with the following command
<syntaxhighlight lang="Bash">
svn co https://svn.lmd.jussieu.fr/Planeto/trunk/MESOSCALE/LMD_MM_MARS/SIMU
</syntaxhighlight>

Make sure the installer can be executed
<syntaxhighlight lang="Bash">
chmod 755 SIMU/meso_install.sh
</syntaxhighlight>

Make a link (e.g. where you are, in the parent directory of /data) to the main script in this SIMU directory
<syntaxhighlight lang="Bash">
ln -sf SIMU/meso_install.sh .
</syntaxhighlight>

Run the installer with a simple display of possible options
<syntaxhighlight lang="Bash">
./meso_install.sh -h
</syntaxhighlight>

== Install the code ==

Update to the latest version of installer
<syntaxhighlight lang="Bash">
cd SIMU
svn update
chmod 755 meso_install.sh
cd ..
</syntaxhighlight>

Run the installer by providing a name for your specific directory
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT
</syntaxhighlight>

''Special case'': In case you do not have a gitlab account, ask for an archive (tar.gz) of the code.
Let us assume the name is git-trunk-mesoscale-compile-run-spirit.tar.gz
and the file is in the current directory (for instance in /homedata/_MY_LOGIN_)
then run the installer with the following command
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT -a git-trunk-mesoscale-compile-run-spirit
</syntaxhighlight>

Installing Mars mesoscale model on spirit

2023-01-23T15:35:28Z

Aspiga: /* Install the code */

== Set up environment ==

Add this in your ~/.bashrc then source the file

<syntaxhighlight lang="Bash" line>
module purge
module load intel/2021.4.0
module load intel-mkl/2020.4.304
module load openmpi/4.0.7
module load hdf5/1.10.7-mpi
module load netcdf-fortran/4.5.3-mpi
module load netcdf-c/4.7.4-mpi
declare -x WHERE_MPI=/net/nfs/tools/u20/22.3/PrgEnv/intel/linux-ubuntu20.04-zen2/openmpi/4.0.7-intel-2021.4.0-43fdcnab3ydwu7ycrplnzlp6xieusuz7/bin/
declare -x NETCDF=/scratchu/spiga/les_mars_project_spirit/netcdf_hacks/SPIRIT
declare -x NCDFLIB=$NETCDF/lib
declare -x NCDFINC=$NETCDF/include
</syntaxhighlight>

== Set up the installer ==

Go to your 'data' directory (cd /homedata/_MY_LOGIN_ ''or'' cd /data/_MY_LOGIN_) and download the installer with the following command
<syntaxhighlight lang="Bash">
svn co https://svn.lmd.jussieu.fr/Planeto/trunk/MESOSCALE/LMD_MM_MARS/SIMU
</syntaxhighlight>

Make sure the installer can be executed
<syntaxhighlight lang="Bash">
chmod 755 SIMU/meso_install.sh
</syntaxhighlight>

Make a link (e.g. where you are, in the parent directory of /data) to the main script in this SIMU directory
<syntaxhighlight lang="Bash">
ln -sf SIMU/meso_install.sh .
</syntaxhighlight>

Run the installer with a simple display of possible options
<syntaxhighlight lang="Bash">
./meso_install.sh -h
</syntaxhighlight>

== Install the code ==

Update to the latest version of installer
<syntaxhighlight lang="Bash">
cd SIMU
svn update
chmod 755 meso_install.sh
cd ..
</syntaxhighlight>

Run the installer by providing a name for your specific directory
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT
</syntaxhighlight>

''Special case'': In case you do not have a gitlab account, ask for an archive (tar.gz) of the code.
Let us assume the name is git-trunk-mesoscale-compile-run-spirit.tar.gz
and the file is in the current directory (for instance in /homedata/_MY_LOGIN_)
then run the installer with the following command
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT -a git-trunk-mesoscale-compile-run-spirit
</syntaxhighlight>

Installing Mars mesoscale model on spirit

2023-01-23T15:25:39Z

Aspiga: /* Install the code */

== Set up environment ==

Add this in your ~/.bashrc then source the file

<syntaxhighlight lang="Bash" line>
module purge
module load intel/2021.4.0
module load intel-mkl/2020.4.304
module load openmpi/4.0.7
module load hdf5/1.10.7-mpi
module load netcdf-fortran/4.5.3-mpi
module load netcdf-c/4.7.4-mpi
declare -x WHERE_MPI=/net/nfs/tools/u20/22.3/PrgEnv/intel/linux-ubuntu20.04-zen2/openmpi/4.0.7-intel-2021.4.0-43fdcnab3ydwu7ycrplnzlp6xieusuz7/bin/
declare -x NETCDF=/scratchu/spiga/les_mars_project_spirit/netcdf_hacks/SPIRIT
declare -x NCDFLIB=$NETCDF/lib
declare -x NCDFINC=$NETCDF/include
</syntaxhighlight>

== Set up the installer ==

Go to your 'data' directory (cd /homedata/_MY_LOGIN_ ''or'' cd /data/_MY_LOGIN_) and download the installer with the following command
<syntaxhighlight lang="Bash">
svn co https://svn.lmd.jussieu.fr/Planeto/trunk/MESOSCALE/LMD_MM_MARS/SIMU
</syntaxhighlight>

Make sure the installer can be executed
<syntaxhighlight lang="Bash">
chmod 755 SIMU/meso_install.sh
</syntaxhighlight>

Make a link (e.g. where you are, in the parent directory of /data) to the main script in this SIMU directory
<syntaxhighlight lang="Bash">
ln -sf SIMU/meso_install.sh .
</syntaxhighlight>

Run the installer with a simple display of possible options
<syntaxhighlight lang="Bash">
./meso_install.sh -h
</syntaxhighlight>

== Install the code ==

Update to the latest version of installer
<syntaxhighlight lang="Bash">
cd SIMU
svn update
cd ..
</syntaxhighlight>

Run the installer by providing a name for your specific directory
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT
</syntaxhighlight>

''Special case'': In case you do not have a gitlab account, ask for an archive (tar.gz) of the code.
Let us assume the name is git-trunk-mesoscale-compile-run-spirit.tar.gz
and the file is in the current directory (for instance in /homedata/_MY_LOGIN_)
then run the installer with the following command
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT -a git-trunk-mesoscale-compile-run-spirit
</syntaxhighlight>

Installing Mars mesoscale model on spirit

2023-01-23T15:19:19Z