[WRF-UCM] Simulation crashes with NaN temperature and segmentation fault

[ZHOU Wan]

Hello everyone,

I’m running WRF v4.6.1 with the Urban Canopy Model (UCM) enabled, using the MODIFIED_IGBP_MODIS_NOAH land use classification and experiencing simulation crashes due to NaN temperature and a segmentation fault error.

Warning messages in `rsl.error.0000`:

```
WARNING, FRC_URB2D = 0 BUT IVGTYP IS URBAN
WARNING, THE URBAN FRACTION WILL BE READ FROM URBPARM.TBL
USING DEFAULT URBAN MORPHOLOGY
```

Later during the simulation, it crashes with:

```
WARN5: NaN temperature; I,J,L,P= 196 35 1
forrtl: severe (174): SIGSEGV, segmentation fault occurred
```


My Questions:

1. Could the NaN temperature and segmentation fault be caused by `FRC_URB2D = 0` even though `IVGTYP = URBAN`?
I’m aware that this can lead to issues when urban physics is turned on. I’m using the default `URBPARM.TBL`.


2. Could this issue be related to incompatibility between my physics settings and the urban model (SLUCM)?
The model runs fine when I disable `sf_urban_physics`, but I need urban modeling for my study.

Any guidance on how to resolve this issue or what else to check would be greatly appreciated. Thank you in advance!



PS: Key `namelist.input` Settings as following:
&domains
time_step = 30,
time_step_fract_num = 0,
time_step_fract_den = 1,
max_dom = 3,
e_we = 307, 439, 79,
e_sn = 311, 451, 121,
e_vert = 45, 45, 45,
dzstretch_s = 1.2
eta_levels = 1.000, 0.955, 0.940, 0.925, 0.910, 0.900,
0.875, 0.850, 0.825, 0.800, 0.775, 0.750,
0.725, 0.700, 0.675, 0.650, 0.625, 0.600,
0.575, 0.550, 0.525, 0.500, 0.475, 0.450,
0.425, 0.400, 0.375, 0.350, 0.325, 0.300,
0.275, 0.250, 0.225, 0.200, 0.175, 0.150,
0.125, 0.100, 0.075, 0.050, 0.040, 0.030,
0.020, 0.010, 0.000
p_top_requested = 5000,
num_metgrid_levels = 38,
num_metgrid_soil_levels = 4,
dx = 9000, 3000, 1000,
dy = 9000, 3000, 1000,
grid_id = 1, 2, 3,
parent_id = 1, 1, 2,
i_parent_start = 1, 81, 201,
j_parent_start = 1, 81, 201,
parent_grid_ratio = 1, 3, 3,
parent_time_step_ratio = 1, 3, 3,
feedback = 1,
smooth_option = 1,
/

&physics
physics_suite = 'CONUS'
mp_physics = 5, 5, 5,
cu_physics = 1, 0, 0,
ra_lw_physics = 1, 1, 1,
ra_sw_physics = 1, 1, 1,
bl_pbl_physics = 7, 7, 7,
sf_sfclay_physics = 1, 1, 1,
sf_surface_physics = 2, 2, 2,
radt = 10, 10, 10,
bldt = 10, 10, 10,
cudt = 5, 0, 0,
icloud = 1,
num_land_cat = 61,
num_soil_layers = 4,
sf_urban_physics = 1, 1, 1,
! sf_urban_physics = 0, 0, 0,
sf_surface_mosaic = 1,
mosaic_cat = 3,
slucm_distributed_drag = .false.,
use_wudapt_lcz = 1,
distributed_ahe_opt = 2,
/

 

[ZHOU Wan]

This is a follow-up to a previous post I made regarding a NaN temperature and segmentation fault issue when running WRF with urban physics enabled.

I've now visualized the error grid points (where NaN temperature occurs), and interestingly, all the problematic grid cells are located near the nested domain boundaries, as shown in the figure below:



These points correspond to: (i, j) = (240, 168) (i, j) = (433, 282) (i, j) = (435, 383) (i, j) = (435, 399)

This leads me to suspect the issue may be related to the interaction between the nested domain and urban physics.


PS: I’m using the Single-Layer Urban Canopy Model (SLUCM):

sf_urban_physics = 1

The model runs successfully when urban physics is disabled.

However, when I enable `sf_urban_physics = 1`, the model crashes after a few days with:

WARN5: NaN temperature at I,J,L = (x, y, z)
forrtl: severe (174): SIGSEGV, segmentation fault

Could this issue be due to incompatibility between my physics settings and the urban module (SLUCM) near the nest boundaries?

 

[cenlinhe]

Hi, to answer your questions:
1. if IVGTYP=urban but FRC_URB=0, the model will automatically use the urban fraction value from URBPARM.TBL, so this will not be a problem.
2. This could be an issue related to physics incompatibility (particularly PBL). You may want to try changing PBL scheme to YSL or MYJ.
3. It may also related to the vertical layer thickness (too low) for the bottom atmos layer. You may want to try increasing your bottom atmos layer thickness.