### LIGHTNING PARAMETERIZATION BUGS(?)

Posted:

**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.

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.