Get the NPV upper bound better than the Best Case scenario!
Take a look at some notable user issues shared on our forum. Feel free to post your own questions or lend a hand to fellow MiningMath users!
"I’m running MiningMath, but it’s mining a less profitable area, or even waste, or it’s not achieving the specific constraint I’ve set... Why is that?" To understand this, it’s important to recognize that not everything that is aimed to be incorporate into a mining project is mathematically feasible when attempting to respect all constraints simultaneously. Handling multiple,..."
Hello friends, I am writing to make known a problem I have and see if you can help me. I am doing my degree work with MIMA. When I add physical constraints like ML, MW, MB everything goes fine, but when I add Vertical Rate, the optimization process does not exceed 16%. Is there any solution for thi..."
When I import the block model it returns an error "invalid index: (1, 75, 1)."
The Force Mining surface (S1) was initially above the topography. Correction applied: S1 has been projected onto the level of the topography.
The Force Mining (FM) surface used was initially below the economically viable last period surface. Correction applied: FM depth has been reduced by increasing its Z-level.
The Force Mining surface (S1) used for period X+1 was initially above the one (S2) used for period X. Correction applied: the elevation of S1 has been reduced to match S2.
Note: ‘X’ can represent any period value (1, 2, 3, etc.)
The Force Mining surface (S1) employed was initially below the Restrict Mining surface (S2) during period X. Correction applied: S1 has been adjusted upward to align with the elevation of S2.
Note: ‘X’ can represent any period value (1, 2, 3, etc.)
The restrict mining surface used violated slope constraints of the last period surface. Correction applied: the surface has been adjusted accordingly.
The force mining surface used violated slope constraints of the last period surface. Correction applied: the surface has been adjusted accordingly.
The force mining surface (S1) imported for the last period surface was initially below the restrict mining surface (S2) imported for the same purpose. Correction applied: the elevation of S1 has been increased to align with that of S2.
The restrict mining surface (S1) imported for the last period surface was initially above the force mining surface (S2) imported for the same purpose. Correction applied: the elevation of S1 has been decreased to align with that of S2.
The force mining surface (S1) did not initially provide sufficient space to meet minimum operational constraints. Correction applied: adjustments have been made to S1 in critical areas.
The restrict mining surface (S1) was initially below the origin Z level. Correction applied: S1 has been projected to align with the origin Z level.
The force mining surface (S1) was initially below the origin Z level. Correction applied: S1 has been projected to align with the origin Z level.
The edges of the restrict mining surface (S1) were initially below the topography level. Correction applied: the edges of S1 have been projected to align with the topography level.
The edges of the force mining surface (S1) used were initially below the topography level. Correction applied: the edges of S1 have been projected to align with the topography level.
The restrict mining surface (S1) used was initially above the topography. Correction applied: S1 has been projected to align with the topography level.
The restrict mining (RM) surface utilized was initially above the economically viable last period surface. Correction applied: the depth of RM has been increased by reducing its Z-level.
The restrict mining surface (S1) used for period X-1 was initially below surface S2 used for period X. Correction applied: the elevation of S1 has been increased to match that of S2.
Note: ‘X’ can represent any period value (1, 2, 3, etc.)
Slope angles for the restrict mining surface have been adjusted for period X.
Note: ‘X’ can represent any period value (1, 2, 3, etc.)
Slope angles for the force mining surface have been adjusted for period X.
Note: ‘X’ can represent any period value (1, 2, 3, etc.)
Failure while importing CSV. Invalid index: .
This warning message is designed to prevent users from spending time on incorrect scenario setups by flagging potential inconsistencies with the block model data.
It often occurs due to typos, such as inputting values with lower magnitudes than intended. For instance, if production is meant to be 10 million tons per year but is mistakenly entered as 10 thousand tons per year. MiningMath conducts basic validation checks before each scenario optimization, comparing parameters like production limits with the available material. If values are significantly lower than expected, it triggers a warning, as it may result in an unrealistically long mine life, typically over 100 years.The pre-defined scenarios with Marvin deposit can usually appear with Red Warnings.
This means that within the installation process MiningMath could not find a folder to place it. Therefore, to run it you just have to click in the scenario, choose where the files should be and save them.
It is important to mention that Marvin block model is available here, thus if lost it or want to import it again feel free to do so.
The block model must have at least two Economic Value fields, one for process and another one for dump.
MiningMath requires at least one process and one dump destination with their respective economic values. You should analyze your model and be sure to have these fields.
The economic value calculation is one of the most important procedures of MiningMath. Any error in the formula could lead to incompatible results and even increase complexity and runtime, due to incorrect assumptions derived from these values. The main validations on this step can be done by evaluating the minimum and maximum values. Once the data has been imported, you can also perform a data validation procedure.
Error parsing surface.
Usually, when you import an invalid surface, the relative field will appear in red. Hover the mouse over the field to see the details.
The first common issue here is about importing a surface which does not meet the block model limits. To check this issue, verify your origins and check your coordinates by following the steps mentioned on this page.
An additional error is based on the name of the headers of the surface file, which might be always “X, Y, Z”. Thus, if it has any other name or type, correct it accordingly with this statement.
MiningMath tries to communicate with Excel and fails.
The reason why this happens is that there are additional windows (like a login screen or an activation failure) being opened before the worksheet, which is interfering with MiningMath’s generation of reports.
Close the Excel instances completely and then reopen. If an additional window appears before the worksheet, just follow its instructions.
Running the same scenario on different machines may yield slightly different results due to floating-point precision, but this rarely affects NPV. Such variations reflect MiningMath’s flexible approach, allowing multiple valid solutions without compromising economic value.
MiningMath relies on online activation based on the internet connection, or through an identification code from your hardware as a contingency.
If you are experiencing issues with activating your license, you can find the license information on the licensing screen.
Identify your error number/message.
Get your hardware identification code (Host ID), by the two following options:
a) Copy the text disclosed at the "Informations for support", if it is available for you
b) Execute this procedure bellow, explained in this video.
Send us the error number/message generated and the identification (Host ID) by filling this form.
Note: If your error number is -3001 get your solution at this page.
Note 2: The revoke license procedure, available only in commercial licenses, started after version v2.0.24. Therefore, make sure to have an updated version before revoking it on your computer and activate it in another one.
Periods without visible progress often indicate that MiningMath’s solver is still actively working through complex scenarios. These pauses are normal in integrated optimizations, and interrupting them can prevent the model from reaching high-quality, fully converged solutions.
The percentage displayed on the progress bar is only an estimate, as mathematical programming can be unpredictable.
The pre-processing steps, in which the algorithm eliminates the useless material, might keep it stuck in the initial percentage (2%, 4%, etc) for a while, but after that, the optimization can get faster.
If the remaining time reaches zero but the progress bar hasn’t completed and results aren’t available, it’s likely due to the unpredictability of mathematical programming calculations. We recommend waiting until the software completes the optimization—the bar will fill completely, “Completed” will display, and results will become available.
MiningMath can virtually handle any model size. It has successfully run models from clients beyond 10M blocks without reblocking, which might take a few hours to finish. The runtime is directly proportional to the number of blocks, destinations, periods, constraints in use, and variables imported. Therefore, the combination of multiple aspects, are directly related to the complexity of the deposit.
Check for any ‘floating blocks‘ that are not connected to the model’s topography, as shown below. These regions can impact optimization, so removing them might help MiningMath to function properly.
The Home Page centralizes access to your most recent projects and core optimization tools, streamlining your workflow from startup to execution.
MiningMath automatically opens on the home page, as shown below.
Two main areas are acessible from the home page:
Recent projects:This section allows you to select a project. Right-clicking on the project name provides you with a range of options:
New scenario: The "Scenario Config" window will open, allowing you to choose which decision tree to place your new scenario in. You can also enter a name and a description for it. After that, you'll be directed to the Scenario tab to set it up
Here's a more user-friendly version:
Show in Explorer: This option opens the directory containing the folder with your project files and data.
Remove from list: This option removes the selected project from the Recent Projects list
Delete project: This option permanently deletes the project and all associated scenarios.
MiningMath menu: this provides quick access to essential functions.
Here's a description of each item:
New Project: Use this option to start a fresh project. Clicking on it will allow you to create and configure a new mining optimization scenario from scratch.
Open Project: This allows you to open an existing project that you have previously worked on. You can browse your files and select the project you want to continue.
License: Clicking on this option takes you to the licensing section, where you can manage your software license, check its status, or enter a new license key. More info about license can be seen here.
Help: This displays a new window with key software information and links to other essential resources.
Close: This option closes the current session or the entire application.
Once a project is selected, the Decision Trees and Model areas will be displayed (as depicted below).
Both sections provide key information about project results and block model parameters. They can be used as follows:
Decision Trees: This feature allows you to quickly navigate through recent scenarios without needing to open them from their original folders.
Additionally, it lets you create new tabs and organize your mining planning strategies by exchanging scenarios as needed. You can access all paths involved in the project, giving you a comprehensive view that enhances your decision-making process (read more). To open any scenario, right-click and select the "Open" option.
1) Add new trees by clicking on “+” 
2) Rename a tree by double-clicking its name
3) By right-clicking on the tree name, you can add a new scenario, rename the tree, or delete it.
For more options, right-clicking on a scenario’s name reveals hidden choices: open, view model, rename, show in Explorer, delete, and transfer it between decision trees.
Finally, the scenario description can be easily edited with a double click.
Model Table: This section provides key information about your block model and its parameters, allowing you to easily review it at any time using the "Edit" button. This will take you to the Calculator functionality.
This tab streamlines model preparation by allowing users to edit parameters, validate data with built-in tools, and export block models in CSV format for external use.
This tab lets you modify your block model to meet your project requirements. You can also export the block model in CSV format for use with other software packages.
The Model tab begins with the Parameters option, displaying your data from the previous setup during import, along with all other existing fields. You can also remove any parameter if needed.
The Function tab features the Validate Block Parameters table, allowing you to select a single field in your model to verify its values. It also includes an internal Calculator for making adjustments and adding new fields to your block model.
The Viewer tab enables engineers to quickly compare economic results like Net Present Value across multiple mine planning scenarios within a single interface, reducing manual data handling and accelerating decision-making. Its clear visualization of complex optimization outputs helps validate assumptions and align technical and business goals, while MiningMath’s automated feedback supports rapid iteration and refinement to improve mine profitability efficiently.
MiningMath’s 3D Viewer enhances your workflow by providing a comprehensive visualization of your block model, optimization results, and surfaces from various angles. This tool allows you to filter and customize displayed features, offering a quick and efficient overview of your data and optimization processes.
After running your scenario, the MinedBlocks.csv file will display its results on the 3D viewer, allowing you to see your model from different angles. By selecting “Period Mined,” you can view the mining sequence period by period.
By selecting a surface, you can identify topography changes for each period and adjust its opacity, making visualization easier.
MiningMath also lets you import existing surfaces by placing them in the same folder as your other files, allowing you to validate their geometry if needed. Click on Load Scenario to import multiple scenarios and compare them, helping you extract the best results according to your project constraints.
After importing a model, you can manage the scenario setup in the Scenario Tab. The setup process is divided into several guided steps, helping you configure all necessary parameters. Before running the optimization, you’ll receive a summary of the entire setup for your review.
Feel free to explore each step using the links below or by navigating the page tree on the left side of the knowledge base.
Setting general parameters defines the baseline assumptions that drive scenario analysis and optimization. MiningMath allows simultaneous adjustment of key economic and operational inputs, reducing manual rework and speeding scenario iteration. Its unified model framework supports consistent recalibration across scenarios, while academic validation and global use ensure reliable parameter management for engineers and operators focused on maximizing mine value.
When you open a scenario in the Scenario Tab, MiningMath automatically takes you to the General subtab. Here, you’ll find all the essential inputs, including densities, economic parameters, slope angles, and stockpile information.
The description of all sections are outlined below.
Densities: These values are used alongside the block size to help calculate tonnages.
You have two options to define densities:
Field: This displays the column(s) assigned to density during the import process. It allows you to set varying densities for each block.
Default value: This applies to any block that doesn’t have density information, regardless of whether a density column was imported. It’s also used when you select the field as <none>.
Economic Parameters: This field lets you set the discount rate, which is usually applied on an annual basis.
The discount rate reflects the time value of money, impacting how future cash flows from mining ore and waste are valued. It plays a crucial role in the algorithm's decision-making process by influencing the timing and prioritization of mining activities. For more information on economic values, click here.
Slope Angles: These are one of the most important parameters when considering constraints hierarchy.
You have two options for defining slope angles:
Field: This displays the column(s) assigned to slope during the import process. It allows you to set different slope angles for each block.
Default value: This applies to any block that doesn’t have slope information, even if a column was assigned. It’s also used when you select the field as <none>.
Stockpiling: You can enable this feature by checking the box.
When this option is enabled, you can define two parameters:
Fixed mining cost (cost/t): This refers to the average mining cost used in the economic function. This value helps break down the economic value while accounting for stockpiles
Rehandling cost (cost/t): This represents the cost of reclaiming blocks from the stockpile for processing.
Efficient destination assignment directly affects mine profitability by optimizing where and when blocks are sent. MiningMath’s Destinations tab integrates destination decisions within a single optimization step, reducing manual rework and enabling rapid scenario iteration.
Defining destinations is the next essential step after completing the General Parameters. In the Destinations subtab, you can easily add or remove processes and dumps using the buttons on the right bottom.
MiningMath requires at least one destination for processing and one for dumping. Each process must have a recovery field, and you can also define stockpile limits for each destination.
Recoveries and stockpile limits are described next:
Recovery: For each processing stream, you need to specify a recovery value (ranging from 0 to 1) for any element or mineral whose column has been imported as a grade.
This value on the interface is intended solely for generating reports, as it has already been accounted for in the economic calculations.
Stockpile limits: If activated in the General subtab, you can set a tonnage limit for the stockpile here. MiningMath treats this specified tonnage as a cumulative upper limit, applying it throughout the entire life of the mine.
In this example, a limit hasn’t been defined, which means there is unlimited capacity for stockpiling (read more about stockpiles).
Finally, the destination of each block will be reported by assigning them with the numbers 1 to N (see the numbers beside the Name column), which depends on the order of addition.
When working with more than two destinations, you can group certain destinations into different categories. This is especially useful if you need to limit production capacity across grouped destinations. To define groups, simply switch to the Groups tab.
You can add or remove groups using the buttons on the right. To include or exclude destinations from each group, simply click on the red or green cells.
The Production subtab allows you to define custom period ranges and assign both production capacities and economic values per destination. By integrating these parameters directly into the scenario, MiningMath ensures that operational constraints and time-based economic variations are accounted for within the optimization process.
Once you’ve completed the General and Destination subtabs, the Production subtab will be enabled.
In this section, it’s important to add period ranges by clicking the Add Range button in the bottom right corner. Typically, period ranges are defined for annual periods, as shown below.
However, you can also incorporate both short-term and long-term planning within a single scenario (as shown below) or use any combination of period ranges you prefer.
After defining the period ranges, you’ll need to add production capacities and economic values for each range.
Production capacities: Set limits (in tonnes) for each destination, as well as the total amount of material moved per period (read more about production constraints).
Note: If destinations groups were defined at the previous Destinations subtab, these should also be displayed here in order to have their production limited.
Economic values: For each period range and destination, assign an imported economic value. A single destination can have different economic values for various period ranges, as shown below.
MiningMath integrates destination assignment within a single optimization process, enabling simultaneous scheduling and destination decisions that reduce manual rework and support rapid, reliable scenario testing to maximize mining value.
Once the Production subtab is complete, the Geometric subtab will be enabled. In this section, you can define parameters designed to find solutions that meet the basic requirements for operational feasibility.
You can define five different parameters for each period range and timeframe:
Minimum mining width (MW)
This parameter specifies the distance (in meters) from one pit to another. Wider values allow for greater mining fronts and better designs for nested pits, pushbacks, schedules, or any other desired outcomes. (read more).
Minimum mining length (ML)
This parameter defines the minimum distance (in meters) required between at least two points along the walls of surfaces in two consecutive mining periods. This distance is automatically maintained for any values that are smaller than or equal to the Minimum Mining Width (MW) (read more)
Minimum bottom width (BW)
This parameter specifies the minimum horizontal distance (in meters) on the lowest floor of the pit. It ensures that mining operations can be conducted effectively based on the equipment sizing (read more).
Vertical rate of advance
This parameter indicates the vertical distance (in meters) mined in each period. It is calculated by evaluating each mining face independently (read more).
Surface mining limits
You can add two types of surface restrictions:
Force mining: This option requires a surface file (.csv) as input. It defines an area that must be mined within a specified time frame, ensuring that all material within the boundaries is fully depleted (read more).
Restrict mining: This option also requires a surface file (.csv) as input. It defines an area outside the imported surface that cannot be accessed within the specific time frame, effectively setting a maximum mining depth for that period (read more).
Geometric constraints are non-linear and may produce unexpected results as new values are tested. To improve performance and apply stricter requirements, it’s highly recommended to use the Design Enhancement workflow.
Calculating average values across scenarios is key for assessing risk and performance in mining operations. MiningMath’s Average feature supports integrated optimization by aggregating results from multiple runs, reducing manual rework and enabling faster iteration. Its unique approach allows unconstrained risk analysis, while automation and API scripting streamline testing and communication of average outcomes to inform operational decisions.
In the Average subtab, following the Geometric subtab, you can define the minimum, maximum, and weight for the average values of any element or mineral imported as an Average field.
Average constraints can be defined by period ranges, destinations and destination groups.
For each element or mineral imported in each destination and period range, you can set the corresponding weight, mining values, and maximum values.
Weight is defined on a block-by-block basis and is associated with an imported field. The minimum and maximum values serve as limits for the average values of the corresponding material or element within the specific destination and period range (read more).
MiningMath’s Sum function enables integrated, simultaneous aggregation of scenario results to streamline risk evaluation and accelerate decision-making with minimal manual effort.
Sum constraints can be defined by period ranges, destinations and destination groups.
For each field imported in each destination and period range, you can set the corresponding mining values and maximum values.
The minimum and maximum values serve as limits for the sum of the corresponding field within the specific destination and period range (read more).
MiningMath’s Scenario Overview centralizes all parameters for a scenario on one page, enabling engineers and operators to efficiently review and adjust inputs. This supports fast iteration across unlimited scenarios and decision trees, integrating variables simultaneously to deliver optimized, realistic mining plans that enhance profitability while reducing manual rework.
The Overview subtab provides a single page summary of all parameters related to the current scenario.
You can use it to review or adjust any General parameters, Destination parameters, and parameters related to Constraints by period ranges.
Due to the number of constraints and imported fields, you might need to scroll horizontally in order to visualise all the fields related to each period range (depicted below).
Once all configurations have been reviewed you can click on Save.
If there are any files on the scenario’s folder, you will be prompted to confirm if the files can be replaced. In case not, please rename your scenario for it to be saved in a different folder.
Running scenarios in MiningMath enables engineers and operators to evaluate and optimize mine plans by executing integrated, simultaneous optimizations of all mining periods and parameters, producing solutions with potentially higher net present values than traditional methods. This process supports rapid iteration through configurable time limits and queue management, reducing manual rework and accelerating the assessment of alternative strategies. Detailed, exportable results facilitate thorough analysis and integration with other tools, helping identify risks and opportunities early in the planning process.
Once a scenario has been configured, you can use the Run option to execute the scenario.
Advanced options are also avaible before executing a scenario.
Time limit (h)
It is possible to indicate a time limit in hours before running a scenario. The time limit is defined in hours due to the usual complexity of mining projects (read more).
Run options
You can set different export options by clicking on the small button under the Run option (read more about output files).
After the scenario finishes running, you will be able to acess its report, visualise results in the Viewer and also have a summary information in the decision tree.
Accurate formatting of block model data is essential for effective mine planning and optimization. It ensures that all relevant geological and economic variables are correctly interpreted by the software, enabling reliable and actionable results.
The following formatting specifications are required:
Regularized block model: This means all blocks must be the same size.
Air blocks must be removed prior to importation. This is the way MiningMath recognizes the topography.
Coordinates of each block in the 3 dimensions.
Header Names should not have special characters or have them exceed 13. Use this recommendation for folders and files also.
The data format should be a CSV file (Comma Separated Value), which might be compatible with most mining packages.
MiningMath comes preinstalled with the Marvin dataset. Download this file here.
MiningMath does not recognize CSV’s using semicolon (;) as a decimal separator. You may need to change your Windows configuration, by following these steps:
1. Click Start, type control and click to open Control Panel. 2. Under Clock and Region, click Change data, time, or number formats. 3. Click Additional Settings…, and then we can manually change the Decimal symbol.
Finally, you will need to change the separator on the CSV. On Excel, you will need to open it, convert text to columns, and then save it again.
Field Types are the fields MiningMath can understand. Each column imported should be assigned to the proper field type (as depicted below) so that the software treats each variable accordingly with its meaning.
Coordinates X, Y, and Z refer to your geo-referenced information.
Average refers to any variable that could be controlled by means of minimums and maximums considering its average: grades, haulage distance, and other variables.
There should be at least one element assigned as Average.
Economic Value refers to the columns containing economic data that represent the available destinations for material allocation. To execute a scenario, the model must include at least one process destination and one waste destination.
It is possible to import multiple economic values at once, and they may be used simultaneously (ex.: multiple processing streams) or calculated in the internal calculator.
Density refers to the block's density. This field is used to calculate the block's tonnage.
Slope refers to slopes varying block-by-block, which gives the flexibility to define slopes by lithotype and sectors.
Recovery refers to recoveries varying block-by-block.
Sum refers to any variable that could be controlled by means of minimums and maximums considering its sum.
Predefined destinations refers to possible fixed destination values. This can be used if you want to define pushbacks or apply lithologic restrictions that prevent certain blocks to be processed. However, by fixing destinations you are impeding MiningMath to reach its full potential. More about this here.
Other refers to information that you with to have in the exported outputs.
Skip refers to any variable that should be ignored. This field type might help improving the runtime since these variables will not be considered and exported along with the optimization outputs.
Shortcuts can be used for automatic recognition in the importation process as in the following image:
The full list of shortcuts is listed below.
| Field name | Shortcuts |
|---|---|
Coordinates | X | Y | Z |
Average | @ | grade |
Density | % | dens | sg |
Economic value | $ | dest | val |
Recovery | * | recov |
Slope | / | slope |
Sum | + |
Skip | ! |
Each software has unique conventions for data formats, naming, and numbering systems. To prevent conflicts when transferring data between different software, ensure you follow the specific procedures required by each. There’s no universal standard—just the correct approach for each tool.
The model’s origin must be placed at the bottom portion, starting to count from the minimum coordinates at X, Y, and Z.
The following image highlights a block model origin at the corner of the first block and the coordinates on its centroid.
MiningMath uses coordinates (X,Y,Z) for which Z, which represents the elevation, starts upwards.
Other mining software may use indexes with IZ starting downwards. MineSight is an example that uses this notation.
To invert coordinates in this format use the following formula to convert:
\(new(Z) = max(Z) + 1 – current(Z)\)
Avoid Common Errors:
1) Ensure the coordinates align with the block dimensions relative to the set origin.
2) Avoid repeated coordinates in the CSV file to prevent import failures.
MiningMath recognizes that all imported blocks of your model are underground. This means it is necessary to remove all the air blocks prior to importation. Unless your topography is totally flat, which is unlikely, the image below shows an example of your model should be displayed.
The non-removal of air blocks may lead to unsatisfactory results and long processing times, since it would be considering blocks that do not exist in reality.
The following video shows how to do remove air blocks using filters on MS Excel. These tips are also applicable to any mining software of your choice.
Correct block model import is critical for integrating geological and economic data to support effective mine planning and optimization. MiningMath needs uniform block sizes and air blocks removal before import.
To import the block model, select the option New Project on the left panel of MiningMath.
Afterwards, the file name input field is shown in red, indicating a mandatory field. Browse for and select the CSV formatted file. Press Next to advance.
A series of project parameters will be requested in order to setup your project. This will be asked in a series of forms as detailed next.
In the next window the Model Name must be entered.
Optionally, the destination folder (Model Folder) can be changed as well as the Scenario Name, and a Scenario Description can be added.
Upon clicking Next, the following window will provide a statistical summary of information for the block model that will be imported. Check the parameters carefully, In particular economic values
Columns imported must contain only numeric values. If a column includes non-numeric values, its minimum and maximum values will appear as “NaN” in the preview. Additionally, the system will only allow the column to be set as “other” or “skip.” Ensure your data is properly formatted to avoid this issue.
Upon clicking Next, the CSV file will be imported into MiningMath, and show data related to the block model geo-reference system, that can be only coordinates. The next steps are to place the rotation degrees (Azimuth rotation), origin (accordingly with your mining package) and the block dimension. The number of blocks is automatically calculated after the origin and dimensions are provided as depicted below.
MiningMath supports the use of block models that have been rotated using an Azimuth rotation.
The amount of rotation degrees can be passed as depicted in below.
After importing, you can see the rotated model in the Viewer tab.
The detailed steps with mathematical formulations for the rotation procedure can be seen here.
To manage multiple pits (multi-mine) within a single project, with as a combination of a rotated pit and a non-rotated pit, follow these steps:
1. Unrotate the rotated model, converting it into a regular model.
2. Combine your models into a single block model.
3. Run your scenarios.
4. Rotate the results back.
When Next is selected, the following form will appear, showing correlations between the imported CSV file header and the available field types in MiningMath.
You must associate each imported column to one of the options located just above the table, for instance: block coordinates X, Y, and Z to Coord. X, Y, and Z field types. For more details on how you can correlate each column, access this link. You can also keep the original data from your previous Mining Package, by using this approach.
If you do not already have an Economic Value function, when importing your block model, you will be directed to the Scenario tab. Then, click on the Function tab to calculate your Economic Value function in the internal calculator as explained here.
MiningMath has mandatory variables (columns) to be assigned to the proper Field Type:
1) Coordinates (X, Y, Z).
2) Average
Validating data screen might be overlooked, but it is very important to validate one's data based on minimums and maximums. Read more.
Each column imported should be assigned to the proper field type in order for MiningMath to treat each variable accordingly. Read more.
Typically, MiningMath recognizes some columns automatically when their headers are similar to the Field Type name. Otherwise, the MiningMath will automatically assign them to the Field Type sum.
To enable the Next button, the user needs to assign each one of the mandatory variables to their respective Field Type.
The next step is to input the grade units. As in the example below, the copper grade has been defined as a percentage (%), while gold grade was defined as PPM, which stands for parts per million and, in turn, is equivalent to g/ton.
After filling all the required fields, the options View Model and Setup Scenario will be enabled. Before setting up your first scenario you can view it by clicking in the View model (example below).
This evaluation in the Viewer should help you answer questions such as:
This is usually an error related to the origins. We recommend checking the origins from the previous mining package, otherwise, MiningMath’s results won’t match the actual coordinates.
You should be aware that MiningMath employs coordinates (X,Y,Z), where Z, representing elevation, starts from the bottom. However, some other mining software may start from the top.
Also check the minimum and maximum values for each coordinate (X, Y and Z) of your CSV file to confirm if they are all within the box of your block model. And always remember that the origin must be the (minX, minY, minZ) of this box, as shown here. Therefore, all the block centroid coordinates in the CSV must be greater (>) to the origin values.
The calculation of the origins is quite simple. Usually, when your CSV file has all blocks below the topography, just take the minimum value of each axis, indicated on the first import screen, and subtract half a block. This will give you the correct origin.
This error may also be related to other aspects such as incorrect spacing (coordinates that do not respect the block dimensions, considering the set of coordinates and the origin), and repeated coordinates, among others. Therefore, we also recommend reviewing the steps of formatting the block model and importing the block model to ensure there are no inaccuracies.
Read permission is required to import your CSV file, while write permission is necessary for SSMOD file. Ensure that the user or group has appropriate permissions in that folder. For more information on configuring file and folder permissions, please refer to the relevant section in the Windows documentation or contact your system administrator.
If you’re getting a “Cannot open file” error when trying to load your CSV into MiningMath, even after trying different locations and running as administrator, here are the main steps to troubleshoot it:
Make sure the file is not open in Excel or another program when you’re trying to load it.
MiningMath requires CSV files with UTF-8 encoding and correct structure. Let’s double-check a few things:
.xls, .xlsx, or .csv.txt.., not a comma ,.C:\MiningMath\Projects\blockmodel.csvC:\Usuários\João\Área de Trabalho\meu_modelo.csvC:\MiningMath\model.csv.You’ve already tried launching as Administrator – that’s great. But if you’re on a corporate or school computer, IT restrictions could still block access. Try moving the file to:
And open from there.
Sometimes Excel saves the CSV in an incorrect encoding.
Here’s how to fix that:
If you experience an insufficient memory warning or a sudden crash while using MiningMath, here are some steps to improve performance:
Upgrade Your RAM: if possible, increasing your RAM is the most effective way to enhance performance. The recommended specifications are listed in the “Recommended Hardware” section. Based on our experience with complex projects, 64 GB is sufficient for most cases.
Free Up Memory: close any unnecessary applications running in the background to free up RAM while using MiningMath.
Increase Windows Virtual Memory: you can allocate disk space to be used as additional RAM. For step-by-step instructions, follow this tutorial.
Reblock the Model: if memory issues persist, consider reblocking to reduce the model size. More details can be found here.
MiningMath does not recognize CSV’s using semicolon (;) as a decimal separator. To change it on Windows, go to:
'Control Panel' > 'Clock, Language, and Region' > 'Region' > 'Change date, time, or number formats' > 'Additional Settings'
Next, change the List Separator to the comma sign (,). Press OK and OK. Finally, you will need to change the separator on the CSV. On Excel, you will need to open it, convert text to columns, and then save it again.
Economic values guide decisions on whether to process or discard material, directly affecting mine profitability and operational efficiency.
MiningMath does not require pre-defined destinations ruled by an arbitrary cut-off grade. Instead, the software uses an Economic Value for each possible destination and for each block. The average grade that delineates whether blocks are classified as ore or waste will be a dynamic consequence of the optimization process.
For optimizing a scenario, MiningMath requires two mandatory destinations at least. Therefore, each block must be associated with:
1 Processing stream and its respective economic value
1 Waste dump and its respective economic value
Even blocks of waste might have processing costs in the economic values of the plant. Therefore, non-profitable blocks would have higher costs when sent to process instead of waste.
If you have any material that should be forbidden in the plant, you can use economic values to reduce the complexity and runtime, as mentioned here.
Simplified flow-chart of blocks’ destinations optimization.
MiningMath insider version allows for the setting of economic values per period. Check all MiningMath versions here.
As you can see, in the Production tab, a new Economic Values option is enabled. You can use it to assign different economic values for each defined range.
Each field related to Economic Value (Process/Waste) must report the value of each block as a function of its destination (Process or Waste in this example), grades, recovery, mining cost, haul costs, treatment costs, blasting costs, selling price, etc. The user is not required to pre-set the destination, as the software will determine the best option during the optimization.
To calculate the Economic Values you can use MiningMaths’s internal calculator, available at the “Function” option inside the “Model” tab. To illustrate the calculation of economic values, an example is shown below. The calculation parameters are listed in Table 1.
| Description | Cu (%) | Au (PPM) |
|---|---|---|
Recovery | 0.88 | 0.6 |
Selling price (Cu: $/t, Au: $/gram) | 2000 | 12 |
Selling cost (Cu: $/t, Au: $/gram) | 720 | 0.2 |
Processing cost ($/t) | 4 | |
Mining cost ($/t) | 0.9 | |
Discount rate (%) | 10 | |
Dimensions of the blocks in X, Y, Z (m) | 30, 30, 30 | |
Table 1: Parameters for calculating the economic values.
Block Tonnes = BlockVolume * BlockDensity
Block Tonnes = 30*30*30*[Density]
Tonnes Cu = Block Tonnes x (Grade Cu/100)
Tonnes Cu = [BlockTonnes]*([CU]/100)
Mass Au = Block Tonnes x Grade Au
Mass Au = [BlockTonnes]*[AU]
Economic Value Process =
[Tonnes Cu x Recovery Cu x (Selling Price Cu – Selling Cost Cu)] +
[Mass Au x Recovery Au x (Selling Price Au – Selling Cost Au)] –
[Block Tonnes x (Processing Cost + Mining Cost)]
Economic Value Process = ([TonnesCu]* 0.88 * (2000–720)) + ([MassAu] * 0.60 * (12 – 0.2)) – ([BlockTonnes] * (4.00 + 0.90))
Economic Value Waste = –Block Tonnes x Mining Cost
Economic Value Waste = –[BlockTonnes] * 0.9
The example block in Figures 4-6 would generate -299,880$ if it is sent to the process, and –55,080.1$ if discarded as waste. Therefore, this block might go to waste, since it would result in less prejudice than when it is processed. MiningMath defines the best destination regarding the set of constraints throughout the time, thus this decision a lot more complex than the example above in most cases.
The economic value calculation is based solely on the values assigned to the blocks. However, if you need to incorporate additional costs and revenues, our economic functions are fully customizable. You can easily model them using our built-in calculator.
Alternatively, you can also use scripts to work with formulas in CSV format. The Labs section provides some custom-built apps that could be useful for that.
Data validation ensures input data quality, preventing errors that slow mining project workflows and enabling more reliable optimization.
Running an optimization for complex projects with several constraints may demand hours only to validate if the formatting has been done properly. Therefore, we present here how to quickly validate your data in MiningMath.
Data validation can be done by following the validation wizard, available in the latest versions of MiningMath, or by following the direct mode instructions at the end of this page. We will first walk through the wizard, which should feel easier and more straightforward, then explain the direct mode process for users of older versions and for advanced users who might prefer greater autonomy and control.
This page uses the Marvin Deposit as an example. To see its parameters and constraints please check the page here.
The wizard is provided (starting on 3.0.13 version) to help with the data validation process. It will automatically start once you have finished importing your data.
Fill in only the necessary information regarding slopes, density, destinations and economic values.
View results and follow instructions for evaluation.
Lastly, check your validation scenarios again (if necessary) in the decision tree or start another process from the new Validation button at the bottom of the Scenarios tab.
In order to directly or manually validate your data, you should close the validation wizard after it is automatically started by the end of the formatting process.
We strongly recommend running MiningMath FULL with the following set up:
Process and dumps set with respective recovery values.
A bigger production capacity than the expected reserves. In this example, the expected life of mine vs production rate is 35-year producing 10 Mt per year. Hence, a value of 1,000 Mt would be big enough to cover the whole reserve.
No discount rate.
No stockpiling.
Density and slope values.
Timeframe: Years (1), since it would all be processed in 1 period.
The figure below depicts this set up at MiningMath, with the highlighted fields.
Results are depicted below, with blocks in the sequencing, surface, surface with blocks and production tonnage.
Ultimate pit
The surface returned by this data validation process represents the most economically viable pit shell, also known as the ultimate pit.
Did the scenario run properly?
Are most of the positive economic values from the process inside this surface?
Is the mining happening in reasonable areas?
Is there a reasonable number of periods of life of mine?
Constraint validation ensures mining optimization models reflect real operational limits, reducing errors and supporting reliable decision-making.
Continuing the data validation, start to add the first constraints related to your project so that you can understand its maximum potential. The surface generated in this case could also be used as a restrict mining in the last period to reduce the complexity of your block model and the runtime of MiningMath, since it includes a set of constraints inputted.
Set up a scenario with 1,000 Mt in the processing plants, which corresponds to a lot more mass than expected in the whole life of the mine.
Add the Minimum Bottom Width (100m). This constraint will allow you to have a suitable work-front for your equipment.
Restrict Mining surface, if you have this constraint in your project.
Grade constraint until 0.7%.
Timeframe: Years (1), since it would all be processed in 1 period.
Note: Sum constraints can restrict the total amount of handling material (ore + waste) of the mine. Therefore, do not use them in the validation.
Now that Constraints Validation step is done, you are able to use this final surface as a guide for future optimizations. This approach reduces the runtime and the complexity of the algorithm because when you take it into account, the blocks below this final optimized surface won’t be considered and the heuristics inside the interface would be facilitated. Notice that we did not make any change in the discount rate, thus, this first NPV does not represent the reality. If you need an accurate result in this step, make sure to adjust it.
It’s important to remember that when we restrict the mining into this surface, the number of periods generated in future runs could be reduced because the average parameters of each one will have to meet the constraints of the overall package. Therefore, to achieve the same parameters in a lower timeframe, some blocks may be discarded due to the mining sequence and the optimization of destinations inside the whole mass.
Having this idea in mind, you should already have enough information to decide and structure the next step of the optimization. Based on the amount mined in the last item and in the processing capacity, define a good timeframe to identify the mining sequence. In this case, we had 231 Mt as the ore total mass to split in almost 23 years, since the processing capacity is 10Mt.
To improve efficiency in the optimization, before working on a yearly basis, we made the decision to consider the first 5 years. It is reasonable to generate a 10-year surface to consider the optimization inside this limit due to observations made before. Remember that each assumption here can be done accordingly with your project’s demands and that MiningMath can work with any timeframe to meet your needs.
Efficient exports are key for aligning optimization results with other tools. MiningMath structures outputs for rapid integration and data consistency.
Select the button Export Model on MiningMath’s Model tab, as shown below.
Clicking on Export, a new page will appear, allowing you to select the folder where the block model exported would be saved with its name.
Just click on “Next” for your model to be exported to the folder selected.
MiningMath allows you to learn, practice, and demonstrate, by showing any scenario previously ran the concepts of Strategy Optimization using the full capabilities of using only Marvin Deposit. This version is freely available to mining professionals, researchers, and students who want to develop their abilities considering this standard block model.
If you are working with the Marvin deposit along with MiningMath free version, be aware that the inclusion of new fields is allowed, as long as: 1) there is no inclusion or exclusion of blocks in the file; and 2) the SLOPE, DENSITY and COORDINATES fields are not modified.
An error message might be displayed when modifications are detected in the basic structure of the standard Marvin deposit. Therefore, use the original CSV file provided with the MiningMath installation.
Below are listed the default parameters for Marvin according to the adaptions made in our formatted model.
| Parameter | Value |
|---|---|
Block size | 23000 m³ (X = 30m, Y=30m, Z=30m) |
AU - Selling Price | 12 $/g |
AU - Selling Cost | 0.2 $/g |
AU - Recovery | 0.60 |
CU - Selling Price | 2000 $/ton |
CU - Selling Cost | 720 $/ton |
CU - Recovery | 0.88 |
Mining Cost | 0.9 $/ton |
Processing Cost | 4.0 $/ton |
Discount Rate | 10% per year |
Default Density | 2.75 t/m³ |
Default Slope Angles | 45 degrees |
Some common constraints applied to the Marvin deposit are listed below.
| Constraint | Value |
|---|---|
Processing capacity | 10 Mt per year |
Total movement | 40 Mt per year |
Sum of processing hours | 4,000 per year (detailed estimate of the plant throughput) |
Vertical rate of advance: | 150m per year |
Copper grade | Limited until 0.7% |
Minimum Mining Width | 50m |
Minimum Bottom Width | 100m |
Restrict Mining Surface | Some surface in .csv format. For example due to a processing plant in the area. |
Fixed Mining (Stockpiling) | 0.9$/t |
Rehandling cost (Stockpiling) | 0.2$/t |
BlockSize * Density * [GradeCU/100 * RecoveryCu * (SellingPriceCU – SellingCostCU) + GradeAU * RecoveryCu * (SellingPriceAU – SellingCostAU) - (ProcessingCost + MiningCost)]BlockSize * Density * MiningCostBelow are listed the default parameters for the McLaughlin deposit according to the adoptions made in our formatted model.
| Parameter | Value |
|---|---|
Block size | X = 7.62m (25ft), Y = 7.62m (25ft), Z = 6.096m (20ft) |
AU - Selling Price | 900 $/oz |
AU - Recovery | 0.90 |
Mining Cost | 1.32 $/ton |
Processing Cost | 19 $/ton |
Discount Rate | 15% per year |
Default Density | 3.0 t/m³ |
Default Slope Angle | 45 degrees |
BlockSize * Density * [GradeAU * RecoveryCu * (SellingPriceAU) - (ProcessingCost + MiningCost)]BlockSize * Density * MiningCostMiningMath exports optimized mining results primarily in universal CSV and Excel formats, including detailed mined block data, mining sequences, and pit surface grids. These outputs enable easy integration with other mining software and support scenario comparison without manual rework.
The Execution Options or Run Options allow the user to define:
Files to be exported.
The visual results to be automatically shown on the viewer after each run.
Figure 1 highlights in (A) where the user can trigger this pop-up window and in (B) the options available, among which the user can:
Export/not export to CSV files:
Set which results to be shown on the viewer:
MiningMath automatically produces:
Formatted reports (XLSX files).
Tables (CSV) whose data feeds the reports.
Updated block model (MinedBlocks or AllBlocks).
Surfaces as a grid of points (CSV)
MiningMath organizes files, as listed below:
SSMOD and SSPRJ are important to report any issues you face.
List Item
SSMOD and SSPRJ are important to report any issues you face.
After each optimization, MiningMath exports the block model in one of two formats:
MinedBlocks.csv: The file presents only the blocks that have been mined from each scenario. Mined Blocks are exported by default, as it is a lighter file.
AllBlocks.csv: The All Blocks file presents all the blocks, whether mined or not, from each scenario, so it is basically the original Block Model along with resultant information from the optimization.
The resultant model includes all columns imported (except the skipped ones) besides the following information:
Mined Block shows whether (1) or not (0) a block have been mined.
Period Mined shows in which period a block have been mined (-99 for blocks that have not been mined). To learn more about the mining sequence within a period, access here.
Period Processed shows in which period a block have been processed (-99 for blocks that have not been processed).
Destination informs the destination of each block — according to the order the user has added processing stream(s) and waste dump(s).
Figure 2 shows where the user can interchange of these options.
Click on the highlighted Execution button (A) to open the Run Options (B).
Select All blocks in model or Only mined blocks, as you need.
Hit OK, then Run.
By default, MiningMath exports the MinedBlocks file as a block model output
MiningMath will generate a report directly on Microsoft Excel, as shown in the following image, and the optimized pit (blocks and surface) in the viewer in case the user chooses this option (right figure above). The automatic preview shows only the mined blocks, colored according to each mining period defined by the scheduler.
The results presented in the Excel spreadsheet show, in the Charts tab, the graphs relative to the reported results calculated in the Report tab. The processed mass results, discarded mass, stock development, Au/Cu percentage in the process, Au/Cu percentage in the dump, metal contained in the process, net present value and cumulative net present value are arranged individually in the Production Process 1, Production Dump 1, Stock Process 1, AU/CU – Grade Process 1, AU/CU – Grade Dump 1, AU/CU – Metal Process 1, NPV and Cumulative NPV tabs, respectively.
By default, MiningMath exports only the Mined Blocks file showing them by period on the viewer, as in the following illustration. The user can change any exporting options on Run Options menu.
If the user chooses to export the model, MiningMath will automatically save the list of the scheduled blocks (MinedBlocks.csv) or all blocks (AllBlocks.csv) in the block model folder, as shown in the figure below, which can be imported into other mining software packages.
The files MinedBlocks.csv and AllBlocks.csv may contain indices and/or block coordinates, and all the imported data/parameters along with the following information:
Mined Block shows whether (1) or not (0) a block have been mined.
Period Mined shows in which period a block have been mined (-99 for blocks that have not been mined).
Period Processed shows in which period a block have been processed (-99 for blocks that have not been processed).
Destination informs the destination of each block — according to the order the user has added processing stream(s) and waste dump(s).
Video 1: Outputs and files’ hiearchy.
In the search for the upside potential for the NPV of a given project, this setup explores the whole solution space without any other constraints but processing capacities and discount rate, in a global multi-period optimization fully focused on maximizing the project’s discounted cashflow.
As MiningMath optimizes all periods simultaneously, without the need for revenue factors, it has the potential to find higher NPVs than traditional procedures based on LG/Pseudoflow nested pits, which do not account for processing capacities (gap problems), destination optimization and discount rate. Traditionally, these, and many other, real-life aspects are only accounted for later, through a stepwise process, limiting the potentials of the project.
MiningMath’s Super Best Case serves as a reference to challenge the best case obtained by other means, including more recent academic/commercial DBS technologies available. See a detailed comparison of these two approaches below.
In modern/traditional technology, large size differences between consecutive periods may render them impractical, leading to the “gap” problem. Such a gap is caused by a scaling revenue factor that might limit a large area of being mined until some threshold value is tested. MiningMath allows you to control the entire production without oscillations due to our global optimization.
In the modern/traditional methodology the decisions on block destinations can be taken following some techniques such as: fixed predefined values based on grades/lithologies post-processing cutoff optimization based on economics post-processing based on math programming or even multiple rounds combining these techniques. With MiningMath the destination optimization happens within a global optimization in a single step, maximizing NPV and accounting simultaneously for capacities, sinking rates, widths, discounting, blending, and many other required constraints.
Modern technology is restricted to pre-defined, less diverse sequences because it is based on step-wise process built upon revenue factor variation, nested pits, and pushbacks. These steps limit the solution space for the whole process. MiningMath performs a global optimization, without previous steps limiting the solution space at each change. Hence, a completely different scenario can appear, increasing the variety of solutions.
In the modern technology the mining sequence is done following an order of benches inside the pre-defined pits’ order. In MiningMath that is not necessary. The mathematical optimization is done
in a single step through the use of surfaces, not being bound to fixed benches.
Due to tonnage restrictions, modern technology might need to mine partial benches in certain periods. With MiningMath’s technology, there isn’t such a division. MiningMath navigates through the solution space by using surfaces that will never result in split benches, leading to a more precise optimization.
Modern approaches present a difference between the optimization input parameters for OSA (Overall Slope Angle) and what is measured from output pit shells, due to the use of the “block precedence” methodology. MiningMath works with “surface-constrained production scheduling” instead. It defines surfaces that describe the group of blocks that should be mined, or not, considering productions required, and points that could be placed anywhere along the Z-axis. This flexibility allows the elevation to be above, below, or matching a block’s centroid, which ensures that MiningMath’s algorithm can control the OSA precisely, with no errors that could have a strong impact on transition zones.
Before setting-up your Super Best Case scenario make sure your project data have been successfully imported and validated.
To run a Super Best Case, after running our Validation Wizard, you only need to add two more mandatory constraints: Processing capacity and Discount Rate.
Depending on your block model and specificities of your project, additional parameters may need to be specified. For example, if you have multiple destinations these could be added for proper destination optimization.
After setting up everything, just hit the “Run” button.
If you already have a scenario set up with all your project constraints and want to explore its Super Best Case, there’s no need to change anything.
Simply click the new Run Super Best Case button in your current scenario, and MiningMath will automatically run the analysis, considering only the constraints required for the Super Best Case. This delivers valuable insights into your scenario’s NPV upside potential.
The results are seamlessly integrated into your decision tree and clearly labeled to indicate the original scenario from which the Super Best Case was derived, as shown below:
Results can be analysed in the Viewer tab and the exported report file. For the pre-installed Marvin dataset, note how the sequencing has no gap problems, and the production is kept close to the limit without violating any restrictions.
The block periods and destinations optimized by MiningMath’s Super Best Case (or any other scenario) can be exported in a CSV format. You could use these results to import back into your preferred mining package, for comparison, pushback design or scheduling purposes. Export options are depicted below.
A refinement of the super best case could be done by adding more constraints, preferably one at the time to evaluate each impact in “reserves”, potential conflicts between them, and so on. You can try to follow the suggestions below for this improvement:
All restrict mining aspects due to forbidden areas.
All force mining aspects for zones that must be mined.
All sum constraints.
All dump and/or total production constraints.
All stockpiles.
Adding additional constraints may increase execution time. For running complex scenarios, it’s recommended to use a powerful machine. To facilitate testing and analyzing multiple scenarios, MiningMath now includes a new queuing system (download it here).
Generating optimized pushbacks is crucial for aligning production volume with economic viability and operational constraints on site.
MiningMath offers the option of producing optimized, single-step pushbacks with controlled ore production and operational designs. This procedure is important to ensure the financial and operational viability of the mining project, as excessively large volumes can render the project unfeasible, while excessively small volumes can result in resource wastage or missed opportunities for ore extraction.
By testing different volumes, it is possible to find an optimal point that maximizes the net present value (NPV) of the project.
MiningMath utilizes timeframes to generate pushbacks at different levels of detail. Timeframes are time intervals that divide the mine’s lifespan into smaller periods. Different timeframes allow users to perform a fast evaluation of the impact of production volume on the NPV. If necessary, adjustments can be made to optimize production and reduce costs.
In Pushback Optimization, multiple optimized pushback scenarios are created with varying levels of detail, enabling users to have a comprehensive view of the impact of volume variations on the project’s performance.
Every pushback produced with MiningMath is created in a single-step, straight from block model, taking into consideration geometric constraints such as minimum bottom width and minimum mining width, controlling tonnages, blending and other requirements.
Multiple single-step pushback scenarios can be created with varying levels of detail, enabling users to have a a higher variety of options and a comprehensive view of the impact of volume variations on the project’s performance.
You can Identify timeframe intervals in your project, so that you can work with group periods before getting into a detailed insight. This strategy allows you to run the scenarios faster without losing flexibility or adding dilution for the optimization, which happens when we reblock.
The idea is to make each optimized period represent biennial, triennial, or decennial plans. MiningMath allows you to do it easily by simply adjusting some constraints to fit with the timeframe selected. Notice that in this example, the processing was not fully achieved, and this kind of approach helps us to understand which constraints are interfering the most in the results.
Try to run with and without dump/total productions to check potential bottlenecks and impacts on waste profiles, which could be useful for fleet management exercises. Also, test with wider mining widths than required, as this is a complex non-linear constraint and you might find better shapes without losing value.
Preinstalled Marvin deposit. It can also be downloaded here.
| Property | Value |
|---|---|
Timeframe custom factor | 5 |
Processing capacity | 50Mt in 5 years |
Dump capacty | 150Mt in 5 years |
Vertical rate of advance | 750 m in 5 years |
Minimum Mining Width | 100m |
Minimum Bottom Width | 100m |
Restrict Mining Surface | Optional |
Grade copper | 0.88% |
Stockpiling parameters | On |
Note: Waste control and vertical rate of advance are not recommended if you are just looking for pushback shapes.
Given the previous initial scenario, you might want to consider different timeframes for your pushback design. In order to perform a Pushback Optimization, the timeframes (in green), process and dump production limits (in green) and the vertical rate (in red) will be adjusted.
By varying the highlighted parameters above, the following decision tree has been constructed for Pushback Optimization.
Three different timeframes are explored: 3 years, 5 years, and 10 years. Each timeframe is associated with specific process and dump production limits. Such limits not only scale with their respective timeframes but also allow for variations that provide flexibility for testing different production scenarios. Finally, the vertical rate is also adjusted to align with the defined timeframe of each scenario. For instance, the vertical rate is set to 450m for the 3-year timeframe, 750m for the 5-year timeframe, and 1500m for the 10-year timeframe.
Afterward, specific results were carefully selected for comparison, focusing on key parameters such as Net Present Value (NPV), production process, and production dump.
The 2 constraints inputted at the production tab are related to the maximum material handling allowed: the third one is about the processing equipment capacity, and the vertical rate of advance is related to the depth that could be achieved adjusted to this interval. The minimum mining width was added because we are already generating designed surfaces that could be used later as guidance of detailed schedules, thus, it should respect the parameter due to the equipment sizing. Parameters such as average, minimum bottom and restrict mining surface, don’t suffer any change in the time frames.
It’s important to remember that the packages of time here don’t necessarily have to correspond to identical sets of years. You could propose intervals with different constraints until reaching reasonable/achievable shapes for the design of ramps, for example. If you wish to produce more operational results, easier to design, and closer to real-life operations, try to play with wider mining/bottom widths rates. Those changes will not necessarily reduce the NPV of your project.
Considering this approach the discount rate serves just a rough NPV approximation and it doesn’t affect much the quality of the solution, given that the best materials following the required constraints will be allocated to the first packages anyway.
Evaluating the upside potential of your project is essential for understanding the full value range achievable under different planning strategies. This page guides you through identifying the maximum NPV and assessing how close your base scenario comes to that benchmark.
NPV Upside Potential is the process of generating and analyzing scenarios to measure the impact of each constraint on the project’s net present value (NPV), from the Super Best Case to a detailed setup. Measuring the impact of each constraint on the NPV is important to assess the financial impact and ensure the project’s viability under different scenarios and conditions. Each constraint can have a significant impact on the project’s NPV, and it is crucial to understand how they affect the project’s financial performance.
By evaluating the impact of each constraint on the project’s NPV, it is possible to identify financial bottlenecks and opportunities for improvement, as well as prioritize problem resolution. This can result in better resource allocation and cost reduction, enhancing the project’s profitability and viability.
In NPV Upside Potential, scenarios are created that sequentially incorporate each constraint of the project, allowing users to have a comprehensive view of the impact of each constraint on the project’s performance. In case more efficiency is needed, the resulting surface obtained on the Constraints Validation or in Best Case refinements could be used as Restrict Mining in the last interval, which might reduce the complexity and the runtime.
Preinstalled Marvin deposit. It can also be downloaded here.
To illustrate this process, let’s consider the base scenario of the Marvin dataset (shown in the figure below). The highlighted green fields represent all the targeted constraints that need to be controlled in this project: process capacity, minimum average grade of CU in process, dump capacity, bottom minimum width, mining minimum width and maximum vertical rate.
The decision tree depicted below has been constructed for a NPV Upside Potential process, based on the above scenario. In this decision tree, the scenarios progressively introduce each constraint into the project.
The target scenario is the last one, with the following restrictions: Process Production=10mt, Dump Production=30mt, Bottom Width=100m, Mining Width=100m, Vertical Rate=150m, and average CU=0.5. However, the constraints are added interactively, starting with the process production, followed by the dump production, widths, and so on.
Note how the cumulative NPV usually decreases (as expected) when more restrictions are added (see note at the end for exceptions). Without this interactive process, there might be a lack of information to understand the NPV of the final, desired scenario.
More constraints usually lead to lower NPV. The exceptions for that are the geometric constraints, which deal with non-linear restrictions. If you are not happy with the results achieved after adding geometric constraints you might need to perform a Selectivity Analysis or Best-Worst Range Analysis of your project.
Understanding how varying mine width constraints affect project outcomes is crucial for optimizing open-pit operations. This analysis provides insights into the trade-offs between operational flexibility and economic performance.
Best-Worst Range Analysis is the process of generating and analyzing scenarios to measure the impact of mine width constraints on the project’s net present value (NPV), from no restriction to wide widths. Measuring the impact of mine width constraints is crucial to determine the optimal fleet equipment configuration in mining operations, with the aim of optimizing productivity and maximizing the net present value (NPV) of the project.
By analyzing variations in width constraints, it is possible to identify the effect of space limitations on mining operations and evaluate the influence of different bench widths on fleet performance. Appropriate mining widths can bring a series of benefits: higher amount of material to be simultaneously extracted; higher fleet productivity; more efficient transportation; easier road maintenance and so on. Hence, the search for different widths allows finding the best combination of equipment and mining techniques aimed at maximizing production and profit simultaneously in each scenario.
In a Best-Worst Range Analysis, scenarios are created gradually increasing the mine width up to a feasible maximum, allowing users to have a comprehensive view of the impact of space limitations on the project’s performance.
Considering the nature of global optimization and the non-linearity of the problem, it is expected that there will be variations in performance (NPV, production, amount of mine fronts, etc.) as parameter values are modified. Therefore, it is crucial to generate a large number of scenarios to obtain a comprehensive analysis of the impact of these variations on the project. This way, a more precise understanding of how different parameter values affect the overall performance can be achieved.
Preinstalled Marvin deposit. It can also be downloaded here.
Consider the following base scenario and decision tree built for a Best-Worst Range Analysis using the Marvin dataset.
The goal in this case is to understand the impact of different values of mining width (in green), which will be tested with a range of different values, from 0m up to 200m.
Note that there is no linear relationship between mining width and NPV. In other words, a higher mining width does not necessarily imply a lower NPV. As previously mentioned, that is due to the non-linearity of the problem.
Considering the nature of global optimization employed in MiningMath, other variables might also be affected by different mining widths. For example, the production could be analyzed for identification of possible issues when employing different mining widths.
Understanding how geometric constraints affect net present value (NPV) is crucial in open-pit mine planning.
Selectivity Analysis is the process of generating and analyzing scenarios to measure the impact of all geometric constraints on the project’s net present value (NPV), from the most selective to the least selective setup. Analyzing the impact of variations in geometric constraints is important to determine the optimal mine configuration and optimize productivity and profit.
By performing such an analysis, it is possible to identify the effect of geometric limitations on mining operations. Moreover, it is possible to evaluate the influence of each parameter and its variation on mine performance. This allows finding the best combination of parameters and mining techniques aimed at maximizing production and profit for each scenario.
In a Selectivity Analysis, scenarios are created including each geometric constraint sequentially and gradually increasing or decreasing their values from the least selective until the desirable requirement. This allows users to have a comprehensive view of the impact of geometric limitations on the project’s performance.
Considering the nature of global optimization and the non-linearity of the problem, it is expected that there will be variations in performance (NPV, production, amount of mine fronts, etc.) as parameter values are modified. Therefore, it is crucial to generate a large number of scenarios to perform a comprehensive analysis of the impact of these variations on the project.
Preinstalled Marvin deposit. It can also be downloaded here.
Consider the following base scenario and decision tree built for a Selectivity Analysis using the Marvin dataset.
The goal is to understand the impact of different values of geometric constraints (mining width, bottom width, and vertical rate of advance). The geometric parameters (in green) will be tested with a range of different values: bottom width with values from 0m up to 200m; mining width with values from 0m up to 200m; and vertical rate of advance with values from 50m up to 300m. In this example, 26 different scenarios were evaluated.
Note that there is no linear relationship between geometric constraints and NPV. In other words, a higher width or lower vertical rate of advance do not necessarily imply a lower NPV. As previously mentioned, that is due to the non-linearity of the problem. The cumulative NPV of the scenarios is compared in the graph below.
A diverse range of results can be achieved with a Selectivity Analysis. However, there are usually two possibilities when they are compared:
Contrasting geometrics parameters with small NPV variations: note that when the bottom width changes from 0m to 80m, and the remaining parameters are fixed, the NPV drops from 454 M$ to 444M$. This indicates that large changes in geometric constraints do not necessarily lead to large changes in the NPV. The same for the scenarios SA_BW000_MW100_VR150 and SA_BW100_MW100_VR250.
Similar geometric parameters with larger NPV variations: when comparing scenarios SA_BW080_MW100_VR150 and SA_BW100_MW160_VR150 there is a drop in NPV from 444M$ to 370M$, highlighting that the 20m and 60m change in bottom width and mining width respectively can lead to a larger NPV difference in the project.
In conclusion, it is important to create several scenarios in a Selectivity Analysis. As exemplified above, results can be quite similar or quite different due to the non-linearity of the problem. Considering the nature of global optimization employed in MiningMath, it is also important to evaluate other indicators. The figures below depict the tonnage achieved for the production, demonstrating the possible impacts for different geometric constraints.
Improving a mine plan isn’t only about chasing higher NPV, it’s also about making designs more practical. This workflow helps engineers refine scenarios that respect constraints while preserving profitability.
Design Enhancement is the process of creating scenarios to conduct extensive searches for solutions with similar NPV values but with fewer violations and improved shapes. This process allows finding more efficient and sustainable solutions that meet specific mine constraints and needs. Hence, seeking these kinds of scenarios is important for optimizing mining operations and for reducing risks and costs.
In Design Enhancement, scenarios are created with more rigorous geometric constraints without compromising the desirable requirements. The goal is to reduce violations and find better forms for the project. This is possible due to the global nature of optimization and the non-linearity of the problem, enabling the use of stricter requirements for the geometric constraints that could lead to a better performance of the project.
Preinstalled Marvin deposit. It can also be downloaded here.
Consider the initial scenario and respective decision tree built for a Design Enhancement process. The goal is to evaluate stricter variations in the geometric constraints (in green).
Note the variation of results for Cumulative NPV and production. The base scenario has a small violation on dump production for period 1. However, when modifying the minimum width to 120m (scenario DE_BW100_MW120_VR150) this violation is not present anymore. Hence, this is an example of how small variations in geometric constraints could lead to less violations.
NPV enhancement explores scenario variations by adjusting key constraints to identify higher-value solutions while maintaining operational limits.
NPV Enhancement is the process of creating scenarios to conduct extensive searches for solutions with higher net present value (NPV) values and similar violations, while considering minimum requirements for project constraints. Scenarios are created that gradually modify constraints from desirable requirements to minimum requirements, with the goal of increasing project profitability.
Preinstalled Marvin deposit. It can also be downloaded here.
Consider the initial scenario and respective decision tree built for a NPV Enhancement process. The constraints in green (production capacities, geometric constraints, and average CU) are considered for modifications, from desirable requirements to minimum requirements, in order to identify solutions with higher net present value (NPV).
Results show a high variation in NPV while the production remains in its limits. Hence, it shows that it is possible to achieve higher NPVs when employing minimum requirements defined by the user.
Effective bottleneck analysis is vital for mining operations to identify constraints in flows that limit profitability. MiningMath’s integrated approach ensures practical, iterative targeting of bottlenecks for optimized outputs.
Bottleneck Analysis involves generating scenarios to conduct extensive searches for solutions with fewer violations while preserving NPV, keeping geometries, optimizing mining operations, and reducing risks. This allows for the discovery of more efficient and sustainable solutions that meet specific constraints and needs of the mine.
In Bottleneck Analysis, after analyzing a desirable scenario it is possible to identify the constraint/s with demanding requirements that directly impact the optimization results and cause significant violation issues. Then, scenarios should be created by relaxing these demanding parameters, enabling users to make decisions to mitigate risks and ensure project viability.
Preinstalled Marvin deposit. It can also be downloaded here.
Consider the base scenario overview and the respective report on the dump production. Note how the first period has violated the 30Mt constraint.
A Bottleneck Analysis can help us identifying the constraint/s with demanding requirements that directly impact the optimization results and cause the violation in the dump production. Four different scenarios are built using a decision tree to analyze different values for dump production limits, minimum average of CU and vertical rate of advance.
Note: To decide which parameters need to be changed, you can consider the contraint priority order that MiningMath employs in order to always deliver a solution. However, adjustments usually depend on the unique characteristics of each project and the flexibility available to modify its requirements.
The graphs below depict a comparative analysis of the results for the scenarios in the decision tree.
This analysis shows that the minimum average constraint of CU, production dump and vertical rate of advance are all restricting the base scenario. When relaxing these parameters, there is an increase of approximately 5% in the cumulative NPV, while the dump productions are kept within their limits and the process productions are closer to the target for some scenarios.
Multivariate sensitivity analysis helps mining engineers understand how changing multiple constraints together impacts NPV, throughput, stockpiles, and schedules in realistic, integrated models.
Multivariate Sensitivity Analysis is the process of creating and analyzing scenarios based on a range of possible values for selected constraints. Analyzing the impact of constraints variation is important for determining the optimal mine configuration and for optimizing productivity and profitability.
With this method, scenarios are created by gradually increasing or decreasing the values of the constraints within a desired range, covering many combinations of values. It allows users to have a comprehensive view on the impact of combinations of constraint values on the project’s performance.
Considering the nature of the global optimization and the non-linearity of the problem, it is expected that there will be variations in performance (NPV, production, mining fronts, geometries, etc.) as parameter values are modified. Therefore, by generating a large number of scenarios, this behavior will be used in your favor, finding a diverse range of brand-new solutions unseen by any stepwise method.
Only with MiningMath, you can achieve such a broad understanding of how different parameter values affect the project’s overall performance and always have the chance to find better and better solutions.
Preinstalled Marvin deposit. It can also be downloaded here.
Consider the base scenario overview and the respective decision tree built for a Multivariate Sensitivity Analysis depicted below.
All the scenarios in decision tree were executed and a set of best and worst results were chosen to be depicted in the graphs below.
The evaluation was conducted by analyzing both cumulative NPV and production stability. The results indicate that:
These observations demonstrate the importance of performing a Multivariate Sensitivity Analysis.
The example provided illustrates a Multivariate Sensitivity Analysis, offering a basic evaluation based on cumulative NPV and production, while varying minimum bottom/mining width. More in-depth analyses may require a visual inspection and/or the use of additional indicators, such as vertical rate of advance. MiningMath reports warnings for certain violations as described here.
Optimizing mine schedules with strategic and tactical integration is critical for maximizing value. MiningMath’s single-step approach enables scenario diversity by treating all variables simultaneously, avoiding step-wise limitations.
MiningMath software allows mining engineers to improve their strategic analysis through risk assessments that are unconstrained by a step-wise approach to optimization. MiningMath’s global mining optimization methodology helps to integrate multiple areas of the business. It handles all parameters simultaneously, delivering multiple scenarios and accounting for both strategic and tactical aspects.
You can check a sequence of pages to learn how to run your first project with our Getting Started training. From installation process and formatting your model files up to the long-term planning of your project.
MiningMath provides different views and solutions for each parameter changed and each possible objective on the same mine. Search through our extensive set of workflows to improve your projects and generate optimized schedules.
When using single-step methodology, it is important not to target infeasible results. MiningMath provides a diverse range of workflows that can help you understand and optimize your project. For example:
Integrating short‑term plans with long‑term objectives ensures operations stay aligned to strategic goals as market prices, ore conditions, and equipment availability change.
MiningMath enables the integration between long- and short-term planning, helping you improve plan adherence and reconciliation. It does so by providing custom timeframes for different periods of the project. This page detailes the necessary concepts and their usage withing MiningMath.
Each period in MiningMath can be customized to fit your planning needs, from very short timeframes, such as months, to extended periods spanning decades. For that it employs factors.
The base factor in MiningMath is 1, which typically represents one year—the most common duration for a planning period. Using 1 as the reference, you can easily define any other timeframe. For example:
In the interface, you can set that in the Economics tab, as illustrated below.
The discount rate in MiningMath is defined per year.
When you use custom timeframes, MiningMath automatically adjusts the discount rate internally to match the specified period. For details on how discount rates are calculated for different timeframes, please visit this page.
By running the Super Best Case, you can generate surfaces to guide the optimization based on the NPV upper bound. In turm, the Optimized Pushbacks workflow provides insights on what could be the challenges of your project and also operational designs that could be used in further steps. At last, a detailed Schedule can be obtained by using, or not, a surface, which could be the final pit or any intermediary one, as a guide.
Following this long-term workflow, you should now have enough information to build a solid long-term view and improve the adherence and reconciliation of your plans. At this stage, you can select a surface and apply it using Force Mining or Restrict Mining to refine the schedule within its boundaries.
This allows MiningMath to precisely reach the defined surface within the chosen timeframe, enabling you to explore different geometries, blending constraints, and other variables required for short-term planning—without compromising the long-term strategy.
Additional tools that can support these refinements include Mining Fronts and Design Enhancement, which allow you to modify surfaces while respecting all constraints and generating results tailored to your needs. Let’s see a more concrete example next.
Consider the following configuration parameters employing the Marvin dataset.
| Parameters | Value |
|---|---|
Timeframe | Custom factor (0.5) representing semesters. |
Processing capacity | 5 Mt per semester |
Total movement | 20 Mt per semester |
Vertical rate of advance | 60m per semester |
Minimum Mining | 120m |
Bottom width | 100m |
Force and Restrict Mining Surface | Surface for period 5 obtained from the Optimized Pushbacks workflow |
Stockpiling parameters | On |
Play with steeper slope angles in the short term? | Yes |
In MiningMath’s interface, we can check all these inputs in the Overview tab
Finally, we can see some of the results after running the scenario illustrated in the images below.
In the example above, fewer constraints were applied, geometries were adjusted, and the average grade was left unrestricted. Defining the early years with a semester-based timeframe can be especially useful for managing stockpiles and other variables during the first few years—for instance, the initial 3 years of operation.
Keep in mind that period ranges in MiningMath are based on the selected timeframe, so you should adjust your variables accordingly.
When using Force + Restrict Mining, you’re instructing the optimizer to break the specified volume into parts and ensure it is fully mined—even if it contains waste—so that the long-term plan is honored. This lets you maintain a global view of the entire deposit while making more tactical decisions for the initial periods. It’s important to note that Force + Restrict Mining should be used only at the beginning or end of the mine life. Applying these surfaces in intermediate periods may directly interfere with the optimization results.
This approach differs significantly from traditional methods that rely on a series of Revenue Factors through multiple LG/Pseudoflow runs, followed by manual adjustments to define pushbacks without mathematical optimization criteria.
Another strategy is to optimize the short-term along with the long-term using different timeframes. In this approach, the integration between the short and long term visions is made in the same optimization process, facilitating the analysis and strategic definitions.
It is possible to:
Define longer periods for the later stages of the mine life, reducing detail where it’s less critical and saving processing time for the early years where precision matters most.
This integrated setup allows for value maximization at the strategic level while ensuring feasibility at the tactical level. It also helps to minimize compliance and reconciliation issues, and improves communication between teams by working from a unified plan.
In this configuration:
Example configuration:
In this case, a 13-period schedule covers 16 years and 6 months, with detailed planning for the first 6 months, yearly breakdowns for the next 6 years, and broader strategic planning for the final decade. The table below illustrates possible parameters for configuring a scenario like this.
| Parameters | Period range 1-6 | Period range 7-12 | Period range 13-end |
|---|---|---|---|
Timeframe | 1/12 of a year (each period representing a month) | 1 year. | 10 years. |
Processing capacity | 2.5 Mt per semester. | 30 Mt per year. | 300 Mt per 10 years. |
Vertical rate of advance | 30m (minimum block size, at this case) per month. | 150m per year. | 1500m per 10 years. |
Minimum Mining | 120m | 120m | 120m |
Bottom Width | 100m | 100m | 100m |
Stockpiling parameters | On | Off | Off |
Different/steeper slope angles in the short term | Yes | No | No |
We can also see the observed inputs in the Overview tab
This article explains how MiningMath advanced users can handle different types of non-regular block models and how they can adapt their data within the current software capabilities. It also presents practical workarounds for working with sub-block and percentual models, and how users can influence future features through direct contributions.
Defining a block model involves balancing geological precision, statistical reliability, and engineering feasibility. The block size is influenced by:
Using blocks smaller than the SMU can lead to overestimations of value and unrealistic assumptions about selectivity and operational precision.
For more details about the different types of block models, access the full article on Types of Block Models in our Knowledge Base.
MiningMath currently supports only regular models natively. While other models such as sub-blocked and percentual are widely accepted in the industry, supporting them natively requires adaptations at the algorithmic level. Rather than attempting partial or unstable support, MiningMath has prioritized a stable foundation for regular models while offering flexible workarounds for others. These workarounds already enable meaningful results for advanced users and lay the groundwork for future native support as demand and resources evolve.
These models can be simulated by:
For sub-blocked models, users may:
These adjustments allow MiningMath to optimize based on simplified yet controlled approximations.
Native handling of percentual and sub-blocked formats is part of our vision, but its implementation depends on real demand and dedicated investment. If you want to accelerate this roadmap, your input can make a difference:
Even small contributions help guide our priorities and improve feature delivery timelines.
Share your use case or materials with our team and help us shape what comes next.
The more detailed your contribution, the faster our evaluation and implementation process. MiningMath prioritizes features backed by real use cases and clear technical value.
Managing multiple pits together optimizes the entire project’s schedule and value. MiningMath’s global optimizer analyzes all mines simultaneously for integrated results.
MiningMath’s global optimization algorithm effectively addresses the challenges of integrated multi-mine projects by considering all pits simultaneously. Unlike individual pit optimization, this approach delivers a comprehensive solution that optimizes the entire project, providing a more cohesive and strategic overview.
Multi-mine projects often hold hidden opportunities for maximizing value. Given their inherent complexity, it’s common to apply simplifications that, while convenient, can lead to sub-optimal solutions when using traditional LG/Pseudoflow methodologies instead of MiningMath. These simplifications may ultimately reduce the project’s potential value from a mathematical standpoint.
For multi-mine projects, the block model must include all mining regions for simultaneous optimization. If your pits are mapped in separate datasets, it’s essential to follow the steps outlined below:
Work with a single block model or single pit first, run the initial tests and understand this region before handling the block model modification.
Try to eliminate meaningless blocks, which would not affect the solution and could increase complexity.
Add a second model or pit to explore the process of working with multi-mine projects. This combined block model file should meet the same requirements as a single model, as outlined on the data formatting page, ensuring unified characteristics.
Experiment with surface adjustments to refine results, filter out regions you don’t wish to mine, and apply other guidance as needed. Since MiningMath surface files maintain a consistent order, using an Excel file (available here) can be a helpful tool for these modifications.
Use mining fronts if you’d like to control the material extracted from each region.
Add the other regions and start using everything that you wish.
When using actual UTM coordinates from mines that are geographically far apart, the combined block model spans a massive area with large empty zones between deposits. This leads to:
Instead of directly using UTM, introduce a simplified, local coordinate system:
After translation and integration:
The current version of MiningMath applies the same values for vertical rate, bottom width, and mining width across the entire block model. However, in a multi-pit scenario, each pit may have unique geometric parameters that impact selectivity. In these cases, we recommend setting the parameters for one pit, fixing its solutions (as the force and restrict mining settings have the highest priority), and then starting the optimization of the other pits. This approach ensures that the optimization considers the mass already planned for extraction from the first pit.
An efficient workflow starts by running an initial scenario without geometric parameters to serve as a validation or best-case scenario for scheduling optimization. Next, configure a scenario using the geometric parameters of the most selective mine—meaning the smallest widths and highest vertical rate (VR)—to create the least constrained scenario in terms of geometry. The surfaces generated from this setup can then be used to fix solutions for Mine 1.
For example, you could take Surface 1 and adjust the elevation in other areas to reflect the mass extracted in Period 1 from Mine 1, as well as the potential extraction from the second pit. With these results, you can refine surfaces or mining fronts, conduct a sensitivity analysis of the geometric parameters across multiple projects, and still maintain the benefits of global optimization.
In mining operations, integrating socio-environmental constraints into optimization models is critical to balance economic and non-economic objectives in real-world scenarios.
Technology has been developed to incorporate social and environmental factors in the mining project optimization, assessing these impacts whilst maximizing its net present value (NPV). The method can quantify socio-environmental aspects, such as dust, noise, avoidance of springs/caves/tribes, carbon emissions, water consumption, and any parameter that could be controlled by its average or sum. These environmental and social aspects can be assessed following internationally recognized standards (ISO 14044).
Minviro in partnership with MiningMath has developed an approach to integrate such quantitative assessment into strategic mining optimization. This enables socio-environmental impacts to be constrained in the mining optimization, and the economic cost of reducing them to be calculated as a consequence. The way to do it is by inserting these variables linked with each block of your model, following these instructions. Considering this methodology, published here, significant reductions in the global warming impact could be achieved with a small economic cost. For example, using an environmental constraint it was possible to reduce 8.1% of CO2 emission whilst achieving 95.9% of the net present value compared to the baseline, as you can see in the image bellow.
Several scenarios for mine development, processing setup, energy/water consumption, CAPEX (content in Spanish), OPEX etc. can be evaluated . It is also possible to include geometric constraints in order to restrict a mining area due to legal and site-specific issues that affecs the local population, using this feature. Spatially and temporally explicit socio-environmental risks can be included in mining optimization, providing an opportunity to assess alternative project options or explore a socio-environmental cost benefit analysis. For each aspect considered, decision makers are able to propose a range of possible scenarios and assess the economic cost of constraining these to different levels.
The decision-making board, which previously had access to one or a few scenarios, now has a cloud of possibilities optimized and integrated with the technical and economic aspects of the project, reducing risks and adding sustainable value. The mathematical intelligence behind it is based on modern and well-accepted Data Science and Optimization concepts academically proven. The methodology has been tested in real mining projects with gains in NPV ranging between 15% and 20% on average, where socio-environmental aspects haven’t been added yet.
MiningMath supports early-stage planning under uncertainty by enabling scenario testing without fixed constraints. Its integrated optimization avoids premature assumptions, reduces manual rework, and accelerates identification of viable strategies even when economic inputs are not yet defined.
One of the many possibilities offered by MiningMath’s approach is to have multiple overview scenarios to evaluate different project assumptions, before doing a more detailed work. It does not demand an arbitrary/automated trial-and-error cutoff definition, nor a fixed input in form of pushbacks that will guide further optimization steps within the boundaries of a simplified problem. A subtle but substantial implication is the possibility of seeing a totally different mine development throughout the mine life cycle for each project assumption change. This allows mine managers to have a clearer view of the decision-tree and the possibilities on their hands, to improve economic, technical, and socio-environmental performances.
Considering this context, mine managers can judge greenfield projects to know whether or not they should prioritize a geotechnical study. This could be done by running multiple scenarios, considering the expected variability for slope angles for a given deposit. For example, in a given deposit, benchmarks from similar deposits indicate the overall slope angles might vary between 35-45 degrees. Before reaching the conclusion using an in-depth geotechnical study, multiple scenarios can be used to estimate the economic impact of each possible assumption for the overall slope angle. The conclusion might, then indicate a low economic impact, that could postpone the need for a detailed study.
The same idea applies to any parameter, which ultimately represents a project assumption.
MiningMath conducted an illustrative example with 2000 simulations varying multiple parameters independently. The results produced the chart from Figure 1, showing the probability (Y-axis) and the Project’s Value (X-axis). In this case, a detailed geotechnical study might be postponed, as the Project’s Value varies between 700 to 1100 MU$, in function of the OSA.
Mine planning typically follows a step-by-step process: nested pits, pushbacks, then scheduling. While this structure simplifies planning, it limits flexibility and can reduce project value.
MiningMath software allows mining engineers to improve their strategic analysis through risk assessments performed in a single-step approach to optimization. In other words, MiningMath’s global mining optimization methodology helps to integrate multiple areas of the business. It handles all parameters simultaneously, delivering multiple scenarios and accounting for both strategic and tactical aspects.
Hence, it is important to understand other current best practices employing a stepwise rationale and their disadvantages compared to MiningMath’s single-step approach.
The mining planning models built with current best practices have developed shortcuts and approximations to try to deliver acceptable results that consider all the project’s complexities and constraints. To handle it, powerful machines are required to find a solution and to simultaneously determine the optimum pit limit and mining sequence that deliver the maximum project value.
Figure 1 depicts a stepwise approach used by current best practices.
Figure 1: Current best practices: stepwise approach
These steps may include different strategies, technologies or algorithms. However, they are all usually solved individually in three larger stages:
Regardless of the technologies or algorithms, in a stepwise approach the aim is to initially find the final pit limit that maximizes the undiscounted cash flow to then focus on block sequence within this final pit envelope. By constraining the problem and predefining inputs, these shortcuts (approximations) help to save time and computer resources, enabling such software to consider complexities such as ore blending requirements, different processing routes, stockpiling policy, truck fleet considerations, and so on.
With current best practices employing some stepwise approach, thousands of potential schedules can be generated with a multitude of different methods, but they are all based on the same stepwise rationale, with one step guiding the other. Commonly, schedules follow from a set of nested pits and other fixed input parameters such as geotechnics, metallurgical performance, blending constraints, etc. Therefore, the results frequently present similar behaviours and restrict the full exploration of the solution space.
MiningMath solves the stepwise issues through math optimization models that integrate multiple areas of the business, in a single-step. It handles all parameters simultaneously and delivers multiple scenarios, accounting for both strategic and tactical aspects. To better understand MiningMath uniqueness please continue reading here.
MiningMath’s single‑step optimization engine integrates all stages of mining planning into a unified model, enabling simultaneous adjustment of pit limits, destinations, sequencing, and operational constraints. In practice, this delivers more realistic and economically efficient mine plans that avoid manual iteration and lock‑in issues.
MiningMath allows mining managers to improve their strategic analysis through risk assessments that are unconstrained by stepwise processes. Through math optimization models that integrate multiple areas of the business, MiningMath handles all parameters simultaneously and delivers multiple scenarios, accounting for both strategic and tactical aspects.
MiningMath optimization is not constrained by arbitrary decisions for cut-off grades or pushbacks, since these decisions are usually guided by prior knowledge or automated trial-and-error. Thus, each set of constraints in our technology has the potential to deliver an entirely new project development, including economic, technical, and socio-environmental indicators, along with a mine schedule, while aiming to maximize the project’s NPV.
MiningMath acknowledges that each project has its own characteristics. Thus, it also allows you to choose which workflow fits best in your demand and decide which one should be used. Straight from block model you can find solutions to your short-term, schedules, optimized pushbacks or super best case, as depicted in Figure 1.
Figure 1: Single-step approach employed in MiningMath. Straight from block model to short-term, schedules, optimized pushbacks or super best case.
As MiningMath optimizes all periods simultaneously, without the need for revenue factors, it has the potential to find higher best case’s NPVs than traditional best case procedures based on LG/Pseudoflow nested pits, which do not account for processing capacities (gap problems), cutoff policy optimization and discount rate. Usually, these, and many other, real-life aspects are only accounted for later, through a stepwise process, limiting the potentials of the project.
The use of LG/Pseudoflow methods to perform pit optimization aims to maximize the undiscounted cash flow of the project. On the other hand, MiningMath maximizes the discounted cash flow. Therefore, regions in which MiningMath has decided not to mine are, probably, regions where you have to pay for removing waste on the earlier periods, but the profit obtained by the discounted revenue from the hidden ore does not pay for the extraction.
A proper comparison between this methodology could be done if you import the final pit surface obtained from the other mining package into MiningMath, and use it as Force/Restrict mining. This way, MiningMath will do the schedule optimization using the exact same surface, which will allow you to compare the NPV for each case. Figures 2 and 3 depict two comparisons between undiscounted and discounted cashflows.
MiningMath offers the option of producing Optimized Pushbacks with controlled ore production and operational designs to guide your mine sequencing. Having this broader view in mind, you are already able to begin the scheduling stage. The block periods and destinations optimized by MiningMath could be imported back into your preferred mining package, for comparison, pushback design or scheduling purposes.
When using MiningMath, it is possible to define the pit limit and mine schedule simultaneously. That is, to determine which blocks should be mined, when this should happen and to where they should be sent to maximize the NPV, while respecting production and operational constraints, slope angles, discount rate, stockpiles, among others, all performed straight from the block model. This means that the steps of pit optimization, pushback and scheduling are not obtained separately, but in a single and optimized process.
To help with all that, our software allows you to build Decision Trees which enable a broader view of your project and a deeper understanding of the impacts of each variable. This is all possible because MiningMath works with a global optimization which simultaneously regards all variables, instead of using a step-wise approach. The software provides different views and solutions for the same mine for each parameter changed and each possible objective.
Ensuring a solution, even in the face of tight or conflicting constraints, is critical for maintaining project momentum and avoiding costly manual trial-and-error.
Multiple, complex constraints increase the likelihood of not finding or not existing feasible solutions. Nonetheless, MiningMath always delivers a solution, even if it could not honor the entire set of constraints imposed or had to reduce the NPV to find a feasible solution.
When dealing with highly constrained problems, other technologies might take hours or days to realize there is no feasible solution. The reason for that is because they usually employ generic optimization algorithms, not suitable to take decisions in a mining problem. In this case, the only option is to prepare a second execution with more flexible constraints, but still with no guarantee of feasibility.
On MiningMath, once an unfeasible solution is detected, the algorithm takes decisions on which (less relevant) constraints should be flexible, returning some warnings to the user at the report. This is performed along the optimization process, without compromising the runtimes.
In some cases, the set of constraints may be too limiting, and the software is unable to return a solution, generating the “Unfeasible project” message. In these cases, it is recommended that you relax some restrictions.
The constraints priority order, from the highest to the lowest, is depicted in Figure 1.
Force+Restrict Mining together using the same surface.
Force mining or Restrict Mining, same concept as above, but the surfaces here are corrected according to slopes and it might have some differences.
Total Production Capacity (or the sum of the capacities across all destinations.)
Average and Sum, modeled as strong penalties in the objective function
Improve the NPV
Figure 1: Constraints hierarchy order.
Validating the theory behind any optimization tool is essential to ensure its applicability in real-world mining operations. This page clarifies how MiningMath’s mathematical foundations are verified and what that means for planning reliability.
MiningMath’s results are only possible due to its proprietary Math Programming Solver ©. It consists of a Mixed Integer Linear Programming (MILP) formulation and linearization methods that tackle the challenging non-linear aspects of the mining optimization. In addition, it has its own Branch & Cut algorithm, which provides more efficiency than standard MILP optimizers since it’s fine tuned to this specific optimization problem.
Another major advantage of MiningMath comes from the mathematical formulations based on surfaces (Goodwin et al., 2006; Marinho, 2013), instead of usual block precedences. Block precedence methods might lead to higher errors (Beretta and Marinho, 2014), providing slopes steeper (i.e. riskier, more optimistic) than requested. The use of surfaces eliminates these geotechnical errors and allows for block-by-block geotechnical zones, if needed.
These surface-based formulations allow MiningMath to include geometric constraints, and, consequently, find solutions that are closer to real mining operations. The user can guide geometries by including mining and bottom widths, mining lengths, maximum vertical advance rates, and forcing/restricting mining areas. You can better understand how each constraint interacts with all others here. Such constraints give freedom to the user to work, or not, with predefined cut-offs and pushbacks which might limit the space of potential solutions. An in-depth view of MiningMath’s formulations and algorithm can also be seen here.
This approach (Figure 1) has been applied for years by clients, such as Vale, Rio Tinto, Codelco, Kinross, AMSA and MMG, with a growing number of licenses sold, press releases and academic research also proving the consistency of the implementation. With constant developments since 2013, MiningMath has reached a mature and robust state. It is the first and only singlestep mining optimization engine available in the market.
Figure 1: MiningMath’s approach. From block model to schedule in a single step solved by its proprietary Math Programming Solver ©.
MiningMath’s algorithm lets engineers optimize all key variables together, cutting down manual rework and iteration time.
MiningMath has a flexible mining optimization algorithm that consists of a Mixed Integer Linear Programming (MILP) formulation and linearization methods that tackle the challenging non-linear aspects of the problem. In addition, MiningMath has its own Branch & Cut algorithm, which provides more efficiency than standard MILP optimizers since it’s fine tuned to this specific optimization problem.
One of the major advantages of MiningMath comes from the mathematical formulations based on surfaces (Goodwin et. al. (2006), Marinho (2013)) instead of usual block precedences. Block precedence methods might lead to higher errors (Beretta and Marinho (2015)), providing slopes steeper (i.e. riskier, more optimistic) than requested. The use of surfaces eliminates these geotechnical errors and allows for block-by-block geotechnical zones, if needed.
Another crucial advantage is that MiningMath’s formulation includes geometric constraints, allowing its algorithm to find solutions that are closer to real mining operations. The user can guide geometries by including mining and bottom widths, maximum vertical advance rates, and forcing/restricting mining areas. Such constraints give freedom to the user to work, or not, with predefined cut-offs and pushbacks which might limit the space of potential solutions. Hence, the software provides different views and solutions for the same mine for each parameter changed.
Eventually, linear solutions need to be mapped onto an approximate integer (block-by-block) solution that will represent the scheduling of the mining problem in the real-world. The intelligence to convert continuous solutions into integer and non-linear ones are made by MiningMath’s Branch & Cut algorithm.
MiningMath employs an innovative mathematical formulation and powerful proprietary Branch & Cut algorithm for mining optimization problems. A description of this mathematical formulation and the three main steps of the algorithm employed are given below.
The first step of the mining optimization algorithm is to remove regions that do not add any value to the project. This is an initial assessment that considers slope constraints, reducing the size of the problem and providing a region of interest for the optimization process. Since MiningMath always employs surfaces in its mathematical formulations, this first set of likely profitable blocks are contained within an initial surface as depicted in Figure 1.
In the second step of the mining optimization algorithm, the non-linear, integer problem is approximated to an integer, linear one based on surfaces. For that, it is necessary first to define the common notation across the problem and its variables.
.ssscn files..ssscn files.Having the set of variables defined, is possible now to define a mathematical model with an objective function and necessary constraints.
Objective function
Intuitive idea
- Sum of the economic value of blocks mined per period, destination, and simulation.
- Average the result by the number of simulations.
- Subtract penalties for certain violated restrictions associated with some user defined parameters.
Requirements
- \(V_{c,t,d,s}^{z}\): cumulative discounted economic value of block \((c, z)\) in simulation \(s\), period \(t\) and destination \(d\). More about this calculation here.
Formulation
\(max\frac{1}{s}\)\(\sum\limits_{s=1}^{S}\sum\limits_{t=1}^{T}\sum\limits_{c=1}^{M}\sum\limits_{z=1}^{Z}\sum\limits_{d=1}^{D}\)\((V_{c,t,d,s}^{z} x_{c,t,d}^{z}) \,-\, p\)where\(p = \sum\limits_{t=1}^{T}\sum\limits_{g=1}^{G}(\overline{\alpha_{t,g}}(\sum\limits_{s=1}^{S}\overline{f_{t,g,s}})\)\( + \underline{\alpha_{t,g}}(\sum\limits_{s=1}^{S}\underline{f_{t,g,s}})\)\( + \overline{\beta_{t,g}}(\sum\limits_{s=1}^{S}\overline{j_{t,g,s}})\)\( + \underline{\beta_{t,g}}(\sum\limits_{s=1}^{S}\underline{j_{t,g,s}})) \)
Finally, the objective function is constrained by the restrictions below
Figure 3: Two surfaces (blue and yellow): a) not crossing each other and respecting the constraint; b) crossing each other and not respecting the constraint.[/caption]Intuitive idea
Requirements
Formulation
Figure 4: Maximum allowed difference (Hx, Hy, and Hd) in elevation between adjacent cells in contact laterally in the x direction (a), in contact laterally in the y direction (b), and in contact diagonally (c).[/caption]Proprietary constraints not disclosed. Possible examples of constraints of the same type, but not the ones actually employed.
Intuitive idea
Requirements
Formulation
Figure 5: Distance between centroids above surfaces (green lines) and below surfaces (red lines) respecting constraints. Blue blocks are mined in period 1, while yellow blocks are mined in period 2.[/caption]Intuitive idea
Requirements
Formulation
Intuitive idea
Requirements
Formulation
[latex]t = 1,...,T, g = 1,..., G, s = 1,..., S[/latex]
Intuitive idea
Requirements
Formulation
[latex]t = 1,...,T, g = 1,..., G, s = 1,..., S[/latex]
Proprietary constraints not disclosed
Intuitive idea
Formulation
The next step in the mining optimization algorithm is to convert the linear solution to an integer, non-linear one. MiningMath’s Branch & Cut method is responsible for this conversion. Once it is done, the resulting solution can be evaluated, leading to the end of the algorithm’s execution or to a new optimization process. This new process might be triggered if one of the two situations arise:
restrictions are violated due to transformation from linear to integer, non-linear solution, or due to problem being infeasible.
an evaluation of certain restrictions in the transformed integer, non-linear solution concluded that they might not affect the problem and be better discarded or modified.
If any of these are true, the solution at this stage will be sent back to Step 2 for linearization and refinement. Thus, if this refinement is caused by situation 1) then the goal is to improve the solution’s feasibility. This feasibility is improved according the constraint hierarchy order depicted in Figure 6.
Figure 6: constraints hierarchy order.
In contrast, if it is caused by situation 2) then the goal is to allow the optimization to focus on the bottlenecks of the problem and improve the current NPV. Once none of these situations have been identified, the current solution is returned. Note that each time the algorithm goes back to Step 2, a new global optimization is performed, thus the new resulting solution might be entirely different.
The whole process of the mining optimization algorithm, from input to output is summarized in the diagram and pseudo-code below. References are made to previous Steps 1, 2, and 3. This algorithmic flow together with the proposed mathematical formulation exemplifies the innovative methodology applied to solve a single mine scheduling problem.
Constraint selection directly influences NPV — and in some cases, more constraints may even enhance value. MiningMath allows you to test this behavior systematically.
MiningMath has a flexible mining optimization algorithm that consists of a Mixed Integer Linear Programming (MILP) formulation and linearization methods that tackle the challenging non-linear aspects of the problem. It is the only mining package able to handle a diverse range of constraints in a single-step process. However, such range of available constraints raises the question:
How to add all the required constraints without losing too much value?
There is no exact procedure, as each constraint models a different engineering aspect. Therefore, there must be an experienced engineer willing to explore a range of possibilities by building Decision Trees, wisely choosing scenarios that get closer to the real problem (more constraints added) without losing so much value (or even gaining, given some non-linear aspects).
The following sections suggest possible workflows that can be followed in order to perform an efficient analysis.
It is important to analyze scenarios to measure the impact of each constraint on the project’s net present value (NPV), from the Super Best Case to a detailed setup. For example, with a NPV Upside Portential analysis.
When performing such an evaluation it is common that the cumulative NPV usually decreases (as expected) when more constraints are added. However, there are exceptions as described in the following section.
Geometric constraints are modelled as non-linear restrictions. This non-linearity can lead to counterintuitive results, with more constraints potentially causing a better NPV. Hence, if you are not happy with the results achieved after adding geometric constraints you might need to perform a Selectivity Analysis or Best-Worst Range Analysis of your project.
MiningMath offers a diverse range of Workflows that can be followed in order to improve your project’s results. If you are still struggling with certain parameters or constraints, please have a look on all possible options to identify what would be better suited to your particular case.
Mining sequences based on heuristics may overlook key constraints, risking suboptimal outcomes. MiningMath eliminates this issue through its Timeframes approach.
A mining sequence per period outlines the order in which blocks are to be mined within each period, typically starting from the first block (block 1) and ending with the last block (block N). It is common that other mining packages produce such sequences as part of their output.
This page explains what are the disadvantages of such sequences, and how MiningMath handles it through the concept of Timeframes.
These sequences are usually generated using heuristic approaches. For example, some methods gather all blocks from each period and, starting from the highest bench, select a specific horizontal direction to enumerate them. Some other tools also employ short-term strategies with greedy algorithms to optimize mining operations on a day-to-day basis.
Although a sequence of blocks can be defined for mining, these sequences often lack optimization criteria during their creation. For instance, approaches that prioritize starting from the highest bench only ensure that slope angles are respected, neglecting other geometric constraints. Similarly, greedy algorithms fail to consider the global view, potentially leading to violations of certain constraints later on.
Therefore, MiningMath does not provide such sequences, as users might assume that constraints will be respected when, in reality, they may not be.
MiningMath tackles this challenge by introducing the concept of Timeframes. This feature empowers users to specify the level of detail they desire within each mining period while maintaining a comprehensive overview and ensuring that all constraints are duly considered.
We recommend initiating the entire Life of Mine (LOM) setup with smaller time frames, such as “months,” for the initial interval. However, in some cases, employing Force and Restrict mining surfaces from previous runs can help reduce the complexity of the problem and enhance efficiency.
Slope angles are critical to safety and ore recovery in open-pit mining. Controlling them effectively avoids unstable designs and repeated manual adjustments.
Slope angles are a critical consideration in the mining industry, as they directly impact safety and significantly influence a wide range of operational parameters. The most relevant types include:
Each of which plays a specific role in balancing safety, operational efficiency, and ore recovery. This makes slope angles one of the most critical parameters when establishing a constraints hierarchy. Their values often vary depending on factors such as time frames (short- or long-term), rock type, lithology, mine sector, depth, and geotechnical domains. Therefore, it is essential to clearly define these assumptions to use this parameter effectively and align it with your project’s specific goals.
With MiningMath’s single-step, optimization engine, you can uncover opportunities that manual or stepwise planning might miss. Ultimately, its engine is able to optimize resource utilization and can improve project outcomes. Transform your mine planning process by leveraging MiningMath’s advantages and take your mining projects to new heights of efficiency and success.
The traditional workflow for open-pit optimization, design, and production scheduling often leads to discrepancies between the parameters used during the optimization phase and those applied during the design phase. Ramp design and placement, for instance, significantly influence the OSA, creating a mismatch. This misalignment frequently necessitates an iterative process of re-optimizing the same scenario based on the finalized pit design.
MiningMath controls the Overall Slope Angle through a “surface-constrained production scheduling” approach, where surfaces define groups of blocks to be mined (or not), instead of relying on the traditional “block precedence” method. This approach enables MiningMath to incorporate geometric constraints into its unique single-step optimization, delivering solutions that are closer to real mining operations.
Surfaces determine the timing of block extraction. For instance, blocks located between the surfaces associated with periods 1 and 2 will be mined in period 2. A block is considered “between” two surfaces if its centroid lies within the vertical space defined by them. In this example, blue blocks are mined in period 1, while yellow blocks are mined in period 2.
Within surfaces, slope constraints are managed by controlling the angles between adjacent points within a defined grid structure, rather than evaluating the angles between arbitrary pairs of points, as depicted below.
MiningMath employs a continuous linear variable for slope control, achieving superior accuracy compared to the discrete nature of block-based methods. Moreover, this grid-based approach ensures precise approximation of the deposit’s angles by focusing exclusively on grid-connected points, eliminating the need for comparisons between unrelated points. Adjacent elevations within a single surface must comply with a maximum allowable height difference, calculated based on the specified slope angle restriction (read more). This method guarantees that each generated surface represents a feasible solution while adhering to production requirements and delivering enhanced accuracy, particularly in transition zones.
While it is theoretically possible to analyze more pairs of points that are not adjacent, such an approach would result in a significant increase in computational complexity. Both our practical experience and academic research (here and here), demonstrate that this added effort is not justified. MiningMath’s method already delivers more precise slope control than traditional precedence-based techniques.
Unlike MiningMath, technologies based on the Lerchs-Grossmann and Pseudoflow approaches often exhibit a well-known “slope error”, which represents the discrepancy between the input parameters for the OSA and the actual measurements derived from the output pit shells. This issue arises from the “block precedence” methodology, where calculations connect the block’s centroids, a process that may not align with the block model dimensions. As a result, the decision to mine a block in its entirety or not can impact the OSA, potentially complicating the generation of a pit shell that matches the designed pit.
MiningMath provides two options for handling slope angles:
Block-specific slope definitions directly within the model.
A default slope value that can be applied universally or used as a fallback for blocks without predefined slope information.
In the interface, these can be found in the Overview tab.
For scenarios requiring multiple variable slope assumptions, you can prepare additional columns (e.g., Slope 1, Slope 2, … Slope N) in the block model before import. This setup allows you to select the appropriate slope data for each scenario directly through the interface, eliminating the need to repeatedly edit and re-import the block model.
In the interface, you can choose the field option as the primary rule for variable slope angles or select <none> to apply a constant value across the entire model. If the chosen field contains missing data, the defined default value will automatically be used for those blocks.
When assigning a field to the slope angles parameter, this will represent the column that will be assigned to the slope on each block as depicted below.
This approach allows a high level of flexibility to use any specific criteria. These possibilities can also comprise bi-dimensional and tri-dimensional variations, beyond linear and non-linear functions.
Short-term planning presents a valuable opportunity to leverage the same platform used by the strategic mine planning team, enhancing project adherence and reconciliation. By selecting a surface and applying it as a constraint, mining can be restricted to specific areas, refining the entire operation.
This approach can utilize a surface already designed with ramps or any surface generated by MiningMath that adheres to the OSA within the required time frame.
This flexibility allows for steeper Bench Face Angles based on operational blasting parameters. To maximize this feature, follow the suggestion to set up angles block by block and experiment with different angles according to your project’s capabilities. This methodology enables the algorithm to adjust the constraints hierarchy, ultimately leading to improved results.
Geometric constraints help align mining operations with equipment limits, safety margins, and regulatory or physical boundaries. In MiningMath, these rules are not applied after the fact—they shape the optimization process itself, producing practical results without compromising value.
In a mining project, the mine planner must accurately dimension each unit operation to determine the most suitable set of equipment for the existing conditions. With MiningMath, operational parameters are integrated as constraints within the objective function, rather than being applied post-pit optimization. This methodology ensures solutions that adhere to operational criteria while maximizing NPV, leading to more effective data utilization and uncovering opportunities that might be overlooked with manual steps and arbitrary assumptions.
The Geometric tab is the place to set minimum mining & bottom widths, mining length and vertical rate of advance, whose values are applicable to every period. The user can also use surfaces to define operational constraints in compliance with period ranges, which can limit, force or achieve an exact shape, based o the constraints hierarchy.
There are two types of widths restrictions that can be created:
Mining Width: distance from a pit to another.
Bottom Width: bottom minimum area.
Currently, MiningMath does not mine partial blocks. As a consequence, the software will round up any widths to cover the next integer block.
It is also possible to define a Vertical Rate of Advance for each period range. The VR will be rounded up to cover the next integer block.
A minimum horizontal distance that should be respected from a pit to another in every period can also be defined in the Minimum Mining Length field. Currently, this is only available in the insider version.
The figures below show a simplistic meaning of each width/length available and the vertical rate of advance.
For each period range, the user can consider:
1 force mining surface.
1 restrict mining surface.
Each surface file is valid from period A up to final of period B, as depicted below.
The following video shows how the variation of operational constraints impacts your solution and how you can take advantage of these parameters to find results more closer to the reality.
Operational constraints
Understand why small changes in geometric parameters can lead to unexpected variations in NPV, and how MiningMath transforms this instability into a strategic optimization advantage through massive scenario generation and comparison.
In traditional mine planning methodologies, geometric parameters such as Minimum Mining Width or Minimum Mining Length are typically treated with rigidity. It is commonly assumed that incremental changes to these parameters will produce proportional and predictable impacts on the project’s economic outcomes, particularly the Net Present Value (NPV). However, practical experience using MiningMath shows that this is often not the case, and no other technology is capable of handling such geometric aspects within a single global optimization process.
The NPV’s variability in response to seemingly minor adjustments, such as a small change in the minimum mining width, can be nonlinear, unstable, and counterintuitive. A small change might unexpectedly increase or decrease results, defying the deterministic logic that typically governs the industry.
Rather than viewing this instability as a flaw, it can be leveraged as a strategic opportunity, provided the planning tool supports rapid evaluation of multiple scenarios, as is the case with MiningMath’s approach.
MiningMath enables users to systematically explore the unstable behavior of geometric variables by queuing multiple scenario generations and/or accessing MiningMath’s servers to run scenarios in parallel. By progressively varying parameters such as Minimum Width, Minimum Length, or Minimum Bottom Width, the system can produce different scheduling results along with their respective NPVs.
For instance, changing the minimum mining width from 30m to 80m in 10-meter increments may reveal a nonlinear response curve. Instead of an expected smooth fall in NPV, results fluctuate, highlighting patterns that only become visible through dozens of executions.
Note from the graphs that, after running multiple scenarios, users can create Excel charts to identify performance peaks that represent operational and economic opportunities that would likely go unnoticed in more restrictive approaches.
While MiningMath is currently working to automate chart creation, it provides all the necessary outputs for quick visual analysis, enabling robust, data-driven evaluations.
By using the Execution Queue to vary geometric parameters systematically, MiningMath supports the creation of a structured decision tree, enabling:
Iterative exploration: once favorable results are identified for one variable, others can be varied to refine the solution further
| Aspect | Traditional Methodology | MiningMath Approach |
|---|---|---|
Width Exploration | Defined in pushbacks and fixed for the next steps | Through multiple scenarios, considering all constraints simultaneously in a single-step optimization. |
Impact Evaluation | Not possible, as pushbacks do not consider scheduling constraints | Through comparisons of NPVs, warnings, and geometric aspects of multiple potential solutions |
System Response | Predictable but limited | Unpredictable, revealing other possible solutions |
When to Use | For a standard, well-known, and stable base case mine planning scenario | For deeper studies to improve NPV and/or other indicators |
Instability in the behavior of geometric parameters should not be seen as a limitation; it is a gateway to uncovering hidden optimization opportunities. Only with MiningMath, users have the autonomy to generate and compare as many scenarios as needed, turning uncertainty into informed decisions.
Explore this behavior in your next project and discover how simple changes might unlock better geometries and greater economic value.
Minimum width constraints are crucial to ensure operational feasibility and equipment access, particularly in narrow ore bodies. These controls help prevent unrealistic geometries during optimization.
On MiningMath, the widths and lengths are constraints within the objective function, which means that they are regarded in the optimization instead of being considered just on the pit design stage, when roads, access are drawn to conceive an operational feasible to the pit.
The definition of minimum widths is a pretty useful feature to obtain operational results and play with different geometries accordingly with the project requirements. It is important to understand that they are very complex parameters to be respected while considering 3-dimensional non-linear models, which also influence the runtime of each scenario. Therefore, it is not possible to always guarantee that all minimum widths are respected due to the deposit geometry and also the constraints hierarchy. Testing different values is a great strategy to identify opportunities that could bring the best mining sequence and NPV.
Bottom widths (BW) are the minimum horizontal distance, on the lowest floor of the pit, as seen in Figure 1. It is required to allow mining operations based on the equipment sizing. This parameter is considered the same for all periods and is related to adjacent slopes and applicable in other areas regarded as pit bottoms.
Mining widths (MW) are the minimum horizontal distance that should be respected from a pit to another in every period, which means that this is the horizontal distance between the walls of two surfaces that belonged to consecutive periods, as shown in Figure 2.
This feature is more complex than the minimum bottom width since it would drastically change the pit shapes to identify the best regions. Note that wider values provide greater mining fronts and also better designs to nested pits, pushbacks, schedules, or any other result that you are looking for.
The Mining Length (ML) represents a minimum distance that must exist between at least two points amidst the walls of surfaces among two consecutive mining periods. This distance is already respected for any values smaller or equal to the MW. Thus, this parameter extends such distance between any two points for a value greater than MW. Figure 3 depicts an example
Figure 4 shows a section view of the McLaughlin deposit, where each color represents a given period. The horizontal arrows highlight the bottom and the mining width, while others identify the vertical advance. Mining lengths cannot be depicted in this 2D representation.
The widths inputted in the interface define a diameter (d) of a circle. As MiningMath does not mine partial blocks, the software will consider the block size as a reference to define whether d should be rounded up to the next integer multiple. The approximated circle results in a polygon, whose objective is to select centroids of adjacent cells. Then, MiningMath will assign the same elevation value to the selected cells to define mining surfaces.
Figure 5 shows, in sequence, an example of how the minimum width of 25 meters and possible mining length of 50 meters could be defined over a 10 x 10 meters grid (block’s dimension in x and y direction).
When adding more restrictions to a project, it is common for the net present value (NPV) to decrease as the project becomes more restricted. However, since geometric constraints are not linear, it is possible that the results may not follow this trend as new values are tested.
To better understand the impact and potential of width variables in your project, it is recommended to perform a Best-Worst range analysis
Controlling the vertical rate of extraction is critical in mining operations to maintain geotechnical stability and optimize resource recovery over time. Managing this constraint ensures safe progression through the orebody while aligning with operational and economic goals.
The vertical rate of advance (or siking rate) is defined as the vertical distance, in meters, mined in each period, and it is calculated by evaluating each mining face independently, as shown in this figure.
The total vertical distance mined across all periods should be consistent with the pit depth and equipment available. In cases of unfeasibility this parameter will respect the constraints hierarchy in which it is placed at a lower priority.
The vertical rate of advance (VR) is a complex parameter within the optimization. The VR works as an upper bound to avoid operationally unfeasible solutions. Therefore, testing different values is a great strategy to identify opportunities that could bring the best mining sequence and NPV.
The Mining Width (MW) is not mandatory when using VR, but it plays an important role when defining its value. The MW and VR, together, define volumes of material for each mining period. A reduced MW might create additional challenges for the algorithm to comply with the VR. Therefore, it is important to play with different values, especially when VR is not being fully respected.
Vertical Rate: Definition, Hierarchy of Constraints & Complexity
To evaluate different values for the VR constraint, you can use Decision Trees. The figures below depict a base case for VR evaluation using the Marvin dataset and a respective decision tree built with different VR values.
Notice the fluctuation in NPV illustrated below, influenced by this singular parameter. Additionally, take note that smallest values like 30m (equivalent to block height) and 60m trigger warning violations in the generated report file. This indicates that MiningMath’s algorithm had to adapt the VR constraint for a viable solution to be achieved, keeping other indicators, such as tonnage, within limits. You can see more on the next section on how to prioritize the VR constraint in case adjustments like that are necessary to achieve feasible solutions.
Evaluating different values of VR can lead to unexpected results. For example, when restricting the VR (lower values), results might not necessarily achieve lower NPVs (understand why here). At the same time, higher values of VR could also lead to a higher NPV compared to a certain base case. A more advanced approach could be the use of different VR values for specific timeframes of your project (usually in future periods).
With MiningMath, you can experiment with various VR values and analyze their resulting consequences, particularly economic ones, empowering your team to present compelling arguments for proposing project changes.
The vertical rate of advance is one of the first constraints to be relaxed within MiningMath’s Hierarchy of Constraints (read more). To ensure VR is at least closer to what you need, relax low-priority constraints manually. This way you will lead the algorithm to a more flexible scenario and a broader solution space, which may help it to find a feasible solution for the new set of constraints.
Besides, if the user aims to force a maximum vertical rate for a given period, it can be created a flat surface constraint regarding the achievable depth and input it as a Restrict Mining. Beyond that is important to notice that even the goal of achieving “process full” could result in a non-feasible solution while the VR is still respected, therefore, this feature is very sensitive to any other parameter.
Vertical rates controlled by surface constraints
In summary, it is crucial to assess various parameter values to gain a deeper understanding of how they can impact your project, particularly concerning geometric constraints. You can explore additional workflows presented here that can assist you in achieving better results.
In some cases, certain zones must be mined due to regulatory, environmental, or operational needs, even if not immediately profitable. Force Mining enables these requirements to be met without locking the plan into rigid geometries.
Force mining is a surface used to deplete the material of the entire area in a specific time-frame.
This feature is responsible for making MiningMath achieve at least the surface inserted, which means that all the material inside its limits should be extracted, whether is ore or waste. Thus, this feature could be also understood as a minimum depth that should be mined at a specific timeframe.
Keep in mind that these surfaces might be adjusted during the optimization to respect the slope angles (as depicted below), which has a higher priority order on the algorithm, while the optimization is done.
Therefore, more material can be mined either to correct the overall slope angle or to increase the NPV.
This functionality is commonly used to refine/keep the mining amount of a previous good surface in early periods, force a specific depth which the deposit should achieve, create custom advances, extract material to make a region available to allocate equipment, etc.
As MiningMath aims to assist the users to apply their project knowledge to guide the algorithm into the best decisions, that is why surfaces are one of the most important constraints hierarchy, which enables the implementation of custom geometries and operational parameters based on this smart hints imposed. Thus, forcing-surfaces might be the reason for disrespecting production limits, blending constraints, geometries, and so on, which require the user to be careful by using these functionalities. To sum up, the material above a Force Mining imported surface will be certainly mined until the specified period of time and what is below it will be mined only if the blocks respect all the other constraints and generate profitable results.
The approach here was the attempt to deplete a mining front with high grade ores in the first period on the optimization, which considers the region which has IY higher than 35, inside the final pit of the Data Validation and limited until the elevation 250.
To build such surface the first step was to place the Z coordinates in this excel file, then use conditional functions to define these limits.
By having a surface suitable to use, a scenario of Exploratory Analysis was run using the set up of disclosed.
Note that a scenario without Force Mining was also run to have a good comparison.
As a result, the Force Mining surface totally mined along additional material to fulfill the processing capacity and also adjustments on the slope angles which generated the results disclosed.
Lastly, it is always useful to compare these scenarios with the ones that did not use this approach and generated different sequences. This example illustrates how powerful could be user assumptions to generate better results or explore possibilities.
Download the Mining_Front-FM.csv surface file and play on your own.
Controlling extraction limits per period is essential for operational compliance and maximizing value. Restrict Mining allows this by enforcing spatial boundaries during optimization.
The Restrict mining parameter is defined to prohibit access to any area in a specific time-frame. This parameter allows you to ignore what is outside an input surface. In other words, only the material above it is available to be extracted, whether is ore or waste. This feature could be also understood as a maximum depth that could be mined at a specific timeframe.
Restrict Mining is commonly used to refine/optimize the mining amount of a previous surface in any period, restrict depth to a specific value which the deposit could achieve and extract the best ore in custom advances. It locks/prohibits an area due to concession rights, environmental issues, or even due to an already built stockpile, waste dump or structure in general, etc.
To sum up, the material above a Restrict Mining imported surface will be available to be mined until the specified period of time and what is inside could be mined if the blocks respect all the constraints and generate profitable results. Regarding what is outside, it will not be mined whether profitable or not.
For this example we employ the standard scenario scn21-PriceUp-RampUp-Protection300 that comes pre-installed.
In this example, periods 3 and 4 have a Restrict Mining surface as depicted below.
In the results, it is possible to identify that periods 1 to 4 do not go
beyond the limiting surface on the west portion, defined by the higher elevations of the cells (equal to the topography).
From periods 5 to 12, when the restricting surface is no longer applied, blocks can go beyong the previously constrained area.
The second example is based on the attempt to extract the best material inside the Mining_Front-FM.csv, which mapped high-grade ores in the first period as mentioned here.
Using the suitable surface file, in a scenario of Exploratory Analysis, the example was run using the set up below. A scenario without Restrict Mining was also run to have a good comparison.
As a result, the Restrict Mining surface mined the best material within the area available.
In turn, this generated different sequences as depicted below.
These examples illustrate how powerful could be user assumptions to generate suitable results or explore possibilities. The Restrict Mining parameter enables the implementation of custom geometries and operational parameters based on a smart hint imposed by the user.
Surfaces used for Restrict Mining might be adjusted during the optimization to respect the slope angles. Slope angles have a higher priority order on the algorithm, while the optimization is done. Therefore, less material can be mined either to correct the overall slope angle or to increase the NPV. Still, surfaces are one of the most important constraints in the hierarchy.
Combining force and restrict mining constraints ensures that extraction plans respect both minimum and maximum limits, leading to more realistic and economically sound schedules.
MiningMath allows the user to combine Force and Restrict mining by using surfaces on each field as you already read in the previous pages. These features allow us to use different arrangements due to concession rights, exchanging of land with adjacent mining companies, allocation of waste material inside exhausted areas, environmental issues, and so forth.
By using them together, the user can either reach the exact shape of a pit if you input the same surface as Force and Restrict mining at the same time frame (Figure 1), which has the highest priority constraint in the hierarchy order. It is also possible to optimize the material between surfaces if you add different surfaces in these two fields (Figure 2), which might be adjusted either to correct the overall slope angle or to increase the NPV, as mentioned before.
Based on these concepts, MiningMath allows you to export surfaces from the best scenario to a bigger mining package, design it with your mining package, create the grid of points, import the designed pit, and, finally, optimize and refine as much as you can by using smart constraints. Therefore, the user has the advantage to control the results by guiding results accordingly with the project requirements.
Surfaces used simultaneously in both fields, force and restrict mining, are interpreted as follows:
Different surfaces: MiningMath will force mining according to the forcing-surface and will restrict mining according to the restricting-surface.
Same surface: MiningMath will achieve the same format proposed by the surface in use until the end of the time frame in which they have been applied.
This approach allows you to use different surfaces in the same time frame or split them accordingly to the goals that you want to achieve since this feature works close to what is shown in Figure 2 above.
In this example, it was used the same constraints were mentioned on the schedule optimization page. Besides, the surface 2 of this scenario was add on the force mining field in the second time frame, which means that by the end of the second period the mining should reach at least the shape imposed. The restricting surface used came from the constraints validation page and was added on the last interval, which means that the algorithm could not surpass this limit. Figure 3 discloses the optimized mining sequence volume between the surfaces inserted, and Figure 4 shows the set up of the scenario.
As result, the Figures 5 and 6 illustrate how the force mining has influenced the the firsts periods of the optimization, which mined more material due to its profitability.
Figure 7 disclose the constraint validation surface, used as restrict mining.
Figure 8 shows the final result regarding the force and restrict mining features, which respected the surface constraints and demonstrates the capability of these features to guide results.
The following figure exemplifies how the user can take into account any pit design to make MiningMath iteratively produce more operational results, detailing a previous scenario.
In this case, the user needs to use the same surface in both fields, force and restrict mining, and during the same period of time to reach the exact shape of the designed surface.
Although the workflow on Figure 9 uses a designed pit, it is possible to use pits from previous scenarios as well, so that you can freeze good results and optimize further periods. Below are some examples of it:
Getting the same: Achieve the same final pit of a previous scenario.
Using the traditional approach: Define a pushback from 5 to 5 years.
This powerful workflow allow a lot of flexibility so that the user can guide solutions based on insights and previous knowledge of the deposit. The concept is a pretty unique feature of MiningMath and such approach could be easily done by following the steps of creating surfaces and validating them on the footer bellow.
Surfaces in MiningMath are built from gridded point sets aligned with block centroids of your mine model, enabling precise geometric constraints without the need for manual triangulation from CAD. This streamlines the process and helps ensure design accuracy.
The surface files on MiningMath are a set of points (Figure 1), which are aligned with blocks centroids on X and Y axes (Figure 2). The easiest way to avoid any error message is by using a topography surface created by MiningMath on the Data Validation, for instance, and then manipulating only the Z coordinates.
Usually, the designed surfaces on traditional mining CADs are based on contour/drawn lines and point triangularizations (Figures 3 and 4). Therefore, they are continuous figures which can not be recognized on MiningMath.
Here, it’s the step-by-step to create surfaces on MiningMath:
Import the TopographySurface.csv (Figure 5), which is a grid of points, in the CAD of your Mining Package. The CSV file mentioned might be obtained by validating scenarios or any other execution on MiningMath.
Manipulate only the Z coordinates and project them in a way that fits your needs. There are 3 main options at this step:
Export the modified point set (Figure 9) as a CSV using a different name. Open the file on excel or the notepad to make sure that the header is correct (Figure 10) before importing on MiningMath since it is pretty common that these exported come along with meaningless information that can interfere with the importation.
Select the points in the area that should be restricted, place them at the highest elevation of the topography, and set rest of them at the bottom.
Use as a restricted mining surface.
Figures 11 through 13 illustrate the process.
Note: The X and Y coordinates must remain the same.
Choose the points inside the area you want to force mine, place them at the elevation that you wish, and let the rest of them at the topography.
Use as a force mining surface.
Figures 14 through 16 illustrate the process.
Note: The X and Y coordinates must remain the same.
Define your polygons or use designed surfaces, by following the methodology presented in 2. Creating surfaces Step-by-step.
Use as a force and restrict the mining surface.
Figures 17 through 19 illustrate the process.
Note: The X and Y coordinates must remain the same.
Validating surface integrity is essential to ensure that mine plans align with design constraints and field data, reducing rework and improving confidence in operational decisions.
The best way to generate surfaces is by using a topography surface created by MiningMath, which is created after the Data Validation, then manipulating only the Z coordinates. Make sure to meet all the surface requirements disclosed here.
Headers must be named as X, Y, and Z. These files have to obey an ascending value order in each one of the axes.
Same size of the block model, item 1.1 of this page explains it.
Its points must be aligned with blocks' centroids, items 1.1 and 1.2 help you to understand it.
Defined as a grid of points, the visual validation, item 1.2 shows it.
To be in the CSV format.
By using the values of a Marvin Deposit file in Figure 2, we find the Block model centroids boundaries which begin at XMin=15; YMin=15 and has the maximum centroid value of XMax=5,295; YMax=8,265, which could be confirmed by checking the topography generated by MiningMath.
Then, its time to search for your surface limits, at this example the file chosen was “Surface-RM-offset-300m”. The easy way to find it, is by filtering the axis values, as shown in Figure 3, which disclosed XMin= 15; YMin=15 and XMax= 1,815 and YMax= 1,785. Therefore, even though this file was also based on Marvin Deposit, it is not possible to use it since the surface smaller than the block model in place, which means that it does not have the same size as the block model file.
It is always worthwhile to check the limits of the designed surface (Figures 4 to 8) if we face an error. Remember that everything, even elevations, must be in the boundaries of the block model and check the recommendations for your surface.
The centroids maximum limit by using the equation for each axis:
Maximum centroid value = OX + (NX*DX)-(DX/2)
Where:
OX is the origin of the X-axis;
DX is the block dimension of the X-axis;
NX is the number of blocks in the X-axis.
Note: (DX/2) is related to the distance which should be summed on the origin to find the centroid of the first block, or reduced at the block model limit to find the last centroid, since origins are based on the corner of the block model.
The following video presents how to validate surfaces numerically and visually. This initial verification is what enables you to understand what might be happening and where the error is. The example used regards to the message: “Error parsing surface: Coordinates aren’t properly spaced” but it fits any case where the surfaces used are causing a problem, especially when a red box error shows up.
In this case, as there are a lot of values that do not match the correct ones for X and Y, the quicker and easier way to fix it is restarting from the beginning.
Video 1: Validating surfaces.
If this message appears, it’s possible that your surface file contains more than one elevation for the same coordinate. Please check the CSV file.
MiningMath allows you to guide optimization by adjusting only the Z-values of its generated topography surfaces, preserving alignment and format. This approach simplifies the creation of force or restrict mining constraints and facilitates integration with external tools. Providing flexibility in the final period (using <end>) enables the model to optimize period counts. This method enhances control over deeper mining areas while maintaining consistency with MiningMath’s geometric logic.
The easier way to work with surfaces is by manipulating the Z coordinates of the topography generated by MiningMath, while keeping the same values for the X and Y coordinates.
The surfaces generated in MiningMath have always the same format. Each one of them has an equivalent number of lines. Moreover, the data follows the same order from the first row to the last one. Hence, you can choose the topography file and use it as a guide. This could also facilitate: 1) conversions to original coordinates from other software; 2) filter of regions and pits; 3) creation of force and restrict mining files; and many other options using this concept.
It is worth mentioning that this approach could be easily done by using a simple worksheet and loading the CSV files generated in the viewer for further analysis.
If you are considering geometries, mainly the Mining Width with surfaces imported from a different software package, there will be conflicts between the geometric criteria of MiningMath and the geometric criteria from the surfaces imported.
You must give some freedom for the last period so that MiningMath can also optimize the number of periods. It means that you should use <end> instead of using a lock period range, such as from 16 to 16 for instance.
In order to add more material from deeper areas, you can use a base surface to increase its depth where you wish to get closer to what the project requires. Focusing on the main areas in early periods, you provide tips to the algorithm so that it can understand your approach by using surfaces. The following steps will reproduce an efficient workflow to promote this optimization:
Download this excel file to use as a guidance advance in the steps.
Insert the data in the yellow cells based on your block model information.
Paste the coordinates of the topography surface
Define a new column, plan Z, to represent the coordinates Z of a surface plan. If you are not sure what is the plan Z, you can import a test surface on the viewer, and identify the elevation in which you want to force the bottom area below it.
Create a new column to represent the coordinates Z of the restrict mining surface. This will be used to identify the maximum amount of ore, respecting the geotechnical aspects, that could be extracted. Finally, you can create a condition to define the restrict mining Z at the bottom Z if it is below the plan Z, or at the topography Z otherwise. The figure below depicts this concept and respective formula in Excel.
Set up your scenario and run.
Note: As a result, you will get the maximum potential that can be extracted bellow the elevation that was chosen.
Place the Z coordinate from the base surface that you what to increase the depth to extract more material in the bottom
Paste the coordinate from the maximum potential scenario
Calculate the difference between them.
If the area of the maximum potential surface is bellow the surface base, it will consider the lowest elevation. Therefore, it will consider the additional ore that can be extracted in the bottom along with the base surface used.
Use the mixed surface as force and restrict mining at the period range that you want to achieve it.
Note: After this step, MiningMath will generate operational surfaces so that you can use it on your projects considering the timeframes required.
Surface constraints ensure mining plans respect geological and operational boundaries. MiningMath integrates these constraints within its simultaneous optimization, reducing manual rework and enabling fast scenario testing. Its automation and scripting tools uniquely support flexible, reliable surface management for practical, feasible mine designs.
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.
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
MiningMath incorporates destination assignment directly into the optimization process, allowing simultaneous decisions on routing, sequencing, and constraints. This integration improves planning coherence, reduces manual rework, and supports multiple destinations in a single run—enhancing flexibility and helping ensure consistent, accurate material allocation across complex mining operations.
MiningMath aims to maximize the NPV of a mining project, and as such, it uses a discount rate in all calculations, it also considers the value of money through time. The software decides which blocks will be mined, when, and to which destination they must be sent. The mathematical model bases its decision on the economic values of each possible route. It means that MiningMath aims to identify, in a global view, which is the best destination to increase the NPV, respecting, simultaneously, all the constraints and using the priority order listed here.
Figure 1 shows, on the right bottom corner of the screen, the buttons responsible for add/remove destinations.
The panel Type shows the type of each destination added. The user must add at least:
One (1) processing stream;
One (1) waste dump
The numbers at the left of the screen are identifiers for each route at the mined blocks output file.
Especially when using multiple destinations, the user should consider using more meaningful names for each route. Figure 2 highlights the panel Name, where the user can rename each one.
Figure 3 shows the recovery panel, which is intended to input recoveries used during economic value calculation. The difference is that now it is for reporting purposes, which means it is not being considered twice.
Figure 4 highlights the Economic Value panel. Here, the user can assign each economic function to the proper destination.
As shown in Figure 5, stockpile limits are available only for processing streams, if activated in the General tab. These limits are valid for the life of mine.
Defining accurate metallurgical recovery is essential for linking processing performance to plant economics and ensuring profitability forecasts reflect real-world output.
One of the most important and basic concepts in mineral processing is metallurgical efficiency. Two terms are used to describe this efficiency: recovery and grade.
The recovery or percent recovery refers to the ratio of the valuable material (metal or mineral) contained in the concentrate with reference to the amount of the same material in the processing plant feed.
The main place where the user input the recovery information is when defining the Economic Values.
However, as this information is implicit in the economic functions, the user need to input this value on the interface for purposes of generating reports.
On the Destination tab (light green), the user can define recoveries for each element in the panel (dark green) from Figure 1.
A detailed mine planning is likely to require an iterative process to update a block model with new information.
Considering the usage of specific tools for measurements, analysis, and reporting, mine planners might be interested in using the thorough information acquired on recoveries along the way.
When editing the data set, the user can add as many columns as needed, defining recoveries for each block. Figure 2 shows how it would look like.
Figure 3 shows a dropdown menu where the user can choose which recovery to use:
RecoveryA
RecoveryB
Constant recovery
NOTE the user does not need to use all the recovery fields imported for each run. This means recovery fields might be created for further scenarios, being used separately. The same concept is valid for columns with slopes and economic values.
The following video presents how to use a different recovery for each block.
Video 1: Varying recoveries for each block.
Stockpiles help recover value from blocks initially marked for dumping, while smoothing production over time.
Stockpiles are handled as a post-processing stage within the optimization algorithm. After generating the mining surfaces, the algorithm reviews blocks initially considered for discarding and evaluates which ones have the potential to be stored for later processing instead of being sent to the dump. In other words, this all occurs as part of the optimization process, before the final destinations of the blocks are determined.
MiningMath evaluates whether a block’s net value (Revenue – Fixed Mining Cost – Rehandling Cost) exceeds the cost of discarding it, applying the appropriate discount rates for both the extraction and processing periods. This means that stockpiles effectively optimize blocks initially destined for the dump, potentially recovering additional value. For selecting a block’s destination, MiningMath uses the same logic of maximizing project value. The software identifies which discarded blocks should be reclaimed to address production shortfalls over time, ensuring optimal resource utilization. The diagram below summarizes the stockpile methodology.
To enable the stockpiles on the interface the first step is on the General tab where two inputs are required:
Fixed Mining Cost: value used to decompose the economic value while considering stockpiles.
This cost is essential because MiningMath uses this parameter when calculating economic values. It helps break down the block's value, allowing the algorithm to accurately account for costs incurred during mining and those applied during processing.
Rehandling Cost: represents the cost to reclaim blocks from the stockpile to the process.
This cost is applied to break the economic values into parts and apply the discount rate at the time a block is processed.
After that, on the Destinations tab, you can define stockpile limits for each processing plant added, remembering that this limit is based on the life of mine, not in a period timeframe.
Since stockpiles are a post-processing unit of the algorithm, total tonnage restrictions might be violated when the stockpiles are processed. Total tonnages restrictions are only considered during the processing unit of the algorithm.
When defining the stockpile, MiningMath’s algorithm ensures that ore blocks are not discarded and later recovered from the waste pile. Instead, ore blocks that cannot be processed immediately due to period constraints are sent to the inventory pile after sequencing. During sequencing, blocks are marked for disposal but are only discarded once storage is finalized. This process ensures that ore blocks, marked for disposal due to period constraints, are identified and stored in an inventory for future processing. This prevents blocks from being mistakenly discarded because of scenario constraints.
Stocked blocks represent a common operational challenge in open-pit mining, often leading to bottlenecks in production schedules and suboptimal resource allocation. Understanding how to handle them strategically can make a significant difference in the feasibility and value of a mine plan.
There are two common ways that mining software packages deal with stockpiles:
Reclaiming blocks according to an average grade for the entire stockpile.
Reclaiming blocks selectively in any required sequence such as FIFO (first in, first out), LIFO (last in, first out), etc.
Both options are approximations and have their advantages and disadvantages.
Currently, MiningMath reclaims blocks selectively from stockpiles according to the highest Economic Values. Read more about Reclamation Policy.
The user can analyze MiningMath’s output in the files MinedBlocks or AllBlocks and report the periods in which a block has been mined and when it has been processed.
Video 1: How to trace stocked blocks.
Artificial stockpiles help simulate intermediate storage within your optimization flow, enabling greater control over how material is handled and processed.
Artificial Stockpiles is an advanced operation to incorporate external sources of material to your model and use them as an input on your scheduling.
This technique is especially useful when you need to incorporate the following scenarios into the optimization process:
Pre-existing stockpile from ongoing operations.
Underground material to be blended with open-pit material.
Ore bought from third-part companies to fulfill production shortfalls.
There are two main ways artificial stockpiles can be incorporated into the optimization: 1) modelling the stockpile with its actual geometry; or 2) creating a simplified artificial stockpile. These are detailed next.
Modelling an existing stockpile with its actual geometry is the best alternative to include it into the scheduling for cases where you need an operational control over:
For this process, use a modelling software to perform the following steps:
Use the previous topography for the base of the stockpile.
Use the current topography for the top of the stockpile.
Create blocks in-between these surfaces. These blocks will have the same size of the block model.
Assign an average quality (grade) and density to each block created.
Calculate the economic values for these stocked blocks.
Import the model back to MiningMath to further scheduling.
To speed up the process, users can create multiple blocks as needed using a spreadsheet application. This method serves as a useful alternative in scenarios where you require:
You can model artificial stockpiles as rows or as columns. A comparison between each choice is listed below.
| Rows | Columns |
|---|---|
To control a sequence, it may require surface constraints. | Easier sequence. The precedence is defined by the vertical geometry. |
A 1-line row will be affected by minimum widths used for the scenario. | A 1-line column will be affected by minimum widths used for the scenario. |
Thin rows may cause problems to be mined completely. | Long columns may affect how deep the scheduling can go in a single period. |
Multiple rows will give more flexibility and reduce conflicts with the operational constraints from the open-pit scheduling. | Multiple columns will give more flexibility and reduce conflicts with the operational constraints from the open-pit scheduling. |
If you opt for multiple stockpiles, create them with a 2-cell distance to avoid overlapping interference. | If you opt for multiple stockpiles, create them with a 2-cell distance to avoid overlapping interference. |
Create rows of blocks above the topography.
Assign an average quality (grade) and density to each block created.
Calculate the economic values for these new blocks.
Import the model back to MiningMath to further schedules.
Consider checking the following requirements and observations.
Notes on modelling:
Note on operational needs:
Notes on the placement within the model:
Use Other Constraints to have additional control over different sources of material, whether they come from the original model or from a modeled stockpile. The figure below shows an example on how to setup your model to track and material from different sources and control them by inputting minimum and maximum limits.
Stockpile reclaim is a post-optimization process with direct operational impact. It ensures high-value material is reclaimed first, supporting NPV maximization and realistic production control.
Stockpiles are managed as a post-processing phase of the optimization algorithm (learn more). The decision-making process for reclaiming stockpiled blocks is driven by their economic value, with the algorithm aiming to maximize NPV. Consequently, blocks with the highest value are reclaimed first, regardless of when they were mined and added to the stockpile.
Various mining software packages may use different conventions for stock reclaim policies, typically aligned with the specific goals of each application or module. Some of the possibilities may include:
FIFO: First In, First Out.
FILO: First In, Last Out.
Reclaiming an average grade for the entire stockpile.
Reclaiming the highest-value blocks first (MiningMath uses this method).
Each one of these other possibilities is an approximation of reality, with its pros and cons.
FIFO and FILO are quite logic but represent a level of selectivity that is not practical. The angle of repose and the positioning of each block are likely the most intuitive examples of reasons for lower selectivity in practice.
An average grade for the entire stockpile is naturally an approximation, considering the amount of material that should be blended to make it close to the reality.
Reclaiming the high-value blocks first also assumes a selectivity level that is not possible in reality. However, it is quite aligned with the mathematical goal of maximizing the project's NPV for strategic evaluation.
Ultimately, none of these approaches are fully operational. The final decision still relies on the expertise of the professional overseeing the strategy optimization, who uses their preferences, experience, and skills to introduce additional levels of control.
This section aims to bring a few ideas on how the user might guide the algorithm in order to follow one’s preferred reclaim strategy. For this article, the user should have prior knowledge in the following concepts.
How to use pre-define destinations.
How to create multiple economic assumptions, and how to handle fake destinations.
How to handle different output files (mainly MinedBlocks.csv and AllBlocks.csv).
The general idea is to set up and run a baseline scenario to find what is optimal for the long-term value. The solution obtained in this step will guide further executions.
For this manipulation you will need to switch the output format to export the entire block model along with the optimization results, which is saved in the AllBlocks.csv file. This is essential for any iteration requiring re-optimization of a previous solution. By default, MiningMath exports only the MinedBlocks.csv file.
The results will indicate which blocks should be mined, when they should be mined, and whether they were immediately processed, stockpiled and later processed, or discarded.
The goal is to utilize previous outputs to generate new columns of economic values by introducing fictitious destinations. This involves creating multiple processing streams that do not coexist but effectively represent a single plant. These fictitious destinations, combined with predefined economic values, enable the user to impose their preferred level of control.
Additionally, based on prior results, the user must adjust the new economic values by specifying the final destination for each block.
For the FIFO approach, a block stocked during the second period on the first run, should be sent to the stockpile of Process 1 to be reclaimed first. Hence, this block must have a very negative value for all other destinations.
Define a criteria for stocked blocks (Period Mined different from Period Processed) that should be reclaimed early or later. This criteria must be based on the previous results from the AllBlocks.csv (depicted below), and on the columns Mined Block, Period Mined, Period Processed, and Destination.
Add a pre-defined destinations column based on the criteria adopted.
Set up your scenario considering the pre-defined destinations will not coexist.
Notice that: 1) Process 1 and its stockpile will be used from Period 1 to Period 5; 2) Process 2 and its stockpile will be used from Period 6 to Period 10; and 3) Process 3 and its stockpile will be used from Period 11 to .
Optimize the new scenario to have a better approximation for the final NPV, considering the strategy of your preference.
Fixed mining costs simplify early-stage economic modeling, but they may not reflect real operational variations. MiningMath offers flexible ways to approximate variable costs through customized inputs and iterative workflows.
MiningMath was conceived with some simplifications for current version, such as the fixed mining costs.
The software uses a fixed mining cost, which is incorporated into the economic formulation at an early stage. This value is entered through the user interface, enabling the software to recognize and adjust the pre-calculated economic values accordingly. The appropriate discounts are then applied to each block based on its status: whether it is (1) processed, (2) discarded, or (3) stockpiled and later processed. In all cases, mining costs are factored in before processing costs and revenue are considered.
For mined blocks in the stockpiles context, the possibilities for the material flow and their cost calculation are:
Mine-to-process: this is already embedded in the economic formulation.
Mine-to-waste: this is already embedded in the economic formulation.
Mine-to-stock: this is considered the same as the cost for mine-to-waste. However, this is a limitation, since these two costs might not be always the equal due to, for example, different distances at the mine site surface (different haul costs).
Stock-to-process: this considers an additional cost, represented in the user interface by the re-handling cost.
Mining costs might be defined with some variability for purposes of higher detail. This sections shares some ideas on how to consider variable mining costs, in which some goals are based on different aspects, such as:
The following steps outline how to add block-by-block mining costs to the block model file and define their average cost within the software.
Prior to the model import, create a column of mining costs by block — including whatever costs are applicable: blasting, haul, loading, etc.
Calculate the Average Mining Cost of all of the blocks.
During the model import, assign the Mining Costs column to the field type Other; MiningMath will export this column along with its output.
Use the Average Mining Cost as the Fixed Mining Cost for the stockpiles.
Run MiningMath.
OPTIONAL for more accurate approximation: analyze the MinedBlocks.csv file (or AllBlocks.csv) and calculate the average mining cost just for the stockpiled blocks.
OPTIONAL: run MiningMath again, now using the new average mining cost (from step 6) as the fixed mining cost for the stockpiles.
For which the steps are:
Open the MinedBlocks.csv.
Edit the stocked blocks' value to add new costs.
Calculate the NPV manually.
For which the steps are:
For the first execution, set up MiningMath to export the AllBlocks.csv and run.
Use the output model (AllBlocks.csv) to update the economic value for stocked blocks. Then, save as a new model.
For the next execution, re-import this model with fixed surfaces for all periods.
This process does not guarantee that the solution will remain unchanged; stockpiled blocks may vary, potentially requiring further iterations for better approximation.
Since stockpiles are treated as a post-processing unit and are not part of the optimization, Option 1 offers a more accurate NPV calculation.
The following features are already in our pipeline:
We are collaborating with a partner to develop a calculator and post-processing analysis tools for future integration with MiningMath. For more information, please contact our support team or read about our future overview.
Production constraints shape how much material can be mined or processed in each period, directly influencing the realism and profitability of a schedule. Modeling these limits accurately helps align strategic plans with actual capacity.
MiningMath allows the user to set period ranges and its corresponding production limits. This functionality allows the use of options such as pre-stripping, production ramp-up, prices changing over time, among others. It is worth mentioning that the discount rate on MiningMath is already applied in the first period. For more information on NPV calculation click here.
In the Scenario tab, under the Production option the user can define period ranges.
Such ranges allow the user to vary variables over time such as:
The Timeframe Panel allows users to set values for their projects, ensuring more accurate sequencing. These values are applied to calculations on a timeframe basis. Users can either select a predefined value or input a custom one to suit their specific needs.
For example, in this case, we selected a timeframe of one year. This means that each generated period in the sequencing corresponds to a single year.
In the Production panel the user can define limits for any destination added.
In this example, we have the following limits:
These limits are being considered from Period 1 up to the end of the life of mine.
Multiple period ranges based on different timeframes can also be added added.
In this image, two period ranges were defined as follows:
This approach allows you to fragment the life of the mine and adjust parameters over time as needed. The Add Range and Remove buttons, located at the bottom-right corner, make it easy to add or remove period ranges.
Explicit limit for all available destinations are not always required. For instance, the dump can be assigned an <unlimited> upper bound. This provides MiningMath with the flexibility to adjust process throughput and increase dump tonnages (up to the Total limit) whenever it identifies this approach as a way to maximize the project’s NPV. For users who prefer greater control and want to restrict this flexibility, simply define a specific limit for each destination.
On the other hand, the production capacity fields for processes require a defined value. If unlimited production is desired, you can simulate this by entering an extremely high, practically unreachable number (e.g., 9999999999999).
MiningMath allows you to apply global average constraints—such as minimum grades or contaminant limits—directly within the optimization process. This built-in flexibility reduces post-processing and ensures more consistent compliance across the entire planning model.
Average constraints are based on the average of any quantifiable parameter modeled block by block. To use this feature on MiningMath, the dataset must contain an auxiliary field/column which considers a value of what you wish to limit regarding the value of it in each block. Therefore, this feature controls the avarage value of the variable that has been modeled considering blocks that were mined in that single period. Since this feature is based on average parameters, the algorithm can use lower values to respect this target and increase the NPV with higher ones.
This feature is usually applied on blending to combine low-grade and high-grade blocks in order to increase the profitability. Although, it could have a lot of other applications. Basically, any variable which could be could be modeled considering these assumptions could be controlled.
Video 1: Blending and other constraints.
Some examples using average are listed below:
Grade of a contaminant on the plant.
Haulage distance, based on the destination each block.
The user can define:
Minimum and maximum average limits.
Different limits for different materials.
Different limits for different intervals.
Different limits for different destinations.
Create auxiliary fields in the block model, quantifying the information to be controlled.
During the importation, assign the column to be blended to Grade (Figure1).
On the Average tab, input minimum and maximum limits for each variable (Figure 2a), period range (Figure 2b), other weights to be considered (Figure 2c) and destination (Figure 2d).
Sum constraints let you control total values like tonnage or metal content directly in your model, helping align plans with production targets.
Sum constraints are based on the sum of any quantifiable parameter modeled block by block. To use this feature on MiningMath, the dataset must contain an auxiliary field/column which considers a value of what you wish to limit regarding the value of it in each block. Therefore, this feature controls the total amount of the variable that has been modeled based on blocks that were mined in that single period. Basically, any variable which could be modeled considering these assumptions could be controlled.
Video 1: Blending and other constraints.
Some examples are listed below:
Tonnages and proportions of rock type and metal production.
Consumption of inputs such as energy spent during comminution, and fleet hours spent to mobilize material.
Contaminants control on the processing plant during each period.
Blasting material consumptions.
The user can define:
Different sum limits for each material.
Different sum limits for each intervals.
Different sum limits for each destinations.
Combine all the options above in order to achieve globally optimized results.
Create auxiliary fields in the block model, quantifying the information to be controlled (Figure 1).
During importation, assign these auxiliary columns to Sum (Figure 2).
On the Sum tab, input minimum and maximum limits for each variable, period range and destination (Figure 3).
Accurate definition of lithotypes or rock types in the block model is essential for controlling material classification and flow in mine planning. These definitions serve as the basis for generating auxiliary columns that aggregate variables across the model.
Mining fronts, rock type, or lithotype are usually defined in the block model as strings or converted to integer numbers. As the next step, the user defines which ranges of material types should be allowed, avoided or forbidden in the processing plant.
The ideal way to model material types for further control of this variable is to create tonnage columns for each material type. Therefore, you will be allowed to:
Control material types to be allowed, avoided, or forbidden in any destination.
Control the proportions of different material types, if applicable.
Analyze scenarios with different levels of flexibility.
Understand how the project development changes in face of each hypothesis tested.
Assess the impacts of the flexibility level given on economic and technical variables of the system.
The general idea is to create auxiliary columns in the block model to control any variable through their sum. Then, use the same idea of if-then-else statements, example:
If variable value matches condition
Then auxiliary column equals to X
Else auxiliary column equals to Y
To control the amount of material by rock type, create columns for tonnages of each lithotype, as shown in Figure 1, where:
Lithotype A has its tonnage inputted in the field Tonnage A.
Lithotype A equals zero for fields Tonnage B and Tonnage C, as it does not match the specified condition, i.e. being a lithotype B or C.
The same concept is used to the other material types.
Figure 2 shows the same concept being applied to measured, indicated, and inferred resources.
Whatever is the variable being modeled, the columns created with a similar purpose should be assigned to the field type “Sum”, during the importation, as shown in Figure 3.
On the interface, the user will need to insert General and Destinations parameters in order to enable the Sum tab (Figure 4). The next step is to define the limits to be imposed to each variable, to which destinations, and to which period intervals.
Figure 3: Importation screen where variables to be controlled through sums are properly assigned to the field type “Sum”.
Figure 4: Illustrates the interface and options available.
Mining fronts define specific zones in the mine plan where constraints can be applied independently, allowing more precise control over production targets and regional strategies. By embedding these controls directly into the model, MiningMath reduces the need for external tools and manual adjustments. This approach supports faster scenario testing and highlights the most profitable areas for mining, aligning operations with both technical and economic goals.
The ‘mining fronts’ approach, as shown in Figure 1 and 2, is a good way to refine results, control regions, and understand which are the best results considering different amounts extracted from a specific place. Using this methodology, you have the possibility to categorize masses by depth, a specific coordinate intervale, even into sectors based on into 360 degrees vision, of your project.
The general idea is pretty similar to what is used to define material types. The first step is to identify the area which you want to control. Then create an additional field regarding the mass on that region and assign it as a sum constraint while importing it. At last, go to the sum tab and control the minimum or maximum amount at the process or dump destinations.
Note that by using this feature you are able to control what, how much, and when the blocks should be mined according to what you want to analyze. This concept is also very useful in the context of mine design, although it increases the complexity while compared with the use of force/restrict mining surfaces, it can also guide solutions, geometrically speaking. It is important to remember that the sum constraint has a high priority parameter in the algorithm and it can also influence the other inputs based on the hierarchy order.
Identify and define your regions as you wish. For instance, use this excel file, place the z from the validation data scenario, calculate the elevation difference with the topography, filter the region which has a 0 result, and create a dispersion chart to identify the final pit. Then, take the coordinates/indexes, which will be the limits of your mining fronts, in this case, the boundary between the mining fronts was at the index 35. Figures 3 and 4 have some visual information to help you.
Calculate the tonnage of your mining front in an additional field and import it as a sum parameter. In this case, the mining front 1 is in the region above or equal to the limit chosen and the mining front 2 is what is bellow it, as seen in Figure 4.
Use the sum tab to control the Mining Front of each destination. Play with the minimum or maximum that should be extracted from each mining front and understand how the results change. The scenarios, that are shown in Figures 5 to 9, used the production, geometric and stockpiling parameters from the Data Validation page.
Download this modified Marvin Deposit file and play on your own.
Incorporating uncertainty directly into mine planning improves reliability under variable grade and volume conditions.
While single scenarios of distinct models are run separately, a stochastic scenario consist of obeying all the single scenarios at once. Hence, stochastic simulations requires equiprobable models to consider uncertainties related to geological aspects, such as grade and/or volume of ore. This is achieved through an adapted resource block model that contains equiprobable values for a given set of variables containing a certain level of uncertainty.
As a consequence, MiningMath produces reports with the risk-profile of indicators presenting the minimum, maximum, expected, and percentiles P10 and P90 (these are threshold values, indicating that 10% of the indicators are below the P10 and 90% of the indicators are below the P90). The graphs below illustrate the NPV and cumulative NPV respectively for stochastic models run with MiningMath.
Maximum expected NPV for period 2
Minimum NPV expected for Period 2
P90 NPV for Period 3. 90% of possible expected values for Period 3 are below this point.
P10 NPV for Period 3. 10% of possible expected values for Period 3 are below this point.
Expected NPV for Period 6.
Maximum expected Cumulative NPV for Period 2.
Minimum Cumulative NPV expected for Period 3
P90 Cumulative NPV for Period 4. 90% of possible expected values for Period 3 are below this point.
Expected Cumulative NPV for Period 5.
The purpose of this page is to briefly explain how to import data and manage stochastic constraints using MiningMath.
Uncertain-fields are those which might vary from simulation to simulation. By definition stochastic models have uncertain fields. Typically, grade fields contain uncertain information. Therefore, the user will need to format each equiprobable possibility in a specific way: name each uncertain column as the same name adding {#} (where # is a number from 1 up to n). The image below highlight how grade headers should look like in a example with 5 simulations.
Note that the grade information will influence the economic values for the processing stream. Therefore, the user will also need to calculate the economic values for each possible grade information, as illustrated below.
The example in this page comes from a simulated copper deposit that can be downloaded here.
Expected values to control the averages over all simulations.
These constraints will guarantee that, in average, the indicators will be within the defined ranges. For example, take Expected Min = 0.60 and Expected Max = 0.65 for a certain constraint. If there are 3 simulations returning 0.59, 0.62 and 0.65, the average is 0.62, so this is within the range defined.
All simulations to guarantee that each one of them respect certain criteria
These constraints control the variability, or the spread, of the results to be within a certain acceptable range. Let's take an example where such a range has Min = 0.60 and Max = 0.65, and again three simulations returning 0.59, 0.62, and 0.65. In this case the solution will be penalized by the optimizer, as 0.59 < 0.60. Learn more about penalized solutions here.
Stochastic optimization is an optimized way to combine all these modelled uncertainties into one schedule that maximizes the expected NPV of the project.
After executing the optimization with constraints for simulated indicators, it is possible that such constraints will not be respected due to some infeasibility in the problem (more about infeasibilities here).
MiningMath will try to solve any violated constraints following its hierarchy order.
Stochastic constraints are of the average and sum types. They have higher priority than any NPV improvements and time limits imposed by the user.
Time limits in MiningMath’s “Run” tab help deliver solutions within fixed durations, aligning with daily planning needs.
It is possible to indicate a time limit in hours before running a scenario in the “Run” tab as depicted in Fig. 1. The time limit is defined in hours due to the usual complexity of mining projects and by the fact that MiningMath will always try to deliver a reasonable solution.
MiningMath is built via a global and interactive algorithm. It solves the entire mining optimization after formulating a global mathematical model. The result of such optimization might deliver a solution with room for improvement, due to necessary approximations for solving complex non-linear restrictions, such as the geometric ones, or due to infeasibilities identified in the problem’s restrictions. In turn, if an improvement is possible, another iteration of the global algorithm is prepared and executed.
Therefore, in order to deliver any solution, the whole mining problem needs to be solved at least once, making a more fine-grained time limit (i.e. seconds or minutes) not possible to be set. In other words, the time limit is evaluated before each iteration of a global optimization that executes multiple times as depicted in Fig. 2.
The algorithm is designed in such a way that it is able to adjust subsequent iterations once it has identified that the time limit becomes restricted. However, it is important to highlight two aspects of such adjustment:
It will not interrupt the current iteration of the algorithm. Hence, while it is expected that this adjustment will help the execution to achieve the desired time limit, it is still possible that it will take more than what was defined.
Once an adjustment is made, a different problem will be defined and consequently new solutions will be explored. Thus, while unlikely, there is a chance that solutions will end up better than those unrestricted in relation to time. Therefore, despite not being implemented for this purpose, the time limit might be used to find more diverse solutions. For instance, you might build decision trees with different time limits. Even if better results are not obtained, fast solutions will still give you a quicker assessment of your project.
MiningMath supports predefined destinations for use cases like pushback design or lithologic constraints. While this limits optimization flexibility, it can reduce run time and align results with external tools. Preassignment is implemented via block model or Calculator and can be cross-checked in the Viewer tab.
Predefined destinations refers to a predetermined assignment of individual blocks destinations (such as waste or process) within a mining operation before any optimization is performed. We have already seen that MiningMath works with Economic Values for each destination, taking each one of them into account to decide whether or not a block should be mined and where it should be sent to. Thus, fixing destinations or predefining them is not a concern anymore, especially with MiningMath technology.
However, it might still be necessary if you are using MiningMath to define pushbacks while making use of other constraints, comparing the MiningMath technology with other software solutions, or just want to reduce MiningMath run time by accepting a less optimized solution.
Utilizing this parameter restricts MiningMath from optimizing the destinations of predefined blocks based on economic values, as it relies solely on the predetermined allocations. Thus, you are impeding MiningMath to reach its full potential.
Predefine destinations to define pushbacks.
Lithologic restrictions that prevent certain blocks to be processed. For example, preventing a rock type block to be sent to a processing plant.
Speeding up the algorithm's run time (while accepting a possible loss of NPV, due to an unoptimized choice of destinations).
Among others.
When formatting and importing your block model csv file, you can have a predefined destination column, as depicted below. This column will indicate the fixed destination for each block.
When importing the csv file, make sure to define the field type of your destination column as Predefined Destinations
The option to predefine destinations can also be made in the Calculator area. The figure below depicts a new parameter Destinations that is set to 1 (a process destination) if the grade of CU is greater or equal 0.5, or -999 (non existent destination) otherwise. Note that the field type is set to Predefined Destinations.
After creating the new parameter (using the calculator or importing the field in the block model file), make sure it is being used in the Scenario tab as depicted below.
In the Viewer tab you can verify the destinations. Just select the Destinations field in the Blocks area to check the destination value of the filtered blocks. In the exampled depicted below all destinations are filtered to 1.
Accurate cash flow modeling is essential for evaluating the economic performance of a mining project. MiningMath integrates discounted and undiscounted cash flow calculations directly into its optimization engine, ensuring financial outcomes are aligned with operational constraints from the outset. By enabling custom timeframes and automating scenario analysis, it supports faster iterations, reduces manual adjustments, and provides deeper financial insights to guide strategic decisions.
MiningMath’s objective function maximizes the discounted cash flow over the entire life of the mine in a single mathematical optimization step, taking all necessary constraints into account simultaneously. In contrast, other software packages that use LG/Pseudoflow methods for pit optimization focus on maximizing the undiscounted cash flow for each given revenue factor. Hence, the solutions provided by MiningMath are not easily comparable to undiscounted flow approaches that only consider slope angles.
A visual comparison between undiscounted and discounted cash flows is provided below. This comparison indicates that MiningMath’s decision not to mine certain regions is likely due to the higher cost of waste removal outweighing the potential profit from extracting hidden ore. Despite discounting, the revenue from the hidden ore is insufficient to cover the extraction costs in these areas.
A proper comparison between both methodologies could be done if you import the final pit surface obtained from the other mining package into MiningMath, and use it as Force/Restrict mining. By utilizing this surface as a guide, MiningMath can precisely optimize scheduling within the specific boundaries delineated by the imported surface. This integration simplifies the comparison of NPV between MiningMath and various other mining packages, giving a more comprehensive evaluation of the methodologies employed by each one.
For comparisons targeting specific objectives, such as maximizing early-period cash flow or identifying profitable areas in the initial years, the following examples will guide you in setting up the appropriate scenarios within MiningMath.
If you want to emphasize the cash flow in the early mining periods, simply create a decision tree varying the discount rate. The higher the rate value, the more weight will be given to the early periods, leading the undiscounted cash flow to have higher values at the beginning, while later periods will be heavily penalized by the discount rate.
If you wish to mimic the same greedy behavior as in the context of nested pits in MiningMath, you should drop all constraints and set a 1-<end> (only) interval with the desired ore productions, asking MiningMath to focus solely on maximizing the cash flow of this single pit, regardless of the long-term consequences, as in the picture below and similar to this process.
If you with to focus on finding the most profitable area to operate during the early years and the long-term consequences of such decisions are not an immediate concern, you must setup MiningMath accordingly., dropping all constraints after initial years. For example, it is possible to only have interval 1-5 timeframe (represensint the first 5 years) and 6-<end> with no constraints and infinite productions, as depecited below.
An even greedier approach would be to have just the 1-5 interval, meaning “I only have these 5 years to operate this mine”. In this case, you could also setup the discount rate to zero, so that you can analise only the undiscounted cashflow.
MiningMath allows you to keep as much of the global view as you wish while constraining your project as much as needed, even changing criteria for short and long-terms. If you’re unsure, simply run multiple scenarios and choose the one that best meets your objectives.
We recommend these strategies primarily for comparison and validation purposes. However, we recognize that any comparison aligned with a project’s long-term objectives should apply a consistent discount rate throughout the entire life-of-mine (LOM) in both cases.
Correct azimuth rotation ensures spatial accuracy by rotating block models around a defined XY origin while preserving depth (Z). MiningMath handles this directly within the model, removing the need for manual adjustments or preprocessing. It also supports automation through scripts or API, enabling rapid testing of rotated scenarios and maintaining consistency across varied setups.
MiningMath supports the use of block models that have been rotated using an Azimuth rotation.
This procedure performs a rotation of a point around a specific origin in the \(XY\) plane, while preserving the \(Z\) coordinate. Below are the steps involved, along with the corresponding mathematical formulas.
Azimuth normalization
First, the azimuth value is adjusted to ensure it lies within the range of \(0\) to \(360\) degrees. This is done by taking the remainder of the azimuth divided by \(360\)
\(\text{azimuth} = \text{fmod}(\text{azimuth}, 360.0)\)
In mathematics, the function \(\text{fmod}\) (floating-point modulus) computes the remainder of the division of two floating-point numbers. If the azimuth value is negative, \(360\) degrees is added to make it positive:
\(\text{azimuth} = \begin{cases}
\text{azimuth} + 360.0 & \text{if } \text{azimuth} < 0.0 \\
\text{azimuth} & \text{otherwise}
\end{cases}\)
Inversion of Rotation Direction
The adjusted azimuth is then inverted to perform the rotation in the opposite direction:
\(\text{azimuth} = -\text{azimuth}\)
Conversion from Degrees to Radians
The azimuth in degrees is converted to radians, as trigonometric functions use radians:
\(\text{radians} = \frac{\text{azimuth} \times \pi}{180.0}\)
Calculation of New Coordinates
The new \(x\) and \(y\) coordinates are calculated by applying the rotation in the \(XY\) plane around an origin \((x_0, y_0)\). The formulas used are:
\(
p_x = \left( (x - x_0) \times \cos(\text{radians}) + (y - y_0) \times \sin(\text{radians}) \right) + x_0\)
\(
p_y = \left( -(x - x_0) \times \sin(\text{radians}) + (y - y_0) \times \cos(\text{radians}) \right) + y_0\)
Where \((x, y)\) are the initial coordinates of the point, and \((x_0, y_0)\) are the coordinates of the origin.
Preservation of Z Coordinate
The \(z\) coordinate of the original point remains unchanged during the rotation:
\(z_{\text{final}} = z_{\text{initial}}\)
Final Result
The result of the procedure is a new point with coordinates \((p_x, p_y, z)\), where \(p_x\) and \(p_y\) are the new coordinates in the \(XY\) plane after the rotation, and \(z\) is the original coordinate in the \(Z\) axis.
\(\text{New Point} = \{ p_x, p_y, z \}\)
Labs are compact, in-app tools available from version 3.0.8 that let engineers edit CSV files, compute statistics, and adjust model inputs directly within MiningMath—eliminating the need for external software and reducing manual rework. Each Lab (like csv_column_operations) opens as a standalone mini-app, streamlining scenario testing without disrupting workflows. Users can also develop and share custom tools through the MM Labs repository, extending functionality to suit specific operational needs.
Starting from version 3.0.8, a new set of small apps are provided in the MiningMath Labs section. These apps provide quick solutions to common problems, for example changing input csv files.
To use the Labs section for the first time click on the Labs button. You might be prompted to select a folder with writing permissions in which the apps will be stored.
Once you have it selected wait a few sconds until it opens in a new window as depicted below.
Note: Labs may take a bit longer to open the first time.
The Labs window might take a few seconds to open the first time in order to download all necessary files. Please wait and do not close the MiningMath application in the meantime.
To run any app, just double click its name. For example, if you double click the csv_colum_operations script a new small window will pop up asking you to select a csv file to perform alterations.
Once a file has been selected, you will have the option to add or remove columns, get column statistics, and save colums.
From now on you should be able to play with all the options and all the apps and see if there is anything that can aid in your project.
These apps are custom-built and may contain errors. Please back up your project and use them at your own risk. If you are interested in the future overview of MiningMath and other supported functionalities yet to come, please check this page.
Reblocking reduces model complexity by merging smaller blocks into larger ones, which can significantly shorten optimization runtimes. While MiningMath’s 64-bit technology handles large models without needing reblocking, an optional tool in MM Labs allows custom aggregation when simplification is beneficial.
Reblocking is a method used to decrease the number of blocks in a block model by combining some of the smaller blocks to create larger ones. For example, if your blocks have the dimensions of 5 x 5 x 5, you could increase it to 10 x 10 x 10, which could reduce the number of blocks to half of its standard dataset size.
Note: when reblocking your model it is important to evaluate dilution aspects that can be lost by increasing the block size.
MiningMath is 100% based on 64-bit technology and it is capable of handling tens of millions of blocks without requiring reblocking. Hence, it does not offer built-in reblocking options, but only a custom-built application in the Labs section as described later in this page.
Reblocking can significantly reduce optimization runtime. Users have observed substantial improvements in runtime by implementing double, triple, or even quadruple reblocking. For example, feedback indicates that for a 32M blocks model, optimization runtime decreased from 36 hours (with double reblocking) to 12 hours with triple reblocking, and further to just 4-5 hours with quadruple reblocking.
MiningMath provides an app in its MM Labs section that is able to reblock your block model. An example is provided below.
Open the Labs section in the main menu as depicted below. Note: You will need at least version 3.0.8 to start using the MM Labs applications. More about Labs can be seen here.
A reblocking application should be available. Double click on it to open the app.
You will be prompted to select the csv file of your block model. Afterwards, you will need to inform the coordinate columns, model dimensions and desired reblocked dimensions.
Based on the columns of your model, you will be able to indicate which columns should be summed, averaged or weighted averaged. Lastly, you will need to indicate the output csv file. This file needs to be created beforehand.
Cut‑off grades influence sequencing, recovery, and profitability. MiningMath handles them dynamically, integrating cut‑off decisions into simultaneous optimization with sequencing, routing sub-threshold blocks without manual intervention. This reduces rework and enables rapid scenario testing via scripting, all while respecting operational and economic constraints.
MiningMath does not rely on predefined assumptions for determining a limit for cut-off grades. Instead, it uses mathematical optimization based on discounted cash flow while considering various constraints such as production capacity, blending, and vertical advances. Unlike traditional methods, it is not limited by fixed pits, pushbacks, or phases; the mining sequence is an optimized result based on the input parameters. This flexibility is especially beneficial in complex cases with multiple destinations or constraints, helping to uncover hidden opportunities.
The cut-off grade is the concentration of a mineral or metal required to classify material as either ore or waste. Material with a concentration above the cut-off is classifed as ore, while anything below is classified as waste.
Different from MiningMath, other software packages usually make manual assumptions to pre-define a cut-off, and based solely on that, decide whether some material should be processed or not. That is needed, for example, before running LG or Pseudoflow algorithms. However, this simplified approach doesn’t account for other required mine scheduling constraints. Moreover, even the best algorithms commercially available for destination optimization perform this task apart from mine scheduling.
MiningMath is not constrained by cut-off grades, fixed pits, or pushbacks. It’s the only software available that optimizes the mining sequence and the destination optimization in a single-step, all at once, considering the all constraints applied, as a truly global optimization process.
These advantages become even more apparent in more complex cases with multiple destinations or constraints that could be overlooked, hiding potentially valuable opportunities when not considered jointly.
As a result, MiningMath may reveal new possibilities, deliver more realistic results and even lead to an increase in NPV through its unique single-step optimization.
Since the algorithm does not employ cut-offs to manually assign destinations to blocks, it automatically sends the less valuable blocks to the dump, based on the constraints you’ve set. MiningMath prioritizes meeting all constraints to optimize the average grade, leading to an increase in NPV through global optimization. Hence, even blocks with positive economic value may be discarded if their value is below the minimum required for processing at a given time. In scenarios without stockpiling policies, blocks with higher positive value may also be sent to waste, as there’s no alternative destination. As a result, MiningMath may deliver outcomes different from your initial expectations. However, for comparative purposes you can adjust the results as needed using the methods suggested below.
With MiningMath’s single-step, optimization engine, you can uncover opportunities that manual or stepwise planning might miss. Ultimately, its engine is able to optimize resource utilization and can improve project outcomes. Transform your mine planning process by leveraging MiningMath’s advantages and take your mining projects to new heights of efficiency and success.
Forcing a cut-off grade on MiningMath will likely make you lose part of the advantages it can offer. However, for many reasons, mining professionals might still be willing to force it, either to compare different methodologies, to understand the practical effects of using it or not, and so on. Different approaches are available to force a cut-off grade, which are described next. Note that these could also be employed to forbid any material type on the plant.
Predefining destinations before any optimization is performed is also a possibility within MiningMath when importing a block model.
A detailed guide on how to use this parameter can be seen here.
You can create multiple columns of economic values, each one for a cut-off you want to test. Then, force MiningMath to use this limit by defining very negative values for the destination you want to avoid, as depicted below, for a cut-off of 0.5. The math is:
Economic Value Process = If [Ore_Grade] > [0.5], then [f(Economic Value)], else [-999,999,999.00]
Grades in MiningMath are controlled as a minimum and/or maximum average calculation, which means that these limits do not represent cut-off values since the algorithm can use lower values to blend higher ones. Thus, to use this approach, just set a very negative value on the grades below the cut-off so that these blocks would reduce substantially the average when processed. It can also work to constraint a contaminant maximum limit by adding a high grade on it, as it can be seen below. Once again, the math is:
Ore_Grade1 = If [Ore_Grade] < [0.5], then [-999,999,999.00], else [Ore_Grade]
Another option is by using the sum tab to control material types. Therefore, it would be required to create a field to calculate only waste blocks mass and set the constraint of the maximum limit of it in the plant as zero, as it can be seen below. It is worth mentioning that this approach could increase the complexity of the optimization due to the priority order within the algorithm.
Tonnage_Waste = If [Ore_Grade] < [0.5], then [Volume*density], else [0]
The mined blocks file (example below) is the main output to trace the blocks from each destination, to understand the results, and to find the best way to enhance your reporting based on any detail that you wish to disclose.
There are many useful tips to identify, and understand the results generated, some of them, are listed below:
Filter results where the period mined is equal to the period processed (blocks processed). Check the process economic values of those blocks and identify the lower one (which means the cut-off value at the plant). This can be compared with higher processing economic value of those who went to the dump.
Calculate the average grade of any material in period mined equal to the period processed filter. Check if the blocks going to dump would have exceeded any limit in the plant. If so, even having good economic values, they would not comprise the constraints in place.
To sum up, there are a lot of validations that can be done to understand why the algorithm is taking such decisions. It is also worth mentioning that any constraint can influence the results, even geometric ones, which could change the sequence and also change the destination of a block at any period.
MiningMath enables the generation of pushbacks, schedules, and constrained surfaces in a single run, using a direct block-scheduling engine that avoids the need for iterative, stepwise planning. Outputs can be exported to traditional mine-design tools, supporting smooth integration across workflows. With scripting and API capabilities, teams can automate scenario testing and quickly update models, improving collaboration and reducing time between strategic planning and operational execution.
MiningMath doesn’t necessarily compete against mine scheduling optimization packages. The only concept we and all research centers worldwide recommend mining companies to overcome is the one related to Pit Optimization, due to the set of problems you have to face when dealing with such technology.
Therefore, even our simplest version has more features to generate nested pits with better control so that you could design better pushbacks and define a mine schedule using your preferred tool. The reason why this software can deliver such results is the Direct Block Scheduling methodology based on Mixed Integer Linear Programming (MILP) model and proprietary heuristics. Check other technical details and related research in our theory section.
MiningMath also allows you to generate optimized pushbacks, which could facilitate your design process and guide your mine schedule while using other software packages. Notice that our tool is an optimizer that simply breaks the whole deposit (your block model) into smaller pieces, aiming for maximum Net Present Value, but respecting as many constraints as you wish:
A usual application of our technology is basically on strategy optimization for building decision trees. Once we run dozens/hundreds of scenarios of the yearly schedule optimization and fine-tune their parameters/constraints, our users take some of the resulting surfaces of MiningMath and use them to design some pushbacks so that they could integrate with other packages, such as MSSO, COMET, etc. This procedure could be accelerated/simplified by working with packages of years and finding shapes closer to pushbacks you’re used to.
The outputs of our software will serve basically as optimized pushbacks, searching for maximum NPV and controlling whatever variable you consider necessary. Once we manage to import MiningMath surfaces into the other package, they will serve as guidance and they should assist the other package in finding higher NPVs. Most of these packages also allow us to predefine the blocks’ destination, if we wish to use MiningMath optimized cutoff policy. Finally, the package should have “only” the duty to do the bench scheduling, according to your short-term operational/tactical needs.
Even if you decide, for any internal reason, that you have to use LG/Pseudoflow to define final pit limits, there is no problem at all. MiningMath is the only tool available in the market capable of performing complete strategic analysis by building decision trees unconstrained by predefined pushbacks. Please, check this short example (in Spanish) with dozens of scenarios just for the decision on CAPEX regarding processing capacities. Check also the second half of this video for a broader view on how to use the same concept to take strategic decisions on many other aspects related to mine projects or ongoing operations. I assure your managers will get much more interested in your reports once you start adding this sort of strategic analysis. Notice you could perform this sort of analysis either free of constraints or respecting any pre-existing (designed) ultimate pit or pushbacks.
Going one step beyond, we also have clients improving their adherence and reconciliation between long and short-term mine plans by using MiningMath as a complementary tool. Notice that, by using MiningMath in strategic mine planning, you could add more constraints from real-life operations, even if you decide just to check your current long-term plans. Also, notice you could place some surface limits, such as the designed surface of the next five years plan for example, and give some controlled freedom to short-term planners to rerun their mine plans, including more operational details, as long as they don’t change anything from period 6 on and they don’t affect the NPV negatively. Whenever they find an issue or an opportunity, short and long term teams have a way to collaborate and generate new joint configurations that account for all the strategic and tactical needs of the project simultaneously. All the remaining details, such as the designs, could be adjusted using the current mining packages available.
If you wish to skip such steps and go straight to your final designed plans, we can guide you through this process, which includes a loop of running MiningMath and designing surfaces, until reaching a reasonable and operational sequence. This is a much more innovative procedure, which tends to achieve higher NPVs.
In open-pit mine planning, working directly with coordinate systems often leads to errors and inefficiencies — especially when integrating multiple data sources or refining constraints. This page explains how converting coordinates to indices within MiningMath helps streamline model setup and scenario adjustments.
The indices of each block represent its position in the model, indicating in which column, line, and level (IX, IY, and IZ) it is.
The indices must be integer values, starting with any value (for Marvin model, it was adopted the indices 1,1,1 for the first block).
The model’s origin must be placed at the bottom portion, starting to count from the minimum coordinates at X, Y, and Z.
Figure 1 highlights the origin of the Marvin block model and the first block index coordinates (1,1,1).
Figure 1: Block’s Matrix.
However, if the block model contains geo-referenced information based on coordinates, they could be converted into indices before being imported to MiningMath.
To perform this conversion, check the following demonstration on how to convert coordinates into indices using data from Figure 2 and the equation from Figure 3.
Figure 2: Sample data to convert coordinates into indices.
Figure 3 exemplifies using the X-axis but the process is the same for Y and Z axes by just using the corresponding information.
Figure 3: Equation to convert coordinates into indexes.
Click here to download a spreadsheet to convert the coordinates into indices and calculate the economic values.
Figure 4: Resultant coordinates converted to indexes.
The video below exemplifies the conversion process in case you have any doubts.
Video 1: How to convert block coordinates into block indices.
Dilution and recovery directly affect profitability. MiningMath lets you define these at the block level, integrates them into optimization, and supports quick scenario testing—improving accuracy, reducing manual work, and enabling faster, data-driven decisions in open-pit planning.
This is an informal video on how to consider dilution and mining recovery.
Video 1: Dilution and Mining Recovery.
READ MORE
Keeping an untouched version of your original dataset helps isolate errors, validate outputs, and compare changes across scenarios. It’s a simple step that supports faster troubleshooting and more reliable use of MiningMath’s optimization capabilities.
A common question while using MiningMath integrated with other mining packages is: How to keep the data from one to another?
In order to facilitate this format exchange, you can keep any field from the other software and import it as a Other parameter. By following this approach MininingMath will keep the data in the reports and MinedBlocks.csv generated after the optimization. Thus, you will able to import it on your mining package by following the same parameters as to when it was exported.
This approach is quite useful when we have to keep the original coordinates X, Y, and Z or any other data that would help to identify the blocks in the platform which it came from.
Keeping an untouched version of your original dataset helps isolate errors, validate outputs, and compare changes across scenarios. It’s a simple step that supports faster troubleshooting and more reliable use of MiningMath’s optimization capabilities.
In MiningMath, fixed operational costs such as infrastructure or maintenance can be embedded directly into the optimization process using binary logic linked to designated blocks. This ensures that costs are triggered only when relevant regions are mined, eliminating manual adjustments and enabling simultaneous evaluation of economic feasibility. The approach supports scalable scenario testing and integrates smoothly with API workflows, making it suitable for both strategic planning and fast iteration across multiple configurations.
Fixed costs are expenses that do not vary with production or mining volume, such as equipment maintenance, infrastructure, and fixed labor costs. They are fundamental to the economic viability of the operation, ensuring the financial sustainability of the mine regardless of production variations.
In MiningMath, fixed costs can be directly incorporated into the mining model, ensuring they are considered in decision-making processes.
MiningMath also allows for pit optimization, aiming to maximize undiscounted cash flow while considering fixed costs and all desired constraints. This enables an economic feasibility assessment of specific regions throughout the project’s lifespan. To do this, binary decision field must be used, which require additional configurations in the block model and the pit optimization scenario.
This methodology is an experimental approach, and MiningMath wasn’t specifically built for this use case. Unforeseen results might arise. If you experience any issues or inconsistencies, we suggest contacting our support team for help.
Create a block just above the defined topography, avoiding the model’s edges. Alternatively, select an existing block at the topography level; in this case, its related field values must be considered in the analysis of the results.
To prevent interference with scenario constraints, this block should have:
Very low density;
A slope of 89.9999;
Null values for any additional constraints imposed in the scenario.
The block should also contain the fixed cost value for all economic value fields.
Create a new field in the block model for binary decision-making. This field should:
Have a negative value equal to the number of blocks in the region or an even smaller value for the special block.
Have a value of 1 for all blocks in the region with fixed operational costs.
Have a value of 0 for all other blocks that do not belong to the region.
Perform the standard block model import. During the field type definition, set the created decision field as SUM.
After importing, visualize the block model using the software’s viewer. Check that the values assigned to the binary decision field are correct and properly distributed as expected.
Create a pit optimization scenario where the pit’s lifespan is limited to a defined period. Additionally, include all project constraints for the mine’s entire lifespan. To streamline the optimization process, it is recommended to avoid geometric constraints, as this will help reduce complexity.
In the sums tab, set the maximum value to 0 for the special field created.
Run the scenario and validate the obtained results.
With this configuration, whenever any block in the region is mined, the special block containing the fixed cost must also be mined. This ensures compliance with the restriction and guarantees that the fixed cost is properly included in the mining scenario.
This process should be repeated for each different fixed cost and region that needs to be included in the model to ensure proper cost allocation across the entire mining plan.
This approach enables a more effective and realistic modeling of fixed costs within mining planning. MiningMath’s flexibility allows users to evolve their modeling over time, expanding to more sophisticated scenarios and ensuring better operational results.
This methodology can also serve as a first step toward a more complete transition to a fully optimized environment, reducing dependence on manual solutions and increasing the reliability of internal reports.
Furthermore, in the long term, MiningMath can be integrated into short- and medium-term planning, providing a continuous optimization process that may eventually replace the use of other tools.
MiningMath allows engineers to set geometric connectivity between blocks, aligning plans with equipment reach and operational logic. This ensures realistic schedules without fragmenting the optimization process.
A block-by-block schedule is likely very difficult to achieve in operations – example: operations does not allow using multiple types of equipment on the same bench. How to cope with it?
Although MiningMath works with blocks as inputs, the level of connectivity is user-defined by playing with geometrical parameters in the interface.
The following image shows results for the Marvin deposit when changing the Minimum Widths (filtered view after Period 2).
Note everything changes when playing with a single parameter, including the Life of Mine and geometries. Such impacts are also possible when playing with economic aspects, slope angles, environmental and boundary constraints, fleet size, processing setups, blending requirements, etc.
Watch the following video on how to play with operational constraints to achieve results closer to the reality of any project.
Video 1: Operational Constraints.
Mining operations benefit when optimization isn’t overloaded with constraints. This approach helps expose the mine’s true economic potential.
The relationship between the number of constraints and Net Present Value (NPV) is generally inversely proportional. Scenarios with fewer constraints enable the optimization algorithm to search more freely, often leading to higher NPV results. It is therefore recommended to first explore the full potential of a mining project, starting with the Data Validation procedure, followed by the other possible Workflows that can inform further steps.
To better understand the effects of constraints, the MiningMath team conducted 2,000 simulations as depicted below.
The study examined the impact of both individual constraints and their combined effects.
Individual Variation
Initial simulations tested the effect of varying individual constraints such as Copper Selling Price, Mining Widths, and Vertical Rate of Advance. These parameters were adjusted individually to understand their tendencies. The results showed that most individual variations had a high probability of generating NPVs around $900M.
Combined Scenarios
The next phase involved running "overall" scenarios, where all 11 variables were assigned random values simultaneously. In these cases, the constraints collectively reduced the NPV potential, with a higher likelihood of NPVs around $200M.
The findings of the above study highlight a key principle: increasing constraints tends to decrease the likelihood of achieving higher NPVs. Users are encouraged to explore constraints to strike a balance between freedom for the algorithm and guidance to achieve practical results. Some strategies for that are given throughout the page.
MiningMath employs mathematical programming to maximize NPV while respecting imposed constraints.
Advanced users can take advantage of this capability by strategically placing constraints that guide the optimizer toward better solutions.
For example, starting with unrestricted total movement/production allows for better waste distribution over time. Subsequently, applying production limits (e.g., 100 Mtpa, 90 Mtpa) helps assess tendencies by creating a curve of scenarios against NPV.
The ideal approach begins with minimal constraints and gradually introduces reasonable ones. By doing so, the algorithm focuses on a narrower solution space, potentially yielding higher NPVs.
Start with minimal constraints and avoid adding complex geometries.
Gradually introduce constraints one by one to observe their impact on NPV.
Use an Workflow to assess how each assumption influences long-term project outcomes.
Measure the "cost" of each constraint to guide managerial decisions.
Relax constraints when possible: For instance, temporarily flex slope angles to improve designs.
Use hints to guide the algorithm: Relax low-priority constraints or simplify complex scenarios into smaller problems.
Iterate gradually: Optimize from the least-constrained to the most-constrained scenarios.
Nonlinear optimization problems often present challenges due to the presence of local maxima, where the algorithm may become “stuck,” preventing it from finding the global maxima.
One effective strategy to mitigate this issue is to introduce slight modifications to the parameters. These adjustments should be small enough that they do not significantly alter the practical outcome but are sufficient to change the mathematical structure of the problem.
Some examples (not exhaustive) of constraints that could be shaked-up are:
This “Shake-up” approach encourages the algorithm to explore alternative paths in the solution space, potentially bypassing local maxima and improving the chances of identifying better solutions.
Understanding the nuances of constraints is critical. Constraints may be relaxed to achieve feasible outcomes but should not be violated in ways that render the project unfeasible.
Examples of constraints that could be relaxed:
Examples of violated constraints
Reports detailing these nuances are available in the Excel output’s Report Tab for review.
Introduce guidance gradually: Add constraints thoughtfully to guide the algorithm toward realistic results.
Leverage hierarchy: Use the hierarchy order to prioritize and relax constraints strategically.
Iterative problem-solving: Break down complex scenarios and iterate over multiple runs to assess tendencies.
Controlling optimization runtime is crucial to align results with operational deadlines and computing resources.
RunTimeLimit) that guides how long the system will iterate toward better solutions.The optimization run time is a common concern for professionals dealing with robust models. This page aims to provide context and guidance to improve run times, which might be quite useful for having a big picture of the project’s behavior under different assumptions and hypotheses.
The runtime depends on a combination of multiple aspects. It is directly related to the complexity of the deposit and it is proportional to the number of:
Often, users are concerned with the limits to handle models with +20M blocks. MiningMath can virtually handle any model size. It has successfully made tests with models up to 240M blocks without reblocking, which took three weeks to run, and over a 32 Gb desktop machine.
Typically, datasets with 5 million blocks take a few hours (in an 8GB RAM machine). In the future, the technology will be capable of concurrently running multiple scenarios on the same computer. There is no need for special servers with extra RAM capabilities for deposits of average size.
Overall, the main bottleneck for MininingMath is memory consumption. Hardware upgrades that most positively impact the optimization run time are:
MiningMath is a single-thread application, which means:
MiningMath utilizes the linear programming solver provided by CLP to implement the Simplex algorithm. Each execution of CLP utilizes one core/nucleus/processor because Simplex is not easily parallelizable (meaning it can’t run faster by using multiple processors). As far as our studies have shown, there hasn’t been a market solution for this, and scientific research hasn’t yielded very satisfactory results yet.
The most recommended strategy is passing through the tutorial steps of validating data and constraints validations then starting using the surfaces as a guide to reduce the complexity, without losing dilution aspects on your approach.
To get such guidance on a broader view with a reduced runtime you can for example create optimized pushbacks. The last step is to get a detailed Schedule since the model has such complexity. If such approaches do not offer a proper runtime, try to get intermediate results by splitting the total production into 2 or 3 periods.
Reblocking is a method used to decrease the number of blocks in a block model by combining some of the smaller blocks to create larger ones. This can be done using MM Labs as described here.
Note: when reblocking your model it is important to evaluate dilution aspects that can be lost by increasing the block size.
It is possible to indicate a time limit in hours before running a scenario. The time limit is defined in hours due to the usual complexity of mining projects and by the fact that MiningMath will always try to deliver a reasonable solution.
This is a complex parameter that may not always be feasible to adhere to. It could also hinder the final solution, since it is restricting the algorithm from exploring a broader range of potential solutions. However, even if better results are not obtained, fast solutions will still give you a quicker assessment of your project. To better understand how the time limit works, you can visit this page.
Another strategy to reduce runtime might be the use of timeframes. MiningMath allows the integration between the short and long term visions in the same optimization process, facilitating the analysis and strategic definitions.
For example, it is possible to consider less detail for longer time horizons. Such horizons need to be considered in the overall view of the mine, up to exhaustion, but they consume optimization processing time that can be more focused on the early years of operation. The figure below depicts an example with monthly time frames in the initial periods of the project, transitioning to yearly periods, and extending to decennial periods in the final stages. You can visit this page for more information on how to use timeframes.
Streamlining repetitive tasks helps reduce errors and speeds up scenario testing.
The following video comprises some tips and tricks to optimize your workflow when running multiple scenarios. The options comprise:
Altering multiple scenarios through the SSSCN files, which are XML files that could be parsed using scripts created by the user, then running scenarios through the interface.
Running scenarios from the command prompt, without recurring to the User Interface.
Video 1: Optimizing your workflow.
Representing mixed-material blocks accurately is essential for reliable planning in complex geological settings. Percent models enable a more nuanced understanding of ore-waste distribution.
MiningMath does not yet natively support percent models, but this feature is on our development roadmap. If you’d like to see this functionality prioritized, we encourage you to reach out to our support team.
In the meantime, you can use the formatting options below to prepare your percent model for use with MiningMath.
A percent model divides the mineral deposit into blocks while accounting for irregularities in the deposit’s shape. Instead of assuming each block is entirely filled with material, the percent model indicates the proportion of each block that actually contains valuable material.
Although this is not a mandatory step for the optimization process, the lithology can be defined considering:
For example, consider the information of a block as depicted below:
PM, if considering the greatest parcel in terms of value.
[block size × density]. The average density of a block should be the weighted average, based on the lithologies present and their respective percentages.Recoveries should also be calculated based on the amount of material recovered from each parcel of the block.
The economic value is calculated considering the amount of material recovered from each parcel, along with their respective revenues and costs.
The economic value of a block can be calculated both with and without dilution:
Without dilution (Option 1): Only ore parcels feed the plant
In this case, the economic value for the process will consist of Revenue - Costs, where:
• Revenue refers to the ore parcel (70%).
• Processing Costs refer to the ore parcel (70%).
• Mining Costs refer to the entire block (100%).
Since MiningMath processes the entire block, input a higher value for the process limit, assuming the algorithm will feed the plant with the remaining parcel of waste (30%).
1) Create Auxiliary Columns: Track and control the tonnage limits of ore, waste, and any specific lithotype you want to monitor (as shown below).
2) Set Auxiliary Columns as "Other": During the import process, mark these auxiliary columns as "Other." This allows you to track and control the tonnages of each material.
3) Adjust Production Charts: Ignore the default production charts and instead use the tonnage charts set as "Other Constraints."
With dilution (Option 2): The entire block feeds the plant.
In this case, the economic value for the process will consist of Revenue - Costs, where:
• Revenue refers to the ore parcel (70%).
• Processing Costs refer to the entire block (100%).
• Mining Costs refer to the entire block (100%).
Since there is dilution, the processing limit input in the interface should reflect the actual plant limit.
1) Create Auxiliary Columns: Use auxiliary columns to provide further control of the tonnages for each parcel, ensuring accurate tracking.
2) Adjust Processing Limit: Input the real plant limit in the processing limit field to account for dilution.
By using these adjustments, you can accurately model the economic value of blocks with dilution.
The figure below depicts an example of calculations for a block composed of different lithotypes and its respective economic values assuming no dilution and diluted material (download the spreadsheet here).
Block models define how geological and economic data are spatially represented, directly impacting planning outcomes.
The most common block model types used to define and manage the spatial distribution of geological and economic data are Regular, Percent, Subblocked, Reblocked, and GSM (Gridded Seam Model). Below is a brief overview and comparison of each type.
Regular Block Model: The deposit is divided into uniform blocks of fixed size in three dimensions (X, Y, Z).
This is the type natively supported by MiningMath. Formatting instructions can be seen here. Rotation of regular block models is also supported as described here.
Percent Block Model: Extends the regular model by incorporating percentage values to represent how much of a block contains a specific material or belongs to a given domain.
This is not natively supported. However, instructions on how to format this model with and without dilution are provided here.
Reblocked Block Model: It is created by merging smaller blocks (often from a subblocked model) into larger ones to simplify calculations or meet specific optimization constraints.
MiningMath provides an app in its MM Labs section that is able to reblock your block model. Further instructions can be seen here.
Subblocked Block Model: Refines regular blocks by dividing them into smaller sub-blocks where needed, typically along geological boundaries or to represent irregular shapes more precisely. It can give a higher detailed representation of geological features, but can also lead to large file sizes, higher computational demands, and higher complexity to prepare and manage.
This is not supported by MiningMath.
GSM (Gridded Seam Model): This is used for stratified deposits, like coal or other layered materials. It divides the deposit into horizontal layers (seams) and models variations within each layer. However, it is less flexible for deposits with significant vertical or irregular variations.
This is not supported by MiningMath.
These models offer flexibility in balancing accuracy in deposit representation with complexity in computational effort required for optimization.
The table below highlights the trade-offs between accuracy and complexity, using the regular block model as a reference point. It also summaries the block model types supported by MiningMath.
| Model type | Best for | Complexity (lower is better) | Accuracy (higher is better) | Support |
|---|---|---|---|---|
Regular | Deposits with uniform geometry | Standard | Standard | |
Percent | Deposits with irregular ore/waste distribution | Higher | Higher | |
Reblocked | Simplified optimization or large-scale production planning | Lower | Lower | |
Subblocked | Detailed geological models with sharp boundaries | Higher | Higher | |
GSM | Layered, stratified deposits with predictable structures | Higher | Higher (for stratified deposits) |
Fake destinations allow adjustments to recovery, cost, or value assumptions over time without changing the mining sequence. This avoids rework and supports faster scenario testing.
Fake destinations serve as a workaround to account for variations over time in recovery rates, ore prices, costs, or even combinations of these economic factors. Additionally, they can be used to manually segregate materials of varying qualities into different stockpiles, providing greater control over resource management. There are two possibilities when considering fake destinations as detailed below.
In this setup the real Plant throughput is 15 Mt/year, with two fake plants:
Figure below depicts the setup in the interface.
Setup as depicted below.
In the case of defining scenarios of price fluctuation, different ore prices for the same material should not coexist. Thus, each plant will use a specific function but will represent the same one in reality.
In the following example, columns CU_1 and CU_1.2 represent the economic values considering the default price for copper and an increase of 20% in this default price.
The main point here is the fact that these circumstances cannot coexist. On the Production tab, add and define Period Ranges in which each function will exist. Then, when Process 1 (CU_1) is active, use the proper production limit for it. For the other(s), define a production of zero in the same period.
Repeat this logic for any other period range you need. The image below gives a clear example of it.
Manually separating blocks of different qualities is explained in this page due to its particularities.
MiningMath accepts imperial unit models but doesn’t convert units automatically. To ensure consistency, users must manually adjust all economic inputs and block values before import, typically by converting to metric using external tools or preprocessing scripts before loading into the platform.
For importing databases, MiningMath uses the metric system exclusively. In case your database is in the imperial system, it should be modified to a counterpart in the metric system. This page provides a script and further instructions for you to do this conversion successfully.
For this process, python and pandas packages are required (see installation guidelines below). In case you find any issues using the script, or if you make any modifications to it that could be useful for the community as a whole, please share your discoveries at our Forum.
python scripts, just copy or download this simple python script and run it in your machine. Otherwise, keep scrolling for further instructions.
import pandas
# define conversion consts
# foot to metter const
ft_to_m = 0.3048
# short tonne to metric tonne const
st_to_t = 0.907184
# ounce to gram const
oz_to_g = 28.34952
# import imperial model
imperial_model = pandas.read_csv("imperial_model.csv")
# create metric model
metric_model = pandas.DataFrame(columns=['X', 'Y', 'Z'])
# set coordinates to metric model (foot to meter)
metric_model['X'] = imperial_model['X'] * ft_to_m
metric_model['Y'] = imperial_model['Y'] * ft_to_m
metric_model['Z'] = imperial_model['Z'] * ft_to_m
# set dimension to metric model (foot to meter)
metric_model['!DIM_X'] = imperial_model['DIM_X'] * ft_to_m
metric_model['!DIM_Y'] = imperial_model['DIM_Y'] * ft_to_m
metric_model['!DIM_Z'] = imperial_model['DIM_Z'] * ft_to_m
# set mass to metric model (short tonne to metric tonne)
metric_model['!MASS'] = imperial_model['MASS'] * st_to_t
# set volume to metric model (cubic metter)
metric_model['!VOLUME'] = metric_model['!DIM_X'] * metric_model['!DIM_Y'] * metric_model['!DIM_Z']
# set density to metric model (metric tonne per cubic metter)
metric_model['%DENSITY'] = metric_model['!MASS'] / metric_model['!VOLUME']
# set grades to metric model (ounces per short tonne to grams per metric tonne or ppm)
metric_model['@GRADE_AU'] = imperial_model['GRADE_AU'] * oz_to_g / st_to_t
metric_model['@GRADE_CU'] = imperial_model['GRADE_CU'] * oz_to_g / st_to_t
# set recovery values to metric model
metric_model['*REC_AU'] = imperial_model['REC_AU']
metric_model['*REC_CU'] = imperial_model['REC_CU']
# set economic values to metric model
metric_model['$PROCESS'] = imperial_model['PROCESS']
metric_model['$WASTE'] = imperial_model['WASTE']
# export metric model to csv
metric_model.to_csv("metric_model.csv", index = False)
Download Python's lastest version at https://www.python.org/downloads/.
Once the download is complete, open the .exe and follow the instructions for a default installation. Make sure to select "Add Python to Path" before proceeding, as depicted below.
At this point, the installation should be concluded. You can check if Python has been correctly installed by running the command python --version at Windows PowerShell.
Pandas is an open source data analysis and manipulation tool, built on top of Python. Follow the steps below to install it:
Open the Windows PowerShell and run the command "pip install pandas".
Once the installation is complete, you're able to run Pandas inside your Python programs. You can check if Pandas has been correctly installed by running the command "pip show pandas" at Windows PowerShell.
This script can be used to convert foot to meter; short tonne to metric tonne; and ounce to gram.
It works with the columns: X, Y, Z, DIM_X, DIM_Y, DIM_Z, MASS, VOLUME, DENSITY, GRADE_AU, GRADE_CU, REC_AU, REC_CU, PROCESS, WASTE.
Follow the steps below:
Save your database in a file named imperial_model.csv, at the same folder where your script is located.
Run the command python imperial.py at the Windows PowerShell from the folder where the script is located. The example below shows the script in the Downloads folder.
Open the output file named metric_model.csv, and that's it! Your data has been converted to the metric system.
John is a mine planning engineer working on Marvin deposit. He’s conducting the long-term production scheduling plan and is concerned on what would be the best scenario to optimize Marvin’s operations.
The mine has some constraints, such as slope angles defined block-by-block and a default value of 45 degrees for blocks missing information. The total movement is limited to 60 Mt/yr.
Format, economic values, and import this Marvin data. Save it as MMCI_YourName_Marvin.
Choose your own economic parameters and fill the Table 1b to simulate a process B.
Remember that if you used spreadsheet software to remove the Air Blocks, you might need to join all data in a unique column. A great tip on this is to join the columns by using &","&:
=X&",&Y&",&Z&",&Cu&",&Au&",&Density,Slope
Use the following steps to evaluate your project:
Now that you know MiningMath is able to easily run multiple scenarios, you should play with the remaining parameters, evaluate the results and bring a proposal for the board. You should:
Download Screencast O-Matic or equivalent screen recording software.
Prepare a presentation (ppt or docx), which could be structured by answering the following questions:
a) What is the goal of your evaluation?
b) How did you use MiningMath to achieve your goal? Which were the features used? What was the methodology used to get to your results
c) Why have you got such results?
Record it as if you were reporting your analysis to the board. Upload it on YouTube as public. The video should be limited to 5 minutes.
Send the link, materials, and the Marvin data used to your teacher.
What are the main resources of MiningMath viewer and which are the output files?
Could market changes be considered based on different ore selling prices throughout time? If yes, how?
Is it possible to forbid the optimization to access some specific region? If yes, which feature could be used?
Which geometric features could be used to get results accordingly with the operational needs?
What are the benefits of building decision trees?
What are the main differences between Lerchs-Grossmann/Pseudoflow and DBS methodologies?
What is the importance of considering a discounted cash flow on the optimization decision-making process? Does the value of money through time impact the mining sequence?
Could the optimization handle multiple destinations? Over 2 processing plants? One stockpile for each with maximum capacity?
Could production ramp-ups be part of the optimization constraints?
Is it possible to control the average of a given variable, such as grade, haulage distance and etc.? How many properties can be controlled? Is it possible to change them over the mine's life?
How does the cut-off grade policy work on MiningMath?
What are the main validations before running a scenario?
Can MiningMath run more than one scenario simultaneously?
Which are the 3 main suggestions of the integrated workflow?
Is it possible to generate a short term planning using MiningMath?
November 22, 2019.
“Mining is a business. This may sound obvious. But when one tries to look at how we operate that becomes much less evident. Are we really looking at what would be important for any business? I’ve had this discussions throughout my career in mining and I must say in many cases technical people, i.e. geologists, mining engineers, processing engineers – those who run the mines – do not look at business metrics. At all!!! Let’s look at a miner. “Let’s move tonnes and increase equipment utilization”, one would say! This person will see the efficiency improvements in higher utilization. Does it help increase shareholder returns? No, not really. It has nothing to do with it.”
Alexey Tsoy, LinkedIn Article
March 21, 2019
“The last two tragedies that desolated Brazil, leaving hundreds of deaths and miles of environmental devastation, from Brumadinho and Mariana, raised a great question: it is possible to reduce the risks of tailing dams and to guarantee everyone’s safety in an efficient and economically viable way?
MiningMath, startup from Belo Horizonte, says yes. The company has created a software, SimSched, which, through the union of modern programming, and data science, allows the combination of any variables from a mining project to generate analysis, hypothesis and possible results. The objective is to contribute to improve the decision-making processes in the mining companies, in order to effectively consider the economic, social and environmental aspects of the business.”
March 18, 2019
“Five Startups of the Minas Gerais Government Accelerator (SEED – Startups and Entrepreneurship Ecosystem Development) from several segments, with solutions for business areas, visited last Tuesday (March 12th) the Mining Hub in Belo Horizonte (MG), to strengthen the relationship and exchange experiences on the market.
Among the startups were: MiningMath, which markets a solution that supports decision making at a strategic level specific to the mining industry, from designing a project to optimizing the value chain during the development phases; Recrutamento Inteligente (“Intelligent Recruitment”), which facilitates the management of intellectual capital; The Mindset, which acts in the management of mental health professionals; Cargo Sapiens, which offers management and compliance solution for international logistics; VG Resíduos, which connects producers and consumers of waste.”
December, 2018
“MiningMath has developed mine data management software that promises to reduce costs and anticipate the environmental consequences of mining. The tool crosses and organizes data from different departments of a mining company to generate scenarios with the possible geological, environmental, economic and social impacts of an action in a given location.”
From left to right: the engineer Matheus Ulhoa and the partners of MiningMath, Fabrício Ceolin and Alexandre Marinho (MiningMath).
November 6, 2018
“With the advent of industry 4.0, traditional and grassroots activities such as mining start to gain new ground in Brazil and the world. The use of innovative technologies such as data science, internet of things and optimization of processes breathe new life into the industry, promoting added value gain to the minerals extracted in the country, such as iron ore, whose largest production is concentrated in Minas Gerais.
Proof of this is that mining startup MiningMath recently won first place at the MineTech Mining Solutions Technical Challenges Challenge with an innovative technology to simulate scenarios to support strategic mining decisions using modern techniques of programming.”
Event in the Capital discussed a more sustainable performance, besides the optimization of processes and improvements in the performance of the sector (Vale Agency).
October 25, 2018
“The software combines variables ranging from geological aspects to economic data and legal, environmental and social constraints.
An innovative technology designed to simulate scenarios to support strategic decisions in the mining field, developed by former students of UFMG, Alexandre Marinho and Fabrício Ceolin, won the first place in the MineTech: Technical Challenges and Mining Solutions Challenge in early October , held in Moscow during the 14th Russia Exploration and Mining Forum.”
UFMG · Mining.com · Hoje em Dia · SIMI · Notícias de Mineração · FUNDEP
Fabrício Ceolin (left) and Alexandre Marinho (right) are the founders of the MiningMath startup (Personal Files).
October 16, 2018
CSA Global Principal Consultant-Corporate, Alexey Tsoy will present at the upcoming MiningMath Creating Value in Mining; Strategy Optimisation through Data Science Conference on November 6 2018 at the Museum of Mines and Metals in Belo Horizonte, Brazil.
Alexey will present on Strategic Schedule Optimisation.
October 16, 2018
Alexey Tsoy, Principal Consultant – Corporate and Business Development at CSA Global, is the winner of the 2018 MineTech Competition: 2nd Mining Technical Challenges and Solutions Competition’s at the 14th Russian Mining and Exploration Forum held between 2-4 October in Moscow, Russia.
“Alexey presented on Strategic Schedule Optimisation; forming part of this year’s MINEX conference ‘Building Up Innovative Excellence in Mining and Exploration’ […]. The proposed approach is based on a software called SimSched Direct Block Scheduling (DBS) […]. The software applies a simplistic approach where a block model is optimized on economic values assigned to each block in pre-processing. The simplicity allows a great degree of flexibility on assigning the economic values. Moreover it allows definition of variable costs based on time, residence time, or indeed any other parameter that can be calculated and limited in time.”
“The software that could revolutionize mine planning”April 9, 2018
This publication states that the traditional planning includes the discount rate, production limits, blending and other technique-economical variables during advanced stages of planning and SimSched brings the possibility to reduce the number of iterations for planning.
“A unique and flexible tool for planning, which currently doesn’t exist in the industry. ” — Fabián Lemus, Senior Long-term Mine Planning Engineer.
The Scheduling The Sequences (STS) project, conducted by Antofagasta Minerals, includes a co-development of SimSched DBS, where major tests will focus on Minera Centinela, a multi-pit project with multiple processing streams that might benefit from an integrated plan. This will provide flexibility to analyze and evaluate development scenarios and the inclusion of new projects.
How digital innovation can improve mining productivityWith profits down, miners are focused on improving their productivity. Digital innovation could provide a breakthrough.
Read more.
Digital Transformation—The future of MiningIn a challenging market, the digital transformation of mining companies has become a business imperative—leveraging technology to improve processes aligned to value.
Read more.
A tool for these timesConsidering the current resurgence in commodity prices, every mining company should concentrate on strategy optimization to ensure that operations move from a cost-focused mindset to one centred on value maximization in order to reap the benefits of the upturn in the mining industry.
Read more.
SimSched Direct Block Scheduler (DBS) is an open pit optimization package that selects maximum NPV pit shell while generating a mining schedule. Read more.
In the mining the change in technology, i.e., processes and software, does not happen fast but it takes its time, around 10 to 15 years as miners are very. (LinkedIn article)
Mine Optimizations and SimSched DBS is a friend of yours now. SimSched DBS is the most powerful tool to achieve and compare NPV results of the pit. Read more.Publications
2018 Sensitivity Analysis applied to operational parameters, IFG, Brazil (Portuguese)
2017 NPV Analysis as a function of the discount rate and cost of rehandling implementing SimSched DBS to open pit mining, Universidad Nacional de Colombia, Colombia (Spanish)
2017 Universidad de San Luis, Argentina (Spanish)
Source: What is Direct Block Scheduling?
During decades, the mining industry has dealt with Mine Planning as a step-by-step process. This traditional technology has been established in an intelligent manner in face of the technological limitations of that time.
Source: Lerchs-Grossmann, rest in peace.
We’d like to share the news that the main limitations of open pit mine plan and design based on Lerchs-Grossmann have been surpassed by a novel and innovative technology.
The concept of Pit Optimization is becoming obsolete. Here we bring a comparison showing the variety of outputs you can obtain from a single optimization.
You can check a sequence of pages to learn how to run your first project with our Getting Started training. From installation process and formatting your model files up to the long-term planning of your project.
Click HereIn order to take the maximum of MiningMath’s Optimization we recommend this flow through our Knowledge Base. It will guide you step-by-step in order to integrate multiple business’ areas and to improve your strategic analysis through risk assessments unconstrained by step-wise processes.
Quick Check: Here you’ll have all the necessary instructions to install, activate and run MiningMath.
How to run a scenario: Once everything is ready, it’s time to run your first scenario with MiningMath so you can familiarize with our technology!
Playing with pre-defined scenarios: Each change in a scenario opens a new world of possibilities, therefore, it’s time to understand a little more about and see it in practice, playing with pre-defined scenarios.
Decision Trees: Decision Trees provide you a detailed broad view of your project, allowing you to plan your mining sequence by analyzing every possibility in light of constraints applied to each scenario, which options are more viable and profitable to the global project, as well as how these factors impact the final NPV.
Current best practices: Here we go through the modern technology usually employed by other mining packages. It is important to understand these in order to comprehend MiningMath differentials.
MiningMath uniqueness: Now that you’ve practiced the basics of MiningMath, and understand how other mining packages work, it’s time to get deep into the theory behind the MiningMath technology.
Interface Overview: It’s time understand our interface overview with detailed information about every screen and constraints available in MiningMath. Home page, Model tab, Scenario tab, and Viewer for a better understanding of the possibilities.
Formatting the Block Model: Learn how to format your block model data and use it in MiningMath.
Importing the block model: Go through the importation process and to proper configure your data.
Economic Values: MiningMath does not require pre-defined destinations ruled by an arbitrary cut-off grade. Instead, the software uses an Economic Value for each possible destination and for each block. After your data is formatted and imported into MiningMath, you may build your Economic Value for each possible destination.
Data Validation: Once your data is set, it’s time to validate it by running MiningMath with a bigger production capacity than the expected reserves. Thus, you will get and analyze results faster.
Constraints Validation: Continuing the validation, start to add the first constraints related to your project so that you can understand its maximum potential.
Integrated Workflow: Each project has its own characteristics and MiningMath allows you to choose which workflow fits best in your demand and to decide which one should be used.
Super Best Case: In the search for the upside potential for the NPV of a given project, this setup explores the whole solution space without any other constraints but processing capacities, in a global multi-period optimization fully focused on maximizing the project’s discounted cash flow.
Optimized Pushbacks: Identify timeframe intervals in your project, so that you can work with group periods before getting into a detailed insight. This strategy allows you to run the scenarios faster without losing flexibility or adding dilution on the optimization, which happens when you reblock.
Optimized Schedules: Consider your real production and explore scenarios to the most value in terms of NPV.
Short-term Planning: Now that you built the knowledge about your project based on the previous steps, it is time to start the integration between long and short-term planning in MiningMath. You may also optimize the short-term along with the long-term using different timeframes.
Exporting Data: After running your scenarios, you can export all data. Results are automatically exported to CSV files to integrate with your preferred mining package.
This tutorial provides a detailed guidance to the pages in the knowledge base for new MiningMath users. A shorter tutorial can be found here with a set of must read articles. In this tutorial, a larger number of pages is contextualized and recommended for those with no previous experience using MiningMath but who wish to gain a more advanced knowledge.
Quick check: Verify if your computer has all the minimum/recommended requirements for running the software.
Put it to run: Here you’ll have all the necessary instructions to install, activate and run MiningMath.
The next step after installation is to understand the home page interface and import your project data. The following pages go over these in detail.
Home page: MiningMath automatically starts on this page. It depicts your decision trees, recent projects and model information.
Import your block model: import your csv data, name your project, set fields and validation.
Modify the block model: this window aims to help you to modify your block model accordingly with what is required for your project and also allows you to “Export” the block model to the CSV format to be used with any other software.
Calculator: calculate and create new fields by manipulating your project inside MiningMath.
If you don’t have a block model ready to be imported you might want to create a new one. The following pages can guide you through this process.
Once you have started your block model defined, there are several options to set up your project’s parameters before running a scenario.
Scenario tab: set densities, economic parameters, slope angles, stockpiles, add/remove processes and dumps, production inputs, geometric inputs and so on.
Save as: save the scenario's configuration once it has been configured.
Run: the Run tab is the last step before running your project’s optimization. Change the scenario name, set a time limit, and set up results files.
After running your scenario it is important to analyze and understand the given results.
Output files and 3D viewer: by default, MiningMath generates an Excel report summarizing the main results of the optimization. It also creates outputs of mining sequence, topography, and pit surfaces in csv format so that you can easily import them into other mining packages. The 3D viewer enables a view of your model from different angles.
Export model: export your model as a csv file. This can be used in new scenarios or imported in other mining packages.
MiningMath offers a lot of customization. You might use pre-defined scenarios to learn with standard parameters. Otherwise, the following pages of the knowledge base detail several important parameters that might need to be fine tuned in your project.
Complex projects might need advanced configurations or advanced knowledge in certain topics. The following pages cover some subjects considered advanced in our knowledge base.
In order to understand the theory behind MiningMath’s algorithm, a set of pages is provided to describe mathematical formulations, pseudo-code, and any rationale to justify the software design.
ManingMath acknowledges and supports different workflows. This knowledge base provides a set of articles aimed at showing how MiningMath can be integrated into other workflows or have its results used by different mining packages.
The only mandatory requirement for using MiningMath is a 64-bits system. Other minimum requirements are listed further:
Windows 10
64-bits system (mandatory)
110 MB of space (installation) + additional space for your projects' files.
Processor: processors above 2.4 GHz are recommended to improve your experience.
Memory: at least 8 GB of RAM is required. 16 GB of RAM or higher is recommended to improve your experience.
OpenGL 3.2 or above. Discover yours by downloading and running the procedure available here.
Visual C++ Redistributable: Installation of Visual C++ Redistributable is necessary to run this software.
Memory should be a higher priority when choosing the machine in which MiningMath will be run on. Here’s a list of priority upgrades to improve performance with large scale datasets:
Higher Ram
Higher Ram frequency
Higher processing clock
RAM is one of the most important components to consider when choosing a computer for running MiningMath, especially since Windows alone consumes a significant amount of memory.
If you experience an insufficient memory warning or a sudden crash while using MiningMath, here are some steps to improve performance:
Additional tip: in rare cases, when working with boxes, adjusting block coordinates to bring them closer together can create a smaller model box, improving performance.
Video 1: MiningMath installation process.
To activate your license, you will need to:
Open MiningMath (it will open automatically after the installation, but you can open it manually afterwards).
On the left menu, click License.
Select the field "I have an activation code" and paste the License Code provided by MiningMath.
Click "Activate license".
If you need to open an old project, just follow these steps:
Open MiningMath (it will open automatically after the installation, but you can open it manually afterwards).
On the left menu, click on Open Project.
Search for the folder in which you saved your old project.
Select the ".ssprj" file.
Click on "Open" and it will show up on the "Recent Projects"
Now you can open it!
The images below illustrate this process:
NOTE:
MiningMath’s licensing method demands an internet connection.
MiningMath allows you to learn with each scenario by providing standard parameters which simulate some common constraints that a mining company may face. Standard scenarios are listed and described below so you can identify the main changes made within the “Overview” tab.
The ultimate goal of this practice is to prepare you to build Decision Trees, which allow you to organize scenarios in order to understand how variables influence one another and, consequently, how these variables determine the final NPV.
When utilizing MiningMath’s free version, access to all software functionalities is restricted to the Marvin database, which comes pre-installed. This database is identified by its specific slopes, block dimensions, and model dimensions. In the event that these values have been changed for any reason, the original file can be downloaded here.
The Base Case consists of the initial scenario, with a uniform production capacity and without sum, average or surface mining limits.
While the base case considers a uniform production capacity, the BaseCase-RampUp scenario offers the possibility to vary the levels of production within the different timespans. We have an initial production capacity of 10Mton on the first 2 periods; 20 Mton on periods 3 and 4; and 30 Mton from period 5 until the end of the mine’s lifetime, with a total movement constraint of 30, 60, and 80 Mton, considering the increase of production within the time-frames mentioned.
Scenarios “PriceUp” and “PriceDown” differ in relation to the basic scenario in the economic value used for the calculation of the P1 process, where there is an increase and a decrease of 10% at the copper selling price, respectively. In the destination tab, “P1 Cu +10” and “P1 Cu -10” were the values used for the process.
These scenarios consider a 10% copper selling price increase and decrease, and a ramp-up of the production capacity at the same time, as mentioned before.
This scenario considers a 10% copper selling price increase and a ramp-up of the products at the same time, as mentioned in the previous scenario. In addition, a restrict mining surface (this constraint is used to prohibit access to this area in a specific timeframe) was included up to the fourth period, since it may represent some legal constraints on a project.
Below you can see a description of some scenarios of other Decision Trees.
The MW150 scenario considers different geometries from the base case at the geometric constraints. In this scenario, 150 meters was used as mining width (the horizontal distance between the walls of two surfaces that belonged to consecutive periods), and a vertical rate advance of 180 meters.
In the AvgCu scenario, blending constraints were added in the average tab to consider allowed at the process plant 0.5% as a minimum and 0.7% as a maximum average copper grade. The optimization will have to fulfill the P1 process capacity and, as an additional challenge, it has to meet this new set of parameters related to the Cu average content within the ore.
Scenario Proc13000h considers 13.000 hours of processing equipment used as the maximum limit. This constraint was inserted at the sum tab and it controls variables such as rock type feeding, energy consumption, and any parameter controlled by its sum. Scenario Proc13000h-33Mt considers an increase of 10% in the production, inserted at the production tab beyond the parameters mentioned previously.
This considers a yearly production for period range 1-4 and triannual planning for range 5-end. This way is possible to integrate both short and long-term planning in a single run, facilitating the analysis and strategic definitions.
Any kind of timeframe can be used according to your needs.
Running scenarios efficiently is essential to evaluate mine planning alternatives under changing economic or technical conditions. This guide shows how to execute a model within MiningMath using the user interface or automated scripting.
Video 1: Downloading MiningMath.
On MiningMath’s interface, you will find the Marvin block model and its scenarios (Figure 1). It is possible to preview the scenario and its parameters before opening it (Figure 2).
Choose and open Base Case, click the “Overview” tab (Figure 3) to check the parameters, and then click on “Run” to run the optimization (Figure 4).
After that, a short report with the results will be generated. To view it, check all the boxes on the “Load Options” window and click on “Load” (Figure 5).
Finally, whenever you feel ready to run your own scenarios, start by formatting your data here.
When utilizing MiningMath’s free version, access to all software functionalities is restricted to the Marvin database, which comes pre-installed. This database is identified by its specific slopes, block dimensions, and model dimensions. In the event that these values have been changed for any reason, the original file can be downloaded here.
When setting up your first scenario, you may come across some situations such as unavailable tabs and some fields marked in red. These situations are quite simple to resolve, as shown in the following video:
Reviewing MiningMath’s output helps validate your model and spot inconsistencies early. Its structure enables quick comparisons across scenarios, integrates constraints and sequencing automatically, and outputs data in a consistent, scriptable format—reducing manual effort and making it easier to iterate and adapt plans for more robust decision-making.
The 3D viewer enables a view of your model from different angles. The block colors are defined accordingly with each property displayed, varying from blue to red (smallest to largest), due to destinations, periods, or any other parameter. Therefore, it’s possible to filter the blocks by the period in which they were mined or processed, for instance. In addition, it also allows you to compare multiple scenarios by loading different cases and using the left bar to change from one to another.
After optimizing your block model and running your scenario(s), MiningMath generates standard output files with detailed reports. The main files have a universal format (.csv), which allows you to easily import them onto other mining packages to start your mine design and further steps of your projects.
To open the project folder, click on the scenario’s name with the right button of your mouse and choose “Show in the Explorer“. The optimization’s main output files are:
Scenarioname.xlsx: Short report with the main results.
MinedBlocks.csv: Detailed report which presents all the blocks that have been mined.
Surface.csv: Grid of points generated through the pit each period.
Provides you with a short report with the main results of the optimization: several charts and sheets in which you can analyze the production on each period, the stockpiles by periods, the average grade of processes and dump, NPV per period, the cumulative NPV (Net Present Value), etc.
This file offers a detailed report on all the mined blocks and their specificities: information on the mining sequence based on each block extracted, along with mined and processed periods, destinations, economic value, and all information used for the optimization. This file also allows you to identify blocks that were stocked and the algorithm decision-making process.
The surface scenario brings a grid of points generated through the pit of each period: each surface is named according to its mining periods and contains information about the topographic coordinates at that time. These files can be imported into the viewer separately, so that you can verify and validate your data before starting the optimization process. Note: The surfaces are exported/imported from/at MiningMath in Coordinates.
Video 1: Outputs and files hirearchy.
MiningMath allows you to learn with each scenario by providing standard parameters which simulate some common constraints a mining company may face. Standard scenarios are listed and described below so you can identify the main changes made within the “Overview” tab.
The ultimate goal of this practice is to prepare you to build Decision Trees, which allow you to organize scenarios in order to understand how variables influence one another and, consequently, how these variables determine the final NPV.
The examples in this page come preinstalled with every version of MiningMath. If you have deleted this project by any chance, please download the zip file below, extract the files and choose the “Open Project” option in MiningMath.
When utilizing MiningMath’s free version, access to all software functionalities is restricted to the Marvin database. This database is identified by its specific slopes, block dimensions, and model dimensions. In the event that these values have been changed for any reason please download it again.
While the base case considers a uniform production capacity, the BaseCase-RampUp scenario offers the possibility to vary the levels of production within the various timespans. We have an initial production capacity of 10Mton on the first 2 periods; 20 Mton on periods 3 and 4; and 30 Mton from period 5 until the end of the mine’s lifetime, with a total movement constraint of 30, 60, and 80 Mton, considering the increase of production within the time-frames mentioned.
Scenarios “PriceUp” and “PriceDown” differ in relation to the basic scenario in the economic value used for the calculation of the P1 process, where there is an increase and a decrease of 10% at the copper selling price, respectively. In the destination tab, “P1 Cu +10” and “P1 Cu -10” were the values used for the process.
These scenarios consider a 10% copper selling price increase and decrease, and a ramp-up of the production capacity at the same time, as mentioned before.
This scenario considers a 10% copper selling price increase and a ramp-up of the products at the same time, as mentioned in the previous scenario. In addition, a restrict mining surface (this constraint is used to prohibit access to this area in a specific timeframe) was included up to the fourth period, since it may represent some legal constraints on a project.
Below you can see a description of some scenarios of other Decision Trees.
The MW150 scenario considers different geometries from the base case at the geometric constraints. In this scenario, 150 meters was used as mining width (the horizontal distance between the walls of two surfaces that belonged to consecutive periods), and a vertical rate advance of 180 meters.
In the AvgCu scenario, blending constraints were added in the average tab to consider allowed at the process plant 0.5% as a minimum and 0.7% as a maximum average copper grade. The optimization will have to fulfill the P1 process capacity and, as an additional challenge, it has to meet this new set of parameters related to the Cu average content within the ore.
Here, the same blending constraints of the previous scenario (AvgCu) were added, in addition to a stockpile limit of 5Mton for process 1, on the destination tab. This feature allows you to control the stock limit of your whole process, which increases the optimization flexibility to feed the plant, while respecting the blending constraints that were already implemented.
Scenario Proc13000h considers 13.000 hours of processing equipment used as the maximum limit. This constraint was inserted at the sum tab and it controls variables such as rock type feeding, energy consumption, and any parameter controlled by its sum. Scenario Proc13000h-33Mt considers an increase of 10% in the production, inserted at the production tab beyond the parameters mentioned previously.
Customizing data directly in your block model can save time and reduce external preprocessing steps. MiningMath’s built-in calculator enables flexible transformations tailored to each scenario.
This feature allows the user to manipulate their project inside MiningMath, enabling adjustments and new field creation. Figure 1 shows a general view of the calculator. On the left side we have the block parameters and on the right the calculator itself, where the calculation can be done.
To manipulate the calculator just insert a name for the new field, select the type of field (to know more about field types, access this link), and build your expression. In case of a more complex expression, just mark the field “Logical Test” to enable conditional features. To manipulate the calculator just insert a name for the new field, select the type of field (to know more about field types, access this link), and build your expression. In case of a more complex expression, just mark the field “Logical Test” to enable conditional features.
+ : Addition
- : Subtraction
* : Multiplication
/ : Division
% : Modulus
** : Exponential
// : Floor division
To facilitate the understanding, let’s work on some examples. You can see below a generic math expression (left), and its equivalent written on MiningMath’s calculator (right)
x**2*((y/2)-1)Using an example of the Marvin’s Economic Value calculation, we are going to add a Block Tonnes field, as the figure 2:
One more time using Marvin’s block model, let’s suppose we want a maximum slope angle of 45 degrees.
First, we name our Field, in this case, will be “SlopeMax45d”, select the field type as “Slope” and check the Logical Test box. Then a double click on the Slope field select it and already put it on the Expression. The next step is to select the operator, as we want a maximum of 45 degrees, we choose the operator “>” and insert the value 45 in the text box. If the value is true, that is, if this value is bigger than 45 it will now have the value of 45 assigned to it. If the value is false, i.e., lower than 45, then it will keep its value. Figure 3 shows this calculation:
During the expression construction, green or red lines will underline it, highlighting the correct parts and the ones that need adjustments to become correct. When it is all set, just click on “Add field” and this new field will be available for use on the project on its correct field type assignments. In case the user needs to delete a field, just go to the parameters option, select and delete it.
To remove an existing field, go to the “Parameters” tab, select the desired field and click “Remove”.
Certain constraints related to your project can be defined so that you can understand its maximum potential. The surface generated in this case could also be used as a restrict mining in the last period to reduce the complexity of your block model and the runtime of MiningMath, since it includes a set of constraints inputted.
Set up a scenario with 1,000 Mt in the processing plants, which corresponds to a lot more mass than expected in the whole life of the mine.
Add the Minimum Bottom Width (100m). This constraint will allow you to have a suitable work-front for your equipment.
Restrict Mining surface, if you have this constraint in your project.
Grade constraint until 0.7%.
Timeframe: Years (1), since it would all be processed in 1 period.
Note: Sum constraints can restrict the total amount of handling material (ore + waste) of the mine. Therefore, do not use them in the validation.
Now that Constraints Validation step is done, you are able to use this final surface as a guide for future optimizations. This approach reduces the runtime and the complexity of the algorithm because when you take it into account, the blocks below this final optimized surface won’t be considered and the heuristics inside the interface would be facilitated. Notice that we did not make any change in the discount rate, thus, this first NPV does not represent the reality. If you need an accurate result in this step, make sure to adjust it.
It’s important to remember that when we restrict the mining into this surface, the number of periods generated in future runs could be reduced because the average parameters of each one will have to meet the constraints of the overall package. Therefore, to achieve the same parameters in a lower timeframe, some blocks may be discarded due to the mining sequence and the optimization of destinations inside the whole mass.
Having this idea in mind, you should already have enough information to decide and structure the next step of the optimization. Based on the amount mined in the last item and in the processing capacity, define a good timeframe to identify the mining sequence. In this case, we had 231 Mt as the ore total mass to split in almost 23 years, since the processing capacity is 10Mt.
To improve efficiency in the optimization, before working on a yearly basis, we made the decision to consider the first 5 years. It is reasonable to generate a 10-year surface to consider the optimization inside this limit due to observations made before. Remember that each assumption here can be done accordingly with your project’s demands and that MiningMath can work with any timeframe to meet your needs.
Accurate NPV evaluation is central to aligning technical decisions with financial value. MiningMath calculates NPV using discounted cash flows across both standard and custom timeframes, ensuring consistency even with irregular period definitions.
The following video explains more about the NPV calculation made by MiningMath’s algorithm. The understand of these steps might be useful for users working on projects with variable mining costs, which are not yet smoothly implemented on the UI.
Video 1: NPV calculation.
The discount rate (%/year) is provided by the user in MiningMath’s interface, as depicted in the figure below.
In a usual scenario period ranges are defined by annual time frames, as depicted in Fig-2.
In this case, the annual discount rate multiplier (annual_multiplier) to return the discounted cash flow is performed as follows:
\(\text{annual_multiplier}(t) = \) \(\frac{1}{(1 + \text{input discount rate})^t}\)
The table below exemplifies one case for 10 periods.
| Period | Process 1 | Dump 1 | NPV (Discounted) M$ | Annual multiplier | Undiscounted NPV M$ |
|---|---|---|---|---|---|
1 | P1 | Waste | 1.2 | 0.909 | 1.320 |
2 | P1 +5% | Waste | 137.9 | 0.826 | 166.859 |
3 | P1 +5% | Waste | 132.5 | 0.751 | 176.358 |
4 | P1 +5% | Waste | 105.4 | 0.683 | 154.316 |
5 | P1 -5% | Waste | 89 | 0.621 | 143.335 |
6 | P1 -5% | Waste | 92 | 0.564 | 162.984 |
7 | P1 -5% | Waste | 91.3 | 0.513 | 177.918 |
8 | P1 -10% | Waste | 52.3 | 0.467 | 112.110 |
9 | P1 -10% | Waste | 54.3 | 0.424 | 128.037 |
10 | P1 -10% | Waste | 12.1 | 0.386 | 31.384 |
Table 1: Example of annual multiplying factors and undiscounted cash-flows for a 10% discount rate per year. Process 1 exemplifies the use of different economic values per period.
the NPV (discounted) resulting from a 10 yearly period with a 10% discount rate per year.
the annual discount rate (annual_multiplier) for each period; and
the undiscounted NPV as the result of the discounted NPV divided by the annual_multiplier.
MiningMath allows the creation of scenarios in which period ranges are defined with custom time frames (months, trienniums, decades, etc.), as depicted in Figure 3.
In this case, the discount rate is still provided in years on the interface. However, the discount rate per period follows a different set of calculations. To identity the correct multiplier (discount rate for a custom time frame) applied to each custom time frame, it is necessary to apply the formula below:
\( \text{mult}(t) = \frac{1}{(1 + \text{discount_rate}(t)) ^ {\text{tf_sum}(t)}}\)
where:
\(
\text{tf_sum}(t) = \sum_{i=1}^{t}\frac{TF(i)}{TF(t)}
\)
and
\(
\text{discount_rate}(t) = (1 + \text{annual_discount_rate})^{TF(t)} – 1
\)
and
\(
TF(t)=
\begin{cases}
1,& \text{if}\, t\, \text{is in years}\\
\frac{1}{12},& \text{if}\, t\, \text{is in months}\\ 3,& \text{if}\, t\, \text{is in trienniums}\\
etc.&
\end{cases}
\)
For example, to calculate the multiplier of the first period in figure 3, the equation would be:
\( TF(1) = \frac{1}{12} = 0.8333… \)
\(
\text{tf_sum}(t) = \sum_{i=1}^{1}\frac{TF(1)}{TF(1)} = 1
\)
\(
\text{discount_rate}(1) = (1 + \text{annual_discount_rate})^{TF(1)} – 1 = (1 + 0.1) ^ {1/12} – 1 = 0.007
\)
\( \text{mult}(1) = \frac{1}{(1 + \text{discount_rate}(1)) ^ {\text{tf_sum}(1)}} = \frac{1}{(1 + 0.007)^{1}} = 0.993 \)
Another example, to calculate the multiplier of period 15 in figure 3, the equation would be:
\( TF(15) = 3 \)
\( \text{tf_sum}(t) = \sum_{i=1}^{15}\frac{TF(i)}{TF(15)} = 2 \)
\( \text{discount_rate}(15) = (1 + \text{annual_discount_rate})^{TF(15)} – 1 = (1 + 0.1) ^ {3} – 1 = 0.331 \)
\( \text{mult}(15) = \frac{1}{(1 + \text{discount_rate}(15)) ^ {\text{tf_sum}(15)}} = \frac{1}{(1 + 0.331)^{2}} = 0.564 \)
Decision Trees give you a comprehensive view of your project, helping you plan your mining sequence by evaluating every possible scenario. They allow you to assess constraints, identify the most viable and profitable options for the overall project, and understand the impact of different variables on the final NPV. For example, consider plant production per year as a variable factor. With Decision Trees, you can analyze how each constraint—such as ore price—impacts annual production and influences the overall success of the project.
By running multiple scenarios within the same Decision Tree, you can also assess how each change affects the generated mining sequence, as in the example below.
This broader perspective helps you determine the best course of action to maximize value for your company.
Once a project is selected, the Decision Trees and Model areas will be displayed (as depicted below).
From this area, you can get a comprehensive overview of all scenarios and their respective NPVs. Additionally, you can create decision trees and easily add or remove scenarios as needed. For more information about using the decision trees interface please check the contents here.
MiningMath comes pre-installed with a number of decision trees that can be used for learning purposes.
To illustrate scenario analysis within a decision tree, the following subsections compare two pairs of scenarios.
Let’s analyze the PriceUp scenario where the economic value of Process 1 changes (for more information about calculating economic values check the page here).
Naturally, key metrics like NPV are affected. By examining both the NPV and total movement, we can see that a different mining sequence was generated, extending the mine’s lifetime by one period.
Total mass (Process+waste) handled on each scenario.
This market shift also led to an increase in cumulative NPV, directly influenced by the rise in copper selling prices.
Comparison of cumulative NPV. No increase for base case at period 11.
Next, let’s analyze the AvgCu scenario in which a restriction in the average grade at Process 1 was added, using a minimum and a maximum limit of copper.
The blocks selected for processing must meet established targets, enabling better selectivity in determining what should be processed. Blocks with grades higher or lower than required can be blended to achieve an average grade that aligns with constraints while maximizing NPV.
Notably, most periods saw an increase in total mass (production + waste) due to a higher stripping ratio (ore/waste). This adjustment was necessary to maintain the 30 Mt ore production at Process 1 while meeting the average grade targets set in the AvgCu scenario.
Total mass (Process+waste) handled on each scenario.
In this scenario, more efficient stockpiling is expected, allowing the algorithm to leverage its blending capabilities and decision-making intelligence to determine the optimal block combinations for maximizing plant capacity.
Additionally, the cumulative NPV reveals that imposing average grade constraints reduces the algorithm’s flexibility, leading to some financial loss in exchange for the operational stability often required in processing plants.
Comparison of cumulative NPV. No increase for base case at period 10.
Overall, MiningMath aims to maximize cumulative NPV while minimizing the mine’s lifetime, given the provided constraints. This approach helps reduce project depreciation caused by interest rates.
In conclusion, MiningMath streamlines mine project evaluation by replacing traditional, time-consuming methods—often based on 1960s technology and reliant on manual pit designs and limited scenarios—with a global optimization scheduling approach. This allows users to quickly generate multiple, mathematically optimized scenarios that incorporate constraints from various business areas. By enabling the creation of structured decision trees, MiningMath enhances strategic analysis and supports more informed, integrated decision-making across the company.
Hi, it's Mima here 😇 Ask me any questions!
