Prognostic lightning from CAM

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:
- [x] Add this to CMEPS
- [x] 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