Discussion of logging event behavior in the context of other disturbance

[glemieux]

My Q's above still stand. Thinking more on this, by setting harvest_rate = 1 the current logging event behaviour is functionally equivalent to setting fates_mort_disturb_frac = 0. Is that the behaviour we're going for? Wouldn't that mean canopy gaps caused by logging could close v rapidly due to gap filling done according to PPA rather than gap-phase regrowth?

Originally posted by @walkeranthonyp in #961 (comment)

[glemieux]

The above questions referred to above can be found in issue #961 (comment) and are quoted below. @walkeranthonyp please feel free to adjust the name of the discussion title if it is inaccurate. I only skimmed the original discussion.

From your comments and reading of the code, logging enacted from the param file is supposed to affect 100% of the area so that all of a logged patch becomes a new patch. But damage to plants only happens through lmort_direct, lmort_collateral, lmort_infra. All l_degrad does is to bring the part of the patch not damaged by logging into the new patch. Is that accurate (or close enough)? If so I have two questions:

1. I guess that means PPA can kick in on the new logged patch so whatever trees are not damaged can fill the canopy rapidly. Is that the desired effect?
2. What happens in the case of HLM driven harvest if/when l_degrad is high? That seems inconsistent with the intention of the land use dataset which I guess assumes that all of the area defined by harvest_rate is damaged in some way - or is l_degrad always low in these simulations and/or lmort_collateral, lmort_infra and lmort_direct are controlled by the HLM / land use dataset?

[sshu88]

Hi @walkeranthonyp . Just saw this discussion and I can share with you the current behavior of FATES under the situation described by Q #2.

First, l_degrad ( = (1 - logging_direct_frac - logging_collateral_frac - logging_mechanical_frac) * harvest rate ) can be directly controlled through FATES parameter file. I guess these parameters are designed for selective logging. So before any simulation I would suggest to revise these parameters from the default values based on your own experiment design. In the case of global simulation, only the portion of wood trunk (struct + sapwood) under logging_direct_frac will be harvested and put into the product pool, the portion under l_degrad will be sent to the new patch and other parts will be sent to litter.

Thus, if your harvest rate forcing is the actual harvested wood (area or biomass/carbon), logging_direct_frac need to be changed to 1 and other two parameters to 0 in order to keep consistency to the forcing, and LUH2 belongs to this case (Although I'm also confused about if they accounted for total forest carbon or only forest trunk when they resolve the spatial distribution of harvest rate from country-level wood harvest list. And using total vegetation carbon is inaccurate). This means we can only perform clear-cut instead of selective logging from the current FATES in this case.
If the harvest rate forcing is area or biomass affected by the logging activity, you can test your combination of these parameters.