Error about CFL

[sophiazjjj]

I have completed a 5-nested simulation with resolutions of 12150-4050-1350-450m-150m using WRF 4.0, and used ndown to make the driving file for 50m. However, when continuing the simulation with 50m resolutions, I encountered "Segmentation fault" in module_sf_sfclay. I have already reduced the time step to 2/375 seconds, set epssm = 0.5 and set w_damping=1.
I checked the wrfout and found abnormally large vertical velocity values at the boundaries：


It is also worth noting that I do not encounter this error when running a 6-nested simulation together and it can run successfully.

How can I resolve this issue? Hope someone can help me.

d01 2024-09-24_21:17:12+**/** 1 points exceeded cfl=2 in domain d01 at time 2024-09-24_21:17:12+**/** hours
d01 2024-09-24_21:17:12+**/** MAX AT i,j,k: 8 259 80 vert_cfl,w,d(eta)= 2.735555 163.9140 1.5949000E-02
d01 2024-09-24_21:17:12+**/** 11 points exceeded cfl=2 in domain d01 at time 2024-09-24_21:17:12+**/** hours
d01 2024-09-24_21:17:12+**/** MAX AT i,j,k: 8 259 80 vert_cfl,w,d(eta)= 4.341385 138.5703 1.5949000E-02
[a3411n12:59035:0:59035] Caught signal 11 (Segmentation fault: address not mapped to object at address 0xfffffffe15e229c0)
==== backtrace (tid: 59035) ====
0 0x0000000000050b35 ucs_debug_print_backtrace() ???:0
1 0x0000000002cc91c1 module_sf_sfclayrev_mp_psim_stable_() ???:0
2 0x0000000002cc4734 module_sf_sfclayrev_mp_sfclayrev1d_() ???:0
3 0x0000000002cc2333 module_sf_sfclayrev_mp_sfclayrev_() ???:0
4 0x000000000258ccf3 module_surface_driver_mp_surface_driver_() ???:0
5 0x0000000001c1a409 module_first_rk_step_part1_mp_first_rk_step_part1_() ???:0
6 0x0000000001557e07 solve_em_() ???:0
7 0x00000000013f7ed0 solve_interface_() ???:0
8 0x0000000000582b93 module_integrate_mp_integrate_() ???:0
9 0x0000000000411b91 module_wrf_top_mp_wrf_run_() ???:0
10 0x0000000000411b4f MAIN__() ???:0
11 0x0000000000411ae2 main() ???:0
12 0x00000000000223d5 __libc_start_main() ???:0
13 0x00000000004119e9 _start() ???:0

 

[Ming Chen]

CFL violation indicates that the model is numerically unstable. Usually we can suppress the instability by:
(1) turn on w_dampling
(2) reduce time_step
(3) increase epss up to 1.0

Your case is special because it is of extremely high resolution. At the 50m resolution, the model would run in large-eddy mode. I am not sure how you provide lateral forcing for this case?

 

[sophiazjjj]

Thanks for your suggestion, but I have try all the three settings.

To provide lateral forcing:
1. I first run a 5-nested simulation with resolutions of 12150-4050-1350-450m-150m,
2. then use wrfout of 150m resolution to ndown and make wrfbdy
3. use wrfbdy to provide lateral boundaries for 50m resolution

CFL violation indicates that the model is numerically unstable. Usually we can suppress the instability by:
(1) turn on w_dampling
(2) reduce time_step
(3) increase epss up to 1.0

Your case is special because it is of extremely high resolution. At the 50m resolution, the model would run in large-eddy mode. I am not sure how you provide lateral forcing for this case?

 

[Ming Chen]

The approach looks reasonable. However, for such a high resolution run, we actually don't have many experiences how the model behaves. Note that many physics schemes are developed for resolution scales from a few km to several tens of km.

I would suggest that you recompile WRF in debug mode, then rerun this case. The log file will tell exactly when and where the model crashes first, which may give you some hints what is wrong.

 

[sophiazjjj]

The approach looks reasonable. However, for such a high resolution run, we actually don't have many experiences how the model behaves. Note that many physics schemes are developed for resolution scales from a few km to several tens of km.

I would suggest that you recompile WRF in debug mode, then rerun this case. The log file will tell exactly when and where the model crashes first, which may give you some hints what is wrong.

I have already run in debug mode.
It indicates that the issue was caused by CFL instability of sf_sfclay_physics.

Is there any other approach to limit W.
And I checked the wrfbdy, all the values of W in wrfbdy are 0. Is it reasonable? If not, how should I do?

 

[Ming Chen]

The time step is already very small, and I don't think further reduction can help for this case.

w-damping is the option we use to suppress violent vertical velocity. Again, this option seems not sufficient enough.

W == 0 in wrfbdy is expected. However, note that this is for handling large scale forcing data at several tens of km resolution.

Sorry that I don't have an immediate answer how to make it work for your case. As I stated previously, WRF is designed for mesoscale simulation and it does have limitations in extremely high resolution simulation.