Closed jsfried closed 6 years ago
I added a last page to this tethered calculation document that includes the combined calculation. Petitmermet_harvest_cost_model.docx
I'll tackle this first thing tomorrow, it looks like the do to list is something like this:
Harvester:
Forwarder:
Moving Jeremy's comment over: Bigger goof-up than what thought. We need to change the tethered system to accommodate handling of large log trees. They can be forwarded the same as the small log trees, but their felling must be by a manual felling equation (that also bucks and limbs, like those used in cable manual WT/log). Can you add that to the system? Otherwise, large log trees will end up coming out for free.
If I'm understanding, you're saying tethered systems needs 3 machines:
For 1/2, we will only use the Tethered system specific equations. It sounds like you want to have a specific one for Manual as well (i.e. don't get the average of all manual systems, use one specific equation)? And this Manual equation will be limited to large trees only.
That way, the final harvesting system cost for each stand will be:
TetheredHarvester_HPA CPH + TetheredForwarder_HPA CPH + TetheredManual_HPA * CPH
Does that mean we will also need a limiter for TetheredHarvester so that it doesn't remove large log trees? i.e. it will have a limiter based on percentage slope and log tree size (if so I need to also resolve issue https://github.com/USFS-PNW/Fia_Biosum_Scripts/issues/12 )? Or does it just ignore large log trees in determining hours per acre and that component gets added in from the manual hours per acre calculation?
Edit: I'm leaning toward the latter, if I understand correctly, since the harvester equation already only accounts for small trees. But we'd either need that separate manual equation or a manual equation that is limited to large logs
Not yet sure whether manual equations are broken down by harvest system. Under FRCS (and I assumed OpCost also) even in a mechanical system (like Ground-based Mech WT), there was an allowance to separately account for the harvest of a limited TPA of large log trees with chainsaw felling, because they are too large to be harvested by machine. But under a WT system like that, those fallers do NOT limb and buck (so sawyer time per large log tree should be shorter). In other systems (like Ground based CTL), large log trees are also manually felled, but also bucked and limbed (which presumably takes more time). Are there different saywer equations reflecting these differences or did that not get picked up on when OpCost was developed?
AS to the rest, yes. And "Or does it just ignore large log trees in determining hours per acre and that component gets added in from the manual hours per acre calculation?" Yes- the harvester only accounts for the small log trees and chip trees (if any). The large log trees are added on via the manual hours associated with chainsaw activity. Note that this means that what we mean by "total volume" or average volume varies by purpose. For harvester, it should be weighted combo of chip and small log trees. For forwarder, it should be weighted combination of all but brush cut trees. But a better architecture going forward would be to calculate these components for each log size class separately (chip, small and large) as there would be less artifactual error due to averaging.
A few of the harvest systems are set up to incorporate manual harvesting time:
Cable Manual WT Cable Manual WT/Log Ground-Based Manual WT Ground-Based Manual Log Cable Manual Log
But these are just taken from getting the mean of all the Manual machine hours per acre values. The behjou and ghaf ones were set to only be applied to stands where dbh.cm was greater than a value, but it was not consistent. hartsough and kluender manual were also used but were not limited.
It sounds like we want to be changing what equations/parameters are used based on the harvest system and not the other way around (which is essentially how it's set up now)? Does that sound right?
Because in theory the same equation could be used for two different harvesting systems, but the limiters would be different depending on the harvest system. If you recall, this issue came up with some manual systems already - some were limited to be only calculated certain DBHs, but then it gets averaged with other manual values when the harvest system cost is calculated.
Or the same equation could be used for two different harvesting systems, but the parameters could be different? That is, for the manual equations that were limited, for example, it's limited based on dbh.cm that was calculated as the average dbh calculated from the twitchVol. So it's calculating the hours per acre time based on the equation parameters (for behjouManual, dbh and distBetweenTrees) for stands where the average stand dbh.cm > 40, but wouldn't it then be including time to harvest smaller trees that wouldn't be harvested using manual methods? Or is that built into the equation already and the equation should just only be used for harvesting systems where those limits make sense?
That may be a separate issue we need to address later, because now I'm completely confused. If we're focusing on the tethered systems, a separate manual equation just for tethered systems based on large log volume/tpa will be the easiest solution.
CS: It sounds like we want to be changing what equations/parameters are used based on the harvest system and not the other way around (which is essentially how it's set up now)? Does that sound right?
JF: Yes, the harvest system determines what happens in the way of which machines and how they are used.
JF: Sorry for the confusion. For now, yes tethered system will need to add a sawyer component that averages sawyer equation results for equations that are designed to fall and buck and limb (perhaps all of them are?) but of course omit any equation that would be outside the limits of the eqn. Hopefully there is always at least one eqn available for every situation. We don't want harvest cost to be zero (e.g., if cut list only contained 100" trees and none of the eqns handled that) because then harvest cost would be zero and volume yield (via processor) could be immense and that would be a cheat!
@jsfried So in Opcost_Input, am I changing all the Harvesting.System values to tethered then, or are we still calculating for Cable Manual WT/Ground-Based Mech WT and just including Tethered as an option for optimization?
A complete implementation plan is now posted on GitHub https://github.com/USFS-PNW/Fia_Biosum_Scripts/blob/master/OPCOST/Petitmermet_harvest_cost_model_implementation_plan_20180412.docx @carlinstarrs
Need to combine the two aspects of forwarder usage (for forwarding and for loading) into one set of equations (with parameters that vary by gentle/steep slope class).