Open rosiealice opened 9 months ago
Just wanting to scope the level of difficulty involved in this. In the original SPITFIRE code, the emissions were calculated as the 'emissions factor' per species of trace gas, multiplied by the carbon burned (see exceprt from the original Thonicke 2010 SPITFIRE paper:
For refererence, a link to whole Thonicke SPITFIRE paper is here
The emission factors are PFT specific, as described below. Their provenance was updated for CLM5.
Also for reference, this is the table of EFs from the original SPITFIRE model, depicted in their table 1:
It is worth noting that the CLM5 fire model works in a similar way https://github.com/ESCOMP/CTSM/blob/2e2434d10e35404be5284022270f474d50d2db26/src/biogeochem/CNFireEmissionsMod.F90#L292
It seems like as of the CLM5 release, actually getting the emissions into the atmosphere was a 'research topic' (this from the CLM5 paper).
I guess that Maria vM has probably continued with this effort since the release. It might well be worth involving her in this discussion. The canopy injection height calculations happen here. The emission heights are hard-coded:
https://github.com/ESCOMP/CTSM/blob/2e2434d10e35404be5284022270f474d50d2db26/src/biogeochem/CNFireEmissionsMod.F90#L324
There are potential some duplication issues that we would need to navigate here, but my suspicion is that we should just have FATES handle its own emissions factors and code. The amount of actual physics involved is very small (it's only really 2-3 equations we are talking about) and (most importantly) the principle of FATES is that it handles everything with a PFT identity. Having to map a new PFT back onto an existing set of fire emissions would be a world of pain in the long run when we wanted to introduce new things into FATES. Plus there is a lot of potentially interesting science to be done with the links between e.g. plant trait and their emissions which we don't want to rule out.
L
Noting that this implementation is at first only going to work in NOCOMP mode, since the emissions factors and injection heights are only defined per pft for now. This is OK for our current purposes.
Here is a rough to do list. Not necessarily in the optimum order.
INPUTS
The parameter file is here:
https://github.com/NGEET/fates/blob/main/parameter_files/fates_params_default.cdl
Within the parameter file, the parameters are 'name spaced' which means that they where possible have a name that allows similar parameters to appear together when they are all listed alphabetically. (fates_leaf_xxx, fates_rad_xxx, fates_allom_xxx). The fire ones are under fates_fire_xxx, near the bottom.
The new parameter will need defining, next to the other fire parameters, and the initialising. We should call it fates_fire_emission_factors.
[ ] Make a 'number of emission classes' dimension in pft file.
This should look like the other dimensions :
fates_pft = 12 ;
fates_nemissions = x ;
This should be consistent with the emis_nflds in the HLM, which is read in from lnd_import_export.
[ ] Make 'injection height' parameter, indexed by PFT
[ ] Do plumbing to read and make these parameters available in the FATES code.
OPERATIONS
[ ] Create a new subroutine in the SPITFIRE module to house the emissions code.
[ ] Implement the emissions logic from the CTSM codebase.
[ ] Make (very, very) sure that the biomass units being used to create emissions are the same across both models.
[ ] Implement the injection height logic from the CLM fire model (though without the hardwired parameters!)
[ ] Account for the difference in timestep between the fire model is fates and the CTSM. I think it is OK to divide by the number of timestep in a day, noting that hourly fire modeling is not currently in our scope.
[ ] Create fates side emission flux variables for each species. Indexed at the site level? (Check this before we start).
[ ] Create injection height variable.
[ ] Allocate and initialize these variables.
[ ] Populate the variables with the calculated values.
[ ] Push these variables across the HLM-FATES interface
CTSM side changes.
Build, submit, test,
Do PR, declare victory..
L
For the sake of the 'hackathon', I propose that we split into teams of two-ish and tackle the input, operations and output separately.
Maybe (depending on attendance) Input; Matvey & Alok Operations; Kjetil & Rosie Output; Marianne & Marit
Working branches: CTSM: feature/fates-fire-emissions Fates: feature/fates-fire-emissions
Fireflx_patch is the emissions variable in CLM Fireemis_inst@ztop_patch is the emissions height variable.
New, post meeting to do list.
Option 1: is more future proof, as the emissions code lives in fates adjacent to all the additional fire information.
Need to make sure that the species in FATES appear in tne exact same order as expected in the HLM.
Option 2: is simpler from an immediate coding perspective, but needs a FATES to HLM PFT mapping.
Additions to to do list from meeting
Currently fire-emissions from CTSM into CAM can only work for CN or BGC modes and NOT with FATES. As a longer term goal we need FATES to be able to send fire-emissions from CTSM to the coupler and into CAM-Chem.
This task concerns botht this issue on CTSM, to do with getting the emissions to the atmosphere to work at the same time as FATES: https://github.com/ESCOMP/CTSM/issues/1045'
and thus issue on FATES, to do with actually calculating the emissions: https://github.com/NGEET/fates/issues/1088