Pass Harvested C from FATES to ELM and Activate Dynamics of Wood Product Pools

[sshu88]

Current ELM-FATES simulations can read land cover types and harvest rates information from surface data and pass these information in FATES. No information about harvested C flux into wood product pools is passed back to ELM. The following changes are made to pass harvested C wood products from FATES to ELM and activate the bookkeeping model in ELM when using FATES.

First, the following new site-level variables are defined: fates%bc_out(s)%hrv_deadstemc_to_prod10c and fates%bc_out(s)%hrv_deadstemc_to_prod100c. Both variables are calculated in EDLoggingMortalityMod.F90 following the same method in ELM::dynHarvestMod::CNHarvest (dyn_subgrid/dynHarvestMod.F90), i.e., use parameter ELM::pftvarcon::pprodharv10 to determine the fraction of wood products (currentSite%mass_balance(el)%wood_product) being put into the 10-years product pool. I added a new subroutine UpdateHarvestC to handle the calculation because no parallel subroutines available in FATES to perform the calculation. Since logging in FATES does not distinguish logging by PFT types (only by woody or non-woody), a mean value of all woody types is used for simplicity and further parameterization of this parameter is required. Second, values from FATES (such as variable hrv_deadstemc_to_prod10c) are transferred to ELM variables, col_cf%hrv_deadstemc_to_prod10c and col_cf%hrv_deadstemc_to_prod100c, in elmfates_interfaceMod.F90 through a newly created subroutine ELM::elmfates_interfaceMod::wrap_WoodProducts. This subroutine is called through ELM::EcosystemDynMod::EcosystemDynNoLeaching2 before calling ELM::WoodProductsMod::WoodProducts. Finally, subroutine ELM::WoodProductsMod::WoodProducts is activated under the “use_fates” tag to update wood product pools in ELM and calculate land use emission.

[ckoven]

Thanks @sshu88 for this update. I'm curious about the pros and cons of handling the prognostic wood product pools via a flux back to the host model versus keeping track of them at the site level within FATES (and possibly providing them as diagnostic variables to the HLM). Do you see there being a strong scientific argument either way? What information about the product pools does the ELM bookkeeping model want and what does it do with that information?

[jenniferholm]

Thanks @ckoven!
@sshu88 can provide more detail.... As just a short response here, we discussed both options for keeping track of the product pools on the HLM side vs. FATES side, and I believe Shijie would like to eventually implement both options. Since there are benefit/needs of the wood product "bookkeeping" on both ends. But, I would love to hear more discussion here, and if this seems like duplicative effort? (Therefore just pass over diagnostic variables from FATES to HLM).

As a first step the HLM still needs to receive the harvest wood products flux, and keep track of these variables for emissions, etc. @sshu88 - can you provide more detail here, and answer Charlie's question about what the ELM wants and does with this information? Thanks! But eventually the next step is also keeping the bookkeeping done on the FATES side. Which will be crucial if/when we add in harvest by PFT, or additional harvest, land-use parameters. I think Shijie wanted to work on one step at a time (at least in the PR).

@aldivi , @bpbond - do you guys have comments or thoughts on transferring harvested wood product pools from FATES?

[sshu88]

Thanks @ckoven for the comment. @jenniferholm and I actually discussed and planned to add both of them: A. passing prognostic wood product flux and activate wood product pool dynamics in HLM and B. duplicate wood product dynamics in FATES). In plan A, since ELM bookkeeping model only accounts for 2 pools (10 years and 100 years) and the partition of harvested wood C based on PFT-dependent parameters, the harvested wood flux is aggregated to grid level and all other information in FATES is collapsed, such as the quality of harvested wood product based on the species, age and DBH. In plan B, we can have more flexibility to expand the bookkeeping model, such as accounting for the combination of different quality of wood products and accounting for more detailed wood product turnover rates based on their actual usage. Right now we're at the first step to apply the plan A. To answer your questions, I summarized the advantages of both plans. For plan A:

1. Less coding effort and easy to complete.
2. Easier for model inter-comparison since the same bookkeeping model as others have been applied.

For plan B:

1. Can apply different strategy of wood harvest.
2. Can provide information for more realistic design of wood product pools driven by actual usage of the wood products.
3. More researches can be done to account for the consequence of different wood harvest strategy on local C cycle.

[rgknox]

Nice work @sshu88 . Both methods seem to have there merits. I'm not a big fan of implementing both ways, I would say choose a method and go with that until it doesn't work. It sounds like you have method A coded up already?

[sshu88]

@rgknox Testing the code using Brazil site now.

[ckoven]

Thanks @sshu88 this is really helpful.

[sshu88]

I have completed one site scale and one global scale validation for my revision.

Validation case 1: Single Site Test platform: Cori-Haswell

Ran a spin-up of Brazil site starting from 0 with Qian atmospheric forcing from 1951 - 2000 for 2 cycles, i.e., 100 years, to build up enough carbon pools. Start the simulation with do_harvest turned on and the logging event code set to default value (-30, harvest once a year on Julian Day = 30). The following variables are recorded:

Var 1. Harvested C flux (HARVEST_CARBON_FLUX) reported by FATES Var 2. Input flux of the harvested C into the product pools from ELM (“HRV_DEADSTEMC_TO_PROD10C”+”HRV_DEADSTEMC_TO_PROD100C”) Var 3. Land area of different secondary forest patches after harvest (SECONDARY_FOREST_FRACTION) Var 4. Primary Forest and Non-Forest Harvest rate by the time series data, i.e., “HARVEST_VH1”+”HARVEST_VH2”.

1) Check if the harvested C flux in FATES (Var 1) equals the harvested C flux from ELM (Var 2)? Yes, Var 1 and Var 2 equal each other . See the following plot.

2) Check if Var 3 from the FATES matches the harvest rate (i.e., change of the primary/secondary land fraction) read in from the time series file (Var 4)? Checked, and yes, Var 1 and Var 2 equal each other. See the following plot.

Note: Harvested C flux into wood products pool in ELM is in the unit of gCm-2s-1, but the wood product in FATES has the unit of kgC/site m2. Right now I transferred the unit to match ELM.

Codes for producing plots and the ELM-FATES history files are available through the following link: https://drive.google.com/drive/folders/1K81GMgat4zynZ4PLy-PsB4jF9vTcgNdm?usp=sharing

Validation case 2: Global 4deg x 5deg Test platform: Cori-Haswell

Ran a spin-up from 0 with Qian atmospheric forcing from 2001 - 2010 for 10 cycles, i.e., 100 years, to build up enough carbon pools. Start the simulation with do_harvest turned on and the same logging event code as site scale case. The same variables as single site cases are recorded:

1) Check if the harvested C flux from FATES (Var 1) equals the harvested C flux from ELM (Var 2)? Checked. See the following plot.

2) Check if Var 3 from the model matches the harvest rate (i.e., change of the primary/secondary land fraction) read in from the time series file (Var 4)? Checked. See the following plot.

Codes for producing plots and the ELM-FATES history files are available through the following link: https://drive.google.com/drive/folders/1tra5u5qgyx5afzWCdrHG8IOwd-vG9PNn?usp=sharing