MineLib: McLaughlin
What a published solution loses when it has to be executable
Published mine plans model the geology in detail and the operation barely at all. A solution can be close to the best available answer to the model it was given, and still describe something a site could not physically do.
These benchmarks test that. We take a published solution, require it to obey the physical constraints a real operation works under, and see what its value does. We then run the same deposit through Cognomine, where those constraints are inside the problem from the start.
We have done this on two deposits. On one the published solution lost 58.4% of its stated value. On the other, 29.5%. A plan built without physical constraints was not designed to survive them or to fail them, so how it fares once they are applied is essentially random. Nothing in the reported NPV tells a planner which case they are looking at.
What we tested
MineLib is a public library of open pit mining problems, set up as the mining equivalent of MIPLIB and used as a common reference set across the field. It is published at minelib.org and described in Espinoza, Goycoolea, Moreno and Newman, "MineLib: a library of open pit mining problems", Annals of Operations Research 206(1), 2013.
We took McLaughlin, a defunct gold mine in California and the largest instance in the library at 2,140,342 blocks, together with the best-known published solution for it. That solution is a strong one. MineLib records its gap to the linear programming upper bound at 0.2%, so against the model it was given it is close to the best answer available. We verified its precedence compliance ourselves against the instance's 73,143,770-arc precedence file, finding no real violations.
The instance economics are the library's own and unchanged: gold at $900 per ounce, mining cost $1.32 per ton, processing cost $19 per ton, 90% recovery, and a 15% discount rate.
The model those economics sit in is the issue. Of the ten constraint families a real operation works under, the published problem models two.
What the published model leaves out
| Constraint family | Status | What the model does |
|---|---|---|
| Plant feed (processing) capacity | Modelled | 3,300,000 short tons/year, the model's only resource constraint |
| Cross-campaign scheduling precedence | Modelled | Block-level only, with no campaign or territory grouping, so any two precedence-independent blocks anywhere in the pit can be mined in the same period regardless of the distance between them |
| Active dig-face separation | Not modelled | No fleet or equipment model exists, so any number of faces can be worked at once with no physical separation |
| Equipment operating-hour budget | Not modelled | No diggers, trucks or operating-hour budget of any kind, so material moves at whatever rate the optimiser chooses |
| Fleet purchase capital | Not modelled | No fleet ownership or purchase-cost term, so any early mining spike gets the diggers and trucks it needs for free |
| Haulage destination allocation | Not modelled | Every block is assigned a destination, but there is no haul route, travel time or distance-based cost, just a flat per-tonne cost wherever the block sits |
| Waste destination capacity | Not modelled | No waste dump capacity, geometry or placement constraint |
| Monthly production timing | Not modelled | Annual period buckets only, with no monthly sequence that could be checked against fleet, lag, haulage or waste placement |
| Drill-and-blast prep time | Not modelled | No minimum gap between a predecessor block clearing and its successor starting |
| Undermining stability guard | Not modelled | A block may be scheduled while material on the bench directly above and beside it is still standing, so the dig can open a void under a block that then has nothing supporting it |
None of this is a criticism of the solution or the people who produced it. It answers the model it was given extremely well. The model just does not describe a mine.
Results
MineLib PCPSP (fair scored replay)
Legalised indicative replay
- NPV (monthly discounted, with fleet capex)
- $628,701,261
- Undiscounted cashflow
- $2,248,824,637
Our solution
Constrained production run
- NPV
- $949,941,181
- Undiscounted cashflow
- $1,996,037,566
- NPV vs fair scored replay
- +$321,239,920
- % of fair scored replay
- 151.0%
The published solution scores $1,510,126,435. Required to obey six constraint families it was never given, monthly production timing, drill-and-blast prep, undermining stability, dig-face separation and fleet purchase capital, plus its own mill limit applied monthly rather than annually, the same schedule is worth $628,701,261. Nothing about the deposit, the economics or the discount rate changes. 58.4% of the stated value does not survive.
Roughly 95% of the published schedule's first-period mill feed cannot physically be reached that early, principally because drill-and-blast preparation takes time, and partly because a limited number of dig faces can only strip so much material at once.
The two are discounted differently, and deliberately. The published solution is discounted in annual buckets, its own convention. The replay is discounted monthly, because once a schedule has to be physically legal it has a monthly sequence to discount.
Against the constrained comparator, the Cognomine plan carries $321,239,920 more NPV. Its undiscounted cashflow is lower. The published schedule moves around 2.6 times more total material and processes roughly 17% more ore, so its undiscounted total is higher. It over-selects, because nothing in its model told it that reaching material takes time and equipment.
Ore left in the ground
Every mine plan leaves ore in the ground. Deciding what is worth extracting and what is not is one of the central judgements in a strategic plan, and both plans here make it. The difference is what informs the decision.
Both plans compute the cutoff as they go rather than taking a fixed grade, and both work from the same raw block data. The difference is what the calculation can see. Cognomine prices the fleet, haulage and drill-and-blast time needed to reach a block, so material that costs more to reach than it returns is left in place. The published formulation has no way to represent those costs, so its cutoff is computed as though reaching a block were free. That is why it moves more rock and processes more ore for less value.
Both plans above are solved to maximise net present value. Recovery, production rate, cost profile and capital sequencing can each be set as the objective instead, and a plan built to maximise recovery would mine more of this deposit and return a lower NPV. Which of those a site wants is a commercial decision, not a solver setting we make on its behalf.
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. That limitation is the finding rather than a flaw in the method, but it does mean the replay is not the best plan a constraint-aware solver would build from the same selection.
- The problem definitions differ. The published formulation cannot represent a stockpile. Cognomine can. Real operations have stockpiles, which is why we model one, but it is a difference in the problem being solved and not only in the answer. The stockpile in this run is finite, at 50 million tons, smaller than one carried by a producing site we work with, and it 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 was above the supported production limit. The 2,140,342 block model was solved at full resolution to show what the solver can do. Cognomine production accounts accept raw block models up to around one million blocks, and every model is reduced to scheduling units before solving: under 100,000 in a standard run, up to 500,000 in High Fidelity. Reblocking reduces spatial resolution rather than constraints, and on a model of this size it would return a lower NPV than the figure above. High Fidelity narrows that gap by working at finer resolution, at a longer solve time, and is included in every credit. How reblocking and High Fidelity work
- One deposit is one deposit. The same method on zuck_large produced a very different result. See that benchmark
Why it matters
A plan is only worth what a site can execute. The value lost between the two figures above is why experienced planners discount solver output before they read it, and they are right to.
Cognomine models the constraints that shape a real mine plan from the start, so the number it produces is a number the operation can work towards.
Run it on your own numbers
Sources: MineLib PCPSP instance mclaughlin and the best-known published solution mclaughlin_pcpsp_gmunoz120723.sol, objective 1,510,126,435 at a 0.2% gap to the linear programming upper bound, retrieved from minelib.org on 2 September 2026.
The solution was provided by Gonzalo Muñoz and obtained from the LP relaxation using a modified TopoSort heuristic: Muñoz Martínez, G. I. (2012), Modelos de optimización lineal entera y aplicaciones a la minería, master's thesis, Department of Mathematical Engineering, Universidad de Chile. Open access at repositorio.uchile.cl/handle/2250/111132.
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.