Opened 3 years ago
Last modified 3 years ago
#764 new enhancement
Restructure the variable harvest_pool
Reported by: | luyssaert | Owned by: | somebody |
---|---|---|---|
Priority: | major | Milestone: | Not scheduled yet |
Component: | Anthropogenic processes | Version: | trunc |
Keywords: | Cc: |
Description (last modified by luyssaert)
The code of r7113 distinguishes 12 different sources of vegetation mortality, however, the history files distinguish just 3 sources. These three sources distinguish crop, grass and wood harvest because this separation could make use of the PFT-dimension of the variable harvest_pool. If future application require distinguishing between land cover changes, management and natural disturbances and additional dimension could be added to this variable. Note that this additional dimension would considerably increase the memory use of the variable but would remain a sparse matrix (mostly zero values).
Note that the harvest pool is expressed in gC/grid/y. The reason why the absolute harvest flux is written to the history files rather than the relative flux (gC/m2/y) is that land cover change (but also a clear cut) could result in setting the veget_max of the PFT to zero. In that case we would have a flux value that can no longer be upscaled to the pixel level because veget_max of the PFT that was harvested/cleared/changed is now zero. This could of course be solved by storing the veget_max prior to harvesting/clearing/changing and using this veget_max whenever dealing with the harvest_pool. That seems even more error prone (especially in the mass balance checks) than the decision to use absolute fluxes.
The current implementation makes use of the variable harvest_type. This variable could be used to tell whether the harvest comes from harvesting/clearing/changing but this variable can only contain one value for each PFT at each pixel. Hence, only the last cause/source of the last harvest will be recored. Given that LCC is dealt with the first day of the year but the other disturbances can also occur later in the year this approach will result in underestimating LCC and overestimating forest management. For example, part of a forest PFT was converted to cropland at day 1. The biomass loss will be stored in harvest_pool and harvest_type is set to LCC. A few days later a winter storm resulted in considerable damage. The biomass loss will be correctly added to the harvest_pool but harvest_type will be overwritten as storm damage. Because of the storm many large trees were killed and the last day of the year the stand needs to be clear cut because its density has become too low. The biomass loss will be correctly added to the harvest_pool but harvest_type will be overwritten as clearcut. When analyzing harvest_pool and harvest_type for this pixel, all biomass losses will be assigned to clearcutting. To overcome this issue an extra dimension needs to be added. When this dimension is added the variables harvest_type and harvest_cut could be removed.
Change History (2)
comment:1 Changed 3 years ago by luyssaert
- Description modified (diff)
comment:2 Changed 3 years ago by luyssaert
- Priority changed from minor to major