Pit optimisation (HPF)

Pit optimisation looks like a geometry problem but is really a graph problem. Every block carries an economic value — what it is worth if you process it, minus what it costs to dig it. Some are positive, most are negative. You cannot take a positive block without first taking everything above it inside the slope cone.

That constraint makes the set of minable blocks a closure: if a block is in the pit, all of its predecessors must be too. The optimal pit is therefore the maximum-weight closure — the closed set whose block values sum to the largest possible total. That problem has an exact solution, and it is equivalent to finding a minimum cut on a flow network. No heuristics, no local optima, no operator judgement in the loop.

The quality of a pit optimisation is decided by the precedence structure long before the solver runs. Approximating a slope cone with too coarse a pattern quietly costs you metres of wall angle across the whole pit.

The engine builds precedence from Caccetta–Giannini minimum-search patterns — the provably memory-minimal set of offsets that reproduces a given slope angle over a given number of benches. You get the geometric accuracy of a large search cone without carrying the arc count that would normally come with it.

Slopes that vary the way real pits do

Slopes are specified as azimuth–slope pairs and interpolated around the pit (linear, cubic or cosine), so a wall that steepens through a competent domain and lays back over a fault is represented as such — not averaged into a single overall angle. Block sizes are carried through the cone construction, so non-cubic blocks produce correct geometry rather than a distorted cone.

Irregular and sub-blocked models

Where a model is reblocked, sub-blocked or otherwise irregular, precedence can be supplied as an explicit arc list instead of a generated pattern. Those arc files are memory-mapped from disk, so a precedence graph far larger than RAM streams rather than loads — and the same arcs are what Direct Block Scheduling later schedules against.

Before any graph is built, every block is valued through a full economic model — the same parameter set a Whittle practitioner would expect, because that is exactly the comparison our clients make:

• Metallurgical recovery per element, including recovery curves by material type
• Mining recovery and dilution applied to tonnes and grade
• Cost adjustment factors — separate ore and waste tables, varying by depth or domain
• Ore-mining premium for the additional cost of selective ore mining
• Royalties and TC/RC plus selling and transport costs
• Cut-off grade applied per block or per column, with ore-class masks for material routing

Values are converted to scaled 64-bit integers inside the solver, with overflow clamping, so the minimum cut is computed in exact integer arithmetic. Floating-point drift cannot quietly corrupt the optimum on a large deposit — a failure mode that is easy to miss precisely because the answer still looks plausible.

Producing 30 nested shells is the easy part. The question that actually matters is which one is the pit — and the largest shell is almost never the right answer, because the undiscounted ultimate pit ignores the fact that the last increment of stripping is paid for years before its ore is milled.

The system runs a revenue-factor search across the ladder, evaluates each candidate shell on a discounted basis rather than an undiscounted one, and reports the shell that maximises value along with the trade-off curve behind it. Pit selection becomes a computed, reproducible result you can defend in a review — not a judgement call about which row of a table looked best on the day.

Direct Block Scheduling takes this further again: rather than accepting any shell as given, it runs the discounted schedule across the candidate shells and keeps the NPV-best precedence-closed pit. The pit is chosen by the schedule that will actually be mined.

A pit shell that stops at a picture is only half a deliverable. Because the optimiser sits inside the platform rather than beside it, the result keeps moving:

• Into the scheduler — the same precedence graph drives the BZ scheduler and Direct Block Scheduling, so the pit and the mining sequence are one model.
• Into 3D — shells, benches and solids render interactively in the browser for review.
• Into your CAD packages — DXF export drops straight into Leapfrog, Deswik and Vulcan, alongside Datamine and Vulcan block-model writes.
• Into the money — tonnes and grades flow to the MineCost zero-based cost model and on into the financial model and risk analysis without a re-key.

And because it is a web platform, your own people do this — set up cases, run them, compare them, export them — in real time, without waiting on a consultant's licence seat or a returned deliverable.