Segmentation fault in WRF 4.7.1 with WPS 4.6 and new urban datasets

Z

zhanyx

New member
Dear WRF community,

I am running WRF 4.7.1 with WPS 4.6, and I have incorporated the updated URB_PARM, FRC_URB2D, and IMPERV data from WPS 4.7. In addition, I added datasets in the geo directory so that MH_URB2D, BUILD_AREA_FRACTION, and LF_URB2D_S are taken from the GloUCP dataset.

When I start wrf.exe, I immediately get a segmentation fault. The model only produces the first output file (wrfout_d01_2018-07-22_00:00:00) and then crashes.

However, if I set slucm_distributed_drag = .true. in the namelist.input, the model runs successfully to completion.

I have already tried adjusting the time step (2dx, 3dx, 6dx) and changing the simulation start date, but none of these resolved the crash.

How can I fix the segmentation fault when slucm_distributed_drag is set to .false.? Any insights, debugging suggestions, or similar experiences would be greatly appreciated. Thank you in advance for your help!

Best regards
 

Attachments

Hi, can you try a small code modification to see if it changes anything? In the file WRF/phys/module_sf_urban.F, right above line 649:
Code: 
if (mh_urb.gt.0.0 .and. .not. distributed_aerodynamics_option) THEN

add the following 2 lines to initialize the BW and SW variables, so that it now reads:
Code: 
BW = 0.0
SW = 0.0
if (mh_urb.gt.0.0 .and. .not. distributed_aerodynamics_option) THEN

After this, recompile WRF - no need to clean the code or reconfigure. Just simply recompile, which should be much faster than a full recompile. Then run this again with slucm_distributed_drag = .false. and let me know if you're able to get past the immediate seg-fault.

Aside from that issue, here are a couple other suggestions:

1. Your domains are a bit too small. Domains should not be smaller than 100x100 grid spaces. Read Why domains should be at least 100x100 grid spaces for details.

2. Depending on the resolution of your input data, your domain resolution of 1000x1000 may be too fine, compared to your input data. Check to make sure the resolution of the input data is not much larger than about 5 km. If it is, you may need to consider adding a parent domain to buffer the resolution difference between the input data and your 1-km resolution domain. See this page (specifically the dx/dy settings) for details.
 
kwerner said:
Hi, can you try a small code modification to see if it changes anything? In the file WRF/phys/module_sf_urban.F, right above line 649:
Code: 
if (mh_urb.gt.0.0 .and. .not. distributed_aerodynamics_option) THEN

add the following 2 lines to initialize the BW and SW variables, so that it now reads:
Code: 
BW = 0.0
SW = 0.0
if (mh_urb.gt.0.0 .and. .not. distributed_aerodynamics_option) THEN

After this, recompile WRF - no need to clean the code or reconfigure. Just simply recompile, which should be much faster than a full recompile. Then run this again with slucm_distributed_drag = .false. and let me know if you're able to get past the immediate seg-fault.

Aside from that issue, here are a couple other suggestions:

1. Your domains are a bit too small. Domains should not be smaller than 100x100 grid spaces. Read Why domains should be at least 100x100 grid spaces for details.

2. Depending on the resolution of your input data, your domain resolution of 1000x1000 may be too fine, compared to your input data. Check to make sure the resolution of the input data is not much larger than about 5 km. If it is, you may need to consider adding a parent domain to buffer the resolution difference between the input data and your 1-km resolution domain. See this page (specifically the dx/dy settings) for details.
Click to expand...
Thank you very much for your reply.

Following your suggestion, I modified module_sf_urban.F and recompiled the code, but I still encounter an immediate segmentation fault. I also adjusted the domain settings, yet the crash persists. In addition, I tested using cglc_modis_lcz as the landuse dataset, but that did not resolve the issue either.

Could the problem be caused by a mismatch between the landuse data and URB_PARAM, FRC_URB2D, IMPERV data? Are there any other approaches I could try to diagnose or fix this crash?

I would greatly appreciate any further suggestions or debugging strategies you might have.

Thank you in advance for your time and help.

Best regards
 

Attachments

Thanks for trying those things. I'm going to request help from our urban physics expert when they're able. Hopefully they will be able to provide some guidance.
 
kwerner said:
Thanks for trying those things. I'm going to request help from our urban physics expert when they're able. Hopefully they will be able to provide some guidance.
Click to expand...
Many thanks for your assistance, and apologies for the bother. May I ask if there has been any progress from the urban physics expert?
 
William.Hatheway said:
i see these things in the namelist, could this be the source?

Code: 
 sf_surface_physics                  = 2, 2, 4,
Click to expand...
Thank you for your reply. Since max_dom is set to 2, I removed the last column from all namelist parameters that originally had three entries, but the immediate segmentation fault still occurs.
 
William.Hatheway said:
And all the static geography files are downloaded? There's quite a few
Click to expand...
I believe so. I am using WPS4.6/geogrid/GEOGRID.TBL.ARW. The geogrid.log shows that all variables were processed successfully except for AHE, but since I have not enabled distributed_ahe_opt, that variable should not be used anyway.
 
You must log in or register to reply here.
Back
Top