Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

WRF wrror when changing ZR value using SLUCM

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

L

Lucien_7

New member
Hi WRF team. I am currently experiencing a problem when I try running sf_urban=1 with some localization change of the URBPARM.PBL

When I change the default ZR value from 10 to 30 or higher, the WRF.exe is not able to run with an error saying "ZDC + Z0C + 2m is larger than the 1st WRF level，Stop in subroutine urban - change ZDC and Z0C". The WRF version is 3.8.1.
I understand the meaning of ZDC and Z0C are as below,

roughness for momentum above the urban canopy layer, Z0C

zero-displacement height above the urban canopy layer, ZDC

But I have no idea how to deal with this problem and I guess the best solution is not to change Z0C and ZDC, as the I am trying to simulate for higher buildings

Thank you so much in advance for your reply and Help,should there be anything needed like more details, please do let me know

Best
 
Dear all,

I am quite new to using WRF and also a new member of this form, so I say hi to all of you and hope that you can help me out!

I am responding to this post, as I am facing the same problem. I currently use WRF V4.15 and I also have some larger values of ZR in the URBPARM.TBL.

With basic discretization settings, I immediately run into the same error message:

Code: 
ZDC + Z0C + 2m is larger than the 1st WRF level

I checked the values of these variables:

Code: 
ZA:   24.5644493
ZDC:   27.3034573
Z0C:   2.64814997

What I tried is to increase the height of the first WRF level from the default value 50 m to 70 m with the following entry in namelist.input:

Code: 
dzbot = 70

Now the simulation runs, but always crashes at a later time with a segmentation fault:

Code: 
Timing for main: time 2010-06-21_01:16:12 on domain   2:    6.23900 elapsed seconds

Program received signal SIGSEGV: Segmentation fault - invalid memory reference. 

Backtrace for this error: 

#0  0x7F6796EC3E08 
#1  0x7F6796EC2F90 
#2  0x7F67965F44AF 
#3  0x247714B in __module_cu_kfeta_MOD_tpmix2 
#4  0x247A33D in __module_cu_kfeta_MOD_kf_eta_para 
#5  0x248DD5D in __module_cu_kfeta_MOD_kf_eta_cps 
#6  0x1EEC8DA in __module_cumulus_driver_MOD_cumulus_driver 
#7  0x16E57A5 in __module_first_rk_step_part1_MOD_first_rk_step_part1 
#8  0x11FC78A in solve_em_ 
#9  0x10B0022 in solve_interface_ 
#10  0x4713D5 in __module_integrate_MOD_integrate 
#11  0x4719B6 in __module_integrate_MOD_integrate 
#12  0x407B93 in __module_wrf_top_MOD_wrf_run

If I change sf_urban_physics to 0, 2 or 3, everything works fine. It just does not work with the SLUCM. I am now wondering, if there are restrictions on using the SLUCM model with higher buildings or if you just have to change any other discretization settings.

Does anyone of you have advice on how to configure WRF with the SLUCM?

Best regards,
Julian
 
Hi,
Take a look at this previous forum post and see if it helps at all:
https://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=40&t=8336&p=14184&hilit=ZDC#p14184
 
Hi kwerner,

thanks a lot for your quick response. I have already read this post as well and it solves the problem with WRF 1st layer thickness. I guess my solution of setting the namelist option dzbot=70 leads to a similar result, as it supposedly sets the first layer thickness while the remaining layer heights are still automatically set. And this seems to work. My problem now is that the SLUCM still does not run and always crashes with a segmentation fault at later times during calculation of clouds or radiation. That is why I was wondering, if the increased first layer thickness leads to other problems or if there is anything else that I don't see.
 
Hi,
It's really hard to say if that's what's causing the segmentation fault. I would recommend trying to compile the code with debugging turned on. (configure -D) and see if you can get any better prints in the rsl.* files indicating where the model is stopping.
 
You must log in or register to reply here.
Top