Skip to content
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

Open
rosiealice opened this issue Sep 15, 2023 · 10 comments
Open

Make fire emissions work with FATES. #35

rosiealice opened this issue Sep 15, 2023 · 10 comments
Assignees
Milestone

Comments

@rosiealice
Copy link
Collaborator

rosiealice commented Sep 15, 2023

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

@rosiealice
Copy link
Collaborator Author

rosiealice commented Sep 22, 2023

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:

Image

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.

Image

Also for reference, this is the table of EFs from the original SPITFIRE model, depicted in their table 1:

Image

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).

Image

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

@rosiealice
Copy link
Collaborator Author

rosiealice commented Feb 9, 2024

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.

  • Make branch for fire emissions starting from most recent FATES tag on NorESMhub
  • Corresponding CTSM branch on the NorESM repo

INPUTS

  • Create parameters for fire emissions factors in pft file. These are dimensioned as the number of emission types by PFT.

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.

  • Make fire emissions branch.
  • Link emissions up to existing emissions variables in CTSM.
  • Make sure these variables are created when fates is running.

Build, submit, test,

  • Run a NOCOMP simulation with fire
  • Check fire emissions happen.
  • Think of sanity checks to assess that the model is doing the right thing.

Do PR, declare victory..

L

@rosiealice
Copy link
Collaborator Author

rosiealice commented Feb 16, 2024

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

@mvdebolskiy
Copy link
Collaborator

Working branches:
CTSM: feature/fates-fire-emissions
Fates: feature/fates-fire-emissions

@rosiealice
Copy link
Collaborator Author

Fireflx_patch is the emissions variable in CLM
Fireemis_inst@ztop_patch is the emissions height variable.

@mvdebolskiy
Copy link
Collaborator

Fire emissions namelist logic
Fire emissions namelist definitions
Fire emissions namelist defaults

@rosiealice
Copy link
Collaborator Author

rosiealice commented Feb 16, 2024

New, post meeting to do list.

  1. Duplicate CNFireMod logic in FATES.
  2. IF block in lnd_atm to use fates emissions instead of c .
  3. CLM namelist to control whether to use FATES emissions or not when FATES is on.
  4. Emissions factors in FATES parameter file.

@rosiealice
Copy link
Collaborator Author

image

@rosiealice
Copy link
Collaborator Author

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.

@rosiealice
Copy link
Collaborator Author

rosiealice commented Mar 1, 2024

Additions to to do list from meeting

  • Make wrap_btran like function to spread the fire emissions out through the day.
  • For exact restarts we need to somehow read things in from the researt file.
  • Pass the number and names of the emissions species that the HLM demands, into FATES.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

4 participants