Prognostic lightning from CAM

[dlawrenncar]

Lightning strikes are one of the sources of fire ignition used by both the CLM big leaf and FATES fire models. Currently, lightning strikes are obtained from a static climatological dataset. Ideally, CLM would be able to use either this climatological dataset OR prognostic lightning coming from CAM. The climatological dataset from NASA provides 2-hourly 'flashes/km2/h' at 0.5 degrees
/glade/p/cesmdata/cseg/inputdata/atm/datm7/NASA_LIS/[clmforc.Li_2016_climo1995-2013.360x720.lnfm_Total_c160825.nc]

Email discussions with CAM group:

Andrew Gettelman:

There is a parameterization for NOx production from lightning:
https://github.com/ESCOMP/CAM/blob/cam6_3_045/src/chemistry/mozart/mo_lightning.F90
That produces a cloud to ground v. in cloud ratio and a total discharge energy based on cloud top height, depth and 'charging zone'. There are output fields for the energy, frequency and the ratio of ground to in-cloud....

There is a 'Flash Frequency' in (flashes storm^-1 min^-1) in this code which is a function of cloud height (some referenced parametrization). That could probably be turned into km2/h with an assumption about storm size. Not sure if it runs all the time or it has to be invoked outside of the mozart chemistry. Will need to contact Chem folks (Simone, Louisa, Francis) to learn more.
To mitigate a situation where the CAM lightning dataset 'screws' up land fire simlations (i.e., if CAM lightning distrubution / frequency is way different to NASA), as an intermediate step, you can configure a unit conversion so that (flashes storm^-1 min^-1) * Factor ≈ flashes/km2/h . Then the 'Factor' is adjustable but hopefully is sensible in terms of storm/km2 * min/h ....

Rich Neale: (an alternative solution)

The question is how would we map variables from convection that would be 'responsible' for most of the lightning at 1 deg.
This could be mass flux, convective heating, convective precip., convective top and I'm sure there are empirical representations available for this.
Here are a couple of examples that base it on cloud top height, mass flux and convective precip. Which would be easy.
https://doi.org/10.1175/JTECH-D-13-00261.1
https://www.sciencedirect.com/science/article/pii/S1364682610002154

Dave:

OK. I will arrange a meeting after LMWG and AMWG meetings to discuss with CAM-Chem folks and Andrew/Rich and CLM people.

Definition of done:

• Add this to CMEPS
• Add this to CAM
• Change CAM to not set atm_provides_lightning in it's namelist add test for it that ignores namelist warnings from CTSM
• Change CTSM so that if it's on it produces a warning
• Have CTSM bring the field in from the coupler and add to atm2lnd fields
• Add the ability to write the field out in CTSM so that it can be evaluated on the CTSM side and compared to the lightning datasets
• Add the ability to the base FATES/BGC fire object to use this rather than reading it from the lightning data files (this will allow it to be used by both FATES and the BGC Li fire code). (This is controlled by atm_provides_lightning)
• Have atm_provides_lightning default off in CTSM
• Evaluate it's use in CTSM-BGC
• Evaluate it's use in CTSM-FATES
• Tune BGC-Fire for using it with CAM
• Tune FATES-Fire for using it with CAM
• Make it the default in CTSM for latest physics version with the tuning changes when coupled to CAM

[dlawrenncar]

Comments from Mary Barth: Just to let you know that flash frequency can be grid size dependent in two ways. If I recall, the CAM flash frequency parameterization depends on "cloud top height". It's a power law so it is very sensitive to the cloud top height. With dz=1000 m, a change in the model level for cloud top height can substantially change flash frequency. Also, it's better to use level of neutral buoyancy than actual cloud top height because the original empirical relation used top of the 20 dBZ contour for the storm and not the actual cloud edge.
Since the parameterization is looking for the maximum cloud top height for a storm, when one changes from dx=100km to dx=25km, for example, there is the possibility for more storms to appear in the 4 grid cells for dx=25km compared to dx=100km, resulting in more flashes in the fine grid spacing case than the coarse grid spacing.
When one goes to even finer resolution, it's possible to have the same storm in multiple grid cells, resulting in double counting of a storm. In WRF, I dealt with this by finding maximum cloud top height for the grid on a CPU. This meant I tried to have enough grid points on a "patch" that would have a storm and then I crossed my fingers.
Consequently, the biggest challenge is that almost all flash frequency parameterizations are based on bulk storm characteristics. It's complicated. Plus the other complication is getting the fraction of total flashes that are cloud-to-ground. We tested the parameterization proposed by Price et al., and it really doesn't work that well, at least for the US at dx~15km.
Finally, I haven't done much with ignition of fires, but I do remember reading that positive cloud-to-ground flashes are hotter and may be the ones that cause fires. They are also much less common than the negative cloud-to-ground flashes. I trust that the fire parameterization is therefore taking some small fraction of the CG flashes.

Okay, that's most of what I know about lightning. Flash rate definitely needs to be evaluated for refined grid meshes.

[jkshuman]

Mary is correct that the fire model is looking to use cloud-to-ground lightning and only uses a portion of that. Within CTSM there is an "ignition efficiency" parameter that is used in the calculation of ignitions. From previous documentation this value was 20%, but I would need to confirm a current value.

[lkemmons]

Based on the meeting today: we would like to pass the the flash frequency (flash_freq), scaled by the cloud-to-ground fraction of flashes (cgic), to CTSM so it can be used to trigger fires. It appears to me that mo_lightning is always called by the physics, but inside mo_lightning there is a check for the NO species in the chemistry and returns if not found. We will need to add some other flag so as to do the flash frequency calculation when NO is not present, and it is desired for the land model. A scale factor will be needed, applied in CTSM (?), that will probably need to be changed depending on model resolution. It is also desired to have a namelist flag to indicate if fires are triggered by CAM lightning or climatologies from fire.
@fvitt - There is no urgency, but I do not think it is a big job. Please coordinate with @ekluzek. I am available to answer any questions.

[ekluzek]

@fvitt when you start working on this, I'd like to make sure it's implemented in a way that the CTSM can know that lightning is being sent and doesn't need to provide lightning files to the CTSM namelist. We didn't do this for ndep, and that has caused some problems. So I'd like to do it in a better way for Lightning. I think the way to do that is to add a namelist option to the drv_flds_in namelist. Then both CAM and CTSM can query it, and know what to do.

[fvitt]

@lkemmons @dlawrenncar In what units should the lightning flash frequency passed to the mediator be? It seems that mo_lightning computes the flash frequency in units of /min. I can easily convert to /sec if that is preferred.

[fvitt]

@ekluzek How does this sound for a namelist indicator in drv_flds_in?

  <!-- ========================================================================================  -->
  <!-- Lightning flash frequency                                                                 -->
  <!-- ========================================================================================  -->

  <entry id="atm_lightning_flash_freq">
    <type>char</type>
    <category>drv_flds_in</category>
    <group>lightning_coupling_nl</group>
    <desc>
      If TRUE atmosphere model will provide prognosed lightning flash frequency
    </desc>
  </entry>

[dlawrenncar]

The lightning dataset that is currently being used within CTSM is in units of. flash/km2/hr, which is obviously a strange unit. I think that whatever unit you use, we can accommodate it. What we need is cloud-to-ground lightning, which based on prior comments in this thread, it looks like it should be possible to provide.

…

On Fri, Jun 24, 2022 at 3:09 PM Francis Vitt ***@***.***> wrote: @ekluzek <https://github.com/ekluzek> How does this sound for a namelist indicator in drv_flds_in? <!-- ======================================================================================== --> <!-- Lightning flash frequency --> <!-- ======================================================================================== --> <entry id="atm_lightning_flash_freq"> <type>char</type> <category>drv_flds_in</category> <group>lightning_coupling_nl</group> <desc> If TRUE atmosphere model will provide prognosed lightning flash frequency </desc> </entry> — Reply to this email directly, view it on GitHub <#1630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVFZT3KQZEVS6VCJSJDVQYPYVANCNFSM5NQIOKEA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ekluzek]

@fvitt on the namelist since it's a namelist you might as well make it logical rather than character. And maybe change to something like
atm_provides_lightning_flash_freq?
so that the operative is that the atm provides lightning? And maybe it just needs to be
atm_provides_lightning
since the variable passed will dictate the specific type and units.

The other suggestion is to make the variable name that's passed be clear if it's the total flash frequency or only the cloud to ground lightning. If it's the total we'll use the formulation inside of CTSM fire to approximate the cloud-to-ground portion. If you send just the cloud-to-ground portion we'll need to have a flag to turn that conversion off inside of CTSM and FATES. It would be better for CAM to be in control of the fraction that's cloud-to-ground so I'd prefer if you did that conversion inside of CAM even if it starts as the same approximation we use.

I agree with @dlawrenncar the units we read on the file of flash/km2/hr is kind of odd, so we'll just convert inside of CTSM to what we need.

[fvitt]

I am not sure if we are estimating cloud-to-ground flash freq or just the total flash frequency. @lkemmons do you know?
https://github.com/ESCOMP/CAM/blob/cam_development/src/chemistry/mozart/mo_lightning.F90

[lkemmons]

The variable 'cgic' in mo_lightning is the fraction of cloud-ground flashes in a storm. We no longer use it to calculate NO emissions because we assume that cloud-ground and cloud-cloud flash energies are the same.
'cgic' is from equation 14 (PG) in Price et al., 1997 (https://agupubs.onlinelibrary.wiley.com/doi/10.1029/96JD03504). The comments in the code are not quite correct (it is NOT the ratio of cloud-ground to intra-cloud).

[fvitt]

I believe this will give cloud-to-ground flash frequency (per minute) in each grid box which CAM will pass to the mediator (to CTSM)

  cam_out(c)%lightning_flash_freq(i) = flash_freq(i,c)*cgic(i,c)

@ekluzek Is a simple logical namelist variable atm_provides_lightning in drv_fld_in sufficient?

[ekluzek]

@fvitt yes a logical atm_provides_lightning in drv_fld_in is great.

[wwieder]

@fvitt has a PR related to this in CAM, #747... there's likely lots of science that should be discussed if we're thinking of using this in CTSM6, @dlawrenncar ?

[dlawrenncar]

If the question is about prioritization, then I'm not sure where to put it. Not up there at the top of the list, but if the PR is ready to be pulled in, then we may want pull it in as an option. Then, we would have the opportunity to test it out.

…

On Thu, Feb 16, 2023 at 10:20 AM will wieder ***@***.***> wrote: @fvitt <https://github.com/fvitt> has a PR related to this in CAM, #747 <ESCOMP/CAM#747>... there's likely lots of science that should be discussed if we're thinking of using this in CTSM6, @dlawrenncar <https://github.com/dlawrenncar> ? — Reply to this email directly, view it on GitHub <#1630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVCO47Y3PZ2LPOALDR3WXZOXFANCNFSM5NQIOKEA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[wwieder]

From co-chairs today, it sounds like CAM will be able to send us lightning strikes, opening up the door for lots of science to start investigating and tuning this for coupled model simulations. Broadly, there's interest in having this be a feature in CESM3. Not sure who may be available or interested in thinking about this?

[wwieder]

looks like this is nearly ready to bring in on the CAM + CMEPS side. @dlawrenncar do we have anyone who can look at using this modeled lightning data for fire ignitions in CTSM? Maybe the obvious first step would be to compare the NASA stream we're currently inputting with results coming from CAM. Is this something that you can work into your schedule, @olyson ?

[dlawrenncar]

Yes. Maybe the first thing would be to get a look at the differences in the climatology of lightning strikes from the NASA stream vs a 10-year CAM run. Then, perhaps we could archive the lightning from the CAM run and create a climatology that looks like the NASA stream and run that through a CTSM land-only run to see what the impact is.

…

On Fri, Apr 7, 2023 at 8:08 AM will wieder ***@***.***> wrote: looks like this is nearly ready to bring in on the CAM + CMEPS side. @dlawrenncar <https://github.com/dlawrenncar> do we have anyone who can look at using this modeled lightning data for fire ignitions in CTSM? Maybe the obvious first step would be to compare the NASA stream we're currently inputting with results coming from CAM. Is this something that you can work into your schedule, @olyson <https://github.com/olyson> ? — Reply to this email directly, view it on GitHub <#1630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVEA5XABZC52EXPLEU3XAANWLANCNFSM5NQIOKEA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[olyson]

I can look at this sometime in the next couple of weeks. Let me know where the CAM run is.

[dlawrenncar]

I don't know that there is a CAM run yet. I think we may need to run one ourselves. It looks like @fvitt is the one who would know if this is ready for a run to be done to start this testing process.

…

On Tue, Apr 11, 2023 at 8:42 AM Keith Oleson ***@***.***> wrote: I can look at this sometime in the next couple of weeks. Let me know where the CAM run is. — Reply to this email directly, view it on GitHub <#1630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVBMHPW3ID4FRLOF2VTXAVUTTANCNFSM5NQIOKEA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[wwieder]

They are doing so much testing of CAM right now, hopefully we can look at a run that Adam or Cecile is already planning to investigate? On Tue, Apr 11, 2023 at 8:45 AM David Lawrence ***@***.***> wrote:

…

I don't know that there is a CAM run yet. I think we may need to run one ourselves. It looks like @fvitt is the one who would know if this is ready for a run to be done to start this testing process. On Tue, Apr 11, 2023 at 8:42 AM Keith Oleson ***@***.***> wrote: > I can look at this sometime in the next couple of weeks. Let me know where > the CAM run is. > > — > Reply to this email directly, view it on GitHub > <#1630 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AFABYVBMHPW3ID4FRLOF2VTXAVUTTANCNFSM5NQIOKEA > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#1630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5IWJHPIBBB5K3NW32ZUUDXAVVCNANCNFSM5NQIOKEA> . You are receiving this because you commented.Message ID: ***@***.***>

[olyson]

Here is a comparison of the annual climatology of total-flashes from the lightning streams file from NASA (top) and from a nine year CAM simulation (bottom):

The CAM FLASHFRQ is in units of min-1, so I divided by the area of the grid cell and converted to day-1 to get total-flashes km-2 day-1.
There are differences but at least they are on the same scale.

The next plot compares cloud-to-ground flashes from NASA (top) to CAM (bottom):

In the top plot, I've multiplied total flashes in the NASA product by a latitude-dependent cloud-to-ground lightning fraction in the fire parameterization (see section 2.24.1.1 in the technical note). Again, the CAM LGHTNG_CLD2GRND is in units of min-1 and I've converted this to cld2grnd-flashes km-2 day-1.

I've created a 2-hourly climatology of LGHTNG_CLD2GRND (cld2grnd-flashes km-2 hr-1) to replace the NASA product (and removed the cloud-to-ground lightning fraction in the code) and run the model. Diagnostics compared to a control are here.
For example, you can see the effects of lightning flash frequency on FAREA_BURNED here.

[wwieder]

Thanks for taking a look at this @olyson, I wonder if we should discuss further at the CLM meeting next week? A few questions come to mind:

• It seems like there a number of scientific questions we could ask with this as we learn more about the capability. Is there someone who may be interested in doing this (or asked to do so)?
• My sense is that the fire module gets tuned for each model release, but I don't have a good idea how big a change this is to try and recalibrate the fire module? Is this Fang has any interested in doing again?
• How much may results change in transient simulations (I'd assume we have no information on this now)
• Are these results likely to be changing much with modifications to CAM (e.g. how 'stable' are these results)?
• Assuming this is a dataset we ultimately want to use, or at least enable, do we make streams files for offline simulations?

[dlawrenncar]

Thanks @olyson. FYI, I won't be at the meeting next week. Previously, the fire model has been tuned at least a little bit. I don't know if Fang would be willing or able to do it next time. It seems like a quick conversation with the CAM group would be warranted to try to understand what the strengths and limitations of the lightning representation is. For example, do they know why they are getting so many strikes over the Andes mountains? Overall, though, as one might expect, the impacts are not super big, probably because lightning is just one of many ignition sources for the fire model.

…

On Thu, May 11, 2023 at 12:06 PM will wieder ***@***.***> wrote: Thanks for taking a look at this @olyson <https://github.com/olyson>, I wonder if we should discuss further at the CLM meeting next week? A few questions come to mind: - It seems like there a number of scientific questions we could ask with this as we learn more about the capability. Is there someone who may be interested in doing this (or asked to do so)? - My sense is that the fire module gets tuned for each model release, but I don't have a good idea how big a change this is to try and recalibrate the fire module? Is this Fang has any interested in doing again? - How much may results change in transient simulations (I'd assume we have no information on this now) - Are these results likely to be changing much with modifications to CAM (e.g. how 'stable' are these results)? - Assuming this is a dataset we ultimately want to use, or at least enable, do we make streams files for offline simulations? — Reply to this email directly, view it on GitHub <#1630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVDOYJVRX5EYSNB3S43XFUTC3ANCNFSM5NQIOKEA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ekluzek]

Note: This work has both come into CMEPS and CAM, and there is a logical trigger that can be set to control it in place now. We currently don't handle it in CTSM so even though it's passed CTSM doesn't do anything with it.

I added an issue in CAM to not pass it by default:

ESCOMP/CAM#1129

NOTE: Until this is default on it should be off, and it should be controlled by CTSM in the build-namelist. And until we can handle it we should add a warning if someone turns it on.