Exposed Ore in Operating Mines
Context
In greenfield examples, the optimization usually starts from a more regular topographic surface. In an operating mine, the situation is different. The initial state already contains mined-out regions, air blocks, steep walls, berms, and exposed ore zones that were shaped by previous operational decisions and geotechnical limits.
This difference matters because MiningMath works on a block model representation. Real mine geometry is continuous and highly detailed. The optimization model, however, represents surfaces through discretized block-based points. As a result, some geometric controls, especially bottom width, are enforced through approximations that may be stricter than what the engineer visually interprets in the real pit.
Why exposed ore may not appear available
A recurrent concern regarding the use of MiningMath in operating mines is simple: “the ore is already exposed, but MiningMath does not pick it in the first periods.” In many cases, the issue is not ore visibility itself. The issue is geometric feasibility under the parameters defined for the scenario.
This difference matters because MiningMath works on a block model representation. Real mine geometry is continuous and highly detailed. The optimization model, however, represents surfaces through discretized block-based points. As a result, some geometric controls, especially bottom width, are enforced through approximations that may be stricter than what the engineer visually interprets in the real pit.
Real geometry versus block model geometry
A real pit floor can have detailed local shapes. In the block model, that same shape becomes a discrete approximation. This affects how the software interprets distances such as minimum bottom width. If the user requests a width that does not fit the block discretization cleanly, the mathematical representation may require a larger effective area than expected.
A simple example helps. If blocks are 30 m wide and the user asks for a 40 m minimum bottom width, the model cannot represent 40 m exactly with one block. In practice, it may need two blocks, which means 60 m in that local approximation. This can prevent MiningMath from deepening an already open area, even when the engineer sees exposed ore in the real pit.
The effect of a strict bottom width in early periods
This is especially relevant in the first periods of an operating mine. Those periods often start from active mining fronts and already exposed material. If the minimum bottom width is too restrictive for the local geometry, the optimizer may not be able to descend into those regions. The result is the false impression that the software is ignoring available ore.
The effect of slope assumptions
A second source of mismatch is the slope model. In real operations, short-term mining fronts often reflect bench face angles, berms, and local designs that can be steeper than the overall slope angle used in strategic optimization. MiningMath controls slope angles directly in the scheduling model, and it supports block-level slope definitions and multiple slope fields. If the early operational fronts are steeper than the global slope assumption used in the scenario, the optimizer may also struggle to deepen those regions.
Solving the issue with MiningMath
The practical solution is not to force the operating mine to behave like a greenfield case. The solution is to adapt the geometric setup to the real starting condition of the mine.
This difference matters because MiningMath works on a block model representation. Real mine geometry is continuous and highly detailed. The optimization model, however, represents surfaces through discretized block-based points. As a result, some geometric controls, especially bottom width, are enforced through approximations that may be stricter than what the engineer visually interprets in the real pit.
1. Reassess bottom width in the first periods
For the first periods, or for the interval where exposed ore and active mining fronts already exist, evaluate the scenario without bottom width, or with a reduced bottom width. The goal is to confirm that the optimizer can “see” and access those regions. Once that is confirmed, the engineer can gradually reintroduce a stricter value.
This is now more practical because MiningMath allows geometric parameters to vary by period range and timeframe in the Geometric settings. Bottom width does not need to remain fixed across the whole mine life.
2. Use period-dependent geometry instead of one fixed value
Operating mines rarely need the same bottom width logic in every period. Early periods may require more flexibility to represent current faces correctly. Later periods can then move to the standard strategic values.
A practical configuration can look like this:
| Period range | Bottom width logic | Objective |
|---|---|---|
Initial periods with exposed ore | Allow the optimizer to access existing mining fronts | Allow the optimizer to access existing mining fronts |
Transition periods | Intermediate value | Reintroduce operational control gradually |
Later strategic periods | Standard project value | Recover long-term design discipline |
This period-based logic is aligned with MiningMath’s geometric controls, which can be set by period range.
3. Review slope angles in the already opened regions
If the early fronts were mined with local geometries steeper than the global overall slope angle, consider assigning slope values in those regions that better reflect the actual operating condition. In practice, this means using local slope definitions for the blocks that belong to the first attack areas, instead of relying only on one average global slope.
This does not mean ignoring geotechnics. It means matching the optimization inputs to the geometry that already exists in the mine and to the actual short-term mining condition. When this adjustment is combined with a more suitable bottom width in the first periods, the optimizer tends to access exposed ore much more naturally.
4. Use surfaces when short-term control is needed
When the objective is to refine the schedule inside a previously defined mining envelope, existing surfaces can also be used as operational guides. In MiningMath, Force Mining and Restrict Mining can help refine short-term scheduling by enforcing or limiting extraction within selected boundaries and timeframes. This is useful when the operation already has a known attack area and the goal is to improve schedule quality without losing adherence to the current mine shape.
Important technical note about constraint hierarchy
MiningMath does not treat all constraints with the same priority. According to the documented hierarchy, Force+Restrict on the same surface has the highest priority, followed by slope angles, then individual force or restrict surfaces, then minimum bottom width, mining width, and mining length.
Comparison with traditional practice
In a traditional workflow, the operating pit geometry is often handled outside the optimization. Engineers optimize one stage, redesign locally, check feasibility, and then rerun or manually adjust the next step. This makes early exposed ore zones highly dependent on interpretation and manual iteration.
MiningMath changes this logic by embedding slope and geometric controls directly into the scheduling problem. But for operating mines, this only works well when the scenario inputs reflect the true initial condition of the pit. The main shift is this: instead of forcing the current mine into a generic strategic setup, the engineer uses period-dependent bottom width, local slope logic, and optional surface controls to make the optimization start from the mine as it actually exists.
Practical benefits
When this setup is done correctly, the main gains are clear:
- Better use of exposed ore in the first periods.
- Fewer false negatives where the optimizer seems unable to access available material.
- More realistic alignment between current mine geometry and optimization inputs.
- Faster sensitivity testing by changing bottom width and slopes by period range, without rebuilding the whole workflow.
- Better support for decision-making in operating mines, especially when short-term and long-term logic must coexist in the same scenario.
Related Knowledge Base links
For readers who want to go deeper into the controls mentioned above, these are the most relevant references:
Geometric: where period-based bottom width, mining width, mining length, vertical rate, Force Mining, and Restrict Mining are configured.
Widths and lengths: explains how minimum widths are handled in MiningMath and why these parameters are complex in 3D non-linear models.
Slope Angles: details MiningMath’s slope control logic, including the difference between overall slope angle and more detailed operational geometries.
Short-term Planning: shows how existing surfaces can be used with Force Mining and Restrict Mining to refine schedules in the first periods.
Guaranteed Solutions: useful for understanding constraint hierarchy when several geometric controls interact.
Final note
In operating mines, MiningMath should not be parameterized as if the optimization were starting from an untouched topography. The current pit geometry already contains operational history, exposed ore, berms, steep faces, and local mining logic. If bottom width and slope angles are not adjusted to that reality, the optimizer may become more restrictive than the engineer expects.
The best practice is to treat the first periods as a special geometric context. Start by ensuring that exposed regions are mathematically reachable, then tighten the controls as the schedule moves away from the existing mining fronts. This type of control is only possible because MiningMath allows geometric constraints to be managed directly inside the optimization, with period-based flexibility and surface-guided refinement.
