Patch cutting in Harvest Library

When patchcutting is applied, the targeted patch size (e.g., 1 ha) is applied within a given stand and cuts patches that cannot be adjacent (1-cell buffer around each cut). The prescription attempts to harvest the targeted percentage of the stand (e.g., 50%). If the size and configuration of patches within the stand does not allow the targeted percentage of the stand to be cut, then the stand is rejected and no harvest occurs in the stand.

This does not cause a problem as long as there are other stands that can be harvested with the appropriate patch size that meets the stand percentage target (60%). However, if stands are relatively small and similar in shape, it can happen that too many stands are rejected for the management area target cut (e.g., 1%) to be reached. In some cases, all stands will be rejected and no harvest will occur. The result is not achieving the desired spatial arrangement (i.e., small patches) nor achieving the desired percent of the Management Area implemented.

The big-picture issue here is which targets are given highest priority when applying a prescription. In this example we have 3 targets: 1-ha patches, 60% removal within stands, and 1% harvest in the management area. The way it is applied right now, the 1-ha patches and 60% removal within stands are both given higher priority than the Management Area target. If the targeted stand percentage cannot be met with the assigned patch size, stands are rejected at the cost of meeting the management area target.

Jan 25, 2013 Project Member #1 brmirand I think a re-ordering of target priorities would be appropriate. I suggest that Management Area targets should be highest priority, followed by patch size, then stand percentage last. That would mean in the case described above, 1% of the management area would be cut in 1-ha patches, but in some cases <60% of individual stands would be cut. The harvest log files already contain the information needed to calculate the percentage of a stand cut, so users could evaluate how close they are coming to meeting the desired target and modify the prescription if not acceptable.

In terms of the code, this revision would simply not reject stands that cannot meet the stand target percentage.

Jan 27, 2013 Member #2 rmscheller I am against re-ordering of priorities. This principle is woven throughout the harvest extension: Stand ranking is independent of the management area target. If we drop this criteria, it opens the door to an infinite number of possible rankings, and I believe the extension would quickly become quite unmanageable. We are struggling to manage this code under the current (more rigid structure).

To resolve the current situation (more of a design issue than a bug), we could first drop the 1-cell buffer around each patch cut. I don't recall why that's in there and it really doesn't make any sense if you have any patch cutting > 35%. Sometimes a large patch will be created by chance. Not a big deal.

If there are still not enough stand, then there are not enough stands. It becomes incumbent upon the user to loosen their stand qualifications.

Jan 28, 2013 Project Member #3 brmirand I agree with your point that stand ranking is independent of the management target area. The issue at hand here is really just a stand ranking issue and whether or not stands get rejected based on whether they can meet the 2 targets of patch cutting (patch size, stand percentage). Right now a stand must be able to meet both targets or else it is rejected. If we want to avoid rejection of too many stands we need to give one of these targets priority over the other.

Your proposed resolution would give the stand percentage the higher priority. That is cut x% of the stands, even if patch sizes exceed the target size. I could also see value in the other order, where you would want the patch size to be matched and sacrifice the percentage of the stand cut.

So, here's my new proposed solution. Let the user decide which of these 2 patch cutting criteria should be given priority, or neither. I'm thinking about adding an optional input parameter for patch-cutting. It might look something like this.

SiteSelection PatchCutting 15% 3 -- The current method. Without the optional parameter the algorithm stays unchanged with stands having to meet both patch size and stand % to be eligible.

SiteSelection PatchCutting 15% 3 Patch -- The keyword Patch indicates that patch size should be given priority over stand % cut. Don't reject stands is unable to reach targeted % cut.

SiteSelection PatchCutting 15% 3 Percent -- The keyword Percent indicates that stand % cut should be given priority over patch size. Don't apply the 1 cell buffer.

This would take a little extra effort to code, but I don't think it would be terrible . This would obviously require some Users Guide revisions as well, including an explanation of the implications of the default method. I am open to suggestions for better keywords if you can think of something better. I think this solution would meet everyone's needs, but let me know if you see any issues with this.

Jul 25, 2013 Project Member #4 rmscheller Brian,

I think the suggested change is worth pursuing, particularly now that the Base Harvest is more stable. However, as a warning, the Base Harvest code is a real thicket and it will take a substantial investment of time to achieve.

Another option: Keep PatchCutting as is and add PercentCutting with the same inputs but with a different priority. This may be easier to code and clearer to the user.

Oct 17, 2014 Project Member #6 lbross@pdx.edu Brian,

Do you have some sample scenarios you can share with me that will allow me to recreate/validate the issue?

Oct 20, 2014 Project Member #7 brmirand Lesley,

I am sending you a set of parameter files that demonstrates this issue. To make sure it gets through, I am sending through Hightail.com. In the Zip file, you'll see 2 harvest parameter files. 'PatchCutting_fails.TXT' shows the issue and fails to harvest any stands. 'PatchCutting_works.TXT' has a different target patch size, and does successfully harvest stands. Let me know if you have any questions on these files.

Hightail download link: https://www.hightail.com/download/UlRUc0x5Z2dnYU94djhUQw

-Brian

Oct 21, 2014 Project Member #8 lbross@pdx.edu I've got the sample files. Thanks Brian!

Oct 28, 2014 Project Member #9 lbross@pdx.edu After reviewing the code, I am in favor of Rob's proposed solution from 25 July 2013: creating a new PercentCutting prescription. The PatchCutting algorithm is complex and I'm concerned about the risk of introducing new conditional logic.

Giving patch size priority over stand % cut is clear. I'm not sure how prioritizing stand % cut over patch size would work. Do you envision one large patch in each stand? I wonder if we should at least enforce a minimum patch size? Oct 29, 2014 Delete comment Project Member #10 brmirand I am fine with adding a new type of prescription instead of essentially overloading the existing PatchCutting. I see a PercentCutting prescription working nearly the same as PatchCutting, except not enforcing the 1-cell buffer that limits where multiple patches can go within a stand. We would still have a minimum patch size defined, and the only difference should be that when the percentage to cut within a stand is fairly high, some of those patches will be adjacent to each other, effectively creating bigger patches.

In the end, the user should have 2 clear choices: 1) Patch size is most important and we never want patches larger than the defined patch size, even if we cannot reach the targeted % stand to cut. Use PatchCutting. 2) The percentage of each stand to cut is most important, and it is okay to sometimes have larger patches than the target. Use PercentCutting.

Both options will have the possibility of not reaching the management area harvest percentages, and this should be added as a note in the Users Guide. If this occurs, and management area prescription percentages are most important, the user would need to relax the limiting factor (either patch size or stand % cut) in order to reach the management area target. But failure to reach the MA target should be reduced because each option will be limited by only 1 restriction, instead of having to meet both at the same time as it is now.

Oct 29, 2014 Project Member #11 lbross@pdx.edu After reviewing the code and documentation, it seems that the 1-cell buffer is an unintended consequence of the algorithm that generates the patches. The cells at the edge of a patch are withdrawn from the pool of available cells as the patch is generated. When the patch reaches its desired size, any cells that aren't included in the patch aren't returned to the available pool. This results in a border around each patch.

Returning these cells to the available pool could result in adjacent patches but each individual patch would technically still be the desired patch size. Is this a problem? If not, I could make this change to the existing PatchCutting selection group.

Adding the option to harvest the stand regardless of whether or not it meets the targeted % (choice 1) to the existing PatchCutting selection group seems straightforward.

If we want to leave the 1-cell buffer in place for the existing PatchCutting Site Selection configuration, I'll need to think about whether a new Site Selection configuration is best.

Oct 30, 2014 Project Member #12 brmirand via email I see value in having both the options of keeping the border cells out of the available pool and returning them to the pool. That's essentially the difference in the 2 options I listed before. In some cases a strict patch size is important, which means you cannot allow adjacent patches that would result in a combined larger patch size. In other cases, it doesn't really matter if adjacent patches combine, but you want to remove a certain proportion of the stand. We should give users the choice to do it either way.

Nov 5, 2014 Project Member #13 lbross@pdx.edu After additional consideration, it seemed that the code changes were minor enough that they could be included in the existing PatchCutting prescription. They new keywords are PatchSize and PercentCut. As requested, if neither of these keywords are present, the prescription will run as it always has:

SiteSelection PatchCutting 75% 10 PatchSize SiteSelection PatchCutting 75% 10 PercentCut

I updated the installer for base harvest 2.3 to use the new harvest libraries but am waiting to hear from Jimm whether or not I should commit it. I e-mailed the installer today to those associated with this issue so they can test.

I temporarily added a log entry that says which priority is being used. This will let you confirm that you are using the new version. The line will look something like this:

Nov 18, 2014 Project Member #14 lbross@pdx.edu Changing status to started. Awaiting verification from Brian so I can take out the extra log entry before marking as fixed.

LANDIS-II-Foundation / Library-Harvest-Mgmt

Patch cutting in Harvest Library #1