Changes between Version 3 and Version 4 of Documentation/UserGuide/NewGrid
- Timestamp:
- 2020-02-28T16:47:07+01:00 (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Documentation/UserGuide/NewGrid
v3 v4 1 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.2 1 3 1) Make sure the grid is stable 4 2) Make sure the climate on the grid is realistic. 2 == What is important to know about using a new LMDZOR grid ? == 3 4 Author: M. !McGrath[[BR]] 5 Last revision: 2020/02/28, J. Lathière[[BR]] 6 7 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. 8 9 10 1) Make sure the grid is stable[[BR]] 11 2) Make sure the climate on the grid is realistic. 5 12 6 13 Step (2) is covered on a different page of the Wiki, so I'll just talk about (1) here. … … 8 15 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). The latest I've had a crash was in month 37. 9 16 10 == Timestep==17 === Timestep === 11 18 12 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.19 If you are not nudging (for a zoomed grid, you should nudge at least the winds), the first parameter to adjust is the timestep.[[BR]] 13 20 14 iphysiq (lmdz.driver, or PARAM/gcm.def_*, depending on the physics you are using) 15 day_step (PARAM/gcm.def_*) 16 nsplit_phys (PARAM/physiq.def_*) 21 There are three distinct variables to adjust for this. 17 22 18 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. 23 - '''iphysiq''' (lmdz.driver, or PARAM/gcm.def_*, depending on the physics you are using)[[BR]] 24 - '''day_step''' (PARAM/gcm.def_*)[[BR]] 25 - '''nsplit_phys''' (PARAM/physiq.def_*) 19 26 20 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).27 '''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. 21 28 22 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. 29 '''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). 30 31 '''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. 23 32 24 33 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. 25 34 26 Some guidelines by Frédéric: 35 === Some guidelines by Frédéric: === 27 36 28 37 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. 29 38 30 == Nudging==39 === Nudging === 31 40 32 41 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 33 42 34 tetagrot 35 tetagdiv 36 tetatemp 43 - '''tetagrot'''[[BR]] 44 - '''tetagdiv'''[[BR]] 45 - '''tetatemp''' 37 46 38 47 These three parameters control the rate of dissipation. Apparently with smaller grid cells for the zoom, one can dissipate more. The default value for all three parameters was 5400, but Frédéric suggested to reduce it to 1200. This seemed to work, although he said even 600 would probably be okay.
