Time marching in LMDZ

De LMDZPedia
Révision de 23 janvier 2021 à 23:29 par Lfairhead (discussion | contributions) (Page créée avec « == Some information about LMDZ time steps (and related input parameters) and time marching scheme == === Overview === LMDZ is a time marching code, which simply means th... »)

(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à : navigation, rechercher

Some information about LMDZ time steps (and related input parameters) and time marching scheme

Overview

LMDZ is a time marching code, which simply means that the evolution equations of the climate system are solved along time, starting from a given initial condition (which is why the GCM typically requires input files start.nc and startphy.nc to run).

In a nutshell: one must distinguish between the time steps for the dynamics and for the physics as the underlying processes (and related numerical constraints) are quite different. In practice the atmospheric motions computed in the dynamics require short time steps (of the order of minutes) whereas (most) processes in the physics can be handled with time steps of a fraction of an hour.

The main parameters (typically set in file gcm.def) that set the time steps in the model are the following:

  • day_step : the number of dynamical time steps per day (must be an integer). Note that this parameter conversely sets the dynamics time step (in s) to dt_dyn=86400/day_step
  • iphysiq : the rate (in dynamical time steps) at which the dynamics will call the physics, must be an integer (and should be a divisor of day_step so that the physics are called an integer number of times per day). This parameter conversely sets the physics time step (in s) to dt_phys=iphysiq*dt_dyn=86400*(iphysiq/day_step)


Good to know

There is no reason or need to change the physics time step when changing the (horizontal) grid, but there are strong stability constraints for the dynamics which requires using a smaller dynamical time step with finer grids. To decrease dt_dyn one must thus increase day_step, bearing in mind the following constraints:

  • The time marching scheme in the dynamics is of mixed Leapfrog-Matsuno type (if the parameter "purmats" is set to false in gcm.def, which is the default behavior) . This means that a number of leapfrog steps are done between single Matsuno steps; this number is set by the "iperiod" parameter (also in gcm.def). Stability constraints (loosely put, the Matsuno step recombines solutions diverging away from each other between even and odd leapfrog steps) require keeping iperiod to 10 or less (typically 5 or 7).
  • It is mandatory that iperiod be a divisor of iphysiq so that the physics package is called over integer cycles of Leapfrog-Matsuno integration.


An illustrative example

As can bee see in the example file (gcm.def_144x142 in the LMDZ DefLists directory, also check this related HowTo): for a 144x142 regular horizontal grid, we set "day_step=672", "iperiod=7" and "iphysiq=7", which implies a dynamical time step dt_dyn=86400./672=128.6 s (i.e. 2.15 minutes) and a physical time step of 86400.*7./672=900 s (i.e. 15 minutes). For an even higher resolution, e.g. 256 x 256 a smaller dynamical step is required and we set "day_step=1344" (i.e. dt_dyn=64.3s), while keeping "iperiod=7" and increasing iphysiq to 14 (i.e. dt_phy=900 s).


13/05/2020