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?
 
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...
i see these things in the namelist, could this be the source?

Code: 
 sf_surface_physics                  = 2, 2, 4,
 
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.
 
zhanyx said:
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.
Click to expand...
And all the static geography files are downloaded? There's quite a few
 
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.
 
zhanyx said:
Many thanks for your assistance, and apologies for the bother. May I ask if there has been any progress from the urban physics expert?
Click to expand...
Hi, I just checked and the physics expert is out of the office through next week, so hopefully they will be able to respond when they return. If it delays much longer than that, please ping me again to remind me to nudge them. I apologize for the inconvenience and thank you for your patience.
 
kwerner said:
Hi, I just checked and the physics expert is out of the office through next week, so hopefully they will be able to respond when they return. If it delays much longer than that, please ping me again to remind me to nudge them. I apologize for the inconvenience and thank you for your patience.
Click to expand...
Thank you so much for your continued attention to this issue!
 
kwerner said:
Hi, I just checked and the physics expert is out of the office through next week, so hopefully they will be able to respond when they return. If it delays much longer than that, please ping me again to remind me to nudge them. I apologize for the inconvenience and thank you for your patience.
Click to expand...
Apologies for bothering you again – any updates on this?
 
zhanyx said:
Apologies for bothering you again – any updates on this?
Click to expand...
No worries at all. I'm glad you reminded me. I reached out to the physics expert again and he's going to look at this sometime this week. Thank you again for your patience while we wait.
 
Hi there, here are the answers to your questions:
1. your namelist.wps looks good. Please double check if there is any unrealistic values (e.g., NaN or -9999) in your wrfinput_d* file for those urban parameter values particularly those updated by yourself.
2. The "slucm_distributed_drag = .false." should work, which is the default setting for WRF.
3. I am using Macbook which cannot uncompress your rsl_error.tar files. What is your error message (can you copy and paste the error message directly here)? One thing to double check: because you are using SLUCM (urban physics=1), make sure that your bottom atmos layer thickness is higher than the highest building roof top in your domain.
4. Have you tried changing other physics option such as use radiation scheme = 4, change PBL scheme, etc.?
 
kwerner said:
No worries at all. I'm glad you reminded me. I reached out to the physics expert again and he's going to look at this sometime this week. Thank you again for your patience while we wait.
Click to expand...
Apologies for the delayed response; it seems my email had a problem and I didn’t receive the notification. Thank you for all your continued help.
 
cenlinhe said:
Hi there, here are the answers to your questions:
1. your namelist.wps looks good. Please double check if there is any unrealistic values (e.g., NaN or -9999) in your wrfinput_d* file for those urban parameter values particularly those updated by yourself.
2. The "slucm_distributed_drag = .false." should work, which is the default setting for WRF.
3. I am using Macbook which cannot uncompress your rsl_error.tar files. What is your error message (can you copy and paste the error message directly here)? One thing to double check: because you are using SLUCM (urban physics=1), make sure that your bottom atmos layer thickness is higher than the highest building roof top in your domain.
4. Have you tried changing other physics option such as use radiation scheme = 4, change PBL scheme, etc.?
Click to expand...
Thank you for your reply. Sorry for the late response – it took me some time to run a few tests based on your suggestions. Below are my replies regarding your suggestions.

  1. I checked all urban variables in wrfinput.d0x, and there are no negative values or NaNs, nor any extremely unreasonable values. In addition, based on my attempts in WRF DEBUG mode, for grid cells where the building standard deviation is 0 or the planar area index is less than 0.01, I changed LU_INDEX and IVGTYP from 13 to 12 in order to resolve possible mismatches between UCPs and the land use data, but this did not solve the problem.
  2. I have repackaged the error messages into a zip file and attached it to this reply. Among them, 0047, 0054, and 0055 have segmentation faults, and the tail of rsl.error.0047 is pasted below.
  3. I set dzbot to 200 to resolve the ZDC+Z0C+2m > ZA error.
  4. I tried changing some parameterization options, including mp_physics, ra_lw/sw_physics, and bl_pbl_physics. The situation changed somewhat. Previously, the model would crash on the first time step, but now the segmentation fault occurs after the model runs for a certain period, and it still cannot output the first hour's wrfout file. The namelist I am currently using is also attached to this reply.
Note: I am currently using WRF4.7.1, and I have added the BW and SW initialization code as suggested in post #2.

Thank you again for your help, and I look forward to your reply.

rsl.error.0047

d01 2018-07-22_00:00:00 Input data is acceptable to use:
d01 2018-07-22_00:00:00 Input data processed for aux input 4 for domain 1
d01 2018-07-22_00:00:00 Input data is acceptable to use:
Tile Strategy is not specified. Assuming 1D-Y
WRF TILE 1 IS 97 IE 115 JS 80 JE 93
WRF NUMBER OF TILES = 1
d01 2018-07-22_00:00:00 ----------------------------------------
d01 2018-07-22_00:00:00 W-DAMPING BEGINS AT W-COURANT NUMBER = 1.000000
d01 2018-07-22_00:00:00 ----------------------------------------
mediation_integrate.G 1249 DATASET=HISTORY
mediation_integrate.G 1250 grid%id 2 grid%oid 3
Tile Strategy is not specified. Assuming 1D-Y
WRF TILE 1 IS 81 IE 96 JS 78 JE 90
WRF NUMBER OF TILES = 1
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
wrf.exe 0000000002F9B122 for__signal_handl Unknown Unknown
libpthread-2.28.s 00001553F1924CE0 Unknown Unknown Unknown
wrf.exe 0000000002263B1E Unknown Unknown Unknown
wrf.exe 000000000226053D Unknown Unknown Unknown
wrf.exe 0000000002B5F6DC Unknown Unknown Unknown
wrf.exe 0000000002114717 Unknown Unknown Unknown
wrf.exe 0000000001755452 Unknown Unknown Unknown
wrf.exe 00000000010E4A56 Unknown Unknown Unknown
wrf.exe 0000000000F574AE Unknown Unknown Unknown
wrf.exe 000000000042CBFF Unknown Unknown Unknown
wrf.exe 000000000042D22C Unknown Unknown Unknown
wrf.exe 0000000000412F77 Unknown Unknown Unknown
wrf.exe 0000000000412B93 Unknown Unknown Unknown
wrf.exe 0000000000412B22 Unknown Unknown Unknown
libc-2.28.so 00001553F1587CF3 __libc_start_main Unknown Unknown
wrf.exe 0000000000412A2E Unknown Unknown Unknown
 

Attachments

You must log in or register to reply here.
Back
Top