Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Instability from MYM_TURBULENCE2.5


New member
I am trying to run forecasts at a uniform 10 km with time step sizes of 50 or 60 seconds. However, the job kept being terminated by something related to MYNN without complaints inside the log file. Some clues can be found in the stdout. The log files are attached. I am wondering whether there are any remedies to this type of issue. Thanks in advance!


  • log.atmosphere.0000.out.txt
    573.1 KB · Views: 4
From your log file it looks like you have 93 vertical layers / 94 vertical levels:
----- reading dimensions from stream 'input' using file
nVertLevels = 93
nCells = 5898242
nEdges = 17694720
nVertices = 11796480
TWO = 2
maxEdges = 6
maxEdges2 = 12
R3 = 3
vertexDegree = 3
nVertLevelsP1 = 94
nMonths = 12
nSoilLevels = 4
Do you see the same issues if you use the default 55 levels?
55 vertical levels did solve it. Does that mean I am setting up too many vertical levels? Is there any formula about the number of vertical levels to be configured?
Unfortunately, I'm not very knowledgeable when it comes to vertical level configuration. I'll ask around to see if there's someone else who may be able to provide some advice, here.

Are you increasing the number of levels by simply setting config_nvertlevels = 94 and letting the init_atmosphere_model program set the level heights, or are you explicitly providing a list of layer interface heights with the config_specified_zeta_levels option? If you're letting the init_atmosphere_model program set the level heights, what model top have you specified with config_ztop?
I am simply tweaking the number of vertical levels (config_nvertlevels). The ztop has been left as default of 30 km. It turns out that this uniform 10km job can run stably with up to 90 levels. Please keep me posted about the recommended vertical level configurations.
I suspect that the problem is that the layers are getting much thinner in the boundary layer, and this is leading to the instability. There is not anything in the log file that directly points to the MYNN scheme. What information about the run points to MYNN problems? Also, are you running version 7?
Yes, I am running with version 7.1.
I am picking on MYNN because in the stdout I am getting messages as below before the job gets terminated. It turns out this message came from the print statements inside module_bl_mynn.F. I

MYM_TURBULENCE2.5: k= 2 sh= 0.3596995
gm= 3.586290 gh= -5.3543845E-05 sm= 0.2661836
q2sq= 1104.81143922880 q3sq= 651.371643066406 q3/q2=
qke= 1309.350 el= 6.085057 ri= 1.4930150E-05
PBLH= 169.2779 u= -14.66846 v= 11.43934
Flerchinger USEd in NEW version. Iterations= 10
Flerchinger USEd in NEW version. Iterations= 10
Flerchinger USEd in NEW version. Iterations= 10
Flerchinger USEd in NEW version. Iterations= 10

Generally, the stdout is silent if the job can successfully run to the end. Does it suggest that I should manually specify vertical level locations to keep the near-surface layers from getting too thin? Thanks in advance!
The last 4 lines are from the NOAH LSM, but I expect the LSM might not be happy with something coming from the MYNN scheme.
I think it would be best for you to design a vertical grid with higher resolution where you want it to be while making sure the vertical grid spacing is not too small over the first 5+ layers.