Anthropogenic ignitions from population density in FATES-SPITFIRE

[jkshuman]

In many regions, humans account for the majority of ignitions. Currently FATES-SPITFIRE handles natural lightning ignitions, but not additional human ignitions. This has been discussed in various forums and is on the fire to-do list, but posting here for comment and discussion on action/implementation.

Many ESMs use population density and GDP to determine the number of human ignitions and associated suppression, and this method can be easily adapted to FATES-SPITFIRE. (suppression will be handled in a separate issue).

To include human ignitions requires:
1) reading of supplemental population density data to calculate potential ignitions,
2) adding these ignitions to the natural lightning ignitions.
(Emphasize that this is an optional dataset for fire model functionality, as HLMs vary, and you wouldn't want human ignitions for some tests).

Per the CLM Li fire model the number of human ignitions (lh):

lh       = pot_hmn_ign_counts_alpha*6.8_r8*hdmlf**(0.43_r8)/30._r8/24._r8
human ignitions (count/km2/hr) = potential human ignition counts * 6.8 * human density **(0.43_r8)/30._r8/24._r8

https://github.com/ESCOMP/CTSM/blob/a3e738cb211157f98d947a7b75ee789193db5fd9/src/biogeochem/CNFireLi2016Mod.F90#L607

where: human density (hdmlf) = read from a datafile,
potential human ignition counts (pot_hmn_ign_counts_alpha) = constant
real(r8) :: pot_hmn_ign_counts_alpha=0.0035_r8 ! Potential human ignition counts (alpha in Li et. al. 2012) (/person/month)

Within the CTSM framework population density is available as a streamfile that is controlled as part of CIME and has spatial and temporal variability. Reading the population density data streamfile is expected to be similar and build from the framework used to read in lightning data through clmfates_interfaceMod (PR #635 and associated CTSM PRs ESCOMP/CTSM#982 ESCOMP/CTSM#983 @slevisconsulting @ekluzek )

In SPITFIRE human ignitions would be added to the number of natural strikes (Site%NF) per day at the site level to provide total ignitions. (below example uses the default constant natural ignitions value and syntax, but it would be a similar addition to daily lightning read in from a data streamfile)

fates/fire/SFMainMod.F90

Lines 692 to 693 in 70dda4c

	!NF = number of lighting strikes per day per km2 scaled by cloud to ground strikes
	currentSite%NF = ED_val_nignitions * years_per_day * cg_strikes

@ekluzek and @slevisconsulting given your experience with adapting the lightning data streamfile for reading through clmfates_interfaceMod what else do we need to consider?

Note: I will create a related issue for fire suppression methodologies one of which is the CLM Li method and considers both GDP and population density.

[slevis-lmwg]

I have @lmkueppers' go-ahead to work on the anthropogenic ignitions.

I expect little additional work relative to the lightning work in ESCOMP/CTSM#991 and #635:

CTSM:

• Remove if (use_cn) so that now FATES may read the pop. density data.
• New fates_spitfire_mode value for the option of using both lightning and anthropogenic ignitions. I won't overthink this for now, but @lmkueppers suggested coming up with a more intuitive two-digit numbering system for fates_spitfire_mode, where the first digit may determine lightning choice and the second digit may determine anthropogenic choice. (Lara, that's how I understood your suggestion.)

Interface: Pass the pop. density to FATES.

FATES: Calculate and add anthropogenic ignitions to SPITFIRE's ignitions.

Since I expect little additional work relative to the lightning work, I will plan on committing changes to the same branches and pushing to the same pull requests (ESCOMP/CTSM#991 and #635). @glemieux @rgknox @ckoven I think I can have all this ready in time for @glemieux 's re-basing of my work.