potential disconnect between disturbance and litter fluxes

[rgknox]

In subroutine spawn_patches(), we are looping through the existing patches on the site, and then based on the rate of disturbance on the existing patches, litter fluxes between the existing patches and the donor patch are calculated.

if (currentSite%disturbance_mortality > currentSite%disturbance_fire) then !mortality is dominant disturbance
             call mortality_litter_fluxes(currentSite, currentPatch, new_patch, patch_site_areadis)
          else
             call fire_litter_fluxes(currentSite, currentPatch, new_patch, patch_site_areadis)  
          endif

The problem is that we have different fluxes associated with the different dominant modes. Each patch has its own dominant mode which defines the mortality rates and area change rates. But, as you see above, we are deciding which litter flux mode to use based on the which is the dominant mode for the site. But a site could have patches with different modes. And in that case, we will have some patches which are producing mortality, area changes and donating to other patches based on their patch defined dominant mode, yet the litter fluxes won't be included because a different site disturbance was dominant.

[ckoven]

@rgknox and I are chatting about this. we both agree that the disturbance decision ought to be handled at the patch rather than the site level. The question is whether its as simple as just changing that line or whether other things need to be done too.

[rosiealice]

I agree that this is inconsistent and should be modified for the sake of getting the logging code operational. I general, has anyone else thought about sensible ways of doing disturbance so that we don't have to 'decide' what type of disturbance happened? The 'dist_type' idea came along with the original ED code, and is retained in this type of calculation. One thing that it does is prevent circumstances where disturbed areas add up to >100% of the total area, (e.g. fire=80%, mortality = 25%, so we only choose fire) but it could potentially cause some quite pathological things to happen. Particularly for chronic types of disturbance, for example, if fire was 1/365% per day, and mortality was 2/365% per day, then we would never see any of the fire, even though it would increase disturbance by 50%... In principle we could implement some sort of conditional probabilities idea where we account for the part of the gridcell where there was some mortality AND a fire happened in a given timestep, and thus do away with the idea of disturbance type altogether, and this was one of the ways I thought that the mortality code could be improved. So a) does that make any sense to anyone else, b) is there a reason to not do that in the long run, other than time and the complexities of having to track the actual and conditional disturbance rates and the potential confusion that might arise?

…

On 31 August 2017 at 14:12, Charlie Koven ***@***.***> wrote: @rgknox <https://github.com/rgknox> and I are chatting about this. we both agree that the disturbance decision ought to be handled at the patch rather than the site level. The question is whether its as simple as just changing that line or whether other things need to be done too. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#266 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMWsQxOpl07AVTku0HhKSHmiXsb2j_Cbks5sdxO_gaJpZM4PGumj> .

-- ----------------------------------------------------------------- Dr Rosie A. Fisher Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305 USA. +1 303-497-1706 <(303)%20497-1706> http://www.cgd.ucar.edu/staff/rfisher/

[ckoven]

@rosiealice yes, I've been thinking for a while that we ought to move towards a unified disturbance scheme ("unisturb"?) that handles the various disturbance routines at once and simultaneously rather than piecemeal and alternately; and @rgknox and I were just talking about this too. I think a plan is that once Yi's code is integrated into master, we could then proceed to refactor all the disturbance code to avoid the one-or-the-other issue.

[rgknox]

How about we let the disturbance areas co-exist, generating a separate new patch for each disturbance mode. Patch fusion will kick in anyway after everything is done.

In the case that the total disturbed area is greater than something like 1, or close to 1:

We could do map the multiple rates unto 2 and 3 dimensional spaces.

For instance if fire rate is 0.25, and treefall is 0.45

Project those two rates onto a square as the margins.

Area that suffers from both simultaneously (we will have to figure out how that is applied) =  0.25*0.45
Area that suffers from just fire =  0.25*(1-0.45)
Area that suffers from just tree-fall = 0.45*(1-0.25)
Total area disturbed = sum of the three
``
As how to handle the  "simultaneous portion": we could assign a priority.  Simultaneous fire and treefall acts like fire, simultaneous logging and treefall acts like treefall, simultaneous logging and fire acts like logging, or something like that.   

[rosiealice]

That all sounds sensible... Particularly the bit about fusion handling it. The overlap code sounds like it might end up as ominously complex when I think about it though. I wonder what the simplest solution to that is? Maybe just capping fire size so the total is never > 1? Deciding that disturbance isn't actually random in space and that the system minimizes overlaps?

…

On Aug 31, 2017 5:07 PM, "Ryan Knox" ***@***.***> wrote: How about we let the disturbance areas co-exist, generating a separate new patch for each disturbance mode. Patch fusion will kick in anyway after everything is done. In the case that the total disturbed area is greater than something like 1, or close to 1: We could do map the multiple rates unto 2 and 3 dimensional spaces. For instance if fire rate is 0.25, and treefall is 0.45 Project those two rates onto a square as the margins. Area that suffers from both simultaneously (we will have to figure out how that is applied): 0.25 *0.45 Area that suffers from just fire: 0.25*(1-0.45) Area that suffers from just tree-fall 0.45*(1-0.25) Total area disturbed = sum of the three As how to handle the "simultaneous portion": we could assign a priority. Simultaneous fire and treefall acts like fire, simultaneous logging and treefall acts like treefall, simultaneous logging and fire acts like logging, or something like that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#266 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMWsQ2V-tbPWc4FyOQz3DDWLfgdpQYebks5sdzyVgaJpZM4PGumj> .

[rgknox]

I'm fine with that approach Rosie. I think that also makes sense given that, if we need to cap, it is surely fire that has a wayyy higher rate than treefall.

However, what is the reduction priority if logging is involved? Or do we simply reduce whatever is the highest rate to get to 1.0?

[rgknox]

The filtering for which litter flux case to implement has been brought to the patch level in #264.