-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make fire emissions work with FATES. #35
Comments
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 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: 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.
OPERATIONS
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) |
Working branches: |
Fireflx_patch is the emissions variable in CLM |
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:
ESCOMP#1045'
and thus issue on FATES, to do with actually calculating the emissions:
NGEET/fates#1088
The text was updated successfully, but these errors were encountered: