PhaseFlow: a schedule is only as good as the bound you can check it against

PhaseFlow schedules an open pit period by period: which blocks come out in which year, under slope precedence in every period and the mining and processing capacity of each one, maximising discounted NPV. The problem is NP-hard, so nobody solves it to proven optimality at real size, and that is exactly why the number on its own is worth little.

Two things make that bound useful rather than decorative. It is checkable by ordering: a CPIT LP bound must sit below a PCPSP LP bound because PCPSP is the richer problem, and it does, by 365 units in 24.5 million. And it is cheap: the critical multiplier algorithm gives the CPIT LP relaxation exactly in O(mn log n) as parametric maximum closures, with no LP solver at all, which is why a TypeScript port re-solves the whole problem live in the browser and a parity test asserts it reproduces the Python bound.

The part I would keep if I could keep only one: two bounds run on every case and the app reports the difference. A certified-but-loose bound relaxes the resources one at a time; the joint Bienstock-Zuckerberg bound does not. The gap between them is the part of a reported optimality gap that belongs to the bound rather than to the plan, and without it you cannot tell a weak schedule from slack in the mathematics you measured it with. On a single-resource instance the two agree to machine precision, which is the strongest correctness check in the repository.

Honest scope, in the product: no stockpiles, no blending, no minimum-production constraints, and not for production mine planning. Engine is the separately published oreblocks. Live · source.