Reading lightning data for use with SPITFIRE

[slevis-lmwg]

I have competed two FATES fire simulations with the default lightning parameter ED_val_nignitions... 1) At the CZ2 site with 100% ponderosa pine initialized with observed stand data (point simulation) 2) On a 2-D transect that includes CZ2 as one of the grid cells; started from bare ground, ran 20 years without fire, then continued with fire

I encountered a problem, however, when I replaced the scalar ED_val_nignitions in this line currentPatch%NF = ED_val_nignitions * currentPatch%area/area /365 with the vector lnfm24(g), the latter being the daily average of 3-hourly lightning data from a 2-D dataset. I used these two lines in subroutine area_burnt to locate the index g: p = currentCohort%pft g = patch%gridcell(p) The problem is that fire can eliminate currentCohort%pft entirely, so the model crashes when I ask for it.

I have a temporary fix. In subroutine fire_intensity I have replaced... currentPatch%fire = 1 ! Fire... :D with if (currentPatch%total_tree_area + currentPatch%total_grass_area > 0._r8) then currentPatch%fire = 1 ! Fire... :D else currentPatch%fire = 0 end if

@jkshuman does not like this because this way a bare ground grid cell full of dead litter cannot burn.

My question @rgknox @ckoven @pollybuotte @lmkueppers @ekluzek is this: Can anyone recommend an alternate way of locating the index g? I think this would eliminate the problem altogether.

Notes:

• I have confirmed that this approach does pick up the correct lightning value for the location.
• In the above line that calculates NF, I converted the lightning units based on a comment in the code stating that NF is in #/km2/day: currentPatch%NF = lnfm24(g) * 24._r8 ! #/km2/hr to #/km2/day

[ekluzek]

The CTSM issue this corresponds with is http://github.com/ESCOMP/CTSM/issues/982

[ekluzek]

@rgknox from looking into the CTSM side, I think it probably makes the most sense to keep the use_fates_spitfire namelist parameter, but also pass the fire_method character string into fates. It will indicate different levels something like: fatesnofiredata and fatesfirelnfm. Later other datalevels could be added fateslNpopdens, fateslNpNgdp, fateslNpNgNag. Most of this would be on the HLM side, it's just useful for FATES to check it to see what data is available from the HLM.

[ekluzek]

Actually now I take that back. You could change it use one type to signify if SF is on and what level of data is being sent to it. At first I thought it needed to use the fire_method character control string that is being used in cnfire -- but now I see that it doesn't need to be that way.

[ekluzek]

OK, I've fleshed out a proposal in the CTSM issue. It removes most of what was added into FATES, and puts it into the HLM. And there it's extending an existing class with a FATES specific fire data class. So there's not duplication of either FATES or CTSM code. It also removes calling CTSM modules from within FATES, which is an important design feature for FATES development (in order to support more than one HLM).

The thing that needs to be decided on the FATES side is how to trigger the different levels of fire data usage. You could use an integer as suggested above by @rgknox to trigger both Spit-Fire and the fire data level. On the CTSM side I was suggesting using a character string called "fire_method" -- because that's how it's handled by CNFire in CTSM. But, it wouldn't have to be handled that way, it just needs to be coordinated between the two.

[ckoven]

this got fixed by #635 so closing.