Surface Constraints
MiningMath uses a surface-constrained mine production scheduling, which is an improvement of the idea proposed by Marinho (2013). Surfaces are one of the most important constraints, allowing the user to impose its manipulations and knowledge to guide the optimization process. It can be used to force areas to back-fill operations, to allocate an in-pit crusher, to restrict an area considering different offsets, and show the economic impacts of preserving or not a given area or community. It also allows to incorporate an operational mine design as a requirement for a given time frame. For example, the mine design for the current year could be a mandatory requirement for the first period, while the rest of the mine sequence would have a new chance to be re-optimized and find a different sequence that finds more long-term value. The following pages unlock all the possibilities of the use of such features.
Internally in the algorithm:
To define slope angles and eliminate geotechnical errors, present in the blocks precedence method (Beretta & Marinho, 2014, 2015).
To handle geometric parameters and comply with minimum widths and maximum vertical rate.
As optimization inputs:
To force mining and achieve a minimum depth, geometry, or area within a given time frame.
To restrict mining and ensure unavailable areas will not be considered as part of the optimization within a given time frame.
To force and restrict mining to achieve an specific design o guide the optmization.
As optimization outputs:
To outline the mine sequence throughout the Life of Mine that maximizes the Net Present Value.
Outputs will be a consequence of the optimization, which implies each set of project assumptions, constraints, and parameters, since it is unconstrained by pushbacks it will produce a different sequence of extraction, unlocking hidden opportunities.
Surface formatting is simple and any surface output from MiningMath might serve as a start point for further manipulations or even for validations. It is important mentioning that they are exported/imported from/at MiningMath in Coordinates.
To have headers named as X, Y, and Z. These files also obey an ascending value order in each one of the axes.
To have the same size of the block model, which means it should not exceed the block model dimensions.
To have its points aligned with blocks' centroids in the X-Y plane.
To be defined as a grid of points.
To be in the CSV format.
To avoid any mistakes, manipulate an output surface from MiningMath instead of creating one from scratch.
Run any scenario to obtain the topography file in MiningMath’s format.
Import the topography.csv, created by MiningMath, on a software able to manipulate it graphically.
Select points inside/outside a polygon. Move them up/down accordingly to the objectives to force or restrict mining. Points should be moved only up and down, along the Z direction.
Once the surface is ready, move it back to the original coordinate system.
Use it on MiningMath.
X and Y coordinates should remain the same, with the same spacing between each pair of points.
For rectangular areas, a spreadsheet application is suitable for this task.
Surfaces are imported in two tabs of MiningMath: Geometric and Overview. Figure 1 zooms in the operational constraints from the Geometric tab. The main variables to use this feature are mentioned on Figure 4, which illustrates that surfaces are imported considering:
The purpose of forcing/restricting mining.
The period range when each surface is applicable.
- MiningMath automatically defines a single period range from "1" to the "" and the the user can also add custom intervals.
In the example from Figure 5, the image highlights the fields to apply:
A restricting-surface valid for periods 1 and 2 (in green), which means that it would be respected until the end of the second year.
A forcing-surface valid for periods 1 to 5 (in blue), which means that the area has to be mined until the and of period 5.
Video 1: Surface Constraints: The ultimate guide
