Track secondary forest area to keep primary and secondary patches distinct

[ckoven]

This PR creates a patch labelling system to track secondary forest patches as separate from primary forest patches. We can thus track the area, biomass, time-since-anthropogenic-disturbance, and time-since-any-disturbance separately for the secondary forest fraction.

This is based on the logging code already in the module. Secondary forest patches are generated either by anthropogenic disturbance from any patches, or by natural disturbance from other secondary forest patches. The maximum number of patches per site is changed from a scalar (default had been 10) to a vector so that we reserve a maximum number of patches in each category. Provisionally I've kept the number of primary forest patches at 10, and added a max of 4 secondary forest patches. During Patch fusion, it will only fuse patches of the same anthropogenic disturbance label.

This PR completes point 1 on the task list outlined in #450.

Collaborators:

discussions with several people based around the tasks outlined in #450.

Expectation of Answer Changes:

For the case with no harvest, this should be bit for bit with master. For cases with harvest, it will differ qualitatively.

I have done some simple tests to ensure that the code is doing what it is supposed to do. E.g.: a short run, started from inventory, with logging turned on, using a specified set of logging parameters as in the default parameter file. These generate annual logging events on the 30th day of each year, where 15% of the trees larger that 50cm are harvested during each event and 5% of all trees are killed by mechanical damage. Attached a figure showing the timeseries of secondary forest area from the simulation. The reason the growth rate is smaller than 15% per year is that the larger trees occupy only about half of the crown area to begin with and get thinned out pretty quickly by the successive logging events.

Checklist:

• My change requires a change to the documentation.
• I have updated the in-code documentation .AND. (the technical note .OR. the wiki) accordingly.
• I have read the CONTRIBUTING document.
• FATES PASS/FAIL regression tests were run
• If answers were expected to change, evaluation was performed and provided

Test Results:

I have't run it through the test suite yet.

CTSM (or) E3SM (specify which) test hash-tag:

CTSM (or) E3SM (specify which) baseline hash-tag:

FATES baseline hash-tag:

Test Output:

[mdietze]

Great to see this sort of functionality come into FATES. Two minor suggestions:

1. Make sure to really document the semantics of this well in the external documentation and publications! Models have to be semantically precise and draw lines that are internally consistent, but those lines inevitably conflict with other peoples definitions or intuitions, and more importantly it can be different from other peoples data (e.g. LULUCF mapping) and lead to invalid benchmarks. For example, if I'm standing in the middle on a completely devegetated landscape immediately post-fire, few field ecologists would call that a primary forest. FATES does. Pretty sure ED does too. Not sure how different remote sensing products would classify it.
2. You might consider tweaking your scheme to allow for an extensible number of classes rather than just two. In previous conversations with Moorcroft, I got the impression that the original Albani scheme had always been intended to be something that could be more extensible. Within the MANDIFORE project we're looking into leveraging that functionality to add more nuance to different management classes (e.g. production, passive, ecological, preservation, censu Becknell et al. 2015 Bioscience) that might have have different harvest frequencies, BA removal, degree of fire suppression, etc.

[jenniferholm]

In our discussion meeting at AGU, Peter mentioned that secondary forests will never return to primary forests, and I think this is how CLM operates. I'm wondering if this should be discussed?

I'm tending to think that once a forest patch has been altered by humans maybe it can never return to primary. For example if the physical conditions of the patch, or processes of the cohorts become so altered by anthropogenic disturbance, than it cannot return.
But maybe if the harvest is a low level of selective harvesting, and the patch does not get harvested again (would that be an option?), then this would be similar to something like a natural blowdown and the surrounding late successional cohorts would aid in eventually developing a community that is very close to primary forest.

Along these same lines, do we need to distinguish when a secondary forest is different from degraded primary forest? Or is that too nuanced.

[bpbond]

@jenniferholm It seems like the whole point of that approach (once you lose primary forest status, it's gone forever) is its, um, black-or-whiteness. So I don't think you could allow any primary forest 'use' without entering a really grey area?

@ckoven 👏

[ckoven]

Hi all, a few quick responses:

@mdietze Yes, I do intend to write this up in the tech note. To be clear here, what we are calling secondary forest is that way only because of logging at this point; anthropogenic fire disturbance is not yet a thing in the model. Re the point of extensibility, the way I've coded it so far should be fairly extensible if we want to add more classes. We just need to adjust the n_anthro_disturbance_categories parameter here:

fates/main/FatesConstantsMod.F90

Line 29 in 284a49a

integer, parameter :: n_anthro_disturbance_categories = 2

, give that category an allowable number of patches here:

fates/main/EDTypesMod.F90

Line 20 in 284a49a

integer, parameter :: maxPatchesPerSite_by_disttype(n_anthro_disturbance_categories) = (/ 10, 4 /) !!! MUST SUM TO maxPatchesPerSite !!!

and then add the logic to define what those patches would be. At this point I see the science of that as a thing to do in the second phase of this effort, where we pull in the full LUH2 transition matrix.

@jenniferholm right now the primary -> secondary forest is one way. I had thought about possibly making it allowable to go back after some long period of time, but the trick there is that within the secondary forest you still have background natural disturbance regime that causes the patches to start losing their history. if you only took the oldest patches then that would mean that only the non-gap portions of the forest got made "primary" again. So I think for now its simplest to leave it as a one-way transition.

One larger and related issue to both of your points that occurs to me is how to handle the fraction of the forest that isn't cut during a selective logging event. i.e. if we specify 15% of the forest be logged, but only of trees with some minimum diameter, then what do we do with the remaining trees? currently they stay in their original patch, which keeps the primary forest label. If we fully clear-cut some fraction of the forest (by specifying a zero minimum diameter) then it should not be an issue. But I wonder if during the logging when we do specify a minimum size, that we also take the same fraction of any canopy trees below the size threshold, and move them into a secondary forest patch to represent a degraded forest state. If so, then a question is whether we put them in the same patch or a different one.

[rgknox]

haha, nice catch @ckoven ! This never would had been tripped!

[rosiealice]

@ckoven, the issue you raise about what to do with the secondary-but-unlogged forest is I think in principle similar to the issue of understory/non catastrophic fires, in that in reality there is a thinned out ecosystem that we want to retain, but it doesn't fit neatly into a 'disturbed or not-disturbed' classification (where disturbance is an all-or-nothing process). I'd be tempted to say the entire area is switched to a secondary forest labels, and then let the fusion algorithms decide what to do about it, given they can discern different densities of biomass and are allowed to fuse with any other patch, (not just their 'older' and 'younger' neighbors as per the modifications for SPITFIRE).

[ckoven]

@rosiealice the more I think about it the more I agree with the solution you propose. It doesn't make sense to me to think of the trees that aren't harvested during a selective harvest event as constituting 'primary forest' anymore. So if we do that, then it would mean that our definition of secondary forest would also include degraded forest. To me that is the simplest logically consistent solution here. But perhaps we should make adding that change a separate PR since it may require more involved changes to the disturbance code.

[rosiealice]

Yeah, I guess degraded and secondary forest are really just two points on a continuum of harvesting severity and thus can both be considered as 'not primary' and thus secondary? Maybe that's something someone that know more about these definition than me should/could weigh in on though, incase it conflicts with more widely used LUMIP/LUH2 type definitions? @dlawrenncar @lawrencepj1 @kvcalvin? @ckoven 's original query is below:

"One larger and related issue to both of your points that occurs to me is how to handle the fraction of the forest that isn't cut during a selective logging event. i.e. if we specify 15% of the forest be logged, but only of trees with some minimum diameter, then what do we do with the remaining trees? currently they stay in their original patch, which keeps the primary forest label. If we fully clear-cut some fraction of the forest (by specifying a zero minimum diameter) then it should not be an issue. But I wonder if during the logging when we do specify a minimum size, that we also take the same fraction of any canopy trees below the size threshold, and move them into a secondary forest patch to represent a degraded forest state. If so, then a question is whether we put them in the same patch or a different one."

[dlawrenncar]

Under the standard definitions in land use community and LUMIP, primary forest or primary land (e.g., natural grasslands) is only land that hasn't been impacted by humans. If there is selective logging in a specific primary forest area, then that forest area would be transitioned to secondary forest. Once land is converted from primary to secondary (according to LUH2 definitions), it can never be converted back to primary land. So, Rosie's initial statement in prior is correct.

…

On Wed, Jan 9, 2019 at 2:39 AM Rosie Fisher ***@***.***> wrote: Yeah, I guess degraded and secondary forest are really just two points on a continuum of harvesting severity and thus can both be considered as 'not primary' and thus secondary? Maybe that's something someone that know more about these definition than me should/could weigh in on though, incase it conflicts with more widely used LUMIP/LUH2 type definitions? @dlawrenncar <https://github.com/dlawrenncar> @lawrencepj1 <https://github.com/lawrencepj1> @kvcalvin <https://github.com/kvcalvin>? @ckoven <https://github.com/ckoven> 's original query is below: "One larger and related issue to both of your points that occurs to me is how to handle the fraction of the forest that isn't cut during a selective logging event. i.e. if we specify 15% of the forest be logged, but only of trees with some minimum diameter, then what do we do with the remaining trees? currently they stay in their original patch, which keeps the primary forest label. If we fully clear-cut some fraction of the forest (by specifying a zero minimum diameter) then it should not be an issue. But I wonder if during the logging when we do specify a minimum size, that we also take the same fraction of any canopy trees below the size threshold, and move them into a secondary forest patch to represent a degraded forest state. If so, then a question is whether we put them in the same patch or a different one." — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#454 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUAcVC2mbk5OJUQz42ViF-qjbX-7fwHVks5vBbjEgaJpZM4Zcois> .

[rgknox]

Checked through restart requirements. Looks good to me, I can confirm that only the the disturbance classification and the age since anthro disturbance are necessary.

[rgknox]

Great use of named constants, two thumbs up

[rgknox]

makes sense

[rgknox]

@ckoven, is it possible that the following logic could be true for cases where the new_patch_secondary is not allocated?

[rgknox]

actually, hold on this. The conflict resolution with master will require this to be irrelevant. Will submit a PR to your branch.

[ckoven]

An update on this. I updated the disturbance code so that it now moves the canopy trees that aren't harvested on account of being below the minimum harvest size into the secondary patch as well. So this makes the secondary forest designation also apply to degraded forest area that has had its large trees logged, as per the discussion above.

Another subtle change that I made here is on the logging-related collateral mortality -- before that was only applied to trees above the harvest diameter with the trees below that assumed to be handled by impact mortality during harvest; but that misses the trees that were in the canopy but below the size threshold. So I've provisionally updated the logic of collateral damage during logging to apply to canopy trees irrespective of their size and let the understory trees suffer from impact mortality. But I want to check with @huangmy and @xuyi02 if this change is consistent with their vision here.

Running this through the test that I used before, with annual harvest events of 15% harvest rate of trees greater than 50cm dbh; plus an additional 5% of collateral mortality and 5% of logging infrastructure mortality; this should therefore give 25% of the forest area as secondary after the first harvest. (Or, more precisely, 25% of the original area that is under tree crowns, which in this case is very slightly less). It now does so:

I think this should be ready for testing and review now.

[huangmy]

@ckoven : I went through the comments and the code, and your modification make sense to me logically. On the other hand, I tried to recall why I made that decision a while ago after talking to @rgknox . I am sure that I did that in case there were too may small trees/biomass in the canopy layer, which would lead to a large flux to CWD and therefore downstream processes. My numerical experiments suggested that it was a possibility at least at that moment. Is that less a problem after your recent changes?

[ckoven]

@huangmy Great, thanks for looking over the changes. I see your point about the possibility that the model could generate too much CWD, and its possible that high CWD could still be a problem. But if it is, then to me a better solution would be to reduce the value of the collateral damage parameter and keep the logic most self-consistent, rather than to keep the nominal value of the collateral damage parameter high, but apply the size-class filter; especially given that the collateral damage parameter strikes me as pretty unconstrained by the literature. Would you be ok with that solution if it were needed?

[huangmy]

@ckoven Yes, you are correct that the collateral damage parameter is not well-constrained. So this solution sounds good to me. Please feel free to proceed. We might need to add a note to the parameter file or the user guide on this so that users are aware of potential issues.

[rgknox]

@ckoven , does age_since_anthro_disturbance tell us anything different than "age"?

[ckoven]

yes. age gets reset whenever any disturbance happens, age_since_anthro_disturbance only gets reset during a harvest event. So, if you have a secondary forest patch that also has other disturbance on it, this information allows you to do something like still go and harvest all the land on a set forest rotation schedule.

[rgknox]

So if a secondary forest patch experiences a tree-fall event, the patch that is created should not reset its age_since_antrho_disturbance, instead it retains that value.

[ckoven]

that's the idea.

[rgknox]

This whole allocation block needs to be removed.

[ckoven]

yep, good catch.

[rgknox]

Checked through to see that age is set to zero for the new secondary patch, and that age sets the age since anthro disturbance, and that angtho age is updated when secondary patches donate area through natural means. If they donate through a logging event, then they contribute a zero to the weighted age of the new secondary patch. Makes sense to me.

[rgknox]

testing

[rgknox]

All expected pass b4b with master, except the 2 year 1x1 brazil, which did not complete due to exceeding the time limit (2 hours). The baseline required 30 minutes. I suspect that the node just got hung up. Will check through the differences in time on the other tests.

[rgknox]

SMS_Lm6.f45_f45_mg37 went from 55.792 -> 70.595 seconds
ERS_Ld60.f45_f45_mg37 (run 1) 21.915 seconds -> 19.248
ERS_Ld60.f45_f45_mg37 (run 1) 19.358 seconds -> 22.352 seconds

I will re-test

[rgknox]

I re-tested and found that the 2 year test completed in about 11-12 minutes, well within the expected time. I can only guess that because this test takes longer, it experienced machine related slow-downs that only it experienced.

/glade/scratch/rgknox/clmed-tests/fates.cheyenne.intel.secondary-0sec-extendwall-v2-Ce862304-F033090c/

I will retest one more time though to be sure, then will integrate.

Also performed 50 year tests on the f10 grid, simulation completed:

/gpfs/fs1/scratch/rgknox/fates-clm-tests/12pft-demprom-secondary-loopcheck-f10_f10_mg37

[rgknox]

sent a conflict resolution to @ckoven. All pass on that branch:

/gpfs/fs1/scratch/rgknox/clmed-tests/secondary-final0-Cbc17668-F30f0809.fates.cheyenne.intel

will integrate pending acceptance