Version 1 (modified by mmcgrath, 7 years ago) (diff)


This is important to know if you are trying to use LMDz as a regional model and zoom over a particular region. I do not give any advice here on how to create the grid (Frédéric Hourdin at LMD created one over Europe for us), but I did learn a few things about what needs to be done next.

1) Make sure the grid is stable 2) Make sure the climate on the grid is realistic.

Step (2) is covered on a different page of the Wiki, so I'll just talk about (1) here.

According to LMD, there are no surefire ways to make sure a grid is stable. All you can do is adjust a few parameters, run a simulation, and see if it crashes with an error in hgardfou (which typically means that the temperature in a grid cell has become unrealistic...for example, the surface temperature exceeds the normal boiling point of water or the temperature is negative).


If you are not nudging (for a zoomed grid, you should nudge at least the winds), the first parameter to adjust is the timestep. There are three distinct variables to adjust for this.

iphysiq (lmdz.driver, or PARAM/gcm.def_*, depending on the physics you are using) day_step (PARAM/gcm.def_*) nsplit_phys (PARAM/physiq.def_*)

day_step appears to be the shortest timestep in the model, and the length in seconds is equal to 86400/day_step (86400 seconds in a day). This is changed according to the grid, and varies from around 480 up to around 3000. 86400/day_step has to be an integer! I think this is the dynamical timestep.

iphysiq is how many dynamical timesteps go into the physical timestep (including how often ORCHIDEE is called). When people say the model has a timestep of 30 minutes, they seem to mean that 86400/day_step*iphysiq=1800 s. 86400/(86400/day_step*iphysiq) must be an integer as well (i.e. there should be an integer number of physical timesteps in a day). A physical timestep of 7min30s is considered fairly short. 30min is common for the old physics, while 15 minutes is standard for the new physics (v3.2).

nsplit_phys is a further splitting of the physics timestep. 86400/day_step*iphysiq/nsplit_phys gives the total formula for the length of the physical timestep. Frédéric Hourdin has said that you should avoid setting nsplit_phys greater than 1.

With the above information, you can play around with the timestep and hopefully get a simulation that runs (and a timestep between 7min30s and 30min). If not, and you are nudging, there is something else you can try.

Some guidelines by Frédéric:

If your grid is on the order of 120 boxes wide and tall, you usually need 720 dynamical timesteps per day (day_step=720). With a zoom with a factor of 4.5, you need on the order of 720*4.5=3240. So day_step=3240 is a good place to start.


One way to avoid crazy physics is to nudge your simulation outside of the zoomed area. This is a requirement, in fact, when running the zoom, because outside of the zoom the boxes are very irregularly shaped which can cause a lot of problems. Using nudging (guidage in French) is covered elsewhere on the Wiki. The parameters that you can play with to increase stability are

tetagrot tetagdiv

vec des mailles de 50km en gros, tu peux aussi te permettre de dissiper beaucoup plus. Par exemple tetagrot=tetagdiv=tetagdiv=1200 ou même encore plus court. Tu pourras toujours relacher un peu après. Les tau_min_u/v=0.05 veulent dire que tu guides en dehors du zoom avec un temps de relaxation de 0.05 jour, soit une 1h12. C'est donc un guidage très fort en dehors du zoom (et c'est bien pour un modèle très zoomé).