FHOPS provides a reproducible benchmark for forest harvest scheduling

A new open-source platform called the Forest Harvesting Operations Planning System, or FHOPS, turns that short-horizon problem into a traceable computational workflow, pairing mixed-integer linear programming with heuristic solvers and replaying their schedules under operational disturbances. The software paper presents benchmark, tuning, robustness, costing and scaling results generated from a public reference ladder in British Columbia, together with code, datasets, logs and a command that regenerates the manuscript’s evidence. The study reports a software capability rather than a new optimization theorem or evidence of broad real-world deployment, and its validation is concentrated on one ground-based harvest archetype.

The platform addresses a reproducibility gap identified in a systematic review by Jaffray and colleagues. Their review covered 23 peer-reviewed studies published from 2005 through 2024 and found recurring limitations, including high site specificity, scarce open artifacts and weak or absent reproducibility support. The three authors of the FHOPS paper disclose that all of them also contributed to that review, which they describe as a publicly verifiable audit of more than 140 studies.

Its central implication was practical: operational planning tools need standardized inputs, transparent formulations and repeatable evaluation workflows before results can be compared without rebuilding entire software environments. FHOPS is presented as the middle contribution in a sequence that moves from that review to a reusable platform and then to follow-up modelling studies using a shared baseline. FHOPS is designed around a “scenario contract” that separates operational assumptions from solver logic.

Its typed inputs describe harvest blocks and their available windows, machines and role-specific production rates, day-shift calendars, landings, mobilization rules and constraint metadata. A machine’s availability flags can remove planned downtime such as maintenance or crew days from the schedule. Role-compatibility data determine which machines can work on particular blocks, while movement penalties and landing capacities encode logistical constraints.

The platform’s scheduling scope is intentionally bounded: upstream decisions about which blocks to harvest and with which system are treated as fixed inputs, and the model ends at the landing, where a loader stages a truckload or the block’s remaining volume. Haul transport, truck dispatching and delivery to mills remain outside the operational model. This separation allows a user to alter a case or transfer a model without rewriting its mathematical implementation, although empirical validation beyond the British Columbia ground-based archetype remains future work.

The software offers complementary solution methods. Simulated annealing, iterated local search and tabu search generate practical schedules for larger instances and rapid re-solving, while a mixed-integer linear programming formulation supplies an exact baseline when the problem is tractable. The same objective is used throughout: a weighted score rewards production and subtracts penalties for unmet block volume, mobilization, transitions, landing surplus and violations of hard feasibility constraints.

Heuristic schedules are re-evaluated when returned, so their exported assignments reproduce the reported score. The formulation is versioned with the code and maps labeled constraints, from machine availability and production limits to inventory balances, truckload thresholds, locked assignments and landing capacity, to Pyomo objects and regression tests. This equation-to-code path is intended to let reviewers and maintainers detect discrepancies between a paper’s stated model and executable behavior.

A rolling-horizon driver can also lock near-term decisions, replay them and carry remaining block volumes, staged inventories, machine positions and locks into the next planning window, although this paper does not establish the best horizon length or re-optimization frequency. Internally, the platform separates scenario ingestion and validation, optimization, schedule playback and key-performance-indicator calculation, and reporting. The stable FHOPS 1.0.1 release is a pure-Python package requiring Python 3.11 or newer, with dependencies that include Pyomo, HiGHS, NumPy, pandas, Optuna and PyArrow.

It is distributed under the MIT license, and its manuscript assets can be regenerated through a benchmark command that also records hashes in a reproducibility log. Continuous integration runs on Ubuntu with Python 3.11; the manuscript assets were generated on Ubuntu 24.04 LTS with Python 3.12, and macOS and Windows are not covered by the continuous-integration system. The paper also distinguishes a provisional tactical-to-operational layer, published as a pre-release for block harvest selection, product flows, transport arcs and delivered-cost or profit objectives.

That layer is outside the stable release evaluated here and is not part of the reported evidence. On the public reference ladder, the operational problem expands from 2 blocks over 7 days to 6 blocks over 21 days and 12 blocks over 42 days, with the same nine-machine role mix. In the smallest scenario, simulated annealing, iterated local search and tabu search delivered identical production of 4,414.70 cubic metres, while their objective scores ranged from 4,295.77 to 4,338.52 and runtimes ranged from 25.13 to 245.50 seconds.

At 21 days and six blocks, all three again produced 15,966.97 cubic metres. Their objective values differed by only 21.78 points, but mobilization costs ranged from 1,764.12 to 1,871.80 Canadian dollars and tabu search required 315.61 seconds, compared with 53.06 seconds for simulated annealing. These comparisons concern schedules within a single scenario.

The software’s objective scale varies with the dataset and weight profile, so values should not be interpreted as directly comparable measures across different cases. The 42-day benchmark illustrates why a single headline score cannot characterize an operational schedule. Iterated local search obtained the highest objective, 24,329.17, followed by tabu search at 24,163.37 and simulated annealing at 24,130.32, a total spread of 198.85.

Production followed a different order: tabu search produced 33,463.63 cubic metres, iterated local search 33,361.75 and simulated annealing 32,984.91. Simulated annealing was fastest at 911.22 seconds, compared with 1,212.70 seconds for iterated local search and 5,387.72 seconds for tabu search, and it also had the lowest mobilization cost, 7,292.52 Canadian dollars. None of the three schedules incurred a hard-constraint penalty.

The results show measured trade-offs among objective value, output, operating cost and computation time rather than universal superiority by one solver. The reference ladder is designed as a baseline for interpreting planner-facing questions and for follow-on studies, not as a definitive ranking of optimization methods. Parameter tuning did not produce a uniform improvement.

The best tuned result for the 42-day case was a tabu-search score of 23,139.82 after one run of 900 iterations, 4.1 percent below the much longer default simulated-annealing benchmark of 24,130.32 after 20,000 iterations. The comparison therefore contrasts short tuning runs with longer default searches rather than equal computational budgets. In the seven-day case, tuning reached 4,338.52, matching the iterated-local-search and tabu-search benchmark scores; in the 21-day case, the best tuned score exceeded the default by 0.14, effectively a tie.

These results support scenario-specific tuning but do not demonstrate that automatic parameter search consistently outperforms default settings. The synthetic-small scenario provides a different baseline signal: no volume was delivered within its horizon, so all three heuristics returned an objective of negative 39.79, reflecting the unmet-volume term rather than a change in the optimization direction. To test operational robustness, the researchers kept solved schedules fixed and replayed them under 50 samples of three disturbance types.

A scheduled machine-shift lost a sampled number of hours, with a mean of 4 hours and standard deviation of 1.5 hours, at a probability of 0.05 per machine-shift. Production was reduced on affected days by sampled weather severity, with an event probability of 0.10 per day. Landing shocks reduced production at an affected landing for a fixed period, with a probability of 0.05 per landing per day.

Mean day-level utilization for simulated annealing and iterated local search differed by less than 0.001 under stochastic playback. In the seven-day scenario, utilization declined from 0.365 to 0.362, and in the 42-day case from 0.566 to 0.562. The largest decrease occurred in the synthetic scenario, from 0.378 to 0.369.

Because utilization records worked hours, weather and landing disruptions appeared more directly in delivered production than in utilization itself. The experiment therefore evaluates the schedules under specified sampled disturbances; it does not establish how they would perform in every operational setting. The baseline also exposes limits that are central to the software’s promise.

FHOPS currently has no broad external-deployment evidence, and its published validation represents one British Columbia cut-to-length ground-based system rather than skyline, helicopter, tethered or salvage operations. Absolute runtimes depend on hardware and solver budgets, so the most reliable interpretation is as a within-study comparison. Seeded heuristic results are reproducible on a fixed platform, but small floating-point differences between software builds can alter an acceptance decision and change a search trajectory.

Synthetic scaling tests increased simulated-annealing runtime from 20.69 seconds for 4 blocks to 45.86 seconds for 8 and 69.22 seconds for 16. Schedule-level costing currently covers mobilization and does not translate delays into standby or delay costs. Warm-start support for HiGHS and Gurobi is implemented, but decisive performance gains for larger stress cases have not been demonstrated.

Within these boundaries, FHOPS offers open infrastructure for forest operations research: standardized cases, inspectable mathematical logic, multiple solver pathways, disturbance testing and one-command regeneration of published assets. Its central contribution is a shared experimental foundation on which planners and researchers can test scheduling questions reproducibly, rather than a universal answer to forest scheduling.

Subject of Research: Reproducible software for optimizing and benchmarking operational forest-harvest schedules

Article Title: FHOPS: a reproducible optimisation and benchmarking stack for forest harvest operations

Article References: Paradis, G., Jaffray, R., & Coupland, K. (2026). FHOPS: a reproducible optimisation and benchmarking stack for forest harvest operations. SoftwareX, 36, Article 103147. https://doi.org/10.1016/j.softx.2026.103147

Image Credits: AI Generated

DOI: 10.1016/j.softx.2026.103147

Keywords: Forestry, Harvest scheduling, Operational research, Mixed-integer programming, Heuristic optimization, Reproducibility, Open-source software, Decision support, Disturbance testing, FHOPS, reproducible, optimisation