Add Dynamic lightning scheme

[weiwangncar]

TYPE: new feature

KEYWORDS: dynamic lightning, cloud-to-ground-Lightning, Intracloud Lightning

SOURCE: Barry.H.Lynn@gmail.com; Barry.Lynn@Weather-It-Is.com (Weather It Is, LTD and Hebrew University of Jerusalem), internal

DESCRIPTION OF CHANGES:
A new dynamic lightning scheme is added. The scheme of Lynn et al. (2012) is a prognostic lightning parameterization, but it is not an explicit microphysical charging–discharge scheme. Rather than predicting electric charge or electric fields directly, the scheme predicts the temporal evolution of a bulk potential electric energy associated with deep convection.

The prognostic variable evolves from time step to time step and is driven by measures of convective intensity, primarily the vertical velocity and the mass content of key hydrometeors. Lightning discharges are triggered diagnostically when the accumulated potential electric energy exceeds prescribed threshold values, representing the onset of electrical breakdown. Following discharge, the potential energy is reduced, allowing subsequent recharge as convection continues.

To run the Dynamic Lightning Scheme add these parameters to the physics section of namelist.input

dyn_lightning_option = 1, 1, 1,
coul_pos = 0.000035, 0.000035,0.000035,
coul_neg = 0.000035, 0.000035,0.000035,
coul_neu = 0.000035, 0.000035,0.000035,

These are charging coefficients are set for
mp_physics = 28, 28, 28,
and can be modified for other microphysical schemes, if needed. For instance, if a scheme does not produce very much cloud water, these values might need to be raised.

One could also modify, j_pos, j_neg, and j_neu, which are threshold values for the breakdown field that control what magnitude of "electric potential energy" must build up to produce an event for each (see Registry/registry.dyn_light). But, this is not recommended as a first step.

The original paper is: Lynn, H. B., Y. Yair, C. Price, G. Kelman, and A. J. Clark, 2012: Predicting cloud-to-ground and intracloud lightning in weather forecast models. Wea. Forecasting, 27, 1470–1488. https://doi.org/10.1175/WAF-D-11-00144.1. Additional papers were published since then. One can also reference this paper: Stefano Federico, Rosa Claudia Torcasio, Jana Popova, Zbyněk Sokol, Lukáš Pop, Martina Lagasio, Barry H. Lynn, Silvia Puca, Stefano Dietrich,
Improving the lightning forecast with the WRF model and lightning data assimilation: Results of a two-seasons numerical experiment over Italy, Atmospheric Research, Volume 304, 2024, 107382, ISSN 0169-8095, https://doi.org/10.1016/j.atmosres.2024.107382.

LIST OF MODIFIED FILES: list of changed files (use git diff --name-status master to get formatted list)

A Registry/registry.dyn_light
M Registry/registry.em_shared_collection
M dyn_em/solve_em.F
M phys/Makefile
M phys/module_microphysics_driver.F
A phys/module_calc_lpi_new.F
A phys/module_ltng_pe.F
A phys/module_ltng_strokes.F
M run/README.namelist

TESTS CONDUCTED:
The Jenkins tests are all passing.

RELEASE NOTE: A new dynamic lightning scheme is added. The scheme of Lynn et al. (2012) is a prognostic lightning parameterization and it predicts the temporal evolution of a bulk potential electric energy associated with deep convection. Activated by dyn_lightning_option = 1.

[weiwangncar]

The regression test results:

Test Type              | Expected  | Received |  Failed
= = = = = = = = = = = = = = = = = = = = = = = =  = = = =
Number of Tests        : 23           24
Number of Builds       : 60           57
Number of Simulations  : 158           150        0
Number of Comparisons  : 95           86        0

Failed Simulations are: 
None
Which comparisons are not bit-for-bit: 
None

[weiwangncar]

@BarryHLynn Can you provide a short description about this scheme? How is it different from other schemes in WRF?

[weiwangncar]

@BarryHLynn How do you define num_light_periods? Is it always 1 in a run?

[BarryHLynn]

Hi: Sorry for the late reply. The Dynamic Lightning scheme of *Lynn et al. (2012)* is a *prognostic lightning parameterization*, but it is *not* an explicit microphysical charging–discharge scheme. Rather than predicting electric charge or electric fields directly, the scheme predicts the temporal evolution of a bulk *potential electric energy* associated with deep convection. The prognostic variable evolves from time step to time step and is driven by measures of convective intensity, primarily the vertical velocity and the mass content of key hydrometeors. Lightning discharges are triggered diagnostically when the accumulated potential electric energy exceeds prescribed threshold values, representing the onset of electrical breakdown. Following discharge, the potential energy is reduced, allowing subsequent recharge as convection continues. num_light_periods is a legacy parameter. It could be removed. I used it when I was doing convective nudging. Barry

…

On Sun, Jan 25, 2026 at 8:42 AM weiwangncar ***@***.***> wrote: *weiwangncar* left a comment (wrf-model/WRF#2276) <#2276 (comment)> @BarryHLynn <https://github.com/BarryHLynn> How do you define num_light_periods? Is it always 1 in a run? — Reply to this email directly, view it on GitHub <#2276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKWLWRRBBI5XHXL454KX27T4IRQVBAVCNFSM6AAAAACR6UZRISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOJWGA4TGNRXGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Barry H. Lynn, Ph.D Senior Scientist, Lecturer, The Institute of Earth Sciences, The Hebrew University of Jerusalem, Givat Ram, Jerusalem 91904, Israel Tel: 972 547 231 170 Fax: (972)-25662581 Weather It Is, LTD Weather and Climate Focus https://weather-it-is.com <http://weather-it-is.com> Jerusalem, Israel Local: 02 930 9525 Cell: 054 7 231 170 Int-IS: x972 2 930 9525

[BarryHLynn]

Hi: Yes, l_obs could be removed; I just didn't want to make changes to my code. Otherwise, it must be called every time step, as it builds up "potential electric energy" each time step, which is advected within the domain. Barry

…

On Thu, Jan 29, 2026 at 5:56 PM dudhia ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In Registry/registry.dyn_light <#2276 (comment)>: > +# state real - ikjftb scalar 1 - - - +state real light_ne ikjftb scalar 1 - \ + i0rhusdf=(bdy_interp:dt) "LIGHTNING_NE" "LIGHTNING NEG TOTAL ENERGY " "J" +state real light_pe ikjftb scalar 1 - \ + i0rhusdf=(bdy_interp:dt) "LIGHTNING_PE" "LIGHTNING POS TOTAL ENERGY" "J" +state real light_neu ikjftb scalar 1 - \ + i0rhusdf=(bdy_interp:dt) "LIGHTNING_NEU" "LIGHTNING NEU TOTAL ENERGY" "J" +# +state real LPOS ij misc 1 - irh05du "LPOS" "Positive Cloud to Ground Lightning Density" "# time-l" +state real LNEG ij misc 1 - irh05du "LNEG" "Negative Cloud to Ground Lightning Density" "# time-1" +state real LNEU ij misc 1 - irh05du "LNEU" "Intra-Cloud Lightning Density" "# time-1" +state real LPI2D ij misc 1 - rh05 "LPI2D" "Lightning Potential Index (2D)" "J/kg" +state real LPI3D ikj misc 1 - rh05 "LPI3D" "Lightning Potential Index (3D)" "J/kg" +state real l_obs i{lp}j misc 1 - irh05 "L_OBS" "Lightning OBS" " " + +#package dynlight_output dyn_lightning_option==1 - scalar:light_pe,light_ne,light_neu;state:lneu,lneg,lpos,l_obs,lpi2d,lpi3d Do we need this commented line? l_obs is not in the code. Could also be removed from registry. — Reply to this email directly, view it on GitHub <#2276 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKWLWRR3E7T6UJVLGJVDY6D4JJCU5AVCNFSM6AAAAACR6UZRISVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTOMRUGIYTAOBXGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Barry H. Lynn, Ph.D Senior Scientist, Lecturer, The Institute of Earth Sciences, The Hebrew University of Jerusalem, Givat Ram, Jerusalem 91904, Israel Tel: 972 547 231 170 Fax: (972)-25662581 Weather It Is, LTD Weather and Climate Focus https://weather-it-is.com <http://weather-it-is.com> Jerusalem, Israel Local: 02 930 9525 Cell: 054 7 231 170 Int-IS: x972 2 930 9525

[dudhia]

@weiwangncar could you go ahead and remove the commented package and l_obs from the registry?
We can leave the call in the microphysics driver.

[BarryHLynn]

As far as I know, we need the package to output the variables and to advect those that need advecting. Have you enabled this in another way? Barry

…

On Thu, Jan 29, 2026 at 8:26 PM dudhia ***@***.***> wrote: *dudhia* left a comment (wrf-model/WRF#2276) <#2276 (comment)> @weiwangncar <https://github.com/weiwangncar> could you go ahead and remove the commented package and l_obs from the registry? — Reply to this email directly, view it on GitHub <#2276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKWLWRTAEZAWSBCGNXZ4RR34JJGDXAVCNFSM6AAAAACR6UZRISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMJZGQ2DSNBWGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Barry H. Lynn, Ph.D Senior Scientist, Lecturer, The Institute of Earth Sciences, The Hebrew University of Jerusalem, Givat Ram, Jerusalem 91904, Israel Tel: 972 547 231 170 Fax: (972)-25662581 Weather It Is, LTD Weather and Climate Focus https://weather-it-is.com <http://weather-it-is.com> Jerusalem, Israel Local: 02 930 9525 Cell: 054 7 231 170 Int-IS: x972 2 930 9525

[dudhia]

As far as I know, we need the package to output the variables and to advect those that need advecting. Have you enabled this in another way? Barry
I mean you have the package statement twice and the one with l_obs is commented out. We can delete that one.

[BarryHLynn]

Correct. Thank you for clarifying. Barry H. Lynn, Ph.D Senior Scientist, Lecturer, The Institute of Earth Sciences, The Hebrew University of Jerusalem, Givat Ram, Jerusalem 91904, Israel Tel: 972 547 231 170 Fax: (972)-25662581 Weather It Is, LTD Weather and Climate Focus https://weather-it-is.com <http://weather-it-is.com> Jerusalem, Israel Local: 02 930 9525 Cell: 054 7 231 170 Int-IS: x972 2 930 9525

…

On Thu, 29 Jan 2026 at 21:00 dudhia ***@***.***> wrote: *dudhia* left a comment (wrf-model/WRF#2276) <#2276 (comment)> As far as I know, we need the package to output the variables and to advect those that need advecting. Have you enabled this in another way? Barry I mean you have the package statement twice and the one with l_obs is commented out. We can delete that one. — Reply to this email directly, view it on GitHub <#2276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKWLWRXMQ34IO63W5EPFBAD4JJKFPAVCNFSM6AAAAACR6UZRISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMJZGY4TONBVG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[marybarthbrock]

I reviewed the PR and have the following comments and questions.
First, this option a good addition to the WRF model as the other lightning options are diagnostic calculations (based on bulk properties of the storm) while this option is prognostic in predicting energy related to charging.

There could be clarification and further information provided in the PR. I initially got the impression that I have to run mp_physics=28 with this new LPI code, but I don't think it is true. So, the text could be revised to say that the code runs with any cloud physics option but the coul_pos, coul_neg, and coul_neu values should be modified when using schemes other than option 28.
Further, it would be nice if the authors provided guidance (if they have it). I say that because I'm often contacted asking for advice on how to use the lightning flash rate diagnostics we added.

There should be guidance about what horizontal grid spacings that the scheme should be used at. The original paper (Lynn et al. 2012) performed simulations at 4-km with one set of tests at 3-km (not much of a change, yet one where changing input parameters improved the results). It sounds like the scheme should only be used for dx<5km and that there should be guidance on how to adjust the parameters when using dx different than 4-km (or whatever base dx the authors are using).

Lastly, it would be good to hear whether the new LPI option could be used with WRF-Chem for predicting lightning-NOx production, which currently uses IC and CG flash rates in its calculation.

[weiwangncar]

@BarryHLynn Please see if you can add more information about the use of the scheme based on Mary's comments. Thanks!

[BarryHLynn]

Dear Mary: Thank you for your very pertinent questions. In short, the scheme is designed with a deliberately simple, scale-aware parameter that reduces the charging coefficients relative to those originally specified for a 4 km grid. It is intended for use at both convection-allowing and cloud-allowing resolutions and is compatible with any microphysical scheme that explicitly represents, at a minimum, liquid water, ice, snow, and graupel (and/or hail). As noted by Federico et al. (2022), the intensity of simulated lightning is sensitive to the choice of charging coefficients, and seasonal or regime-dependent adjustments may therefore improve performance. Moreover, somewhat counterintuitively, a scheme may generate less liquid water yet still produce more lightning—for example, WSM6—simply because it produces more vigorous convection than, say, the Thompson scheme. The SBM scheme, by contrast, generally produces substantially more liquid water than bulk schemes, and for this reason its charging coefficients were reduced from approximately 0.35×10−4 to 0.15×10−4 . Finally, this should be viewed not as a new LPI option, but as an extension of the existing approach, and it is therefore compatible with WRF-Chem and similar coupled systems. In principle, no additional coupling is required beyond passing the diagnosed lightning information to the lightning-NOx parameterization, which relies on IC and CG flash rates. As with existing lightning-NOx schemes, some assumption regarding the vertical distribution of lightning discharge is required, and the user must decide whether to use only intracloud lightning, or both intracloud and cloud-to-ground flashes, when driving NOx production. An additional reference: Federico, S.; Torcasio, R.C.; Lagasio, M.; Lynn, B.H.; Puca, S.; Dietrich, S. A Year-Long Total Lightning Forecast over Italy with a Dynamic Lightning Scheme and WRF. *Remote Sens.* 2022, *14*, 3244. https://doi.org/10.3390/rs14143244 https://www.mdpi.com/2072-4292/14/14/3244 Thank you for your help in getting this published. P.S. Here are short summaries from previous papers, which you may simply leave out of the publication release. Lynn et al., 2015: https://journals.ametsoc.org/view/journals/wefo/30/2/waf-d-13-00028_1.xml#tbla1 The forecasts of CG lightning with the previously published values of *Q* were closest to the observed values. When *Q* was reduced by half, the forecast CG values were from one-third to less than one-half those initially forecast, while when *Q* was doubled, forecast CG values were more than 2 and as much as 3 times larger than with the original charging values. A statistical lightning forecast would have produced values one-half or twice the originally forecast values, respectively. Lynn et al., 2020: https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2020JD033520: "Lynn et al. (2012 <https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2020JD033520#jgrd56599-bib-0026>) produced their study on a 4 km grid. Within the DLS, two parameters were specified a priori, the charging coefficient, Q, and the threshold energy at which lightning occurs, T. Here we tested the sensitivity of the forecast lightning to choice of Q. We also made an additional change to the scheme in order to enable it to be “scale aware.” From: Considering the forecast behavior for different seasons, we note that L100 overestimates the number of strokes in all seasons, and L50 underestimates the number of strokes in all seasons except winter. All DLS configurations overestimated the strokes in winter. L75 overestimates the strokes in spring, fall, and winter, and underestimates their number in summer. The underestimation in summer is almost compensated by the overestimation in other seasons so that the total number of strokes forecasted by L75 is close to the number of strokes observed for the whole year. The result of this comparison shows that the performance of the DLS settings is dependent on the season. In summer, for example, the number of observed strokes fell between the L75 and L100 configurations, whereas it is between L50 and L75 in spring. The results are shown for 24 km grid cells, but similar conclusions were found for other grid spacings. Comparing the FBIAS for the two different configurations, WSM6 produced higher values for all thresholds, showing that the WSM6 microphysical scheme predicts more convection compared to the Thompson scheme [97,98]. The larger FBIAS of the WSM6 configuration results in both larger POD and FAR scores than the Thompson scheme for all of the thresholds considered.

…

On Sat, Feb 7, 2026 at 4:28 AM weiwangncar ***@***.***> wrote: *weiwangncar* left a comment (wrf-model/WRF#2276) <#2276 (comment)> @BarryHLynn <https://github.com/BarryHLynn> Please see if you can add more information about the use of the scheme based on Mary's comments. Thanks! — Reply to this email directly, view it on GitHub <#2276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKWLWRUPJ3L4TSL7VBUEECD4KVETPAVCNFSM6AAAAACR6UZRISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNRTGM3TCMZTHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Barry H. Lynn, Ph.D Senior Scientist, Lecturer, The Institute of Earth Sciences, The Hebrew University of Jerusalem, Givat Ram, Jerusalem 91904, Israel Tel: 972 547 231 170 Fax: (972)-25662581 Weather It Is, LTD Weather and Climate Focus https://weather-it-is.com <http://weather-it-is.com> Jerusalem, Israel Local: 02 930 9525 Cell: 054 7 231 170 Int-IS: x972 2 930 9525