You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A thing occurred to me recently that I am not sure about how we should deal with. Since #279 the canopy spread logic has been at the site rather than the patch level. In the case of a nocomp configuration, if the total area in which woody PFTs can grow is less than the canopy closure threshold parameter on a given gridcell, then the trees will always remain in the high-crown-area state. This doesn't seem ideal to me but I am not sure what the best alternative is. We could change the canopy spread parameter when in nocomp configuration to make it a vector of length nocomp PFTs and evaluate it separately on patches of each nocomp PFT. Or maybe we could leave as-is. Curious if others see this as a problem in the current scheme or if anyone sees a better solution.
The text was updated successfully, but these errors were encountered:
Also noting that this will also apply when and if we have managed land-use types that exclude woody plants: if their total area approaches one minus the canopy closure threshold, then that would change the crown area allometry of trees in the unmanaged land-use types.
glemieux
changed the title
canopy spread in nocomp mode
canopy spread issues
Feb 27, 2023
A thing occurred to me recently that I am not sure about how we should deal with. Since #279 the canopy spread logic has been at the site rather than the patch level. In the case of a nocomp configuration, if the total area in which woody PFTs can grow is less than the canopy closure threshold parameter on a given gridcell, then the trees will always remain in the high-crown-area state. This doesn't seem ideal to me but I am not sure what the best alternative is. We could change the canopy spread parameter when in nocomp configuration to make it a vector of length nocomp PFTs and evaluate it separately on patches of each nocomp PFT. Or maybe we could leave as-is. Curious if others see this as a problem in the current scheme or if anyone sees a better solution.
The text was updated successfully, but these errors were encountered: