WRF lightning scheme only being run at model output times?

[kmlupo]

In WRF v4.5.1, is there any reason why the lightning flash counts (CG_FLASHCOUNT and IC_FLASHCOUNT) would only be updating at the model output times? It would seem intuitive that these fields would update whenever the lightning scheme is called (e.g., at every model timestep when lightning_dt=0 in namelist.input). Running a few 1-hour tests, it is evident that the accumulated fields are only updating at the output times. Setting the history_interval = 60 minutes results in discrete, paintball-like plots at forecast hour 1, where the flashcount is equal to exactly the flashrate * model_dt. Setting the history_interval = 2 minutes results in much more smoothly evolving, geophysical-looking fields (and orders of magnitude more lightning!).

In my opinion, it doesn't really make sense for the model output to essentially "ignore" light rates and flashcounts between output times, as that seems like it would yield an extreme undercounting of lightning (as well as spatial discontinuities). Moreover, this would suggest that the description of the lightning_dt namelist option is a huge misnomer.

Attached a comparison of some tests I've run to demonstrate the issue (also noting that turning fdda nudging on/off changes flash rates). Relevant lightning namelist settings below:

lightning_option = 2,
iccg_method = 2,
iccg_prescribed_num = 3,
iccg_prescribed_den = 1,
cldtop_adjustment = 0,
lightning_dt = 0, ! or 24
lightning_start_seconds = 600,
flashrate_factor = 1.0,
cellcount_method = 2,


--Kevin

 

[Ming Chen]

ic_flashcount and cg_flashcount are accumulated CG flash count and IC flash count, respectively. They are output at the history intervals to represent the total flash counts since the starting of the model integration.
I expect that the values of these two variables over the same period should be the same no matter what history_interval is. Based on your results, it seems not the case.
Can you clarify how you derive CG_FLASHCOUNT and IC_FLASHCOUNT from your output?

 

[kmlupo]

As far as I can tell, these are being computed in module_lightning_driver as:

ic_flashcount(its:ite,jts:jte) = ic_flashcount(its:ite,jts:jte) + ic_flashrate(its:ite,jts:jte) * lightning_dt
cg_flashcount(its:ite,jts:jte) = cg_flashcount(its:ite,jts:jte) + cg_flashrate(its:ite,jts:jte) * lightning_dt

Which completely makes sense, as this is just computing an instantaneous flash count and accumulating it. And agreed, I would expect the count to not depend on history_interval. I haven't yet found an obvious reason in the code as to why this accumulation seems to only be happening at output times.

 

[kmlupo]

Update on this issue -

It appears that the problem is related to reflectivity only being computed at output times. So, when reflectivity-based lightning schemes try to compute a flash rate, reflectivity is zero everywhere, so flash rate is also zero at non-history times. For some microphysics schemes (e.g., Morrison, WDM6, Purdue-Lin), this problem is avoided by setting nwp_diagnostics = 1 in the namelist. For others (e.g., Thompson), there are other parts of the code that prevent this fix from working. I'll add some specific line numbers/modules for where I think this issue is coming from below, but I'm curious if this is a known requirement (and potentially bug for Thompson + lightning), since it does not appear to be documented for the lightning namelist parameters (e.g., https://www2.mmm.ucar.edu/wrf/users/wrf_users_guide/build/html/namelist_variables.html)?

-Kevin


Regarding the issue above (using lightning_option=2 [ltng_crm_PR92z], and Thompson MP) -

In module_lightning_driver.F:
--Lines 340–355: This scheme uses the countCells subroutine to determine cloud extent.
--Lines 617–658: The cellcount is based on the number of grid cells exceeding some reflectivity threshold.

In module_mp_thompson.F:
--Line 1449–1464: calc_refl10cm is only called if do_radar_ref=1 (we have this set so in the namelist) and diagflag = 1 (i.e., is this an output time).
--Line 1459: The Thompson scheme is the only scheme to also include a "ke_diag" term in its call to the reflectivity subroutine. In solve_em, this is forcibly set to "1" (i.e., reflectivity is only computed at k level 1 [which might be the model top in this case]) when nwp_diagnostics is on. This will prevent the Thompson scheme from updating reflectivity even when nwp_diagnostics is on.

In solve_em.F:
--Lines 363–369: diag_flag is only set to true of this is an alarm step (i.e., a history time) or if nwp_diagnostics is set to true. See also setting of ke_diag

In module_ltng_crmpr92.F:
--Line 84: If cell count is zero (ie, no cells exceed the reflectivity threshold), then flashrate is not computed and will equal zero.