meteoadriatic
Member
Hi, from all tests you have done, at this point, I would be pretty surprised if it comes out that the reason for simulation failures is not the PBL choice. It seems we will know soon 
Good luck!
Good luck!
Segmentation fault RRTMG with adaptive time step.
- Thread starter Manuarii
- Start date
Hi Meteoadriatic,Hi, from all tests you have done, at this point, I would be pretty surprised if it comes out that the reason for simulation failures is not the PBL choice. It seems we will know soon
I’ve been trying to use the YSU scheme as the PBL parameterization, but WRF continues to stop unexpectedly without any clear explanation. The simulation halts without generating a segmentation fault or a similar error. Below is an excerpt from the rsl.error file showing the output just before it stops.
The only way I’ve managed to make it work is by further reducing the target CFL value. For example, with target_cfl = 0.2, the simulation stops at 2017-02-20_08:38:37. If I set target_cfl to 0.5, it stops immediately after reaching 2017-02-20_02:00:00. So I keep same parameter for adaptive time step as previous test.
Timing for main (dt= 0.12): time 2017-02-20_08:38:37 on domain 5: 0.06947 elapsed seconds
d05 2017-02-20_08:38:37+**/** Top of Radiation Driver
Timing for main (dt= 0.12): time 2017-02-20_08:38:37 on domain 5: 0.05946 elapsed seconds
d05 2017-02-20_08:38:37+**/** Top of Radiation Driver
...
Timing for main (dt= 0.03): time 2017-02-20_08:38:37 on domain 5: 0.07061 elapsed seconds
d05 2017-02-20_08:38:37+**/** Top of Radiation Driver
Here is the only thing I change in namelist.input :
bl_pbl_physics = 1, 1, 1, 1, 1,
sf_sfclay_physics = 1, 1, 1, 1, 1,
Since the simulation always stops right after showing "Top of Radiation Driver," I suspect the issue might be related to the radiation scheme. Could you confirm if this is indeed the case?
Also, do you think YSU is a suitable choice for simulations at a 1/9 km resolution? It seems to me that it is a good and straightforward PBL parameterization. For reference, I change the sf_sfclay_physics setting when switching to YSU.
Thanks for your help!
meteoadriatic
Member
Hello,
Well, I'm surprised to hear this.
I'm not sure that radiation scheme is the source of the problem; might be but also might not - it might crash because of unrealistic state of the model at that particular point in time. And that is the way to go with debugging I think. Can you set wrfout frequency so that it dumps model state right before the crash, the closer to the crash, the better, and then look into it and see if there is anything unrealistic? That might guide you toward the solution.
For such small grids, instead of YSU, you would probably be better with scale aware schemes (Shin-Hong or SMS-3DTKE) or LES setup.
Well, I'm surprised to hear this.
I'm not sure that radiation scheme is the source of the problem; might be but also might not - it might crash because of unrealistic state of the model at that particular point in time. And that is the way to go with debugging I think. Can you set wrfout frequency so that it dumps model state right before the crash, the closer to the crash, the better, and then look into it and see if there is anything unrealistic? That might guide you toward the solution.
For such small grids, instead of YSU, you would probably be better with scale aware schemes (Shin-Hong or SMS-3DTKE) or LES setup.
Hi Meteoadriatic,
After modifying the frequency while keeping YSU as the PBL scheme, I noticed an unusual pattern in most variables (T2, P, W, U, V). Specifically, there’s a localized spot showing significantly higher values for W. This typically occurs near the highest summit in my third domain, where the slope appears to be quite steep.
To address this, I’m planning to directly smooth the topography in that area, especially around this location, and observe the results.
meteoadriatic
Member
Hello,
Oh, in that case the too steep slope could very likely be the cause of crashes and smoothing will help!
Oh, in that case the too steep slope could very likely be the cause of crashes and smoothing will help!
Hi,
I conducted tests using my 3-domain setup (not yet with 5 domains), reintroducing the Corine Land Cover instead of the default USGS land use classes. However, this change does not seem to improve performance when using the QNSE PBL parameterization. With the YSU scheme, the simulation runs for a few hours before stopping. As I mentioned previously, YSU does not produce any errors in the rsl.error log, unlike the usual segmentation fault encountered with RRTMG. Instead, the simulation stops without providing additional information.
Next, I plan to run tests with my standardized case using the 5-domain configuration and the default USGS land use classes to gain better insight into the issues. This is on that, that I make all my test from the beginning of the discussion on the post.
It’s also worth noting that the smoothing applied to the topography reveals that steep slopes are rare. The smoothing was necessary to reduce slopes in the range of 25–30 degrees. Upon calculating the slopes in the inner domains, I observed that the steepest slope reaches 35 degrees and is very localized to a small area.
I’ll proceed as mentioned with the standardized case and report back.