LIGHTNING PARAMETERIZATION BUGS(?)

Post here if you think you might have found any type of bug

LIGHTNING PARAMETERIZATION BUGS(?)

Postby thgian » Thu Apr 10, 2014 4:47 am

Dear WRF users and developers,

I would like to make you all aware of two (2) potential bugs that we have came across in WRF version 3.5.1.

The first possible bug (we are still looking into it) is related to the implementation of the lightning parameterization (Wong et al., 2013, based on Price and Rind, 1992, 1993, 1994). More specifically, the bug appears when one selects the option for partitioning lightning based on Price and Rind (1993) (cold-cloud depth; iccg_method = 3). In that case, the implementation of any of the available lightning schemes results to irregularly distributed NaNf values of the variable CG(or IC)_FLASHCOUNT across the domain of interest. When using any other iccg_method, results seem to be reasonable.

The second potential bug, possibly related to the first one, has to do with the implementation of the proposed by Wong et al. (2013) methodology for adjusting the model-resolved level of neutral beyoancy (LNB) in order to derive the cloud-top height and, consequently, compute flash rates. Following Wong et al. (2013), the model-resolved LNB should be reduced by 2 km (cldtop_adjustment = 2). However, looking through the physics code of WRF, we noticed that, contrary to the above, LNB is increased by 2 km. Based on some preliminary test runs we have had performed, we found that if we set cldtop_adjustment = 0, flash rates produced by WRF are significantly reduced as it would be expected by reducing the LNB (also stated in Wong et al., 2013). On the other hand, if we keep cldtop_adjustment = 2 we get too much lightning which suggests overprediction of cloud-top height (greater cloud-top heights, more lightning, to put it simply). Hence, we suspect that this is a bug in the WRF code where instead of subtracting cldtop_adjustment, this is actually added to the model-resolved LNB.

To summarize, if anyone else has had any similar experience with the lightning schemes, just let me know. I am currently working on the above-mentioned issues and I will come back as soon as I get cross-checked results for the possible bugs.
thgian
 
Posts: 7
Joined: Tue Mar 10, 2009 5:41 pm

Re: LIGHTNING PARAMETERIZATION BUGS(?)

Postby lynn831018 » Wed Sep 24, 2014 5:53 am

hi thgian,

are you online! Recently I made a numeric model test about a thunderstorm for calculating LPI index (it's a lightning potential index) in the northwest of China using WRFV3.6.1. But the result is very poor. The LPI is zero in second and third grid except mother grid. In my opinion, thunderstorm happened in third grid, so LPI should not equal to zero.I think the lightning parameterization options may be wrong in “namelist.input” file . And the namelist.input setting as follows:
&time_control
run_days = 0,
run_hours = 25,
run_minutes = 0,
run_seconds = 0,
start_year = 2008, 2008, 2008, 2008,
start_month = 06, 06, 06, 06,
start_day = 29, 29, 29, 29,
start_hour = 00, 00, 00, 00,
start_minute = 00, 00, 00, 00,
start_second = 00, 00, 00, 00,
end_year = 2008, 2008, 2008, 2008,
end_month = 06, 06, 06, 06,
end_day = 30, 30, 30, 30,
end_hour = 00, 00, 00, 00,
end_minute = 00, 00, 00, 00,
end_second = 00, 00, 00, 00,
interval_seconds = 21600
input_from_file = .true.,.true.,.true.,.true.,
history_interval = 60, 60, 60, 60,
frames_per_outfile = 1000, 1000, 1000, 1000,
restart = .false.,
restart_interval = 60,
io_form_history = 2
io_form_restart = 2
io_form_input = 2
io_form_boundary = 2
debug_level = 0
/

&domains
time_step = 81,
time_step_fract_num = 0,
time_step_fract_den = 1,
max_dom = 3,
s_we = 1, 1, 1, 1,
e_we = 100, 169, 211, 235,
s_sn = 1, 1, 1, 1,
e_sn = 100, 169, 211, 238,
s_vert = 1, 1, 1, 1,
e_vert = 38, 38, 38,38,
num_metgrid_levels = 27,
dx = 27000, 9000, 3000, 1000
dy = 27000, 9000, 3000, 1000,
grid_id = 1, 2, 3, 4,
parent_id = 1, 1, 2, 3,
i_parent_start = 1, 23, 50, 68,
j_parent_start = 1, 23, 50, 64,
parent_grid_ratio = 1, 3, 3, 3,
parent_time_step_ratio = 1, 3, 3, 3,
feedback = 1,
smooth_option = 0,
num_metgrid_soil_levels = 4,
force_sfc_in_vinterp = 3,
zap_close_levels = 500
sfcp_to_sfcp = .false.
adjust_heights = .false.
eta_levels = 1.000, 0.995, 0.990, 0.985,
0.980,
0.970, 0.960, 0.950, 0.940,
0.930,
0.920, 0.910, 0.900, 0.880,
0.860,
0.830, 0.800, 0.770, 0.740,
0.710, 0.680,
0.640, 0.600, 0.560, 0.520,
0.480,
0.440, 0.400, 0.360, 0.320,
0.280,
0.240, 0.200, 0.160, 0.120,
0.080,0.040,0


&physics
mp_physics = 8, 8, 8, 8,
ra_lw_physics = 1, 1, 1, 1,
ra_sw_physics = 1, 1, 1, 1,
radt = 15, 15, 15, 15,
sf_sfclay_physics = 2, 2, 2, 2,
sf_surface_physics = 2, 2, 2, 2,
bl_pbl_physics = 2, 2, 2, 2,
bldt = 0, 0, 0, 0,
cu_physics = 1, 1, 0, 0,
cudt = 5, 5, 5, 5,
isfflx = 1,
ifsnow = 0,
icloud = 1,
surface_input_source = 1,
num_soil_layers = 4,
num_land_cat = 24,
sf_urban_physics = 0, 0, 0, 0,
topo_wind = 0, 0, 1, 1,
maxiens = 1,
maxens = 3,
maxens2 = 3,
maxens3 = 16,
ensdim = 144,


do_radar_ref = 1,
lightning_option = 3,3,3,3,
lightning_dt = 81,
lightning_start_seconds = 0., 0.,0.,0.,
flashrate_factor = 3.5, 3.5,3.5,3.5,
cellcount_method = 1, 1, 2, 2,
cldtop_adjustment = 2., 2., 2., 2.,
iccg_method = 2, 2, 2, 2,
iccg_prescribed_num = 0.,
iccg_prescribed_den = 1.,
/

&fdda
grid_fdda = 0, 0, 0, 0,
fgdt = 0, 0, 0, 0,
if_no_pbl_nudging_uv = 0, 0, 0, 1,
if_no_pbl_nudging_t = 0, 0, 0, 1,
if_no_pbl_nudging_q = 0, 0, 0, 1,
if_zfac_uv = 0, 0, 0, 1,
k_zfac_uv = 10, 10, 10, 1,
if_zfac_t = 0, 0, 0, 1,
k_zfac_t = 10, 10, 10, 1,
if_zfac_q = 0, 0, 0, 1,
k_zfac_q = 10, 10, 10, 1,
guv = 0.0003, 0.0003, 0.0003, 0.0003,
gt = 0.0003, 0.0003, 0.0003, 0.0003,
gq = 0.0003, 0.0003, 0.0003, 0.0003,
if_ramping = 0,
dtramp_min = 120.0
/

&dynamics
dyn_opt = 2,
rk_ord = 3,
w_damping = 1,
diff_opt = 1,
km_opt = 4,
base_temp = 290.
damp_opt = 0,
zdamp = 5000., 5000., 5000., 5000.,
dampcoef = 0.0, 0.0, 0.0, 0.0,
khdif = 0, 0, 0, 0,
kvdif = 0, 0, 0, 0,
smdiv = 0.1, 0.1, 0.1, 0.1,
emdiv = 0.01, 0.01, 0.01, 0.01,
epssm = 0.1, 0.1, 0.1, 0.1,
non_hydrostatic = .true., .true., .true., .true.,
time_step_sound = 4, 4, 4, 4,
h_mom_adv_order = 5, 5, 5, 5,
v_mom_adv_order = 3, 3, 3, 3,
h_sca_adv_order = 3, 5, 5, 5,
v_sca_adv_order = 2, 3, 3, 3,
moist_adv_opt = 1, 1, 1, 1,
scalar_adv_opt = 1, 1, 1, 1,
/

&bdy_control
spec_bdy_width = 5,
spec_zone = 1,
relax_zone = 4,
specified = .true., .false.,.false.,.false.,
periodic_x = .false.,.false.,.false.,.false.,
symmetric_xs = .false.,.false.,.false.,.false.,
symmetric_xe = .false.,.false.,.false.,.false.,
open_xs = .false.,.false.,.false.,.false.,
open_xe = .false.,.false.,.false.,.false.,
periodic_y = .false.,.false.,.false.,.false.,
symmetric_ys = .false.,.false.,.false.,.false.,
symmetric_ye = .false.,.false.,.false.,.false.,
open_ys = .false.,.false.,.false.,.false.,
open_ye = .false.,.false.,.false.,.false.,
nested = .false., .true., .true.,.true.,
/

&grib2
/

&namelist_quilt
nio_tasks_per_group = 0,
nio_groups = 1,


Could you help me to find the problem? How can I do to get more reasonable result? Thank you very much!

Jianglin
lynn831018
 
Posts: 4
Joined: Tue Dec 04, 2012 5:41 am

Re: LIGHTNING PARAMETERIZATION BUGS(?)

Postby lynn831018 » Wed Oct 15, 2014 10:41 am

hi,
I'm very interested in lightning parameterization scheme. I do some simulated test. But the result of ic and cg are 0. I think my the namelist.input file has problem. the content of namelist.input as follows:

&physics
mp_physics = 10, 10, 10, 8,
ra_lw_physics = 1, 1, 1, 1,
ra_sw_physics = 1, 1, 1, 1,
radt = 15, 15, 15, 15,
sf_sfclay_physics = 2, 2, 2, 2,
sf_surface_physics = 2, 2, 2, 2,
bl_pbl_physics = 2, 2, 2, 2,
bldt = 0, 0, 0, 0,
cu_physics = 1, 1, 0, 0,
cudt = 5, 5, 5, 5,
isfflx = 1,
ifsnow = 0,
icloud = 1,
surface_input_source = 1,
num_soil_layers = 4,
num_land_cat = 24,
sf_urban_physics = 0, 0, 0, 0,
topo_wind = 0, 0, 1, 1,
maxiens = 1,
maxens = 3,
maxens2 = 3,
maxens3 = 16,
ensdim = 144,

do_radar_ref = 1,
lightning_option = 1,1,1,1,
lightning_dt = 162,162,162,
lightning_start_seconds = 600., 600., 600.,0.,
flashrate_factor = 3, 3, 3,3.5,
cellcount_method = 2, 2, 2, 0,
cldtop_adjustment = 2., 2., 2., 0.,
iccg_method = 2, 2, 2, 2,
iccg_prescribed_num = 0.,
iccg_prescribed_den = 1.,
/
Can you help me to check it? Thank you!
lynn831018
 
Posts: 4
Joined: Tue Dec 04, 2012 5:41 am

Re: LIGHTNING PARAMETERIZATION BUGS(?)

Postby agmunoz » Wed Mar 18, 2015 3:35 pm

thgian wrote:Dear WRF users and developers,

I would like to make you all aware of two (2) potential bugs that we have came across in WRF version 3.5.1.

The first possible bug (we are still looking into it) is related to the implementation of the lightning parameterization (Wong et al., 2013, based on Price and Rind, 1992, 1993, 1994). More specifically, the bug appears when one selects the option for partitioning lightning based on Price and Rind (1993) (cold-cloud depth; iccg_method = 3). In that case, the implementation of any of the available lightning schemes results to irregularly distributed NaNf values of the variable CG(or IC)_FLASHCOUNT across the domain of interest. When using any other iccg_method, results seem to be reasonable.

The second potential bug, possibly related to the first one, has to do with the implementation of the proposed by Wong et al. (2013) methodology for adjusting the model-resolved level of neutral beyoancy (LNB) in order to derive the cloud-top height and, consequently, compute flash rates. Following Wong et al. (2013), the model-resolved LNB should be reduced by 2 km (cldtop_adjustment = 2). However, looking through the physics code of WRF, we noticed that, contrary to the above, LNB is increased by 2 km. Based on some preliminary test runs we have had performed, we found that if we set cldtop_adjustment = 0, flash rates produced by WRF are significantly reduced as it would be expected by reducing the LNB (also stated in Wong et al., 2013). On the other hand, if we keep cldtop_adjustment = 2 we get too much lightning which suggests overprediction of cloud-top height (greater cloud-top heights, more lightning, to put it simply). Hence, we suspect that this is a bug in the WRF code where instead of subtracting cldtop_adjustment, this is actually added to the model-resolved LNB.

To summarize, if anyone else has had any similar experience with the lightning schemes, just let me know. I am currently working on the above-mentioned issues and I will come back as soon as I get cross-checked results for the possible bugs.


Hello, I'm having the same problem with iccg_method = 3. Did you solve this problem?

Thanks

Ángel
agmunoz
 
Posts: 14
Joined: Mon Aug 02, 2010 6:23 pm

Re: LIGHTNING PARAMETERIZATION BUGS(?)

Postby Tagi » Mon Jun 08, 2015 7:40 am

Hi all,

I am trying to run wrf 3.6.1. with lightning param. but I got this mesagge of error:


-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 87
lightning_init: lightning_dt needs to be a multiple of model time step dt
-------------------------------------------
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0


I changed more times the lightning_dt but I always have the same message.
Here my namelist


-----------------------------------------------------------------------------------
&domains
time_step = 10,
time_step_fract_num = 0,
time_step_fract_den = 1,
max_dom = 2,
e_we = 207, 361, 791,
e_sn = 217, 247, 811,
e_vert = 84, 84, 84,
p_top_requested = 5000,
num_metgrid_levels = 26,
num_metgrid_soil_levels = 4,
dx = 5002.9863, 1667.6621, 200,
dy = 5002.9863, 1667.6621, 200,
grid_id = 1, 2, 3,
parent_id = 1, 1, 2,
i_parent_start = 1, 36, 199,
j_parent_start = 1, 81, 221,
parent_grid_ratio = 1, 3, 5,
parent_time_step_ratio = 1, 3, 5,
feedback = 1,
smooth_option = 0,
/

&physics
mp_physics = 6, 6, 6,
ra_lw_physics = 1, 1, 1,
ra_sw_physics = 2, 2, 2,
radt = 5, 5, 5,
sf_sfclay_physics = 1, 1, 1,
sf_surface_physics = 1, 1, 1,
bl_pbl_physics = 1, 1, 1,
bldt = 0, 0, 0,
cu_physics = 0, 0, 0,
cudt = 0, 0, 0,
isfflx = 1,
ifsnow = 0,
icloud = 1,
surface_input_source = 1,
num_soil_layers = 5,
sf_urban_physics = 0, 0, 0,
maxiens = 1,
maxens = 3,
maxens2 = 3,
maxens3 = 16,
ensdim = 44,
sst_update = 1,
do_radar_ref = 1,
lightning_option = 2, 2,
lightning_dt = 11, 11,
lightning_start_seconds = 600, 600,
flashrate_factor = 2, 2,
cellcount_method = 2, 2,
iccg_method = 3, 3,

--------------------------------



Can someone help me to understand? I need this run for a thesis and time is ticking!
:?
Tagi
 
Posts: 3
Joined: Fri Apr 24, 2015 4:17 am


Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest

cron