Planets - User contributions [en]

Radioactive tracers

2025-09-17T14:01:04Z

Maxime Maurice:

This page shows how to use radioactive tracers in the Generic PCM to tune the eddy mixing coefficient of 1D simulations in order to reproduce 3D dynamical mixing.
= Motivation =
The Generic PCM has both a 3D and a 1D version. While the 3D self-consistently solves for dynamical mixing of advected quantities (like temperature or tracers), this process can only be parametrized in 1D. This is done by approximating dynamical mixing by a diffusive process:

<math>\frac{\partial q}{\partial t}=-K_{zz}\frac{\partial^2 q}{\partial z^2}</math>

with <math>q</math> the tracer's mass mixing ratio, <math>t</math> time, <math>z</math> altitude, and <math>K_{zz}</math> <math<K_{zz}</math> the vertical diffusion coefficient (in m/s²), also called "eddy mixing coefficient". Notice that <math<K_{zz}</math> is often given in CGS units (cm/s²) in the astrophysical community. This coefficient's value (or vertical profile) is tuned so that 1D abundance profiles match 3D averaged ones.

Depending on the planetary setup, the value (or vertical profile) of <math>K_{zz}</math> that can best reproduce 3D mixing varies. If you want to tune the vertical eddy mixing coefficient to one of your 3D cases, you can run a simulation with radioactively decreasing abstract tracers in both 1D and 3D and compare the vertical distribution of these tracers once a steady-state is reached. In 3D, this distribution is the result of a competition between dynamical mixing which tends to homogenize the atmosphere, and radioactive decay which destroys the tracers with increasing probability with time after their injection. Injection is done from the surface or the top of the atmosphere. Depending on the location of injection, half-life of the tracers, and atmosphere dynamics, the steady-state profile vary.

= Use =
In order to use radioactive tracers, you simply need to add them to the traceur.def file, and define their half-life as well as injection flux at each location. This is done by setting the flags corresponding to these values in the modern version of the traceur.def. In the Generic PCM deftank, the file '''traceur.def.radioactive''' gives an illustration of it, which 6 different tracers, each having half life of 1 day, 1 week or 1 month (normalized by the time of a Martian sol), injected by the surface or the top of the atmosphere:

r1 half_life=8.64e4 bot_prod=8e-6
r2 half_life=6.048e5 bot_prod=1.15e-6
r3 half_life=2.592e6 bot_prod=2.7e-7
r4 half_life=8.64e4 top_prod=8e-6
r5 half_life=6.048e5 top_prod=1.15e-6
r6 half_life=2.592e6 top_prod=2.7e-7

The tracers '''r1''' to '''r3''' are injected from the surface and tracers '''r4''' to '''r6''' are injected from the top of the atmosphere. The flux multiplied by the half-life is kept constant across tracers to keep the profiles comparable. Notice that if no other process affect these tracers (as it should be since these tracers are merely numerical tools and their decay does not aim at modelling any real physical process), the value of their abundance is arbitrary and only the shape of the profile matters.

Below is an illustration of the steady-state distribution of these tracers in the early Mars atmosphere of the benchmark in 3D, and in 1D for three different values of <math>K_{zz}</math>. One sees that large <math>K_{zz}</math> overestimate vertical mixing and thus atmosphere homogenization, while low values underestimate it.

[[File:Radioactive tracers.png|center|frame|Comparison of the vertical mixing between a 3D case and 3 1D simulations of early Mars atmosphere using different values of the eddy mixing coefficient.]]

Radioactive tracers

2025-09-17T14:00:27Z

Maxime Maurice:

File:Radioactive tracers.png

2025-09-17T13:59:21Z

Maxime Maurice: Maxime Maurice uploaded a new version of File:Radioactive tracers.png

Comparison of vertical mixing between a 3D case and 3 1D simulations of early Mars using different eddy mixing coefficients.

Radioactive tracers

2025-09-17T13:58:30Z

Maxime Maurice:

Radioactive tracers

2025-09-17T13:58:06Z

Maxime Maurice:

Radioactive tracers

2025-09-17T13:55:16Z

Maxime Maurice:

File:Radioactive tracers.png

2025-09-17T13:54:22Z

Maxime Maurice: Maxime Maurice uploaded a new version of File:Radioactive tracers.png

Comparison of vertical mixing between a 3D case and 3 1D simulations of early Mars using different eddy mixing coefficients.

Radioactive tracers

2025-09-17T13:52:45Z

Maxime Maurice:

This page shows how to use radioactive tracers in the Generic PCM to tune the eddy mixing coefficient of 1D simulations in order to reproduce 3D dynamical mixing.
= Motivation =
The Generic PCM has both a 3D and a 1D version. While the 3D self-consistently solves for dynamical mixing of advected quantities (like temperature or tracers), this process can only be parametrized in 1D. This is done by approximating dynamical mixing by a diffusive process:

<math>\frac{\partial q}{\partial t}=-K_{zz}\frac{\partial^2 q}{\partial z^2}</math>

with <math>q</math> the tracer's mass mixing ratio, <math>t</math> time, <math>z</math> altitude, and <math>K_{zz}</math> <math<K_{zz}</math> the vertical diffusion coefficient (in m/s²), also called "eddy mixing coefficient". Notice that <math<K_{zz}</math> is often given in CGS units (cm/s²) in the astrophysical community. This coefficient's value (or vertical profile) is tuned so that 1D abundance profiles match 3D averaged ones.

Depending on the planetary setup, the value (or vertical profile) of <math>K_{zz}</math> that can best reproduce 3D mixing varies. If you want to tune the vertical eddy mixing coefficient to one of your 3D cases, you can run a simulation with radioactively decreasing abstract tracers in both 1D and 3D and compare the vertical distribution of these tracers once a steady-state is reached. In 3D, this distribution is the result of a competition between dynamical mixing which tends to homogenize the atmosphere, and radioactive decay which destroys the tracers with increasing probability with time after their injection. Injection is done from the surface or the top of the atmosphere. Depending on the location of injection, half-life of the tracers, and atmosphere dynamics, the steady-state profile vary.

= Use =
In order to use radioactive tracers, you simply need to add them to the traceur.def file, and define their half-life as well as injection flux at each location. This is done by setting the flags corresponding to these values in the modern version of the traceur.def. In the Generic PCM deftank, the file '''traceur.def.radioactive''' gives an illustration of it, which 6 different tracers, each having half life of 1 day, 1 week or 1 month (normalized by the time of a Martian sol), injected by the surface or the top of the atmosphere:

r1 half_life=8.64e4 bot_prod=8e-6
r2 half_life=6.048e5 bot_prod=1.15e-6
r3 half_life=2.592e6 bot_prod=2.7e-7
r4 half_life=8.64e4 top_prod=8e-6
r5 half_life=6.048e5 top_prod=1.15e-6
r6 half_life=2.592e6 top_prod=2.7e-7

The tracers '''r1''' to '''r3''' are injected from the surface and tracers '''r4''' to '''r6''' are injected from the top of the atmosphere. The flux multiplied by the half-life is kept constant across tracers to keep the profiles comparable. Notice that if no other process affect these tracers (as it should be since these tracers are merely numerical tools and their decay does not aim at modelling any real physical process), the value of their abundance is arbitrary and only the shape of the profile matters.

Below is an illustration of the steady-state distribution of these tracers in the early Mars atmosphere of the benchmark in 3D, and in 1D for three different values of <math>K_{zz}</math>. One sees that large <math>K_{zz}</math> overestimate vertical mixing and thus atmosphere homogenization, while low values underestimate it.

[[File:radioactive_tracers.png|center|frame|Comparison of the vertical mixing between a 3D case and 3 1D simulations of early Mars atmosphere using different values of the eddy mixing coefficient.]]

File:Radioactive tracers.png

2025-09-17T13:50:33Z

Maxime Maurice: Maxime Maurice uploaded a new version of File:Radioactive tracers.png

Comparison of vertical mixing between a 3D case and 3 1D simulations of early Mars using different eddy mixing coefficients.

Physics of the Generic PCM

2025-05-02T06:34:54Z

Maxime Maurice: /* CO2 condensation */

This page describes the various physical parametrizations of the Generic PCM and the chronology of their call through the physical iteration. This chronology is important because some variables need to be updated by certain processes before others (examples).
During one physical iteration, the code passes through multiple sub-routines each encapsulating a parametrization. The sub-routines usually take as arguments:
*the dynamical values of the state variables
*the dynamical tendencies of the state variables
*any additional relevant variable
*any additional relevant tendency
and it returns in general tendencies (of the state variables as well as of any other relevant variable).

Work in progress. Need to add links.

=Initialization=
==First call==
Some initializations only need to be done at the very first iteration (e.g. examples).
==Each call==
Some other initializations need to be done at each iteration (e.g. examples).

=Radiative transfer=
==Correlated-k==
The main radiative transfer solver of the Generic PCM implements the correlated-k method, which provides a flexible and quick way to solve radiative transfer equations, particularly suited for GCMs. More informations here.
==Newtonian relaxation==
Newton was a very relaxed physicist, still inspiring us today.
==No atmosphere==
If you have no atmosphere, why do you need a GCM?

=Vertical diffusion=
Compute the vertical diffusion due to turbulence in the planetary boundary layer
==vdifc==
The "old" vertical diffusion routine.
==turbdiff==
The new (and improved!) vertical diffusion routine

=Convection=

Convective mixing in an atmosphere column involves non-resolved, sub-grid processes. To treat convectively unstable regions, there are two mutually exclusive options (convadj.F90 and thermcell_mod.F90). These processes are parameterized using the following routines:

==Dry convection (convadj.F90)==

This is the simplest and most robust parametrization for dry convective adjustment without free parameters. More info [[Convective_adjustment_scheme_in_the_generic_PCM|here]].

==Thermal plume (thermcell_mod.F90)==
This module implements a more accurate and sophisticated parametrization of convection, although it involves several free parameters that need to be tuned for each planet. More info [[Thermal_plume_model_Generic_PCM|here]].

==Non-orographic gravity waves: (''nonoro_gwd_ran_mod.F90'') ==

Parametrization of the momentum flux deposition due to a discrete number of gravity waves randomly generated by setting their waves characteristics (set as Gaussian distribution).

More info [[Non orographic gravity waves drag|here]].

=CO2 condensation (condense_co2.F90)=
Inheriting from the Mars PCM where it is the background species, CO2 condensation is treated as a dedicated step in the Generic PCM's physics. Notice that it only concerns CO2 as a background gas. More info [[CO2_Condensation_(Generic_PCM)|here]].

=Tracers=
Many things can be advected by tracers in the Generic PCM, like chemical species or aerosols. Physical processes involving tracers are parameterized using the following routines:

==Volcano==
This routine parameterizes a source of tracers corresponding to volcanic eruption. More information here.

==Water/ice==
Water aerosols (liquid or solid) are created (resp. consumed) by condensation (resp. vaporization or sublimation), consuming (resp. releasing) latent heat in the atmosphere. In the Generic PCM, the (atmospheric part of the) water cycle is handled by various routines, as explained here.

==Photochemistry==
Chemistry can turn molecules into other molecules, by the action of temperature (thermochemistry) or UV light (photochemistry). This is handled by the photochemistry routine, described [[Photochemistry_of_the_Generic_PCM|here]].

==Generic condensation==
On Earth, only water condenses in the atmosphere, but on other planets (which the Generic PCM aims at simulating), many other chemicals can undergo state change. To take that into account, the Generic PCM has a flexible scheme to deal with any arbitrary species, as desbribed [[Radiative_Generic_Condensable_Specie|here]].

==Sedimentation==
What goes up must come down, as explained [[Sedimentation_of_tracers_in_the_generic_PCM|here]].

==Updates==
This section essentially takes care that the condensation of a major species (e.g. water vapor in steam-rich atmospheres) affects other species, as described here.

==Slab ocean==
This routine solves for big fish eating small fish, as described [[Slab_ocean_model|here]].

==Surface==
The surface part of the water cycle is handled here, as the hydrology page describes.

=Heat Conduction in the Subsurface=
The conduction of heat in the subsurface is solved as described [[Soil_Thermal_Conduction_in_the_Generic_PCM|here]].

=Diagnostics/write outputs=
Nothing very physical here, just writting the outputs! By the way, if you want to know how to output new variables in the [[diagfi.nc]] or [[XIOS]] file, check out [[Outputs|this page]].

Physics of the Generic PCM

2025-04-30T16:29:47Z

Maxime Maurice: /* CO2 condensation */

This page describes the various physical parametrizations of the Generic PCM and the chronology of their call through the physical iteration. This chronology is important because some variables need to be updated by certain processes before others (examples).
During one physical iteration, the code passes through multiple sub-routines each encapsulating a parametrization. The sub-routines usually take as arguments:
*the dynamical values of the state variables
*the dynamical tendencies of the state variables
*any additional relevant variable
*any additional relevant tendency
and it returns in general tendencies (of the state variables as well as of any other relevant variable).

Work in progress. Need to add links.

=Initialization=
==First call==
Some initializations only need to be done at the very first iteration (e.g. examples).
==Each call==
Some other initializations need to be done at each iteration (e.g. examples).

=Radiative transfer=
==Correlated-k==
The main radiative transfer solver of the Generic PCM implements the correlated-k method, which provides a flexible and quick way to solve radiative transfer equations, particularly suited for GCMs. More informations here.
==Newtonian relaxation==
Newton was a very relaxed physicist, still inspiring us today.
==No atmosphere==
If you have no atmosphere, why do you need a GCM?

=Vertical diffusion=
Compute the vertical diffusion due to turbulence in the planetary boundary layer
==vdifc==
The "old" vertical diffusion routine.
==turbdiff==
The new (and improved!) vertical diffusion routine

=Convection=

Convective mixing in an atmosphere column involves non-resolved, sub-grid processes. To treat convectively unstable regions, there are two mutually exclusive options (convadj.F90 and thermcell_mod.F90). These processes are parameterized using the following routines:

==Dry convection (convadj.F90)==

This is the simplest and most robust parametrization for dry convective adjustment without free parameters. More info [[Convective_adjustment_scheme_in_the_generic_PCM|here]].

==Thermal plume (thermcell_mod.F90)==
This module implements a more accurate and sophisticated parametrization of convection, although it involves several free parameters that need to be tuned for each planet. More info [[Thermal_plume_model_Generic_PCM|here]].

==Non-orographic gravity waves: (''nonoro_gwd_ran_mod.F90'') ==

Parametrization of the momentum flux deposition due to a discrete number of gravity waves randomly generated by setting their waves characteristics (set as Gaussian distribution).

More info [[Non orographic gravity waves drag|here]].

=CO2 condensation=
Inheriting from the Mars PCM where it is the background species, CO2 condensation is treated as a dedicated step in the Generic PCM's physics. Notice that it only concerns CO2 as a background gas. More info [[CO2_Condensation_(Generic_PCM)|here]].

=Tracers=
Many things can be advected by tracers in the Generic PCM, like chemical species or aerosols. Physical processes involving tracers are parameterized using the following routines:

==Volcano==
This routine parameterizes a source of tracers corresponding to volcanic eruption. More information here.

==Water/ice==
Water aerosols (liquid or solid) are created (resp. consumed) by condensation (resp. vaporization or sublimation), consuming (resp. releasing) latent heat in the atmosphere. In the Generic PCM, the (atmospheric part of the) water cycle is handled by various routines, as explained here.

==Photochemistry==
Chemistry can turn molecules into other molecules, by the action of temperature (thermochemistry) or UV light (photochemistry). This is handled by the photochemistry routine, described [[Photochemistry_of_the_Generic_PCM|here]].

==Generic condensation==
On Earth, only water condenses in the atmosphere, but on other planets (which the Generic PCM aims at simulating), many other chemicals can undergo state change. To take that into account, the Generic PCM has a flexible scheme to deal with any arbitrary species, as desbribed [[Radiative_Generic_Condensable_Specie|here]].

==Sedimentation==
What goes up must come down, as explained [[Sedimentation_of_tracers_in_the_generic_PCM|here]].

==Updates==
This section essentially takes care that the condensation of a major species (e.g. water vapor in steam-rich atmospheres) affects other species, as described here.

==Slab ocean==
This routine solves for big fish eating small fish, as described [[Slab_ocean_model|here]].

==Surface==
The surface part of the water cycle is handled here, as the hydrology page describes.

=Heat Conduction in the Subsurface=
The conduction of heat in the subsurface is solved as described [[Soil_Thermal_Conduction_in_the_Generic_PCM|here]].

=Diagnostics/write outputs=
Nothing very physical here, just writting the outputs! By the way, if you want to know how to output new variables in the [[diagfi.nc]] or [[XIOS]] file, check out [[Outputs|this page]].

CO2 Condensation (Generic PCM)

2025-04-30T16:28:09Z

Maxime Maurice: Created page with "This page describes the condense_co2 routine of the Generic PCM. This routine, inherited from the Mars PCM, only works for atmosphere where CO2 is the background, dominant gas..."

This page describes the condense_co2 routine of the Generic PCM. This routine, inherited from the Mars PCM, only works for atmosphere where CO2 is the background, dominant gas. If CO2 is a trace, variable gas, you should use the [[Radiative_Generic_Condensable_Specie|generic condensation scheme]].

= Nucleation and Condensation of CO2 =
The condensation and nucleation temperature are calculated using Fanale's formula (subroutines '''get_tcond_co2''' and '''get_tnuc_co2'''):
\begin{equation}
T_{\rm cond}=
\begin{cases}
\frac{-3167.8}{\log(0.01\times P)-23.23} & {\rm if }P<P_{\rm triple}=518000~{\rm Pa}\\
684.2-92.3\times\log(P)+4.32\times\log(P)^2 & {\rm otherwise}
\end{cases}
\end{equation}
At the moment, we consider $$T_{\rm nuc}=T_{\rm cond}$$.

= In the atmosphere =

The routine iterates condensation and sedimentation in the atmosphere column over 20 subtimesteps. It computes:

== Sedimentation of CO2 aerosols ==

Using the subroutines '''co2_reffrad''' for the aerosols particles radius, the Stokes velocity is calculated with subroutine '''stokes''' and the tracers are updated using subroutine '''vlz_fi'''.

== Condensation and sublimation of CO2 in the atmosphere ==
If the local temperature is below the nucleation temperature or CO2 ice is present, condensation / sublimation tendencies for CO2 tracers (ice and gas) as well as temperature (via latent heat effect) are calculated.

= On the ground =

== Condensation and sublimation on the ground ==
Surface tracer and temperature tendencies due to condensation or sublimation at the surface as well as CO2 ice accumulation on the ground due to icefall are then calculated. Importantly, surface pressure is adjusted to account for variations in CO2 ice cover.

== Albedo and emissivity ==
Finally, albedo and emissivity are re-calculated as a function of the amount of CO2 ice deposited.

Physics of the Generic PCM

2025-04-30T15:00:27Z

Maxime Maurice: /* Photochemistry */

This page describes the various physical parametrizations of the Generic PCM and the chronology of their call through the physical iteration. This chronology is important because some variables need to be updated by certain processes before others (examples).
During one physical iteration, the code passes through multiple sub-routines each encapsulating a parametrization. The sub-routines usually take as arguments:
*the dynamical values of the state variables
*the dynamical tendencies of the state variables
*any additional relevant variable
*any additional relevant tendency
and it returns in general tendencies (of the state variables as well as of any other relevant variable).

Work in progress. Need to add links.

=Initialization=
==First call==
Some initializations only need to be done at the very first iteration (e.g. examples).
==Each call==
Some other initializations need to be done at each iteration (e.g. examples).

=Radiative transfer=
==Correlated-k==
The main radiative transfer solver of the Generic PCM implements the correlated-k method, which provides a flexible and quick way to solve radiative transfer equations, particularly suited for GCMs. More informations here.
==Newtonian relaxation==
Newton was a very relaxed physicist, still inspiring us today.
==No atmosphere==
If you have no atmosphere, why do you need a GCM?

=Vertical diffusion=
Compute the vertical diffusion due to turbulence in the planetary boundary layer
==vdifc==
The "old" vertical diffusion routine.
==turbdiff==
The new (and improved!) vertical diffusion routine

=Convection=

Convective mixing in an atmosphere column involves non-resolved, sub-grid processes. To treat convectively unstable regions, there are two mutually exclusive options (convadj.F90 and thermcell_mod.F90). These processes are parameterized using the following routines:

==Dry convection (convadj.F90)==

This is the simplest and most robust parametrization for dry convective adjustment without free parameters. More info [[Convective_adjustment_scheme_in_the_generic_PCM|here]].

==Thermal plume (thermcell_mod.F90)==
This module implements a more accurate and sophisticated parametrization of convection, although it involves several free parameters that need to be tuned for each planet. More info [[Thermal_plume_model_Generic_PCM|here]].

==Non-orographic gravity waves: (''nonoro_gwd_ran_mod.F90'') ==

Parametrization of the momentum flux deposition due to a discrete number of gravity waves randomly generated by setting their waves characteristics (set as Gaussian distribution).

More info [[Non orographic gravity waves drag|here]].

=CO2 condensation=
Inheriting from the Mars PCM where it is the background species, CO2 condensation is treated as a dedicated step in the Generic PCM's physics. Does that only concern CO2 as a background gas? Or does it work also if CO2 is a non-background variable gas? In any case more info here.

=Tracers=
Many things can be advected by tracers in the Generic PCM, like chemical species or aerosols. Physical processes involving tracers are parameterized using the following routines:

==Volcano==
This routine parameterizes a source of tracers corresponding to volcanic eruption. More information here.

==Water/ice==
Water aerosols (liquid or solid) are created (resp. consumed) by condensation (resp. vaporization or sublimation), consuming (resp. releasing) latent heat in the atmosphere. In the Generic PCM, the (atmospheric part of the) water cycle is handled by various routines, as explained here.

==Photochemistry==
Chemistry can turn molecules into other molecules, by the action of temperature (thermochemistry) or UV light (photochemistry). This is handled by the photochemistry routine, described [[Photochemistry_of_the_Generic_PCM|here]].

==Generic condensation==
On Earth, only water condenses in the atmosphere, but on other planets (which the Generic PCM aims at simulating), many other chemicals can undergo state change. To take that into account, the Generic PCM has a flexible scheme to deal with any arbitrary species, as desbribed [[Radiative_Generic_Condensable_Specie|here]].

==Sedimentation==
What goes up must come down, as explained [[Sedimentation_of_tracers_in_the_generic_PCM|here]].

==Updates==
This section essentially takes care that the condensation of a major species (e.g. water vapor in steam-rich atmospheres) affects other species, as described here.

==Slab ocean==
This routine solves for big fish eating small fish, as described [[Slab_ocean_model|here]].

==Surface==
The surface part of the water cycle is handled here, as the hydrology page describes.

=Heat Conduction in the Subsurface=
The conduction of heat in the subsurface is solved as described [[Soil_Thermal_Conduction_in_the_Generic_PCM|here]].

=Diagnostics/write outputs=
Nothing very physical here, just writting the outputs! By the way, if you want to know how to output new variables in the [[diagfi.nc]] or [[XIOS]] file, check out [[Outputs|this page]].

Radioactive tracers

2025-04-15T09:12:08Z

Maxime Maurice:

Radioactive tracers

2025-04-15T09:08:45Z

Maxime Maurice:

= Motivation =
The Generic PCM has both a 3D and a 1D version. While the 3D self-consistently solves for dynamical mixing of advected quantities (like temperature or tracers), this process can only be parametrized in 1D. This is done by approximating dynamical mixing by a diffusive process:

<math>\frac{\partial q}{\partial t}=-K_{zz}\frac{\partial^2 q}{\partial z^2}</math>

with <math>q</math> the tracer's mass mixing ratio, <math>t</math> time, <math>z</math> altitude, and <math>K_{zz}</math> <math<K_{zz}</math> the vertical diffusion coefficient (in m/s²), also called "eddy mixing coefficient". Notice that <math<K_{zz}</math> is often given in CGS units (cm/s²) in the astrophysical community. This coefficient's value (or vertical profile) is tuned so that 1D abundance profiles match 3D averaged ones.

Depending on the planetary setup, the value (or vertical profile) of <math>K_{zz}</math> that can best reproduce 3D mixing varies. If you want to tune the vertical eddy mixing coefficient to one of your 3D cases, you can run a simulation with radioactively decreasing abstract tracers in both 1D and 3D and compare the vertical distribution of these tracers once a steady-state is reached. In 3D, this distribution is the result of a competition between dynamical mixing which tends to homogenize the atmosphere, and radioactive decay which destroys the tracers with increasing probability with time after their injection. Injection is done from the surface or the top of the atmosphere. Depending on the location of injection, half-life of the tracers, and atmosphere dynamics, the steady-state profile vary.

= Use =
In order to use radioactive tracers, you simply need to add them to the traceur.def file, and define their half-life as well as injection flux at each location. This is done by setting the flags corresponding to these values in the modern version of the traceur.def. In the Generic PCM deftank, the file '''traceur.def.radioactive''' gives an illustration of it, which 6 different tracers, each having half life of 1 day, 1 week or 1 month (normalized by the time of a Martian sol), injected by the surface or the top of the atmosphere:

r1 half_life=8.64e4 bot_prod=8e-6
r2 half_life=6.048e5 bot_prod=1.15e-6
r3 half_life=2.592e6 bot_prod=2.7e-7
r4 half_life=8.64e4 top_prod=8e-6
r5 half_life=6.048e5 top_prod=1.15e-6
r6 half_life=2.592e6 top_prod=2.7e-7

The tracers '''r1''' to '''r3''' are injected from the surface and tracers '''r4''' to '''r6''' are injected from the top of the atmosphere. The flux multiplied by the half-life is kept constant across tracers to keep the profiles comparable. Notice that if no other process affect these tracers (as it should be since these tracers are merely numerical tools and their decay does not aim at modelling any real physical process), the value of their abundance is arbitrary and only the shape of the profile matters.

Below is an illustration of the steady-state distribution of these tracers in the early Mars atmosphere of the benchmark in 3D, and in 1D for three different values of <math>K_{zz}</math>. One sees that large <math>K_{zz}</math> overestimate vertical mixing and thus atmosphere homogenization, while low values underestimate it.

[[File:Radioactive tracers.png|center|frame|Comparison of the vertical mixing between a 3D case and 3 1D simulations of early Mars atmosphere using different values of the eddy mixing coefficient.]]

Radioactive tracers

2025-04-14T15:35:34Z

Maxime Maurice:

Radioactive tracers

2025-04-14T15:33:48Z

Maxime Maurice:

Radioactive tracers

2025-04-14T15:33:26Z

Maxime Maurice:

= Radioactive tracer =

== Motivation ==
The Generic PCM has both a 3D and a 1D version. While the 3D self-consistently solves for dynamical mixing of advected quantities (like temperature or tracers), this process can only be parametrized in 1D. This is done by approximating dynamical mixing by a diffusive process, and tuning a value for the effective vertical diffusion, often referred to as the eddy mixing coefficient, K_zz.

Depending on the planetary setup, the value (or vertical profile) of K_zz that can best reproduce 3D mixing varies. If you want to tune the vertical eddy mixing coefficient to one of your 3D cases, you can run a simulation with radioactively decreasing abstract tracers in both 1D and 3D and compare the vertical distribution of these tracers once a steady-state is reached. In 3D, this distribution is the result of a competition between dynamical mixing which tends to homogenize the atmosphere, and radioactive decay which destroys the tracers with increasing probability with time after their injection. Injection is done by the surface or the top of the atmosphere. Depending on the location of injection, half-life of the tracers, and atmosphere dynamics, the steady-state profile vary.

== Use ==
In order to use radioactive tracers, you simply need to add them to the traceur.def file, and define their half-life as well as injection flux at each location. This is done by setting the flags corresponding to these values in the modern version of the traceur.def. In the Generic PCM deftank, the file traceur.def.radioactive gives an illustration of it, which 6 different tracers, each having half life of 1 second, 1 minutes or 1 hour (normalized by the time of a Martian sol), injected by the surface or the top of the atmosphere.

Below is an illustration of the steady-state distribution of these tracers in the early Mars atmosphere of the benchmark in 3D, and in 1D for three differrent values of K_zz. One sees that large K_zz overestimate vertical mixing and thus atmosphere homogenization, while low values underestimate it.

[[File:Radioactive tracers.png|center|frame|Comparison of the vertical mixing between a 3D case and 3 1D simulations of early Mars atmosphere using different values of the eddy mixing coefficient.]]

File:Radioactive tracers.png

2025-04-14T15:28:57Z

Maxime Maurice: Comparison of vertical mixing between a 3D case and 3 1D simulations of early Mars using different eddy mixing coefficients.

Comparison of vertical mixing between a 3D case and 3 1D simulations of early Mars using different eddy mixing coefficients.

Radioactive tracers

2025-04-14T15:03:06Z

Maxime Maurice: Created page with "= Radioactive tracer = == Motivation == The Generic PCM has both a 3D and a 1D version. While the 3D self-consistently solves for dynamical mixing of advected quantities (lik..."

Photochemistry of the Generic PCM

2025-03-05T09:57:08Z

Maxime Maurice: /* Boundary conditions */

= General Use =

== Compilation ==
Photochemistry in the generic model is largely independent of the and does not require to recompile it (just make sure that you have linked the ''LAPACK'' and ''BLAS'' libraries).

== callphys.def ==
In order to use photochemistry, you simply need to have the following line in '''callphys.def''':
photochem = .true.
Other flags related to photochemistry are:
* '''photoheat''': turn on or off heating by UV absorption.
* '''jonline''': turn on or off online photolysis.
* '''stellarflux''': name of the stellar flux file.
* '''depos''': turn on or off deposition.

== traceur.def ==
All chemical species must be listed in [[The_traceur.def_Input_File|'''traceurs.def''']] ('''which needs to follow the modern layout''').

== Reaction network ==
Besides the species- and reaction-specific data files ([[#Photolysis reaction|see below]]), you need one file: '''reactfile''' (located in the '''chemnetwork''' folder) for the reaction network. The first line of the file is ignored, then for each line, the syntax of the '''reactfile''' is as follows:
* Columns 1-50 are reserved for reactants. Their names must match those given [[The_traceur.def_Input_File|'''traceurs.def''']], in particular, if you have both water vapour and water ice as tracers, named h2o_vap and h2o_ice respectively, the name to use for water vapour in chemical reaction is h2o_vap. Reactant species must be separated by any number of blank spaces.
* Columns 51-100 are reserved for products, with the same rules applying. Notice that in the case of a third body reaction, the third body appears only with the reactants and is omitted on the products side.
* Column 101 is an integer designating the type of reaction: 0 for photolysis, 1, 2 or 3 for other reactions, depending on their reaction rate formula. The four next spaces are blank.
* Column 106 and after are dedicated to parameters specific to each reaction type.
Note that lines can be commented out by starting them with the character "!".

== Photolysis ==
=== Online photolysis ===
In the baseline use of the photochemistry model, photolysis are computed at the runtime (online), by solving the UV radiative transfer using the TUV solver, considering species-specific UV cross section. o do so, first make sure that the apropriate flag is set to true in the '''callphys.def''':
jonline = .true.
Photolysis reactions are identified by a 0 at column 101 of the '''reactfile'''. They need two types of files (which need to be placed in '''datadir/cross_sections/'''):
# cross sections (syntax: first line: wavelength in nm, second line cross section in cm2, first line is ignored)
# yield rates (syntax: first line: wavelength in nm, second line: photodissociation yield, first line is ignored)
These data can be found in benchmark cases for common species (e.g. water), or on the following pages for more exotic ones: [https://www.uv-vis-spectral-atlas-mainz.org/uvvis/ Mainz spectral atlas], [https://phidrates.space.swri.edu/ phidrates], [https://home.strw.leidenuniv.nl/~moldata/ Leiden University].
The parameters for photolysis reaction in the '''reactfile''' are given as follows, from column 106: an identifier character string starting with "j", an integer corresponding to the number of cross section files (one for each temperature range), the lower bound of each temperature range, the name of each cross section file, the name of the yield rate file. For example, the following line describes the photolysis of O2 into two O atoms in the ground state:
o2 hv o o 0 jo2_o 4 150 200 250 300 O2_150.abs O2_200.abs O2_250.abs O2_300.abs o2_o.yld
In this case, 4 different cross section files exist, corresponding to the temperature range 150 K-200 K, 200 K-250 K, 250 K-300 K, >300 K.
=== Offline photolysis ===
=== Stellar flux ===
In order to compute photolysis (is it also the case for offline photolysis?), you need to provide a UV stellar spectrum. This file must be located in datadir/stellar_spectra/photochem_stellar_spectra, an is composed of a 2-lines header and 2 columns, the left one indicating wavelength (in nm) and the right one indicating the flux (in photons/cm²/s/nm).
=== Constant photodissociation rates ===
Sometimes photodissociation rates are simply given as a constant throughout the atmosphere. One way to reproduce that is to treat these reactions as type 1 reaction (see below).

== Reaction rate formulae ==
Many reaction rate parametrizations can be found in [https://jpldataeval.jpl.nasa.gov/pdf/NASA-JPL%20Evaluation%2019-5.pdf here]. The model currently accounts for three different formula for the reaction rate (more exotic ones can be hard-coded in the '''chimiedata_h.F90''' file, as indicated in [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Other_GCM_Configurations_worth_knowing_about#Compiling_a_test_case_.28TRAPPIST-1e.29 the TRAPPIST-1e example]). The chosen formula is by 1, 2, or 3 at column 51 or the '''reactfile'''.They read respectively:
# The simple form of the reaction rate is :<math>k=a\left(\frac{T}{T_0}\right)^ce^{\frac{-b}{T} }[M]^d</math>Its parameters (to give in the '''reactfile''' in the same order, starting from column 106) are <math>a, b, c, T_0, d</math>.
# Termolecular reactions have low- and high-pressure-limiting rate constant (<math>k_0</math> and <math>k_\infty</math>, respectively). Their effective rate constant is then given by :<math>k=ge^{-\frac{h}{T} }+\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} }[M]^{d_{\text up} } }{1+\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} } }{k_\infty\left(\frac{T}{T_0}\right)^me^{\frac{-b_0}{T} } }[M]^{d_{\text down} } }fc^{\frac{1}{1+\left[\log_{10}\left(\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} } }{k_\infty\left(\frac{T}{T_0}\right)^me^{\frac{-b_0}{T} } }[M] \right) \right]^2 } }</math>Its parameters (to give in the '''reactfile''' in the same order, starting from column 106) are <math>k_0, n, a_0, k_\infty, m, b_0, T_0, f_c, g, h, d_{\text up}, d_{\text down}</math>.
# Finally, a last form of the reaction rate is :<math>\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} }[M]^{d_{\text up} } }{1+\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} } }{k_\infty\left(\frac{T}{T_0}\right)^me^{\frac{-b_0}{T} } }[M]^{d_{\text down} } }[F_{\text cent}]^X,</math>with <math>F_{\text cent}=1-ae^{-\frac{T}{T^{***} } }+ae^{-\frac{T}{T^* } }+ae^{-\frac{T^{**}}{T } }</math>, and :<math>X=\left[1+\left[\frac{\log_{10}\left(\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} } }{k_\infty\left(\frac{T}{T_0}\right)^me^{\frac{-b_0}{T} } }[M] \right)+c }{N-d\left(\log_{10}\left(\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} } }{k_\infty\left(\frac{T}{T_0}\right)^me^{\frac{-b_0}{T} } }[M] \right) \right)+c } \right]^2 \right]^{-1},</math>with <math>c=-0.4-0.67\log_{10}(F_{\text cent})</math>, <math>N=0.75-1.27\log_{10}(F_{\text cent})</math>, and <math>d=0.14</math>.
::Its parameters (to give in the '''reactfile''' in the same order, starting from column 106) are <math>k_0, n, a_0, k_\infty, m, b_0, T_0, a, T^{***}, T^*, T^{**}, d_{\text up}, d_{\text down}</math>.
For example, the following line describes the 3-body reaction CO + O + M = CO2 + M, whose reaction rate is <math>k=2.2\times10^{-33}e^{-\frac{1780}{T} }[M]</math> (be careful, here <math>[M]</math> corresponds to the molecular density of the atmosphere, not that of the third body):
co o M co2 1 2.2e-33 -1780.0 0.0 1 1.0

= Boundary conditions =
All processes described in this section are implemented in the '''deposition_source.F90''' file in LMDZ.GENERIC/libf/aeronostd.
For each chemical species, two types of surface boundary conditions can be enforced in the chemistry, specified by the '''SF_mode''' in the [[The_traceur.def_Input_File|traceur.def]] file. If none of the flags mentioned below is given, the default boundary conditions are no flux.

== Fixed mixing ratio ==

This boundary condition is enforced by setting SF_mode=1. The value of the surface VMR is then passed to the flag SF_value.

== Deposition velocity and surface production ==

This boundary condition is enforced by setting SF_mode=2. It enforces a surface deposition $$v_{\rm dep}$$ inducing an outflux $$F=-v_{\rm dep}\times[X]$$ with v_dep the surface deposition velocity and [X] the VMR of the tracer in the first atmosphere layer, as well as a fixed production rate (added to each cell of the first atmosphere layer). The value of the deposition velocity (in cm/s) is passed to the flag '''SF_value''' and the production rate (in molecules/m$$^2$$/s) is passed to the flag '''prod_rate'''

In case of surface deposition/production, a production rate can also be specified for each tracer using the flag '''prod_rate''' (value in molecules/m$$^2$$/s). Below is an example of a chunk of a traceur.def file specifying a fixed CO$$_2$$ volume mixing ratio and a surface deposition of CO of 10$$^{-8}$$ cm/s along with a production rate of 10$$^5$$ molecules/m$$^2$$/s:

co2 mmol=44 is_chim=1 SF_mode=1
co mmol=28 is_chim=1 SF_mode=1 SF_value=1e-8 prod_rate=1e5

== Escape ==
Whatever the prescribed boundary condition, an escape rate can also be given at the top of the atmosphere. A parametrization of H escape from H$$_2$$, CH$$_4$$ and H$$_2$$O is currently implemented and commented out.

= Using hard-coded rate constants =

You might sometimes want to track a reaction whose rate constant is not capture by either of the three above parametrizations. In this case you'll need to get your hands dirty and hard-code the rate constant parametrization in the code. Notice that the reaction should not be included in the reactfile in this case (it is however a good practice to indicate it as a commented line and write "hard-coded', both to keep track of your network and because the post-processing tools will notify it by reading the reactfile). Here is how to proceed:

First, identify the type of your reaction: currently, the model distinguishes between 1) bimolecular reactions (A + B -> C (+ D)), 2) quadratic reactions (A + A -> B (+C)), 3) quenching reactions (A + C -> B + C), and 4) heterogeneous reactions (e.g. A + ice -> B + C). Bimolecular reactions are given type '''v4''', quadratic reactions are given type '''v3''', and both quenching an heterogeneous reactions are given type '''vphot''' (the same as photodissociation reactions).

Then, open the file '''LMDZ.GENERIC/libf/aeronostd/chimiedata_h.F90'''. This file has a dedicated section for hard-coded reactions. Some of them are already there, commented out. We'll use one of them (the reaction CO + OH -> CO2 + H) as a example on how to proceed. This is a bimolecular reaction, so we first need to increment the counter of hard-coded reactions of type '''v_4''':
integer, parameter :: n4_hard_coding = 1
In the master branch version of the code, the variable ''n4_hard_coding'' is set to 0. If you're version of the code already has hard-coded reactions, then simply add one to the current value of ''n4_hard_coding''.

In the same file, you will find a subroutine called ''indice_HC'' for registering hard-coded reactions. You can create a space for your reaction, taking example of what's already there. For instance our example reaction is already there:
!===========================================================
! e001 : CO + OH -> CO2 + H
!===========================================================
! nb_reaction_4 = nb_reaction_4 + 1
! indice_4(nb_reaction_4) = z4spec(1.0, indexchim('co'), 1.0, indexchim('oh'), 1.0, indexchim('co2'), 1.0, indexchim('h'))
To use it, you must uncomment the two last lines. The top one increments the number of reactions of type ''v4'', and the second one registers the reacting species for your new reaction.

Then go to the subroutine ''reactionrates_HC''. This is where you will write down the parametrization formula into the reaction rates table (the variable '''v_4''' for bimolecular reactions, '''v_3''' for quadratic reactions, or '''v_phot''' for all others). Again, you can take example of what's already there. If you want to use our example reaction, find the dedicated space, opening with the line:
!--- e001: oh + co -> co2 + h
and simply uncomment the following lines:
!nb_reaction_4 = nb_reaction_4 + 1
to update the index at which the rate is written in table '''v_4''', and then (for instance):
! jpl 2015

!do ilev = 1,nlayer
!!oh + co -> h + co2
! rate1 = 1.5e-13*(t(ilev)/300.)**(0.0)
!!oh + co + m -> hoco
! ak0 = 5.9e-33*(t(ilev)/300.)**(-1.0)
! ak1 = 1.1e-12*(t(ilev)/300.)**(1.3)
! rate2 = (ak0*dens(ilev))/(1. + ak0*dens(ilev)/ak1)
! xpo2 = 1./(1. + alog10((ak0*dens(ilev))/ak1)**2)
!
! v_4(ilev,nb_reaction_4) = rate1 + rate2*0.6**xpo2
!end do
(except the first one) to use the parametrization from the JPL 2015 collection (linked above). Notice that several parametrizations are implemented; to use another one simply uncomment another block, or write your own.

== Hard-coding reactions with 3 products ==
The model does not natively handle reactions with 3 products. The trick is to instead split it into 2 "semi-reactions", for instance instead of HNO3 + OH -> H2O + O + NO2, add 0.5 HNO3 + 0.5 OH -> H2O + 0.5 NO2 and 0.5 HNO3 + 0.5 OH -> O + 0.5 NO2 (or any stoichiometrically-equivalent couple). Each semi-reaction then has the same constant rate as the total reaction. Don't forget to count them as two distinct reactions.

= Python post-processing tools for photochemistry =
A mini python library is available in the '''util''' directory of the Generic model (LMDZ.GENERIC/utils), along with a demonstration jupyter notebook.

Photochemistry of the Generic PCM

2025-03-05T08:55:30Z

Maxime Maurice: Created page with "= General Use = == Compilation == Photochemistry in the generic model is largely independent of the and does not require to recompile it (just make sure that you have linked..."

= General Use =

== Compilation ==
Photochemistry in the generic model is largely independent of the and does not require to recompile it (just make sure that you have linked the ''LAPACK'' and ''BLAS'' libraries).

== callphys.def ==
In order to use photochemistry, you simply need to have the following line in '''callphys.def''':
photochem = .true.
Other flags related to photochemistry are:
* '''photoheat''': turn on or off heating by UV absorption.
* '''jonline''': turn on or off online photolysis.
* '''stellarflux''': name of the stellar flux file.
* '''depos''': turn on or off deposition.

== traceur.def ==
All chemical species must be listed in [[The_traceur.def_Input_File|'''traceurs.def''']] ('''which needs to follow the modern layout''').

== Reaction network ==
Besides the species- and reaction-specific data files ([[#Photolysis reaction|see below]]), you need one file: '''reactfile''' (located in the '''chemnetwork''' folder) for the reaction network. The first line of the file is ignored, then for each line, the syntax of the '''reactfile''' is as follows:
* Columns 1-50 are reserved for reactants. Their names must match those given [[The_traceur.def_Input_File|'''traceurs.def''']], in particular, if you have both water vapour and water ice as tracers, named h2o_vap and h2o_ice respectively, the name to use for water vapour in chemical reaction is h2o_vap. Reactant species must be separated by any number of blank spaces.
* Columns 51-100 are reserved for products, with the same rules applying. Notice that in the case of a third body reaction, the third body appears only with the reactants and is omitted on the products side.
* Column 101 is an integer designating the type of reaction: 0 for photolysis, 1, 2 or 3 for other reactions, depending on their reaction rate formula. The four next spaces are blank.
* Column 106 and after are dedicated to parameters specific to each reaction type.
Note that lines can be commented out by starting them with the character "!".

== Photolysis ==
=== Online photolysis ===
In the baseline use of the photochemistry model, photolysis are computed at the runtime (online), by solving the UV radiative transfer using the TUV solver, considering species-specific UV cross section. o do so, first make sure that the apropriate flag is set to true in the '''callphys.def''':
jonline = .true.
Photolysis reactions are identified by a 0 at column 101 of the '''reactfile'''. They need two types of files (which need to be placed in '''datadir/cross_sections/'''):
# cross sections (syntax: first line: wavelength in nm, second line cross section in cm2, first line is ignored)
# yield rates (syntax: first line: wavelength in nm, second line: photodissociation yield, first line is ignored)
These data can be found in benchmark cases for common species (e.g. water), or on the following pages for more exotic ones: [https://www.uv-vis-spectral-atlas-mainz.org/uvvis/ Mainz spectral atlas], [https://phidrates.space.swri.edu/ phidrates], [https://home.strw.leidenuniv.nl/~moldata/ Leiden University].
The parameters for photolysis reaction in the '''reactfile''' are given as follows, from column 106: an identifier character string starting with "j", an integer corresponding to the number of cross section files (one for each temperature range), the lower bound of each temperature range, the name of each cross section file, the name of the yield rate file. For example, the following line describes the photolysis of O2 into two O atoms in the ground state:
o2 hv o o 0 jo2_o 4 150 200 250 300 O2_150.abs O2_200.abs O2_250.abs O2_300.abs o2_o.yld
In this case, 4 different cross section files exist, corresponding to the temperature range 150 K-200 K, 200 K-250 K, 250 K-300 K, >300 K.
=== Offline photolysis ===
=== Stellar flux ===
In order to compute photolysis (is it also the case for offline photolysis?), you need to provide a UV stellar spectrum. This file must be located in datadir/stellar_spectra/photochem_stellar_spectra, an is composed of a 2-lines header and 2 columns, the left one indicating wavelength (in nm) and the right one indicating the flux (in photons/cm²/s/nm).
=== Constant photodissociation rates ===
Sometimes photodissociation rates are simply given as a constant throughout the atmosphere. One way to reproduce that is to treat these reactions as type 1 reaction (see below).

== Reaction rate formulae ==
Many reaction rate parametrizations can be found in [https://jpldataeval.jpl.nasa.gov/pdf/NASA-JPL%20Evaluation%2019-5.pdf here]. The model currently accounts for three different formula for the reaction rate (more exotic ones can be hard-coded in the '''chimiedata_h.F90''' file, as indicated in [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/Other_GCM_Configurations_worth_knowing_about#Compiling_a_test_case_.28TRAPPIST-1e.29 the TRAPPIST-1e example]). The chosen formula is by 1, 2, or 3 at column 51 or the '''reactfile'''.They read respectively:
# The simple form of the reaction rate is :<math>k=a\left(\frac{T}{T_0}\right)^ce^{\frac{-b}{T} }[M]^d</math>Its parameters (to give in the '''reactfile''' in the same order, starting from column 106) are <math>a, b, c, T_0, d</math>.
# Termolecular reactions have low- and high-pressure-limiting rate constant (<math>k_0</math> and <math>k_\infty</math>, respectively). Their effective rate constant is then given by :<math>k=ge^{-\frac{h}{T} }+\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} }[M]^{d_{\text up} } }{1+\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} } }{k_\infty\left(\frac{T}{T_0}\right)^me^{\frac{-b_0}{T} } }[M]^{d_{\text down} } }fc^{\frac{1}{1+\left[\log_{10}\left(\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} } }{k_\infty\left(\frac{T}{T_0}\right)^me^{\frac{-b_0}{T} } }[M] \right) \right]^2 } }</math>Its parameters (to give in the '''reactfile''' in the same order, starting from column 106) are <math>k_0, n, a_0, k_\infty, m, b_0, T_0, f_c, g, h, d_{\text up}, d_{\text down}</math>.
# Finally, a last form of the reaction rate is :<math>\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} }[M]^{d_{\text up} } }{1+\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} } }{k_\infty\left(\frac{T}{T_0}\right)^me^{\frac{-b_0}{T} } }[M]^{d_{\text down} } }[F_{\text cent}]^X,</math>with <math>F_{\text cent}=1-ae^{-\frac{T}{T^{***} } }+ae^{-\frac{T}{T^* } }+ae^{-\frac{T^{**}}{T } }</math>, and :<math>X=\left[1+\left[\frac{\log_{10}\left(\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} } }{k_\infty\left(\frac{T}{T_0}\right)^me^{\frac{-b_0}{T} } }[M] \right)+c }{N-d\left(\log_{10}\left(\frac{k_0\left(\frac{T}{T_0}\right)^ne^{\frac{-a_0}{T} } }{k_\infty\left(\frac{T}{T_0}\right)^me^{\frac{-b_0}{T} } }[M] \right) \right)+c } \right]^2 \right]^{-1},</math>with <math>c=-0.4-0.67\log_{10}(F_{\text cent})</math>, <math>N=0.75-1.27\log_{10}(F_{\text cent})</math>, and <math>d=0.14</math>.
::Its parameters (to give in the '''reactfile''' in the same order, starting from column 106) are <math>k_0, n, a_0, k_\infty, m, b_0, T_0, a, T^{***}, T^*, T^{**}, d_{\text up}, d_{\text down}</math>.
For example, the following line describes the 3-body reaction CO + O + M = CO2 + M, whose reaction rate is <math>k=2.2\times10^{-33}e^{-\frac{1780}{T} }[M]</math> (be careful, here <math>[M]</math> corresponds to the molecular density of the atmosphere, not that of the third body):
co o M co2 1 2.2e-33 -1780.0 0.0 1 1.0

= Boundary conditions =
== Deposition velocity ==
== Production rate ==
== Escape ==

= Using hard-coded rate constants =

You might sometimes want to track a reaction whose rate constant is not capture by either of the three above parametrizations. In this case you'll need to get your hands dirty and hard-code the rate constant parametrization in the code. Notice that the reaction should not be included in the reactfile in this case (it is however a good practice to indicate it as a commented line and write "hard-coded', both to keep track of your network and because the post-processing tools will notify it by reading the reactfile). Here is how to proceed:

First, identify the type of your reaction: currently, the model distinguishes between 1) bimolecular reactions (A + B -> C (+ D)), 2) quadratic reactions (A + A -> B (+C)), 3) quenching reactions (A + C -> B + C), and 4) heterogeneous reactions (e.g. A + ice -> B + C). Bimolecular reactions are given type '''v4''', quadratic reactions are given type '''v3''', and both quenching an heterogeneous reactions are given type '''vphot''' (the same as photodissociation reactions).

Then, open the file '''LMDZ.GENERIC/libf/aeronostd/chimiedata_h.F90'''. This file has a dedicated section for hard-coded reactions. Some of them are already there, commented out. We'll use one of them (the reaction CO + OH -> CO2 + H) as a example on how to proceed. This is a bimolecular reaction, so we first need to increment the counter of hard-coded reactions of type '''v_4''':
integer, parameter :: n4_hard_coding = 1
In the master branch version of the code, the variable ''n4_hard_coding'' is set to 0. If you're version of the code already has hard-coded reactions, then simply add one to the current value of ''n4_hard_coding''.

In the same file, you will find a subroutine called ''indice_HC'' for registering hard-coded reactions. You can create a space for your reaction, taking example of what's already there. For instance our example reaction is already there:
!===========================================================
! e001 : CO + OH -> CO2 + H
!===========================================================
! nb_reaction_4 = nb_reaction_4 + 1
! indice_4(nb_reaction_4) = z4spec(1.0, indexchim('co'), 1.0, indexchim('oh'), 1.0, indexchim('co2'), 1.0, indexchim('h'))
To use it, you must uncomment the two last lines. The top one increments the number of reactions of type ''v4'', and the second one registers the reacting species for your new reaction.

Then go to the subroutine ''reactionrates_HC''. This is where you will write down the parametrization formula into the reaction rates table (the variable '''v_4''' for bimolecular reactions, '''v_3''' for quadratic reactions, or '''v_phot''' for all others). Again, you can take example of what's already there. If you want to use our example reaction, find the dedicated space, opening with the line:
!--- e001: oh + co -> co2 + h
and simply uncomment the following lines:
!nb_reaction_4 = nb_reaction_4 + 1
to update the index at which the rate is written in table '''v_4''', and then (for instance):
! jpl 2015

!do ilev = 1,nlayer
!!oh + co -> h + co2
! rate1 = 1.5e-13*(t(ilev)/300.)**(0.0)
!!oh + co + m -> hoco
! ak0 = 5.9e-33*(t(ilev)/300.)**(-1.0)
! ak1 = 1.1e-12*(t(ilev)/300.)**(1.3)
! rate2 = (ak0*dens(ilev))/(1. + ak0*dens(ilev)/ak1)
! xpo2 = 1./(1. + alog10((ak0*dens(ilev))/ak1)**2)
!
! v_4(ilev,nb_reaction_4) = rate1 + rate2*0.6**xpo2
!end do
(except the first one) to use the parametrization from the JPL 2015 collection (linked above). Notice that several parametrizations are implemented; to use another one simply uncomment another block, or write your own.

== Hard-coding reactions with 3 products ==
The model does not natively handle reactions with 3 products. The trick is to instead split it into 2 "semi-reactions", for instance instead of HNO3 + OH -> H2O + O + NO2, add 0.5 HNO3 + 0.5 OH -> H2O + 0.5 NO2 and 0.5 HNO3 + 0.5 OH -> O + 0.5 NO2 (or any stoichiometrically-equivalent couple). Each semi-reaction then has the same constant rate as the total reaction. Don't forget to count them as two distinct reactions.

= Python post-processing tools for photochemistry =
A mini python library is available in the '''util''' directory of the Generic model (LMDZ.GENERIC/utils), along with a demonstration jupyter notebook.

Physics of the Generic PCM

2025-03-04T11:05:37Z

Maxime Maurice: /* CO2 condensation */

This page describes the various physical parametrizations of the Generic PCM and the chronology of their call through the physical iteration. This chronology is important because some variables need to be updated by certain processes before others (examples).
During one physical iteration, the code passes through multiple sub-routines each encapsulating a parametrization. The sub-routines usually take as arguments:
*the dynamical values of the state variables
*the dynamical tendencies of the state variables
*any additional relevant variable
*any additional relevant tendency
and it returns in general tendencies (of the state variables as well as of any other relevant variable).

Work in progress. Need to add links.

=Initialization=
==First call==
Some initializations only need to be done at the very first iteration (e.g. examples).
==Each call==
Some other initializations need to be done at each iteration (e.g. examples).

=Radiative transfer=
==Correlated-k==
The main radiative transfer solver of the Generic PCM implements the correlated-k method, which provides a flexible and quick way to solve radiative transfer equations, particularly suited for GCMs. More informations here.
==Newtonian relaxation==
Newton was a very relaxed physicist, still inspiring us today.
==No atmosphere==
If you have no atmosphere, why do you need a GCM?

=Vertical diffusion=
==vdifc==
More info [[Vdifc_mod|here]].
==turbdiff==

=Convection=
Convective mixing in an atmosphere column involves non-resolved, sub-grid processes. These processes are parameterized using the following routines:
==Thermal plume==
This module implements a more accurate and sophisticated parametrization of convection. More info here.

==Dry convection==
More info [[Convective_adjustment_scheme_in_the_generic_PCM|here]].
==Non-orographic gravity waves==
More info here.

=CO2 condensation=
Inheriting from the Mars PCM where it is the background species, CO2 condensation is treated as a dedicated step in the Generic PCM's physics. Does that only concern CO2 as a background gas? Or does it work also if CO2 is a non-background variable gas? In any case more info here.

=Tracers=
Many things can be advected by tracers in the Generic PCM, like chemical species or aerosols. Physical processes involving tracers are parameterized using the following routines:

==Volcano==
This routine parameterizes a source of tracers corresponding to volcanic eruption. More information here.

==Water/ice==
Water aerosols (liquid or solid) are created (resp. consumed) by condensation (resp. vaporization or sublimation), consuming (resp. releasing) latent heat in the atmosphere. In the Generic PCM, the (atmospheric part of the) water cycle is handled by various routines, as explained here.

==Photochemistry==
Chemistry can turn molecules into other molecules, by the action of temperature (thermochemistry) or UV light (photochemistry). This is handled by the photochemistry routine, described [[Photochemistry|here]].

==Generic condensation==
On Earth, only water condenses in the atmosphere, but on other planets (which the Generic PCM aims at simulating), many other chemicals can undergo state change. To take that into account, the Generic PCM has a flexible scheme to deal with any arbitrary species, as desbribed [[Radiative_Generic_Condensable_Specie|here]].

==Sedimentation==
What goes up must come down, as explained [[Sedimentation_of_tracers_in_the_generic_PCM|here]].

==Updates==
This section essentially takes care that the condensation of a major species (e.g. water vapor in steam-rich atmospheres) affects other species, as described here.

==Slab ocean==
This routine solves for big fish eating small fish, as desbried [[Slab_ocean_model|here]].

==Surface==
The surface part of the water cycle is handled here, as the hydrology page describes.

=Subsurface thermal=
Thermal diffusion in the subsurface is solved here, as described there.

=Diagnostics/write outputs=
Nothing very physical here, just writting the outputs! By the way, if you want to know how to output new variables in the diagfi.nc file, check out [[Guide_for_good_coding#Export_variables_in_the_diagfi.nc_file|this]] page.

Physics of the Generic PCM

2025-03-04T11:03:28Z

Maxime Maurice: /* Non-orographic gravity waves */

This page describes the various physical parametrizations of the Generic PCM and the chronology of their call through the physical iteration. This chronology is important because some variables need to be updated by certain processes before others (examples).
During one physical iteration, the code passes through multiple sub-routines each encapsulating a parametrization. The sub-routines usually take as arguments:
*the dynamical values of the state variables
*the dynamical tendencies of the state variables
*any additional relevant variable
*any additional relevant tendency
and it returns in general tendencies (of the state variables as well as of any other relevant variable).

Work in progress. Need to add links.

=Initialization=
==First call==
Some initializations only need to be done at the very first iteration (e.g. examples).
==Each call==
Some other initializations need to be done at each iteration (e.g. examples).

=Radiative transfer=
==Correlated-k==
The main radiative transfer solver of the Generic PCM implements the correlated-k method, which provides a flexible and quick way to solve radiative transfer equations, particularly suited for GCMs. More informations here.
==Newtonian relaxation==
Newton was a very relaxed physicist, still inspiring us today.
==No atmosphere==
If you have no atmosphere, why do you need a GCM?

=Vertical diffusion=
==vdifc==
More info [[Vdifc_mod|here]].
==turbdiff==

=Convection=
Convective mixing in an atmosphere column involves non-resolved, sub-grid processes. These processes are parameterized using the following routines:
==Thermal plume==
This module implements a more accurate and sophisticated parametrization of convection. More info here.

==Dry convection==
More info [[Convective_adjustment_scheme_in_the_generic_PCM|here]].
==Non-orographic gravity waves==
More info here.

=CO2 condensation=

=Tracers=
Many things can be advected by tracers in the Generic PCM, like chemical species or aerosols. Physical processes involving tracers are parameterized using the following routines:

==Volcano==
This routine parameterizes a source of tracers corresponding to volcanic eruption. More information here.

==Water/ice==
Water aerosols (liquid or solid) are created (resp. consumed) by condensation (resp. vaporization or sublimation), consuming (resp. releasing) latent heat in the atmosphere. In the Generic PCM, the (atmospheric part of the) water cycle is handled by various routines, as explained here.

==Photochemistry==
Chemistry can turn molecules into other molecules, by the action of temperature (thermochemistry) or UV light (photochemistry). This is handled by the photochemistry routine, described [[Photochemistry|here]].

==Generic condensation==
On Earth, only water condenses in the atmosphere, but on other planets (which the Generic PCM aims at simulating), many other chemicals can undergo state change. To take that into account, the Generic PCM has a flexible scheme to deal with any arbitrary species, as desbribed [[Radiative_Generic_Condensable_Specie|here]].

==Sedimentation==
What goes up must come down, as explained [[Sedimentation_of_tracers_in_the_generic_PCM|here]].

==Updates==
This section essentially takes care that the condensation of a major species (e.g. water vapor in steam-rich atmospheres) affects other species, as described here.

==Slab ocean==
This routine solves for big fish eating small fish, as desbried [[Slab_ocean_model|here]].

==Surface==
The surface part of the water cycle is handled here, as the hydrology page describes.

=Subsurface thermal=
Thermal diffusion in the subsurface is solved here, as described there.

=Diagnostics/write outputs=
Nothing very physical here, just writting the outputs! By the way, if you want to know how to output new variables in the diagfi.nc file, check out [[Guide_for_good_coding#Export_variables_in_the_diagfi.nc_file|this]] page.

Physics of the Generic PCM

2025-03-04T11:02:30Z

Maxime Maurice: /* Thermal plume */

This page describes the various physical parametrizations of the Generic PCM and the chronology of their call through the physical iteration. This chronology is important because some variables need to be updated by certain processes before others (examples).
During one physical iteration, the code passes through multiple sub-routines each encapsulating a parametrization. The sub-routines usually take as arguments:
*the dynamical values of the state variables
*the dynamical tendencies of the state variables
*any additional relevant variable
*any additional relevant tendency
and it returns in general tendencies (of the state variables as well as of any other relevant variable).

Work in progress. Need to add links.

=Initialization=
==First call==
Some initializations only need to be done at the very first iteration (e.g. examples).
==Each call==
Some other initializations need to be done at each iteration (e.g. examples).

=Radiative transfer=
==Correlated-k==
The main radiative transfer solver of the Generic PCM implements the correlated-k method, which provides a flexible and quick way to solve radiative transfer equations, particularly suited for GCMs. More informations here.
==Newtonian relaxation==
Newton was a very relaxed physicist, still inspiring us today.
==No atmosphere==
If you have no atmosphere, why do you need a GCM?

=Vertical diffusion=
==vdifc==
More info [[Vdifc_mod|here]].
==turbdiff==

=Convection=
Convective mixing in an atmosphere column involves non-resolved, sub-grid processes. These processes are parameterized using the following routines:
==Thermal plume==
This module implements a more accurate and sophisticated parametrization of convection. More info here.

==Dry convection==
More info [[Convective_adjustment_scheme_in_the_generic_PCM|here]].
==Non-orographic gravity waves==

=CO2 condensation=

=Tracers=
Many things can be advected by tracers in the Generic PCM, like chemical species or aerosols. Physical processes involving tracers are parameterized using the following routines:

==Volcano==
This routine parameterizes a source of tracers corresponding to volcanic eruption. More information here.

==Water/ice==
Water aerosols (liquid or solid) are created (resp. consumed) by condensation (resp. vaporization or sublimation), consuming (resp. releasing) latent heat in the atmosphere. In the Generic PCM, the (atmospheric part of the) water cycle is handled by various routines, as explained here.

==Photochemistry==
Chemistry can turn molecules into other molecules, by the action of temperature (thermochemistry) or UV light (photochemistry). This is handled by the photochemistry routine, described [[Photochemistry|here]].

==Generic condensation==
On Earth, only water condenses in the atmosphere, but on other planets (which the Generic PCM aims at simulating), many other chemicals can undergo state change. To take that into account, the Generic PCM has a flexible scheme to deal with any arbitrary species, as desbribed [[Radiative_Generic_Condensable_Specie|here]].

==Sedimentation==
What goes up must come down, as explained [[Sedimentation_of_tracers_in_the_generic_PCM|here]].

==Updates==
This section essentially takes care that the condensation of a major species (e.g. water vapor in steam-rich atmospheres) affects other species, as described here.

==Slab ocean==
This routine solves for big fish eating small fish, as desbried [[Slab_ocean_model|here]].

==Surface==
The surface part of the water cycle is handled here, as the hydrology page describes.

=Subsurface thermal=
Thermal diffusion in the subsurface is solved here, as described there.

=Diagnostics/write outputs=
Nothing very physical here, just writting the outputs! By the way, if you want to know how to output new variables in the diagfi.nc file, check out [[Guide_for_good_coding#Export_variables_in_the_diagfi.nc_file|this]] page.

Physics of the Generic PCM

2025-03-04T10:49:14Z

Maxime Maurice: /* Diagnostics/write outputs */

This page describes the various physical parametrizations of the Generic PCM and the chronology of their call through the physical iteration. This chronology is important because some variables need to be updated by certain processes before others (examples).
During one physical iteration, the code passes through multiple sub-routines each encapsulating a parametrization. The sub-routines usually take as arguments:
*the dynamical values of the state variables
*the dynamical tendencies of the state variables
*any additional relevant variable
*any additional relevant tendency
and it returns in general tendencies (of the state variables as well as of any other relevant variable).

Work in progress. Need to add links.

=Initialization=
==First call==
Some initializations only need to be done at the very first iteration (e.g. examples).
==Each call==
Some other initializations need to be done at each iteration (e.g. examples).

=Radiative transfer=
==Correlated-k==
The main radiative transfer solver of the Generic PCM implements the correlated-k method, which provides a flexible and quick way to solve radiative transfer equations, particularly suited for GCMs. More informations here.
==Newtonian relaxation==
Newton was a very relaxed physicist, still inspiring us today.
==No atmosphere==
If you have no atmosphere, why do you need a GCM?

=Vertical diffusion=
==vdifc==
More info [[Vdifc_mod|here]].
==turbdiff==

=Convection=
Convective mixing in an atmosphere column involves non-resolved, sub-grid processes. These processes are parameterized using the following routines:
==Thermal plume==
==Dry convection==
More info [[Convective_adjustment_scheme_in_the_generic_PCM|here]].
==Non-orographic gravity waves==

=CO2 condensation=

=Tracers=
Many things can be advected by tracers in the Generic PCM, like chemical species or aerosols. Physical processes involving tracers are parameterized using the following routines:

==Volcano==
This routine parameterizes a source of tracers corresponding to volcanic eruption. More information here.

==Water/ice==
Water aerosols (liquid or solid) are created (resp. consumed) by condensation (resp. vaporization or sublimation), consuming (resp. releasing) latent heat in the atmosphere. In the Generic PCM, the (atmospheric part of the) water cycle is handled by various routines, as explained here.

==Photochemistry==
Chemistry can turn molecules into other molecules, by the action of temperature (thermochemistry) or UV light (photochemistry). This is handled by the photochemistry routine, described [[Photochemistry|here]].

==Generic condensation==
On Earth, only water condenses in the atmosphere, but on other planets (which the Generic PCM aims at simulating), many other chemicals can undergo state change. To take that into account, the Generic PCM has a flexible scheme to deal with any arbitrary species, as desbribed [[Radiative_Generic_Condensable_Specie|here]].

==Sedimentation==
What goes up must come down, as explained [[Sedimentation_of_tracers_in_the_generic_PCM|here]].

==Updates==
This section essentially takes care that the condensation of a major species (e.g. water vapor in steam-rich atmospheres) affects other species, as described here.

==Slab ocean==
This routine solves for big fish eating small fish, as desbried [[Slab_ocean_model|here]].

==Surface==
The surface part of the water cycle is handled here, as the hydrology page describes.

=Subsurface thermal=
Thermal diffusion in the subsurface is solved here, as described there.

=Diagnostics/write outputs=
Nothing very physical here, just writting the outputs! By the way, if you want to know how to output new variables in the diagfi.nc file, check out [[Guide_for_good_coding#Export_variables_in_the_diagfi.nc_file|this]] page.

Guide for good coding

2025-02-28T09:06:16Z

Maxime Maurice: /* Add a new user-input variable in physics modules */

== How to create a new module/subroutine ==

Subroutines should be integrated inside a module.
A good writing habit is to add the line "IMPLICIT NONE", in the beginning of the module and subroutine.

First you can define all the variable that belongs to the module and could be used at another place.
A good thing is also to create a subroutine that allocate and initialise module variables.
If the variable is only modified inside the module it should be tagged as protected.
If the variable belongs only to the module it can be specified to be private.

You can now start the writing of the subroutine.

- Start by importing variable and function from other module if necessary.

- Comment the purpose of the subroutine directly.

- Declare the variables, first the one pass in arguments.
Use the intent to specify the status of the variable inside the subroutine.

- Continue with the local and saved variables.

- Then you can define local variables.

- Remember to comment all of them, you can specify the dimension if the variable is an allocatable variable as well as the units and everything that seems appropriate.

You can finally write the code.

<syntaxhighlight lang="Fortran" line>
MODULE aquarium_mod

IMPLICIT NONE

INTEGER, protected :: water ! Define what is the variable, the dimension, units (°) etc...
! ideally all module variables should be "protected" i.e. can only be set or modified
! by routines/functions in the same module but can be used outside of it (as "read-only")
REAL,SAVE,ALLOCATABLE,DIMENSION(:),PROTECTED :: kre1 ! Another comment

CONTAINS

SUBROUTINE aquarium(kre, grass, other_things
& really_anything)

use another_module_mod, only: some_routine, some_variable

!=======================================================================
! subject:
! --------
! What is the subroutine doing
!
! author: Someone smart
! ------
! update: Someone smarter, march 2012:
! - I change something here
!
!=======================================================================

IMPLICIT NONE

!-----------------------------------------------------------------------
!=======================================================================
! Declarations :
!=======================================================================
!
! Input/Output
! ------------
REAL, INTENT(IN) :: something(ngrid,nlayer) ! 2D tabular used as an input only (W/m^2)
REAL, INTENT(OUT) :: kre(ngrid) ! 1D tabular output by the subroutine
REAL, INTENT(INOUT) :: grass(ngrid,nlayer) ! Variable that is modified by the subroutine
! it is an input and output
LOGICAL, INTENT(IN) :: really_anything ! Boolean variable

! Local saved variables
! ---------------------
INTEGER, PARAMETER :: nb_kre = 4 ! Number of kre
INTEGER, SAVE :: rock ! Another variable
LOGICAL, SAVE :: firstcall=.true. ! Another variable

! Local variables
! ---------------
REAL tabular(ngrid) ! Local var
INTEGER i ! Loop var

!=======================================================================
! Beginning of the code
!=======================================================================

IF (firstcall) THEN
! initialize rock
rock = 2
ENDIF !end firstcall

! identify where are the kre
DO i=1,nb_kre
kre(i)=i
if (kre(i).gt.rock) then
write(*,*) "the Kre ", i, "is behind the rock"
else if (mod(kre(i),2).eq.0) then
grass(:,nlayer-1)=grass(:,nlayer-1)-grass(:,nlayer) ! every two kre are eating grass in a very complex way
endif !(kre(i).gt.rock)
ENDDO !end of the loop nb_kre

END SUBROUTINE aquarium

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

SUBROUTINE ini_aquarium(ngrid)
!=======================================================================
! Initialise module's variable
!=======================================================================
IMPLICIT NONE
INTEGER, INTENT(IN) :: ngrid

allocate(kre1(ngrid+1))

END SUBROUTINE ini_aquarium

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

SUBROUTINE end_aquarium
!=======================================================================
! Deallocate module's variable
!=======================================================================

IMPLICIT NONE

IF (allocated(kre1)) deallocate(kre1)

END SUBROUTINE end_aquarium

END MODULE aquarium_mod

</syntaxhighlight>

== Naming subroutines convention ==

Un peu plus pour le PEM peut-être

== When to create subroutines instead of line of code ==

Quand est ce qu'on décide que ca vaut le coup de faire une routine spécifique : exemple négativité des pdq dans physiq_mod

== How to pass variable to subroutine (by argument or by using a module) ==

Base rule: variables should be passed down to routines via arguments. It makes it much easier for readers to follow what's going on and/or do the reverse engineering...

One should only use (import) a variable from a module if it used as "read-only" information. e.g. gravity constant, aerosol optical properties, etc.

== Add a new user-input variable in physics modules ==

How to properly add a new variable read from callphys.def

* Declare your variable in the callkeys module:
<syntaxhighlight lang="Fortran" line>
real,save :: myvariable
!$OMP THREADPRIVATE(myvariable)
</syntaxhighlight>
* Import it from the callkeys module into your module:
<syntaxhighlight lang="Fortran" line>
use callkeys_mod, only myvariable
</syntaxhighlight>
* Look for the flag in callphys.def ('myvariableflag' in the example below) during physics' initialization, or give it a default value if not found (666 in the example below) (in module inifis_mod.F90 for the Generic, Pluto and Titan PCMs, conf_phys for Mars and Venus PCMs):
<syntaxhighlight lang="Fortran" line>
if (is_master) write(*,*)trim(rname)//": Variable description"
myvariable=666. ! default value
call getin_p("myvariableflag",myvariable)
if (is_master) write(*,*)trim(rname)//": myvariable = ",myvariable
</syntaxhighlight>
notice that you don't need to import your variable specifically into inifis_mod / conf_phys because all variables from callkeys_mod are imported.

== Export variables in the diagfi.nc file ==
Simply use the writediagfi routine:
<syntaxhighlight lang="Fortran" line>
call writediagfi(ngrid,"name_in_netcdf_file","description_in_netcdf_file","units",dimensions,myvariable)
</syntaxhighlight>

== Naming variables convention ==

What is the naming convention.
In [[vdifc_mod]] for example.

== Loop index convention ==

Index name for loops over:
* '''physical grid''' : ig (max ngrid)
* ''' vertical levels''' : l (max nlayer)
* '''tracer''' : iq (max nq)
* '''subslopes''' : islope (max nslope)
* '''aerosol''' : iaer (max naerkind)
* '''longitude''' :
* '''latitude''' :

== Efficient loop coding ==

The outermost loop index should correspond to the last index of an array.

Example:
<syntaxhighlight lang="Fortran">
DO l=1,nlayer
DO ig=1,ngrid
array(ig,l)=l*ig
ENDDO
ENDDO
</syntaxhighlight>

== How to use the INTENT ==

Argument of a routine/function can come in 3 different way: IN, OUT, INOUT.
All arguments should be specified as :
* intent(in) : input only, i.e. not modified by the routine (or routines it passes the argument on to)
* intent(out) : output only, i.e. the value is set/computed in the routine (or via a routine it calls)
* intent(inout) : the combination of the two

== How to comment code ==

* '''In english'''
* '''As much as possible'''
* '''By using <code>!</code>''' (also known as the "bang" character) rather than <code>c</code> (which is not interpreted as a comment if in free form, e.g. .F90 files)
* '''Variable definition''' : explain what it is, the dimension, the units etc...
* '''Subroutine''' : Explain what it does, who wrote it, who modify it and why if it is a big change
* '''Loops''' : if the enddo is far away you can comment to which index it correspond to.
* '''Chapter your code''' : you can add section to your code to make it clearer.

== To know when coding with a code parallelized with OpenMP ==
In Fortran, any variable from a <code>module</code>, written in a <code>COMMON</code>, declared <code>SAVE</code> or initialized at the declaration (using <code>DATA</code> or <code>=</code>) is considered a ''static variable''.
When your code is parallelized using OpenMP, these static variables are SHARED by default. '''For the PCM physics, in 90% cases, you want each thread on which the code is parallelized to have its own private version of the variable''', so you should add, after the declaration of your variable, the following line:
<syntaxhighlight lang="Fortran">
!$OMP THREADPRIVATE(variable)
</syntaxhighlight>

== General guide ==

* Always check your modifications and additions by compiling and running in "debug" mode!
* Create .F90 (i.e. free form) instead of .F (i.e. fixed form); but this doesn't mean you should make lines too long!
* Delete unused argument in a function/routine call if you see one
* Delete unused variables
* Choose meaningful names for variables and mention physical unit where they are declared
* Don't hesitate to comment as much as possible, a code is never too commented
* Delete unused commented code lines

== External resources ==

You can check these pages for some guidelines and advice:
* https://www.fortran90.org/src/best-practices.html
* https://fortran-lang.org/en/learn/best_practices/
* https://wvuhpc.github.io/Modern-Fortran/11-Best-Practices/index.html

[[Category:Generic-Model]]
[[Category:Mars-Model]]
[[Category:Venus-Model]]
[[Category:Titan-Model]]

The z2sig.def Input File

2025-02-26T10:10:41Z

Maxime Maurice:

The z2sig.def file contains the pseudo-altitudes (in km) at which the user wants to set the vertical levels. Note that levels should be unevenly spread, with a higher resolution near the surface in order to capture the rapid variations of variables there. It is recommended to use the altitude levels as set in the ''z2sig.def'' file provided in the ''deftank'' directory. If yo uwant to change vertical resolution, check [[Advanced_Use_of_the_GCM#What_you_need_to_know_about_the_z2sig.def_file | there]].

== Example of ''z2sig.def'' file: ==

<pre>
8 H: atmospheric scale height (km) (used as a reference only)
0.004 Typical pseudo-altitude (m) for 1st layer (z=H*log(sigma))
0.017415589434569632 ,, ,, ,, ,, ,, ,, ,, ,, ,, 2nd layer, etc...
0.04197041134830409
0.09573548831202484
0.19905425549248695
0.37769312558816376
0.6610287582071787
1.0796026837077486
1.6625722655258326
2.4354958342473516
3.4187160120951323
4.626429653543951
6.066400344124698
7.740192276155182
9.643775222138789
11.768354425931134
14.10130177147987
17.
20.
23.
26.5
30.
34.
38.
42.
47.
52.
60.
68.
76.
82.
88.
94.
100.
105.
110.
115.
120.
125.
130.
</pre>

'''Note''': Lines beginning with a hashtag are not read

[[Category:Inputs]]

[[Category:Generic-Model]]

Guide for good coding

2025-01-23T09:51:44Z

Maxime Maurice:

== How to create a new module/subroutine ==

Subroutines should be integrated inside a module.
A good writing habit is to add the line "IMPLICIT NONE", in the beginning of the module and subroutine.

First you can define all the variable that belongs to the module and could be used at another place.
A good thing is also to create a subroutine that allocate and initialise module variables.
If the variable is only modified inside the module it should be tagged as protected.
If the variable belongs only to the module it can be specified to be private.

You can now start the writing of the subroutine.

- Start by importing variable and function from other module if necessary.

- Comment the purpose of the subroutine directly.

- Declare the variables, first the one pass in arguments.
Use the intent to specify the status of the variable inside the subroutine.

- Continue with the local and saved variables.

- Then you can define local variables.

- Remember to comment all of them, you can specify the dimension if the variable is an allocatable variable as well as the units and everything that seems appropriate.

You can finally write the code.

<syntaxhighlight lang="Fortran" line>
MODULE aquarium_mod

IMPLICIT NONE

INTEGER, protected :: water ! Define what is the variable, the dimension, units (°) etc...
! ideally all module variables should be "protected" i.e. can only be set or modified
! by routines/functions in the same module but can be used outside of it (as "read-only")
REAL,SAVE,ALLOCATABLE,DIMENSION(:),PROTECTED :: kre1 ! Another comment

CONTAINS

SUBROUTINE aquarium(kre, grass, other_things
& really_anything)

use another_module_mod, only: some_routine, some_variable

!=======================================================================
! subject:
! --------
! What is the subroutine doing
!
! author: Someone smart
! ------
! update: Someone smarter, march 2012:
! - I change something here
!
!=======================================================================

IMPLICIT NONE

!-----------------------------------------------------------------------
!=======================================================================
! Declarations :
!=======================================================================
!
! Input/Output
! ------------
REAL, INTENT(IN) :: something(ngrid,nlayer) ! 2D tabular used as an input only (W/m^2)
REAL, INTENT(OUT) :: kre(ngrid) ! 1D tabular output by the subroutine
REAL, INTENT(INOUT) :: grass(ngrid,nlayer) ! Variable that is modified by the subroutine
! it is an input and output
LOGICAL, INTENT(IN) :: really_anything ! Boolean variable

! Local saved variables
! ---------------------
INTEGER, PARAMETER :: nb_kre = 4 ! Number of kre
INTEGER, SAVE :: rock ! Another variable
LOGICAL, SAVE :: firstcall=.true. ! Another variable

! Local variables
! ---------------
REAL tabular(ngrid) ! Local var
INTEGER i ! Loop var

!=======================================================================
! Beginning of the code
!=======================================================================

IF (firstcall) THEN
! initialize rock
rock = 2
ENDIF !end firstcall

! identify where are the kre
DO i=1,nb_kre
kre(i)=i
if (kre(i).gt.rock) then
write(*,*) "the Kre ", i, "is behind the rock"
else if (mod(kre(i),2).eq.0) then
grass(:,nlayer-1)=grass(:,nlayer-1)-grass(:,nlayer) ! every two kre are eating grass in a very complex way
endif !(kre(i).gt.rock)
ENDDO !end of the loop nb_kre

END SUBROUTINE aquarium

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

SUBROUTINE ini_aquarium(ngrid)
!=======================================================================
! Initialise module's variable
!=======================================================================
IMPLICIT NONE
INTEGER, INTENT(IN) :: ngrid

allocate(kre1(ngrid+1))

END SUBROUTINE ini_aquarium

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

SUBROUTINE end_aquarium
!=======================================================================
! Deallocate module's variable
!=======================================================================

IMPLICIT NONE

IF (allocated(kre1)) deallocate(kre1)

END SUBROUTINE end_aquarium

END MODULE aquarium_mod

</syntaxhighlight>

== Naming subroutines convention ==

Un peu plus pour le PEM peut-être

== When to create subroutines instead of line of code ==

Quand est ce qu'on décide que ca vaut le coup de faire une routine spécifique : exemple négativité des pdq dans physiq_mod

== How to pass variable to subroutine (by argument or by using a module) ==

Base rule: variables should be passed down to routines via arguments. It makes it much easier for readers to follow what's going on and/or do the reverse engineering...

One should only use (import) a variable from a module if it used as "read-only" information. e.g. gravity constant, aerosol optical properties, etc.

== Add a new user-input variable in physics modules ==

How to properly add a new variable read from callphys.def

=== Generic PCM's physics ===
* Declare your variable in the callkeys module:
<syntaxhighlight lang="Fortran" line>
real,save :: myvariable
!$OMP THREADPRIVATE(myvariable)
</syntaxhighlight>
* Import it your module:
<syntaxhighlight lang="Fortran" line>
use callkeys_mod, only myvariable
</syntaxhighlight>
* Look for the flag in callphys.def ('myvariableflag' in the example below) during physics' initialization, or give it a default value if not found (666 in the example below) (in module inifis_mod.F90):
<syntaxhighlight lang="Fortran" line>
if (is_master) write(*,*)trim(rname)//": Variable description"
myvariable=666. ! default value
call getin_p("myvariableflag",myvariable)
if (is_master) write(*,*)trim(rname)//": myvariable = ",myvariable
</syntaxhighlight>
notice that you don't need to import your variable specifically in inifis_mod because all variables from callkeys_mod are imported.

== Export variables in the diagfi.nc file ==
Simply use the writediagfi routine:
<syntaxhighlight lang="Fortran" line>
call writediagfi(ngrid,"name_in_netcdf_file","description_in_netcdf_file","units",dimensions,myvariable)
</syntaxhighlight>

== Naming variables convention ==

What is the naming convention.
In [[vdifc_mod]] for example.

== Loop index convention ==

Index name for loops over:
* '''physical grid''' : ig (max ngrid)
* ''' vertical levels''' : l (max nlayer)
* '''tracer''' : iq (max nq)
* '''subslopes''' : islope (max nslope)
* '''aerosol''' : iaer (max naerkind)
* '''longitude''' :
* '''latitude''' :

== Efficient loop coding ==

The outermost loop index should correspond to the last index of an array.

Example:
<syntaxhighlight lang="Fortran">
DO l=1,nlayer
DO ig=1,ngrid
array(ig,l)=l*ig
ENDDO
ENDDO
</syntaxhighlight>

== How to use the INTENT ==

Argument of a routine/function can come in 3 different way: IN, OUT, INOUT.
All arguments should be specified as :
* intent(in) : input only, i.e. not modified by the routine (or routines it passes the argument on to)
* intent(out) : output only, i.e. the value is set/computed in the routine (or via a routine it calls)
* intent(inout) : the combination of the two

== How to comment code ==

* '''In english'''
* '''As much as possible'''
* '''By using <code>!</code>''' (also known as the "bang" character) rather than <code>c</code> (which is not interpreted as a comment if in free form, e.g. .F90 files)
* '''Variable definition''' : explain what it is, the dimension, the units etc...
* '''Subroutine''' : Explain what it does, who wrote it, who modify it and why if it is a big change
* '''Loops''' : if the enddo is far away you can comment to which index it correspond to.
* '''Chapter your code''' : you can add section to your code to make it clearer.

== To know when coding with a code parallelized with OpenMP ==
In Fortran, any variable from a <code>module</code>, written in a <code>COMMON</code>, declared <code>SAVE</code> or initialized at the declaration (using <code>DATA</code> or <code>=</code>) is considered a ''static variable''.
When your code is parallelized using OpenMP, these static variables are SHARED by default. '''For the PCM physics, in 90% cases, you want each thread on which the code is parallelized to have its own private version of the variable''', so you should add, after the declaration of your variable, the following line:
<syntaxhighlight lang="Fortran">
!$OMP THREADPRIVATE(variable)
</syntaxhighlight>

== General guide ==

* Always check your modifications and additions by compiling and running in "debug" mode!
* Create .F90 (i.e. free form) instead of .F (i.e. fixed form); but this doesn't mean you should make lines too long!
* Delete unused argument in a function/routine call if you see one
* Delete unused variables
* Choose meaningful names for variables and mention physical unit where they are declared
* Don't hesitate to comment as much as possible, a code is never too commented
* Delete unused commented code lines

== External resources ==

You can check these pages for some guidelines and advice:
* https://www.fortran90.org/src/best-practices.html
* https://fortran-lang.org/en/learn/best_practices/
* https://wvuhpc.github.io/Modern-Fortran/11-Best-Practices/index.html

[[Category:Generic-Model]]
[[Category:Mars-Model]]
[[Category:Venus-Model]]
[[Category:Titan-Model]]

Physics of the Generic PCM

2025-01-20T13:03:25Z

Maxime Maurice:

This page describes the various physical parametrizations of the Generic PCM and the chronology of their call through the physical iteration. This chronology is important because some variables need to be updated by certain processes before others (examples).
During one physical iteration, the code passes through multiple sub-routines each encapsulating a parametrization. The sub-routines usually take as arguments:
*the dynamical values of the state variables
*the dynamical tendencies of the state variables
*any additional relevant variable
*any additional relevant tendency
and it returns in general tendencies (of the state variables as well as of any other relevant variable).

Work in progress. Need to add links.

=Initialization=
==First call==
Some initializations only need to be done at the very first iteration (e.g. examples).
==Each call==
Some other initializations need to be done at each iteration (e.g. examples).

=Radiative transfer=
==Correlated-k==
The main radiative transfer solver of the Generic PCM implements the correlated-k method, which provides a flexible and quick way to solve radiative transfer equations, particularly suited for GCMs. More informations here.
==Newtonian relaxation==
Newton was a very relaxed physicist, still inspiring us today.
==No atmosphere==
If you have no atmosphere, why do you need a GCM?

=Vertical diffusion=
==vdifc==
More info [[Vdifc_mod|here]].
==turbdiff==

=Convection=
Convective mixing in an atmosphere column involves non-resolved, sub-grid processes. These processes are parameterized using the following routines:
==Thermal plume==
==Dry convection==
More info [[Convective_adjustment_scheme_in_the_generic_PCM|here]].
==Non-orographic gravity waves==

=CO2 condensation=

=Tracers=
Many things can be advected by tracers in the Generic PCM, like chemical species or aerosols. Physical processes involving tracers are parameterized using the following routines:

==Volcano==
This routine parameterizes a source of tracers corresponding to volcanic eruption. More information here.

==Water/ice==
Water aerosols (liquid or solid) are created (resp. consumed) by condensation (resp. vaporization or sublimation), consuming (resp. releasing) latent heat in the atmosphere. In the Generic PCM, the (atmospheric part of the) water cycle is handled by various routines, as explained here.

==Photochemistry==
Chemistry can turn molecules into other molecules, by the action of temperature (thermochemistry) or UV light (photochemistry). This is handled by the photochemistry routine, described [[Photochemistry|here]].

==Generic condensation==
On Earth, only water condenses in the atmosphere, but on other planets (which the Generic PCM aims at simulating), many other chemicals can undergo state change. To take that into account, the Generic PCM has a flexible scheme to deal with any arbitrary species, as desbribed [[Radiative_Generic_Condensable_Specie|here]].

==Sedimentation==
What goes up must come down, as explained [[Sedimentation_of_tracers_in_the_generic_PCM|here]].

==Updates==
This section essentially takes care that the condensation of a major species (e.g. water vapor in steam-rich atmospheres) affects other species, as described here.

==Slab ocean==
This routine solves for big fish eating small fish, as desbried [[Slab_ocean_model|here]].

==Surface==
The surface part of the water cycle is handled here, as the hydrology page describes.

=Subsurface thermal=
Thermal diffusion in the subsurface is solved here, as described there.

=Diagnostics/write outputs=
Nothing very physical here, just writting the outputs!

Physics of the Generic PCM

2025-01-13T16:50:43Z

Maxime Maurice:

Overview of the Generic PCM

2025-01-13T16:46:30Z

Maxime Maurice:

== What is a GCM ==

A Global Climate Model (GCM) like the Generic PCM calculates the temporal evolution of the different variables (temperature, pressure, mass, mixing ratio of tracers/gas/clouds, winds, etc.) that control or describe the planetary meteorology and climate at different points of a 3D “grid” that covers the entire atmosphere.

To do that, the model solves 3D hydrodynamic equations that describe how atmospheric winds are created by various physical forcings (radiative heating/cooling, etc.) and how these winds transport and redistribute the various atmospheric fields (temperature, tracers, etc.). However, it can be shown that to a good level of approximation, the various forcings can be computed using only local conditions in a column of atmosphere, whereas long-range couplings between various points of the planet are mediated through atmospheric transport.

[[File:Didi-eps-converted-to-1.png|thumb|Physics / Dynamics interface ; credit: Emmanuel Marcq]]

For these reasons, the 3D model is split in two components:

* '''a 3D dynamical core''' abble to integrate in time the general equations for atmospheric circulation when the various local forcings are known. This component (including source code) is common to all terrestrial-type atmospheres, and applicable in certain cases to the upper atmospheres of gas giant planets.
* [[Physics_of_the_Generic_PCM|'''a physical package''']] that is specific to the planet in question (as it takes into account dedicated parametrizations representative of ongoing physical processes) and which computes atmospheric processes in each atmospheric column (which are sub-grid-scale from the point of view of the dynamical core).

In practice, we have several '''dynamical cores''' available with the model: LMDZ (global longitude/latitude grid), DYNAMICO (icosaedric grid), and WRF (rectangular box for local/regional studies)

From an initial state, the model calculates the temporal evolution of these variables, one timestep after another:
* At instant t, variables Xt (temperature for example) are known at every grid point of the atmosphere.
* The physical model calculates the local time derivatives of the various variables -- called the tendencies -- ((δX/δt)1, (δX/δt)2, etc.) due to each physical phenomenon: for example, heating due to absorption of solar radiation and infrared cooling, mixing due to turbulence in the planetary boundary layer, condensation/evaporation of water vapor, etc. These tendencies are calculated via parameterization of the processes involved that try to capture the physical behavior of the atmopshere at the subgrid scale.
* These tendencies are passed to the dynamical core that integrates the model forward in time to the next time step, t + δt, by solving the hydrodynamical equations.
* This new state can be used to recompute the tendencies for the next time step and so on.

== Philosophy of the Generic PCM ==

The accuracy and predictive power of any GCM is often dictated by the choice made for the physical phenomena that are included and for the way they are parametrized. To be accurate, many Earth-centric climate models use very complex parametrizations that are heavily tuned on Earth observations. Such parametrizations can, however, behave very poorly far from the parameter space where they have been validated, thus reducing their predictive power for exotic atmospheres.

As the goal of the Generic PCM is to model the climate of very different planets with the same model, a particular emphasis has been put on using simple parametrizations based as much as possible on ab-initio physical equations and conservation principles to avoid unphysical behaviors in extreme regimes.

== GCM inputs and outputs ==

[[File:Inout-eps-converted-to-1.png|thumb|input/output data]]

The input files are the files needed to initialize the model (state of the atmosphere at instant t0 as well as a dataset of boundary conditions). The output files are “historical files”, archives of the atmospheric flow history as simulated by the model: the “diagfi files”, the “stats files”, the daily averages, and so on. The "parameter files" are the files describing the physical parameters of the planet, as well as the physical parameterizations used in the model. The figure (on the right) shows the main architecture of the Generic PCM.

==== start and startfi files ====

GCM simulations needs a list of initial conditions/parameters to be run. This includes, for example, the initial temperature field, wind field, cloud field, position of water reservoirs on the surface, etc.

In the Generic PCM, initial conditions/parameters are stored [[The_start.nc_and_startfi.nc_input_files|in two files named "start.nc" and "startfi.nc"]]. At each new run, the GCM reads these two files to set up the proper set of initial conditions.

==== start vs restart files ====

At the end of each GCM simulation, the Generic PCM produces several output files, and notably two files named "restart.nc" and "restartfi.nc".

These two files store all the final conditions of the model, which includes, for example, the initial temperature field, wind field, cloud field, position of water reservoirs on the surface, etc.

These "restart.nc" and "restartfi.nc" have the exact same architecture than the "start.nc" and "startfi.nc" files, and can thus be used as initial conditions for a new Generic PCM simulation.

==== parameter (.def) files ====

The parameter files (listed below) are files required by the Generic PCM to run.

List of needed .def files:
<ul>
<li> [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_callphys.def_Input_File ''callphys.def'']: Physical parameters used in the simulation</li>
<li> [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_run.def_Input_File ''run.def'']: Numerical parameters used in the simulation</li>
<li> [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_gases.def_Input_File ''gases.def'']: List of gases in the simulations</li>
<li> [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_traceur.def_Input_File ''traceur.def'']: Numerical tracers in the simulations</li>
<li> [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_z2sig.def_Input_File ''z2sig.def'']: Pseudo-altitudes (in km) at which the user wants to set the vertical levels</li>
<li> [https://lmdz-forge.lmd.jussieu.fr/mediawiki/Planets/index.php/The_diagfi.def_Input_File ''diagfi.def''] (optional): List of wanted outputs</li>
</ul>

==== input data ====

The Generic PCM requires several inputs in order to run. This includes, for instance:
* opacity tables
* aerosols optical properties
* stellar spectrum

These data can be modified/adapted by the users depending on the planet to be simulated.

==== output files ====

At the end of each GCM simulation, the Generic PCM produces several output files, and notably a file named "diagfi.nc". This file is an archive of the atmospheric/surface fields (temperatures, winds, clouds, etc.) along the GCM simulation. This is the file that contains most of the information needed to analyze/understand the content of a GCM simulation.

nb: The Generic PCM can also produce extra output files, such as the "diagspec.nc" files (that keep track of the spectral radiative fluxes in the GCM), the "stats.nc" (that keep track of statistical information along the GCM simulation), etc.

== Our team of developers (by alphabetical order) ==

'''Active contributors'''

*Deborah Bardet
*Siddharth Bhatnagar
*Benjamin Charnay (permanent, LESIA)
*Guillaume Chaverot
*Noé Clément
*Aurélien Falco
*François Forget (permanent, LMD)
*Gabriella Gilli
*Sandrine Guerlet (permanent, LMD)
*Mathilde Houelle
*Yassin Jaziri
*Sébastien Lebonnois (permanent, LMD)
*Jeremy Leconte (permanent, LAB)
*Maxence Lefèvre
*Arthur Le Saux
*Alice Maurel
*Maxime Maurice
*Gwenael Milcareck
*Ehouarn Millour (permanent, LMD)
*Aymeric Spiga (permanent, LMD)
*Keigo Taniguchi
*Lucas Teinturier
*Martin Turbet (permanent, LMD)

'''Collaborators and previous contributors'''

*Tanguy Bertrand
*Antoine Bierjon
*Alexandre Boissinot
*Emeline Bolmont
*Francis Codron
*Antony Delavois
*Thomas Dubos
*Vincent Eymet
*Frédéric Hourdin
*Franck Lefèvre
*Laura Kerber
*Jean-Baptiste Madeleine
*Emmanuel Marcq
*Diogo Quirino
*Franck Selsis
*Jan Vatant d'Olonne
*Margaux Vals
*Romain Vandemeulebrouck
*Robin Wordsworth

[[Category:Generic-Model]]

Physics of the Generic PCM

2025-01-09T17:03:09Z

Maxime Maurice: Created page with "This page describes the chronology of the physical iteration of the Generic PCM. This chronology is important because some variables need to be updated by certain processes b..."

This page describes the chronology of the physical iteration of the Generic PCM. This chronology is important because some variables need to be updated by certain processes before others within the physical iteration (examples).
During one physical iteration, the code passes through multiple sub-routines each encapsulating a parameterization. The sub-routines are passed as arguments:
- the dynamical values of the state variables
- the dynamical tendencies of the state variables
- any additional relevant variable
- any additional relevant tendency
and it returns in general tendencies (of the state variables as well as of any other relevant variable).

Work in progress. Need to add links.

=Initialization=
==First call==
Some initializations only need to be done at the very first iteration (e.g. examples).
==Each call==
Some other initializations need to be done at each iteration (e.g. examples).

=Radiative transfer=
==Correlated-k==
The main radiative transfer solver of the Generic PCM implements the correlated-k method, which provides a flexible and quick way to solve radiative transfer equations, particularly suited for GCMs. More informations here.
==Newtonian relaxation==
Newton was a very relaxed physicist, still inspiring us today.
==No atmosphere==
If you have no atmosphere, why do you need a GCM?

=Vertical diffusion=
==vdifc==
==turbdiff==

=Convection=
Convective mixing in an atmosphere column involves non-resolved, sub-grid processes. These processes are parameterized using the following routines:
==Thermal plume==
==Dry convection==
==Non-orographic gravity waves==

=CO2 condensation=

=Tracers=
Many things can be advected by tracers in the Generic PCM, like chemical species or aerosols. Physical processes involving tracers are parameterized using the following routines:

==Volcano==
This routine parameterizes a source of tracers corresponding to volcanic eruption. More information here.

==Water/ice==
Water aerosols (liquid or solid) are created (resp. consumed) by condensation (resp. vaporization or sublimation), consuming (resp. releasing) latent heat in the atmosphere. In the Generic PCM, the (atmospheric part of the) water cycle is handled by various routines, as explained here.

==Photochemistry==
Chemistry can turn molecules into other molecules, by the action of temperature (thermochemistry) or UV light (photochemistry). This is handled by the photochemistry routine, described here.

==Generic condensation==
On Earth, only water condenses in the atmosphere, but on other planets (which the Generic PCM aims at simulating), many other chemicals can undergo state change. To take that into account, the Generic PCM has a flexible scheme to deal with any arbitrary species, as desbribed here.

==Sedimentation==
What goes up must come down, as explained here.

==Updates==
This section essentially takes care that the condensation of a major species (e.g. water vapor in steam-rich atmospheres) affects other species, as described here.

==Slab ocean==
This routine solves for big fish eating small fish, as desbried here.

==Surface==
The surface part of the water cycle is handled here, as the hydrology page describes.

=Subsurface thermal=
Thermal diffusion in the subsurface is solved here, as described there.

=Diagnostics/write outputs=
Nothing very physical here, just writting the outputs!

Early Mars benchmark - DYNAMICO

2024-10-23T08:03:16Z

Maxime Maurice: Created page with "== Prerequisites == First make sure you can run the early Mars benchmark with the LMDZ dynamical core. Then install dynamico and XIOS (preferentially in the same trunk direct..."

== Prerequisites ==

First make sure you can run the early Mars benchmark with the LMDZ dynamical core.
Then install dynamico and XIOS (preferentially in the same trunk directory).
Now that everything is working separately, let's put everything together.

== Compiling dynamico with the generic PCM physics package ==

First we need to compile dynamico with the physics package of the generic PCM. Go to the ICOSA_LMDZ folder. To compile, we will use the '''make_icosa_lmdz''' file which is a wrapper for the compilation scripts of IOIPSL, XIOS, the generic PCM's physics (called by '''makelmdz_fcm -libphy''') and dynamico ('''make_icosa'''). Some compilation command line examples are provded in the ascii files '''make_irene_lmdz''' and '''compile_adastra-gnu'''. For our purpose, let's go with the following command:

make_icosa_lmdz -p std -p_opt "-b 32x36" -parallel mpi_omp -arch {your_arch} -arch_path ../ARCH -job 8

Make sure that you have been using the same architecture for installing all the pieces. If the compilation worked, the last lines of the prompt look something like:

->Make : 6 seconds
->TOTAL : 7 seconds
Build command finished on Mon Oct 21 15:05:13 2024.

Notice that it will probably take a bit longer, in particular if XIOS needs to be compiled. The bin folder now contains an executable called '''icosa_lmdz.exe'''.

== Adapting the early Mars benchmark ==

Now go to the folder of the early Mars benchmark sources, and create a subfolder called "dynamico". Copy and paste all the .def files from the benchmark into this folder, as well as your executable '''icosa_lmdz.exe'''.

=== planetary_const.def ===

We'll need additional .def files for the planetary constants and run informations. You can simply copy and paste the '''const_earth.def''' for Earth used in the Held and Suarez test of dynamico into the local folder as '''const_mars.def''', and adapt it appropriately.

=== run_icosa.def ===

We'll also use a '''run_icosa.def''' file, for which you can find inforrmation here. You can modify it to have 40 triangles subdivisions and n_spliti and n_splitj equal to 4, and llm=15 (15 vertical levels, as in the benchmark). You also need to set disvert=plugin, meaning that the vertical discretization will be handled by the appropriate plugin from the generic model. Set day_step=480, nqtot=3 (given by traceur.def). Deactivate Rayleigh friction (rayleigh_friction_type=none). Finally, make sure you have physics = phys_external. Now that all the run info is in the '''run_icosa.def''' file, '''run.def''' is simply calling this file:
###########################################################################
### INCLUDE OTHER DEF FILES (physics, specific settings, etc...)
###########################################################################
INCLUDEDEF=run_icosa.def

INCLUDEDEF=mars_const.def

INCLUDEDEF=callphys.def

prt_level=0

## iphysiq must be same as itau_physics
iphysiq=5
#iphysiq=10

Make sure the '''tracer.def''' (the tracer file for dynamico) is consistant with traceur.def (the tracer file for the physics).

Contrarily to the native benchmark, we'll need to use XIOS to run with dynamico. That involves a few more input files. You will find out which xml files you need and where to look for them in the trunk, in the README.xml file which is located in the xml subfolder of the ICOSA_LMDZ folder of the trunk.

The '''context_physics_lmdz.xml''' file contains information relative to the physics grid. The original file creates a grid larger than we need. For the benchmark we will reduce the resolution to 32x32. To do so, add the following block taking example on the already existing ones:

<domain id="dom_32_32" type="rectilinear" ni_glo="32" nj_glo="32" >
<generate_rectilinear_domain/>
<interpolate_domain order="1"/>
</domain>

and indicate that we want to use this new grid as the output grid. To do so, modify the existing line defining variable '''dom_out''' as:

<domain id="dom_out" domain_ref="dom_32_32"/>

Contrarily to the LMDZ dynamical core, a dynamico run usually does not start from a start.nc initial state. Instead, an initial state is generated, from which the simulation really starts. Let's thus make two subfolders: one called "init" where we will generate the initial state, and one called "run" where the simulation will run.

=== iodef.xml ===
Here simply change the line:
<context id="LMDZ" src="./context_lmdz_physics.xml" />
to:
<context id="LMDZ" src="./context_pcm_physics.xml" />

== Generating the initial state ==
In the run_icosa.def, comment out the following lines:
#etat0=start_file
#etat0_start_file_colocated=true
and uncomment instead:
etat0=isothermal
etat0_isothermal_temp=200
and
etat0_ps_white_noise=0.01
etat0_theta_rhodz_white_noise=0.01

== Running the simulation ==

The traceur.def Input File

2024-03-13T17:42:42Z

Maxime Maurice:

== What is it for? ==

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

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

== What is a tracer? ==

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

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

== File structure ==

=== "Old" version ===

Number of tracers need to be specified, followed by tracers names. The following example will set up water tracers to compute water cloud and water cycle in general.

<pre>
2
h2o_vap
h2o_ice
</pre>

=== "Modern" version ===

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

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

== Initialisation ==

=== In 3D ===

In 3D, the initial distribution of tracers is in the '''start.def''' file. In order to change it, you have to modify the '''start.def''', for example using newstart.

=== In 1D ===

In 1D, the initial distribution of each tracer can be read from a file named "'''profile_<tracer name>'''" (e.g. '''profile_h2o_vap''' for the water vapour initial profile), located in the run directory. This file has Nlayer + 1 lines (with Nlayer the number of horizontal layers): its first line is the surface value (in kg/m^2), and then each line is the value at the corresponding level (in kg/kg).

=== Using photochemistry ===

When you use photochemistry (both in 3D and 1D), the initial distribution of tracers can be given as options in the '''traceur.def''' file, as explained above.

[[Category:Inputs]]

[[Category:Generic-Model]]

Other GCM Configurations worth knowing about

2023-05-12T15:57:49Z

Maxime Maurice:

= 3D lon-lat LMDZ setup =

== early Mars ==

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

== Earth with slab ocean ==

TBD by Martin (I will update this case as soon as Siddharth has committed changes)

== TRAPPIST-1e with photochemistry ==

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

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

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

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

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

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

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

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

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

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

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

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

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

nb_reaction_4 = nb_reaction_4 + 1

! joshi et al., 2006

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

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

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

nb_phot = nb_phot + 1

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

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

!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
! photodissociation of NO
!ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

nb_phot = nb_phot + 1

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

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

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

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

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

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

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

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

<syntaxhighlight lang="bash">
wget -nv --no-check-certificate http://www.lmd.jussieu.fr/~lmdz/planets/generic/bench_trappist1c_64x48x50_b32x36
</syntaxhighlight>

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

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

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

<syntaxhighlight lang="bash">

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

'''TO BE COMPLETED BY GABRIELLA'''

== mini-Neptune GJ1214b ==

A warm mini-Neptune

'''TO BE COMPLETED BY BENJAMIN'''

= 3D DYNAMICO setup =

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

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

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

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

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

'''ICOSAGCM''': the DYNAMICO dynamical core
<syntaxhighlight lang="bash">
git clone https://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico.git ICOSAGCM
cd ICOSAGCM
git checkout 90f7138a60ebd3644fbbc42bc9dfa22923386385
</syntaxhighlight>

'''ICOSA_LMDZ''': the interface using to link LMDZ.GENERIC physical packages and ICOSAGCM
<syntaxhighlight lang="bash">
svn update -r 2655 -q ICOSA_LMDZ
</syntaxhighlight>

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

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

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

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

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

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

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

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

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

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

There are two kind of setting files:

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

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

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

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

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

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

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

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

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

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

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

Fat1AU = 1366.0

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

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

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

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

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

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

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

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

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

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

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

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

INCLUDEDEF=jupiter_const.def

INCLUDEDEF=callphys.def

prt_level=0

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

== Hot Jupiter with DYNAMICO ==

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

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

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

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

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

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

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

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

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

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

= 3D LES setup =

== Proxima b with LES ==

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

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

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

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

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

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

TBC ML

= 1D setup =

== rcm1d test case ==

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

Then, copy the executable in your working directory. Notice that the '''.def''' files differ a bit from the 3D case: [[The_run.def_Input_File|'''run.def''']] is replaced with '''rcm1d.def''', which contains more general information. Indeed, the 1D mmodel does not use [[The_start.nc_and_startfi.nc_input_files|'''start.nc''']] or [[The_start.nc_and_startfi.nc_input_files|'''startfi.nc''']] files to initialize. Instead it reads everything from the '''.def''' files. You can find examples of 1D configuration in ''LMDZ.GENERIC/deftank'' (e.g. '''rcm1d.def.earlymars''', '''rcm1d.def.earth'''), the best thing is to have a look at them.

== kcm1d test case ==

Our 1-D inverse model

TBD by Guillaume or Martin

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