PitForge, Banco de Trabajo de Pit Final Exacto y Cascaras de Pit Whittle Anidadas
Un banco de trabajo de diseno minero a rajo abierto que resuelve el pit final de forma exacta, como cierre de peso maximo del grafo de precedencias de bloques reducido a un corte minimo sobre un motor de flujo maximo Dinic, corriendo en vivo en el navegador, y deriva las cascaras de pit Whittle anidadas por factor de ingreso. Reproduce los optimos publicados de tres instancias reales de MineLib a lo mas con 2e-9 de error relativo, y autoverifica cada resolucion con la identidad de dualidad de flujo maximo. Es el unico de los cuatro de Faena cuyo titular se valida contra optimos publicados por terceros y no contra su propio generador.
Contexto de Negocio
El pit final y sus cascaras anidadas fijan la envolvente de reservas, fases y flujo de caja, por lo que un pit erroneo o no auditable se propaga a cada numero aguas abajo. El valor de PitForge es que su respuesta exacta es verificable de dos maneras: contra optimos publicados por terceros que no creo, y contra la identidad de dualidad de flujo maximo. Una instancia de 14.153 bloques con 219.778 precedencias se resuelve de forma exacta en bastante menos de un segundo en un portátil, en un bake en Node del mismo motor TypeScript que corre el navegador (los milisegundos dependen de la máquina; corridas repetidas en un mismo equipo variaron por un factor de varias veces, así que el artefacto registra el entorno y la afirmación es sobre el orden de magnitud), lo que pone un optimizador de grado de diseno en una pagina estatica sin servidor y sin licencia. Los surrogates aprendidos se posicionan como aproximaciones rapidas para exploracion de escenarios, nunca como reemplazo del resultado exacto.
Valor Estratégico
PitForge es el mas fuertemente validado de los cuatro de Faena, y la validacion es de terceros: su pit final exacto reproduce tres optimos publicados de MineLib (newman1, zuck_small, kd) a lo mas con 2e-9 de error relativo, con el mayor resuelto en una fracción de segundo en un bake en Node, mediana de 3, del mismo motor (una cifra dependiente de la máquina, registrada junto a su entorno). Dos propiedades adicionales lo refuerzan. Las perillas de escenario quedan bloqueadas en modo real porque las instancias de MineLib publican sus propios valores netos y precedencias, de modo que rederivarlas romperia la comparabilidad con el optimo publicado, una decision deliberada para proteger el benchmark. Y el grade-nn aprendido se reporta como derrota, no como victoria: sobre una geologia excluida alcanza R2 0,8757, superando apenas a IDW con 0,8591 y quedando bajo el kriging ordinario con 0,9333, y el artefacto lo llama una aproximacion rapida que nunca supera al resultado exacto. Ese numero se movio cuando una particion aleatoria por filas con fuga fue reemplazada por una particion agrupada que deja fuera una geologia completa, asi que la cifra menor es la confiable. La via CPIT parsea el escenario publicado newman1.cpit (6 periodos, 8% de descuento, dos restricciones de recurso), reproduce su cota LP publicada a 3,7e-9, y publica una brecha cota-a-factible de 3,81%; un gemelo sintetico aparte, etiquetado como no comparable, queda en 11,29%. Es un patron reutilizable para un optimizador auditable y autoverificable que se prueba contra numeros que no escribio.
El Desafío
El pit final, el conjunto de bloques que vale la pena minar una vez respetadas las precedencias de talud, es la base de todo diseno a rajo abierto, y tiene solucion exacta: el cierre de peso maximo del grafo de precedencias, equivalente a un corte minimo. En la practica suele aproximarse, o queda encerrado dentro de software comercial cuyos resultados no se pueden reproducir ni auditar. Probar que una implementacion es correcta exige mas que "devuelve un pit": exige igualar un optimo publicado sobre una instancia que no generaste tu mismo, y verificar el solucionador contra su propia identidad de dualidad en cada corrida.
Nuestro Enfoque
PitForge resuelve el pit final como cierre de peso maximo, reducido a un corte minimo via la construccion de Picard de 1976 y resuelto por un motor de flujo maximo Dinic escrito en TypeScript, corriendo en vivo en el navegador. El resultado exacto se describe por lo que es: es el equivalente de cierre maximo / corte minimo de Lerchs-Grossmann, no una reimplementacion de Lerchs-Grossmann. Dinic es el motor en vivo, y a su lado corre un peldano independiente de pseudoflow de arbol normalizado de Hochbaum, que reproduce el mismo valor optimo y el mismo conjunto de bloques en cada instancia validada; no se afirma que los cortes sean identicos ante optimos empatados, porque un corte minimo no tiene por que ser unico. Desde el pit exacto deriva las cascaras de pit Whittle anidadas sobre un calendario ascendente de factor de ingreso, entregando curvas de valor, tonelaje y razon de descarga. La estimacion de ley corre de dos maneras en vivo (IDW y un surrogate grade-nn ONNX sobre un stencil de vecinos de 27 vectores), con kriging ordinario como la base de referencia offline contra la que se mide la red, mas un surrogate de inclusion en el pit. Una relajacion LP de CPIT (scipy HiGHS) con redondeo entero voraz se computa offline y se renderiza desde JSON, nunca en vivo. La identidad de dualidad pitValue = suma(valorPositivo) menos maxflow se asevera en la via MineLib de precedencia explicita y se muestra como verificacion en pantalla en la via interactiva. Estatico en GitHub Pages, con una via de arrastrar y soltar CSV en la app para modelos de bloques propios.
Indicadores Clave de Rendimiento
| KPI | Línea Base | Resultado | Impacto |
|---|---|---|---|
| Correctitud, validada por terceros | Devuelve "un pit" sin verificacion externa | Reproduce 3 optimos publicados de MineLib (newman1, zuck_small, kd) a <= 2e-9 de error relativo | Validado contra optimos que no genero, no contra su propia salida |
| Resolucion exacta, en el navegador | Pit aproximado, o un solucionador de escritorio con licencia | 14.153 bloques / 219.778 precedencias resueltos de forma exacta en una fraccion de segundo (mediana de 3 en Node del mismo motor TypeScript que corre el navegador, dependiente de la maquina; corte minimo Dinic sobre reduccion de Picard) | Optimizador de grado de diseno en una pagina estatica, cero backend |
| Autoverificacion en cada resolucion | Confiar en el numero devuelto | pitValue = suma(positivo) - maxflow aseverado en cada resolucion (identidad de dualidad de flujo maximo) | El optimizador se verifica a si mismo, no solo quien lo llama |
| Surrogate aprendido vs kriging | Afirmar que la red neuronal supera al kriging | grade-nn R2 0,8757 vs kriging ordinario 0,9333 e IDW 0,8591 en una particion que deja fuera una geologia completa (una derrota frente al kriging, publicada como tal); reportado como aproximacion rapida, nunca superando el resultado exacto | Un margen de 0,0033 es un empate, y la ficha lo dice |
Arquitectura
pitforge pipeline
The exact pit, in the browser, checked against published optima
PitForge is an open-pit mine-design workbench. It solves the ultimate pit limit exactly, as a maximum-weight closure of the block-precedence graph reduced to a minimum cut on a Dinic max-flow engine, running live in the browser, and derives the nested Whittle pit shells by revenue factor. Live at pitforge.fasl-work.com, part of the Faena mining-analytics hub.
Say what the engine is
The exact result is the max-closure / min-cut equivalent of Lerchs-Grossmann, via Picard’s 1976 reduction on a Dinic engine. It is not a re-implementation of Lerchs-Grossmann. Dinic is the live engine, and an independent Hochbaum normalised-tree pseudoflow rung runs beside it, reproducing the same optimal value and the same block set on every validated instance; identical cuts are not claimed for tied optima in general. From the exact pit, nested Whittle shells over an ascending revenue-factor schedule give value, tonnage and strip-ratio curves.
Validated against MineLib, not against itself
The exact pit reproduces the published optima of three real MineLib instances:
- newman1: 1,060 blocks, relative error 9.96e-10
- zuck_small: 9,400 blocks, 1.86e-10
- kd: 14,153 blocks / 219,778 precedences, 1.30e-10
The relative errors are properties of the algorithm and reproduce anywhere. Solve times are not: measured under Node on the same TypeScript engine the browser runs, the three take milliseconds to a fraction of a second, but repeat runs on one laptop varied by a factor of several, so the artifact records its environment and no decimal figure is published here. What is stable is the comparison in the same run: the independent pseudoflow rung is one to two orders of magnitude slower on the two larger instances.
All three match: true. Two further instances (marvin, mclaughlin_limit) are excluded with committed reasons (marvin ships with commercial Whittle software; neither has a verified public mirror) rather than silently dropped. In real mode the scenario knobs are locked, because the instances publish their own net values and precedences and re-deriving them would break comparability with the published optimum.
The learned and offline rungs
The duality identity pitValue = sum(positive) - maxflow is asserted in the explicit-precedence MineLib lane and displayed as a live check on the interactive lane, so the optimiser checks itself against its own dual. Grade estimation runs two ways live (IDW and a grade-nn ONNX surrogate), with ordinary kriging as the offline benchmark baseline; the learned grade-nn trails kriging (R2 0.8757 against ordinary kriging 0.9333 and IDW 0.8591, on a split that leaves one whole geology out), and the artifact calls it a fast approximation that never beats the exact result. Both learned models are trained and evaluated on synthetic seeded deposits, with no real drillholes. Scheduling is a CPIT LP relaxation computed offline with scipy HiGHS, rendered from JSON, never live; on the published newman1.cpit scenario (6 periods, 8% discount, two resource constraints) it reproduces MineLib’s published LP bound of 24,486,184 to 3.7e-9 and publishes a 3.81% bound-to-feasible gap, with a separate synthetic twin at 11.29% explicitly labelled non-comparable, and it states plainly that the rounded schedule is a heuristic and is never optimal. It is a design optimiser, not a JORC or NI 43-101 resource estimate.
Stack Tecnológico
En acción
Un recorrido corto por la app en vivo: la interfaz real, grabada desde el sitio desplegado.
Capturas de la Aplicación
