Issue with Lightning Flash Count and cellcount_method in WRF

[parhelion2]

Hi all,

For my case study, I ran multiple WRF simulations using different microphysics schemes with lightning_option = 1 (PR92 updraft-based). However, the results show "invisible lines" dividing the domain, making the output look unrealistic (see cell_count_method_1.png, it shows the accumulated flash count for 24 hours). I tried the same simulations for another day and the pattern problem looks even more intense on that day (see second_case_study.png (label cell2 stands for cellcount_method =2)).

I suspect this is related to parameter cellcount_method, which I initially set to 1 (tile-by-tile calculation). The pattern that can be seen in my simulations look like a tile pattern, but I’m unsure how WRF defines these tiles and if they match my results. I haven't found similar cases in the literature.

To test this, I reran simulations with cellcount_method = 2 for two microphysics schemes. This removed the pattern (cellcount_method_2.pdf — label hope stands for cellcount_method =2), but the total flash count was significantly lower and deviated more from observations, so I'm hesitating to use this option.

Has anyone encountered this issue? Any insights on how the WRF lightning option defines tiles or alternative solutions? Or is there a problem in my namelist?

I would appreciate any help!
Sina

 

[Ming Chen]

Sina,
cellcount_method = 1 is tile-wide, appropriate for large domains;
cellcount_method = 2 is domain-wide, appropriate for single-storm domains.

Would you please take a loo at the following papers, which provide more information about lightning simulation by WRF:

Price, C. and D. Rind, 1992: Simple lightning parameterization for calculating global lightning distributions. J. Geophys. Res., 97(D9), 9919-9933. doi:10.1029/92JD00719

Yair, Y. et al., 2010: Predicting the potential for lightning activity in Mediterranean storms based on the Weather Research and Forecasting (WRF) model dynamic and microphysical fields, J. Geophys. Res., 115, D04205, doi:10.1029/2008JD010868

Lynn, B., et al., 2012: Predicting cloud-to-ground and intracloud lightning in weather forecast models. Wea. Forecasting, 27:6, 1470-1488. doi:10.1175/WAF-D-11-00144.1

 

[parhelion2]

Sina,
cellcount_method = 1 is tile-wide, appropriate for large domains;
cellcount_method = 2 is domain-wide, appropriate for sing-storm domains.

Would you please take a loo at the following papers, which provide more information about lightning simulation by WRF:

Price, C. and D. Rind, 1992: Simple lightning parameterization for calculating global lightning distributions. J. Geophys. Res., 97(D9), 9919-9933. doi:10.1029/92JD00719

Yair, Y. et al., 2010: Predicting the potential for lightning activity in Mediterranean storms based on the Weather Research and Forecasting (WRF) model dynamic and microphysical fields, J. Geophys. Res., 115, D04205, doi:10.1029/2008JD010868

Lynn, B., et al., 2012: Predicting cloud-to-ground and intracloud lightning in weather forecast models. Wea. Forecasting, 27:6, 1470-1488. doi:10.1175/WAF-D-11-00144.1

Hello Ming, thank you for your reply and the references! Unfortunately, further information about my specific problem is not discussed in those papers. Do you might have any more specific information about the tile-wide calculation in cellcount_method =2? Or could you check my namelist for potential issues regarding that?

 

[Ming Chen]

Your namelist.input looks fine to me.

The lightning option is not frequently used, and there might be some issues we are not aware of. Below is a newest paper that discusses the lightning options 1 and 2:

Wong, J., M. Barth, and D. Noone, 2013: Evaluating a lightning parameterization based on cloud-top height for mesoscale numerical model simulations, Geosci. Model Dev., 6, 429–443, GMD - Evaluating a lightning parameterization based on cloud-top height for mesoscale numerical model simulations.

Hope this is helpful for you.

 

[Ming Chen]

Unfortunately dues to limited resources here in NCAR, we are no longer able to explore the performance of individual cases raised by our users. However, we deeply appreciate that you share your experiences and updates on the case, which might be helpful for other users who have same/similar issues.