ckoven
commented
6 years ago this was solved a while ago. closing.
Closed rosiealice closed 6 years ago
ckoven
commented
6 years ago this was solved a while ago. closing.
Converting the email thread started by Yi on the logging extraction process to a GitHub issue, since it seems somewhat complex.
Original question from @xuyi02: There are two approaches to remove CWD of the trunks from logged trees in codes and keep the CWD fraction values as they are in the input file file (i.e., variable of SF_val_CWD_frac in the function of CWD_input).
In the first approach (currently implemented in FATES, 90% completed), we removed the trunk of logged trees from the input of above ground CWD (i.e., CWD_input function). So firstly we modify currentCohort%n to exclude the logged trees and other damaged trees to calculate above ground CWD from turnover trees. Then we add CWD from twig, small branch and large branch of logged trees as well as above ground CWD from collaterally and mechanically damaged trees into the input of above ground CWD.
The second approach was suggested by Rosie: Remove the trunk of logged trees from the output of above ground CWD (highlighted in red arrow, i.e, CWD_out function). To do this, we need to create a new variable to memorize the CWD from trunk of logged trees and take it out of CWD_ag_out.
From @ckoven: Overall this looks good, but I’m not sure I’m following the logic of the two proposed methods of your point 1. It seems like we'd want to remove the wood from the biomass pool directly, rather than either the cwd_in or cwd_out fluxes. The issue with doing it from cwd_in is that that flux only tracks live-dead fluxes associated with understory mortality (not canopy mortality as that is currently passed directly from live to CWD without going through the CWD_in flux). The issues with removing it from CWD_out is that there is no guarantee that the amount of wood you remove is consistent with the logging flux or aboveground biomass pool itself that way.
So instead I’d maybe suggest that we create a separate sequence, probably after all of the natural growth/disturbance processes, and then calculate the logging fluxes from live to product pools, logging-associated mortality fluxes from live to CWD/litter pools, and patch disturbance processes all at once in that separate call sequence. That way we can more easily keep track of the distinction between logging-asscoiaetd distrubance and non-logging-associated disturbance, and have a clearer set of drivers for when we want FATES logging to be driven via the land-use drivers from CLM or ACME.
From Rosie : How would that idea work wrt gap creation (from logging big trees) if it was called -after- the disturbance call? Would we need to do the whole patch disturbance call again? (once for natural canopy mortality and once for logging canopy mortality)?
Might we 'just' implement separate logging fluxes for canopy and understorey trees, like there are for natural mortality? (though this is admittedly already annoying and clunky already)
I think this is not as straightforward as I'd originally thought...