CognomineBeta
All benchmarks
Benchmarks

MineLib: zuck_large

What a published solution loses when it has to be executable

In August 2026 we replayed the best-known published MineLib solution for zuck_large, a 96,821 block deposit, under the same six physical constraints used on McLaughlin. Its stated value fell 29.5%. Cognomine's constrained plan on the same deposit came out 0.8% ahead. All values on this page are in the instance's normalised units.

McLaughlin showed how much a published plan can lose once it has to be executable. zuck_large applies the identical method to a second deposit, and the loss is much smaller. Nothing in either published model was working towards an executable plan, so the size of the loss could not have been read off the reported NPV in advance.

How the constraints are held →

What we tested

zuck_large is a MineLib PCPSP instance of 96,821 blocks. It has two explicit resource constraints in its own descriptor: C0 mining capacity at 3,000,000 tonnes per period and C1 processing capacity at 1,200,000 tonnes per period. Both are genuinely modelled and respected by the published solution.

The instance economics and the 10% discount rate are the library's own and unchanged. The source data is normalised to net value rather than keeping separate price and cost components, so metal price is 1 unit per unit, mining cost 1 unit per tonne, processing is nil because it is already inside the metal price, and recovery is 1.0. Every figure on this page is in those normalised units, not in real currency.

Beyond those two resource constraints, the model is sparse. Of the ten constraint families a real operation works under, it models two.

What the published model leaves out

Constraint families in the published zuck_large solution.
Constraint familyStatusWhat the model does
Mining (C0) capacityModelled3,000,000 tonnes per period, genuinely modelled and respected
Plant feed (C1) capacityModelled1,200,000 tonnes per period, genuinely modelled and respected
Active dig-face separationNot modelledNo fleet or equipment model exists, so any number of faces can be worked at once
Equipment operating-hour budgetNot modelledNo diggers, trucks or operating-hour budget appear in the model
Fleet purchase capitalNot modelled directlyNo fleet ownership or purchase-cost term. The C0 mining capacity does cap how fast material can be moved, which acts as an implicit limit on fleet size, but nothing in the model attaches a cost to buying it
Haulage destination allocationNot modelledTwo abstract destinations, with no route, haul-distance or trucking-cost model
Waste destination capacityNot modelledNo waste dump capacity term, so waste is discarded with no destination limit
Monthly production timingNot modelledThe finest time unit is a full period, so pacing within a period is unconstrained
Drill-and-blast prep timeNot modelledNo blast-to-dig window, so a bench can be re-entered the same period blasting finishes
Undermining stability guardNot modelledA block may be scheduled while material on the bench directly above and beside it is still standing

By capping the mining rate through C0, this instance does implicitly what a fleet model does explicitly: it stops the schedule moving more material than equipment could physically handle. It does so without any capital cost, and without operating hours, haul routes or blast timing, so it is not blind to the rate question even though it has no fleet.

Results

MineLib PCPSP (fair scored replay)

Legalised indicative replay

NPV (monthly discounted, with fleet capex)
40,443,837 units

Our solution

Constrained production run

NPV
40,768,329 units
NPV vs fair scored replay
+324,491 units
% of fair scored replay
100.8%

All figures on this page are in the instance's normalised value units, not real currency.

The published solution scores 57,334,014 units. Required to obey six constraint families it was never given, the same schedule is worth 40,443,837 units. 29.5% of the stated value does not survive.

Against the constrained comparator, the Cognomine plan returns 324,491 units more NPV, at 100.8%. On this deposit the two are close to level.

This published solution held up reasonably well once the constraints were applied. Nothing in its model was working towards that, so a plan that ends up close to executable by chance is still a plan nobody could have relied on in advance.

What this benchmark does not show

  • Constraints are deliberately not identical. That is the point of the comparison. The published solution was produced against a model with no fleet, haulage, drill-and-blast timing or capital. This is not a like-for-like contest between two solvers on the same problem.
  • The replay is our construction. We defined the rules by which the published schedule is made physically legal. Those rules are set out in the methodology note.
  • The replay inherits the published block selection. It is made to obey the physical constraints but cannot re-choose what to mine, because the published formulation has no way to express fleet, haulage or drill-and-blast timing and so cannot be re-solved under them.
  • The problem definitions differ. The published formulation cannot represent a stockpile. Cognomine can. The stockpile in this run is finite, at 5 million tonnes, and operates strictly first in, first out. Material cannot be held back and retrieved out of order to favour grade.
  • This benchmark makes no speed claim. No runtime was published for the comparator, so there is nothing to measure against. Speed results are on the strategic planning benchmark.
  • This run sits within normal production limits. At 96,821 blocks this deposit was solved without reblocking. Standard fidelity handles up to 100,000 scheduling units, High Fidelity up to 500,000. How reblocking and High Fidelity work
  • This is one deposit. We run the same test on other public deposits and publish every result. See all benchmarks

Run it on your own numbers

Sources: MineLib PCPSP instance zuck_large and its best-known published solution, retrieved from minelib.org on 9 September 2026. The library is described in Espinoza, D., Goycoolea, M., Moreno, E. and Newman, A. (2013), "MineLib: a library of open pit mining problems", Annals of Operations Research 206(1), 93 to 114, doi:10.1007/s10479-012-1258-3. Cognomine results are our own. Method in the methodology note.

The same test on McLaughlin →Cognomine vs Google OR-Tools →
All benchmarks