WRF timestep problem

ffrntic

New member
Hello everyone,

I am trying to run WRF v4.5.2 with four nested domains (27 km, 9 km, 3 km and 1 km) for an 8-day simulation (20–28 July 2022) using ERA5 boundary conditions.

With my original configuration (outer-domain time_step = 45 s), the model consistently stops at approximately the same model time (2022-07-20 08:54), regardless of whether I use 16, 24 or 32 MPI processes. In all cases, the model terminates in the microphysics routine with the following message:

** STOPPING IN MICROPHYSICS: (Part 2, end) **<br>** i,k,T [K]: 20 24 -381.133240<br>

I then started reducing the outer-domain timestep. A single-domain (27 km) simulation eventually completed successfully for the entire period (20–28 July 2022), but only after reducing the outer-domain timestep to 15 s. I am currently testing the three nested domains configuration with the same timestep, and so far it has progressed well beyond the previous crash point.

What surprises me is that a 15 s timestep seems extremely small for a 27 km outer domain. Most recommendations suggest much larger values (e.g. around 6 × dx), so I suspect there may be another underlying issue rather than the timestep itself.

My model uses WRF v4.5.2 with four nested domains (27/9/3/1 km) and 196 vertical levels.

I have attached my namelist.input, rsl.out.0000, rsl.out.0021 (where the microphysics error occurs), and rsl.error.0021.

Has anyone encountered a similar problem or has any suggestions on what might be causing the need for such a small timestep? Are there any diagnostics or namelist options that you would recommend checking?

Thank you very much for any suggestions.
 

Attachments

Hi, There are a few things that could be causing your need to use a smaller timestep.
1. If your domain is over complex terrain - see additional information in Segmentation Faults and CFL Errors
2. I notice you're using a pretty low model top (p_top_requested = 10000). Is there a reason you need to use this value, instead of the default value of 5000? If it's possible, try setting it to 5000 and see if that makes any difference.
3. Does this issue happen if you use the model-designated eta levels, instead of using your own?
 
Back
Top