#### MiningMath

Global Optimization with no stepwise process!

## System requirements

The only mandatory requirement for using MiningMath is a 64-bits system, due to its use of Direct Block Scheduling technology. Other minimum requirements are listed further:

1. Windows 10

2. 64-bits system (mandatory)

3. 110 MB of space (installation) + additional space for your projects' files.

4. Processor: processors above 2.4 GHz are recommended to improve your experience.

5. Memory: at least 4 GB of RAM is required. 8 GB of RAM or higher is recommended to improve your experience.

## Recommended Hardware

Memory should be a higher priority when choosing the machine in which MiningMath will be run on. In addition, a list of priority upgrades to improve performance with large scale datasets is given below.

1. High Ram

2. Higer Ram frequency

3. Higher processing clock

Notice that MiningMath does not use multiple processing threads for a single scenario. To take full advantage of a multi-thread processor, consider running different instances of MiningMath with different scenarios.

## Installing, activating and running!

Installing and activating MiningMath is quick and straightforward. All you need to do is to follow the setup wizard and have an internet connection to activate your license.

Video 1: MiningMath installation process.

1. Open MiningMath (It will open automatically after the installation, but you can open it manually afterward).

3. Select the field "I have an activation code", paste the License Code provided by MiningMath.

NOTE:

MiningMath’s licensing method demands an internet connection.

## Play with the predefined scenarios

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.

## Market Conditions Decision Tree

### 1) BaseCase

The Base Case consists of the initial scenario, with a uniform production capacity and without sum, average or surface mining limits.

### 2) BaseCase-RampUp

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.

### 3) PriceUp and PriceDown

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.

### 4) PriceUp-RampUp and PriceDown-RampUp

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.

### 5) PriceUp-RampUp-Protection300 and PriceUp-RampUp-Protection400

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.

## Other Decision Trees

Below you can see a description of some scenarios of other Decision Trees.

### 1) MW150 (Geometries 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.

### 2) AvgCu (Average Decision Tree)

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.

### (Process throughput Decision Tree)

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.

### (Short-Long Term Integration Decision Tree)

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.

## Tutorials

#### Articles

In 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.

## Find new results

1. Quick Check: Here you’ll have all the necessary instructions to install, activate and run MiningMath.

2. 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!

1. 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.

2. 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.

## Understand the technology in depth

1. 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.

2. 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.

3. 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.

## Using and validating your data

1. Formatting the Block Model: Learn how to format your block model data and use it in MiningMath.

2. Importing the block model: Go through the importation process and to proper configure your data.

3. 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.

4. 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.

5. Constraints Validation: Continuing the validation, start to add the first constraints related to your project so that you can understand its maximum potential.

1. 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.

2. 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.

3. Exploratory Analysis: 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.

4. Strategic Planning: Consider your real production and explore scenarios to the most value in terms of NPV.

5. 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.

1. 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.

## In-depth MiningMath

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.

## Software requirements

1. Quick check: Verify if your computer has all the minimum/recommended requirements for running the software.

2. Put it to run: Here you’ll have all the necessary instructions to install, activate and run MiningMath.

## Set up the block model

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.

2. Import your block model: import your csv data, name your project, set fields and validation.

3. 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.

4. Calculator: calculate and create new fields by manipulating your project inside MiningMath.

#### Handling unformatted data

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.

## Define the scenario and run

Once you have started your block model defined, there are several options to set up your project’s parameters before running a scenario.

1. Scenario tab: set densities, economic parameters, slope angles, stockpiles, add/remove processes and dumps, production inputs, geometric inputs and so on.

2. Save as: save the scenario's configuration once it has been configured.

3. 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.

## Results

After running your scenario it is important to analyze and understand the given results.

1. 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.

2. Export model: export your model as a csv file. This can be used in new scenarios or imported in other mining packages.

## Extensive set-up

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.

## Theory

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.

## Workflows

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.

## How to run a Scenario

Reach out to our knowledge base home page if you wish for a quick introduction to MiningMath technology prior to a hands-on approach.

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).

## Results of the Optimization

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.

## Viewer

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.

## Output Files

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.

## Scenarioname.xlsx

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.

## MinedBlocks.csv

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.

## Surface.csv

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.

## Play With Predefined Scenarios

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.

## BaseCase

The Base Case consists of the initial scenario, with a uniform production capacity, and without sum, average, or surface mining limits.

## BaseCase-RampUp

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.

## PriceUp and PriceDown

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.

## PriceUp-RampUp and PriceDown-RampUp

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.

## PriceUp-RampUp-Protection300 and PriceUp-RampUp-Protection400

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.

## MW150

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.

## AvgCu

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.

## AvgCu-Stock5Mt

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.

## Proc13000h and Proc13000h-33Mt

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.

## The calculator

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,), 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.

• - : Subtraction

• * : Multiplication

• / : Division

• % : Modulus

• ** : Exponential

• // : Floor division

## Practical approach

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)\times(\frac{y}{2}-1)$$ x**2*((y/2)-1)

## Adding a field without logical expression

Using an example of the Marvin’s Economic Value calculation, we are going to add a Block Tonnes field, as the figure 2:

## Adding a field with a logical expression

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.

## MiningMath's internal math for NPV Calculation

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.

## Discount rate per period

The discount rate (%/year) is provided by the user in MiningMath’s interface, as depicted in the figure below.

## Undiscounted cash flow for annual time frames

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 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.

In details, Table 1 lists:
• 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.

## Undiscounted cash flow for custom time frames

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.
In the example on Figure 3, the first range is composed of 12 periods of one month each. To calculate their discount rate, a timeframe factor for each period t is defined first. This is basically the value associated with each timeframe, as depicted in Figure 3, or a custom value given by the user. Another required information is the year in which t occurs. For instance, the 2nd month occurs in year 1, while the 13th month occurs in year 2.

$$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}$$

$$\text{year_of}(t) = \text{year in which}\, t\, \text{occurs}$$

The discount rate of periods in which timeframes correspond to less than one year (low_multiplier) is, then, given by the formula:

$$\text{low_multiplier}(t) = \text{annual_multiplier}(\text{year_of}(t)^x)$$

$$\text{where}\, x = \sum_{i=1}^{t}TF(i)$$

Table 2 shows an example of 12 periods of one month each, with:

• timeframe factor;

• cumulative timeframe factors;

• corresponding annual_multiplier for each period;

• the low_multiplier of each period; and finally,

• the undiscounted cash flow (discounted cashflow divided by the low_multiplier)

Period Type Process 1 Dump 1 NPV M$Time frame Years rounded Cumulative factor annual multiplier low multiplier Undiscounted NPV M$
1
Month
P1
Waste
10.8
0.0833
1
0
0.90909
0.99209
10.88612
2
Month
P1
Waste
13.6
0.0833
1
0.08333
0.90909
0.98424
13.81776
3
Month
P1
Waste
11.4
0.0833
1
0.16666
0.90909
0.97645
11.67490
4
Month
P1 +5%
Waste
12.9
0.833
1
0.25
0.90909
0.96873
13.31641
5
Month
P1 +5%
Waste
11.2
0.0833
1
0.33333
0.90909
0.96107
11.65373
6
Month
P1 +5%
Waste
13
0.0833
1
0.41666
0.90909
0.95346
13.63452
7
Month
P1 -5%
Waste
11.2
0.0833
1
0.5
0.90909
0.94592
11.84033
8
Month
P1 -5%
Waste
14.4
0.0833
1
0.58333
0.90909
0.93844
15.34467
9
Month
P1 -5%
Waste
11.8
0.0833
1
0.66666
0.90909
0.93101
12.67437
10
Month
P1 -10%
Waste
14.7
0.0833
1
0.75
0.90909
0.92365
15.91517
11
Month
P1 -10%
Waste
13.6
0.0833
1
0.83333
0.90909
0.91634
14.84165
12
Month
P1 -10%
Waste
12
0.0833
1
0.91666
0.90909
0.90909
13.20000

Table 2: Example of discount rates calculated per month and undiscounted cash flows with a 10% discount rate per year. Process 1 exemplifies the use of different economic values per period.

## Timeframes greater than a year​

In the example on Figure 3, the last period ranges are composed of 3 trienniums. To calculate the discount rate of a triennium, the annual_multiplier of each year contained in it is computed and then averaged. Hence, the discount rate of periods in which timeframes are greater than one year (great_mutiplier) is given by the formula:

$$\text{great_multiplier}(t) =$$ $$\frac{\sum_{y=\underline{t}}^{\overline{t}}\text{annual_multiplier}(y)}{\overline{t} – \underline{t} + 1}$$

$$\text{where}\, \underline{t}\, \text{is the first year in period}\, t\, \text{and}\, \overline{t}\, \text{is the last year in period}\, t$$

Table 3 shows the example of 3 trienniums occuring after 14 periods (12 months and 2 years). The annual_multiplierof each year contained in each triennium is listed. The average of these factors return the great_multiplier of each triennium, which, in turn, divides the discounted cash flow to calculate the undiscounted one.

Period Type Process 1 Dump 1 NPV M$Time frame great multiplier Undiscounted NPV M$ Year rounded annual multiplier
15
Triennium
P1
Waste
378.4
3
0.62280
607.57584
4
0.68301
5
0.62092
6
0.56447
16
Triennium
P1 -5%
Waste
120.8
3
0.46792
258.16321
7
0.51318
8
0.46650
9
0.42409
17
Triennium
P1 -10%
Waste
4.2
3
0.35155
11.94688
10
0.38554
11
0.35049
12
0.31863

Table 3: Example of undiscounted cash flows and discount rates calculated per triennium with annual discount rate of 10%. Process 1 exemplifies the use of different economic values per period.

## Evaluate Project Potential

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.

## Example

• 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.

• 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.

## Using results

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.

## What is MiningMath?

It is a software application that uses innovative technology for direct block scheduling. The MiningMath aims to maximize the Net Present Value (NPV) of a project deciding, based on an imported block model, which blocks will be mined, when and what the destination of each block is.

It is possible to define multiple processing plants, stockpiles and waste dumps, respecting their capacities. It is also possible to set physical limits or force mining in certain regions by importing surfaces.

As the software has a flexible algorithm, it will be possible to include other restriction types in the future, such as blending for example.

## OK, but why should I use MiningMath?

MiningMath allows running a complete schedule directly from the resource block model, with no need to define a final pit, nested pits, pushbacks, cut-off grade optimization and stockpiles as would be required as part of a traditional full scheduling exercise. MiningMath will find a mining schedule that aims to maximize the NPV of the project, combining all the steps mentioned and optimizing all the periods simultaneously. Therefore, an experienced professional can test multiple scenarios by modifying parameters and advance other stages of his work, while MiningMath performs the entire optimization.

## Is the generated solution operational, or only a mathematical result?

Each mining plan generated by the optimization respects important geometrical parameters, such as a minimum pit bottom width, a mining width and vertical rates of advance, which can be configured specifically for your project. Furthermore, MiningMath technology generates surfaces without geotechnical errors. The generated plans are close to the operational reality of the mine, which implies smaller variations in the parameters when ramps are designed.

## In practice, how can I use MininngMath to scheduling optimization?

A block model, in CSV formatincluding indexes or coordinates and economic values of the blocks is first imported followed by entering the primary parameters of the model and production restrictions via interface. Upon completion of these steps, MiningMath is ready to perform the optimization.

The resulting surfaces will respect the user-defined parameters and a report will be generated with graphics containing the most important indicators.

To demonstrate the usage and power of the software, you can access our demo video here.

## Does MiningMath suit my project? What are the limitations of the current version?

The current version of MiningMath suits any open pit mining project that can be modeled with blocks of regular dimensions. If your project has multiple types of rock per block, there are ways to adapt the inputs to handle these cases. MiningMath is 100% based on 64-bit technology and has an efficient algorithm, capable of handling tens of millions of blocks without requiring supercomputers or cloud computing.

To date, MiningMath has focused on developing the best algorithms; future versions will introduce more facilities for the user, including the development of plug-ins to mining softwares on the market.

## I have a sub-blocked model. How could MiningMath be used in this case?

If the model can be exported by dividing all blocks into sub-blocks, then we have a regular database formed only by sub-blocks and MiningMath can run it. We perform regular tests successfully using models with tens of millions of blocks. For future versions, we are planning significant efficiency improvements.

## Does MiningMath have the Lerchs-Grossman (LG) algorithm implemented?

No. LG is a brilliant algorithm for its time, but none of the new software need to implement it anymore. The technological advances have proven that new methods overcome some barriers that the LG faces. These days, any software that has the same mathematical model of LG implemented will rather implement an algorithm based on maximum flow rate (Max Flow) which can be run tens or hundreds of times faster than the LG. However, both LG and Max Flow have no flexibility to include other important restrictions such as a minimum pit bottom width or blending.

MiningMath uses highly recommended technology currently in practice and inside research centers, being what is the most advanced, tested and available when talking about optimization. It was implemented using modern techniques based on mixed integer programming and heuristics. Its mathematical model is more realistic, for considering operational aspects and uses surfaces to return solutions that does not have any geotechnical errors. What in practice is mined are surfaces and not blocks. This type of technology has the flexibility to include other real restrictions, such as blending.

## Interface Overview

#### Articles

MiningMath automatically starts on the Home Page, as shown in Figure 1.

Figure 1: Interface example. Click to expand.

The following are three main information windows:

• The Recent Projects window allows you to select a project and have an overview of the saved scenarios that will appear right away at the Decision Tree tab. It allows the user to quickly navigate through recent projects and scenarios without opening them from their original folders. Clicking with the right button on the project name, the user will have 4 options:

1) New scenario: "Scenario config" window will open allowing you to decide in which decision tree to place the new scenario, its name, and a description for it. Afterward, is going to be directed to set it up in the scenario tab.

2) Show in explorer: This option takes to the directory containing the folder with the project.

3) Remove from list: Excludes the referred project from the Recent Projects list.

4) Delete project: Deletes the project and the scenarios from it.

• The Decision Trees feature enables you to create new tabs and ways to organize the mining planning strategies by exchanging scenarios between them, if necessary. It allows access to all paths involved in the project, providing a broad view and enhancing the decision-making process. It shows decision trees’ scenarios with key information about them, such as name and description to easily identify its characteristics, NPV on M$, runtime, and a direct link to the sheet containing all the results of the scenarios, which are available after the scenario’s execution. It’s possible to: 1) Add new trees by clicking on “+” 2) Rename a tree by double-clicking its name 3) Clicking with the right button, the user may add a new scenario, rename or delete this tree. Getting into more details, some hidden options are available to the user when clicking with the right button on the scenario’s name: open, view model, rename, show in explorer, delete, and the possibility to transfer it between decision trees. The scenario description can be easily edited with a double click. To open any scenario, click on one Recent Project first, and then choose the one you want to work with at the Decision Trees tab by double-clicking with the right button of your mouse, and choosing the option "Open", or just selecting “Open” at the right bottom of this feature. The “View” button leads to the MiningMath’s Viewer. • The Model table discloses the main information regarding your block model and its parameters, so that you can easily review it at any time using the "Edit" button shortcut, which will lead you to the "Calculator" functionality. ## Model tab 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. This tab starts at the “Parameters” option, showing your previous set up at the importation, similar to Figure 2, and all the existing fields. It also allows you to remove any parameter at any time. The “Function” option discloses the “Validate your block parameters” table, so that you can choose a single block within your model to verify its values. It also enables MiningMath’s internal Calculator to make adjustments and changes to your dataset with the addition of new fields. ## Scenario tab ## General Parameters MiningMath automatically switches to the Scenario Tab in the General option once a scenario is opened, as shown in Figure 1 The General tab presents all the general inputs regarding densities (Figure 1), economic parameters (Figure 2), slope angles (Figure 3) and stockpiles (Figure 4), which are detailed next. ## Densities Densities, as shown in Figure 1, are used along with block size to calculate tonnages. The user has two options to define them: • "Field" shows the column(s) that has/have been assigned to the density during the importation. This option is intended to allow varying densities by block. • "Default value" is applicable to any block without density information, whether a density column is imported or not. It is also used when you choose the field as . ## Economic Parameters The Discount Rate is a field of Economic parameters, as seen in Figure 2. It is usually considered in an annual base, is responsible to define the impact of mining ore/waste over time, which influences the algorithm decision-making process. While working with different time frames, the discount rate serves just a rough NPV approximation, and it doesn’t affect so much the quality of the solution, given that the best materials would be allocated first. Thus, by multiplying or splitting it by the number of periods, you might get reasonable results. ## Slope Angles Slope angles are one of the most important parameters when considering constraints hierarchy. The user, as seen in Figure 3, has two options here: • Field shows the column(s) that has/have been assigned to the slope during the importation. This option is intended to allow different slope angles by block. • Default value is used to any block without slope information, even if a column was assigned. It is also used when you choose the field as <none> . ## Stockpiling The stockpiling feature can be used by activating the checkbox. When this option is enabled, shown in Figure 4, the user can define: • Fixed mining cost (cost/t) refers to the average mining cost used for the economic functionThis value is used to decompose the economic value while considering stockpiles. • Rehandling cost (cost/t) represents the cost to reclaim blocks from the stockpile to the process. To illustrate the other tabs inside the Scenario tab, the parameters used in the Marvin case will be employed as summarized below: Parameter Subparameter Value Densities Field Density Default value 2.75 Slope angles Field Slope Default value 45 degrees Stockpiling Fixed mining cost 0.9$/t
Rehandling cost
0.2/t Discount rate - 10% Table 1: Parameters used in the Marvin cases. ## Destinations: Process, Dump and Stockpile On the Destinations tab (Figure 5), you will define destinations to where the blocks can be sent. Each target must be mapped with their respective field containing the economic values. MiningMath requires at least one destination for the process and one destination for the dump. For each destination, you have an economic value and recoveries by elements. ## Process & Dump To add destinations, in the bottom corner of the window, click on: • Add Process • Add Dump Each scenario must contain at least one process and one dump among the destinations imported. The destination of each block will be reported by assigning them with the numbers 1 or 2 (see the numbers beside the Name column)which depends on the order of addition. ## Recovery For each processing stream, the user must inform a process recovery, varying from 0 to 1, to any element/mineral whose column has been imported as a grade. This value on the interface serves only for the purpose of generating reports, as it has been considered during the economic calculation. Use the following values for the processing stream: • Cu: 0.88 • Au: 0.60 ## Stockpile You can also define a tonnage limit for the stockpile if activated in the General tab (see Figure 4). MiningMath considers the tonnage inputted as a cumulative upper limit that will be considered all over the life of mine. In this example, a limit has not been defined, which implies an capacity to stock. Read more about stockpiles. ## Economic Value In the column of Economic value, you must assign each destination to its corresponding economic function. Therefore, use: • Destination 1 - Process 1 - Economic Value Process • Destination 2 - Dump 1 - Economic Value Waste Figure 6 zooms in the destination fields, showing how they should look like for this example. ## Production Inputs After completing the previous fields, move to the Production tab (Figure 7). You can define limits (in tonnes) for each destination and the total amount of material moved per period and also add different timeframe ranges in the optimization. For this example, use the values as shown in Figure 7. • TimeFrame: Years (1) • Process 1: 30,000,000 t • Dump 1: 50,000,000 t • Total: 80,000,000 t ## Geometric Inputs On the Geometric tab (Figure 8), you can define parameters intending to find mathematical solutions that already consider basic requirements to be operationally feasible. Figure 8 highlights Operational Fields, which could differ for each period range and timeframesuch as vertical rate. Optional Fields are also allowed. These allow the definition of: 1) areas to be forced and/or restricted; and 2) periods to which surfaces are applied. In this example the values defined for all periods are: • Minimum width: Mining 100m, Bottom: 100 m • Vertical rate of advance: Maximum 150 m In the Geometric tab you can also force mining and restrict mining using surfaces based on coordinates and defined as a 3D-grid of points in the CSV format. Surfaces are the most important constraints within MiningMath’s hierarchy, allowing you to impose one’s understanding and take control of prior results and operational aspects. Using surfaces, you are able to play with geotechnical aspects, force certain regions to allocate waste material, restrict areas to protect the environment, and/or guide operational aspects by importing a designed pit. Due to the complexity of this subject, surfaces will be treated in a specific section of our documentation. ## Average On the Average tab, you are able to define a minimum and/or maximum average grades for any element/mineral imported as grade (Figure 9 area 1). Blending constraints can also be defined by period ranges (Figure 9 area 2) and/or destination (Figure 9 area 3). It’s worth mentioning that this minimum limit does not represent cut-off values. Since it is based on average parameters, the algorithm can use lower values to respect this parameter and increase the NPV with higher ones. If you wish to input a cut-off, a good way to do it is by filtering these blocks and assigning the the mass as a sum field, as mentioned here. ## Sum On the Sum tab, you are able to consider any summed parameter as a minimum and/or maximum limits for any data imported as other (Figure 10 area 1). Other constraints can also be defined by period ranges (Figure 10 area 2and/or destination (Figure 10 area 3). This feature is available only at the full versions of MiningMath. Read more. ## Overview Click on Overview (Figure 11) for a single page summary of all parameters related to the direct block scheduling, as illustrated in the figure below. The Save as option (Figure 12) can be used to redefine the name, description for an edited scenario, and its decision tree. You can also decide which files MiningMath will produce as outputs by using the execution options (Figure 13) before clicking on “Run” your scenario. ## Viewer After running your scenario, the Mined Blocks file will disclose its results on the 3D viewer, enabling the view of your model from different angles. By selecting “Period Mined”, you are able to view the mining sequence period by period. By selecting a surface, it is possible to identify the topography changes of each period and also modify its opacity, facilitating the visualization. MiningMath also allows you to import surfaces already created if you place them in the same folder as the other ones, so that you can validate their geometry if necessary. Click on “Load Scenario” to import multiple scenarios and compare them, in order to extract the best results accordingly with your project constraints. ## Overview ## Last check before running The Overview tab aims to let the user to give a last check on each parameter inputted. Every information available in this screen, as shown in Figure 1, is also present on the previous screens: Note the user can even go straight to the overview tab to save time. ## Save As ## Options to save a scenario By clicking over Save As button, a window will pop-up, as shown in Figure 1. Then, the user will be able to set: • A scenario name • A scenario description These fields intends to better identify a scenario among several ones by just taking a look at the Projects List. ## Run ## Running the optimization The Run tab is the last step before running your project’s optimization. The Figure 1 below shows its interface and in sequence we will discuss each part. ## Editing scenario name At this part is possible to check the saving parameters, such as the Decision Tree where the scenario will be inserted, scenario’s name and description. ## Export to CSV Allows choosing to export the surfaces to a CSV file and/or the block model, with other options such as: all blocks mined; only mined blocks, coordinates and indices. ## Time limit 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. To know more how this is done read the article here. ## Reports visualization The lower part of the screen allows you to view the results, in CSV, if the scenario has already been run, inside the software, facilitating strategic decisions. ## Run button After everything is checked, just Run the scenario. ## Progress bar With the progress bar you can monitor the execution of the scenario and the estimated time it will take to be completely executed, as shown in Figure 2. ## Handling Data #### Articles ## Formatting the block model ## Block Model Basic requirements MiningMath requires the following formatting specifications: • Regularized block model: This means all blocks must be the same size. • Non-rotated model: All blocks must be aligned to the default axis. • Air blocks must be removed prior to importation. This is the way MiningMath recognizes the topography. • Coordinates or Indexes 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. ## Good practices • Configure Microsoft Windows number formatting to use dot as the decimal separator. • Use the metric system. • Set multiple fields that will consider different economic values, material types, contaminant limits, and any other variable you wish to analyze or control. ## Understanding Field Types Field Types are the fields MiningMath can understand. Each column imported should be assigned to the proper field type so that the software treats each variable accordingly with its meaning. ## Mandatory Field Types and their meanings • Coordinates X, Y, and Z refer to your geo-referenced information. The same applies to Index X, Index Y, and Index Z, which requires a column for each one of the 3D axes. • Average refers to any variable that could be controlled by means of minimums and maximums considering its average: grades, haulage distance, and other variables. • Economic Value refers to the columns with the economic value, which represent the available destinations. 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 mentioned on the next page. ## Optional Field Types and their meanings • 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. • 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. ## Field names shortcut Shortcuts can be used for auutomatic recognition in the importation process. These are listed in the table below. Field name Shortcuts Coordinates X | Y | Z Average @ | grade Density % | dens | sg Economic value  | dest | val
Recovery
* | recov
Slope
/ | slope
Sum
+
Skip>
!

## Mandatory requirements

Considering the specifications mentioned before, the formatted data set should have the following information for each block:

• Coordinates or Indexes.

• Grades (at least one element assigned as Average).

• Economic values (at least 1 process and 1 waste).

The following video gives an introduction on how to setup your block model.

Video 1: Block Model setup.

## Attention to software conversions

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 a block model origin at the corner of the first block and the coordinates on its centroid.

Each software uses its own conventions for data format, naming and numbering systems, etc. These differences should be observed to prevent conflicts when transiting data from multiple software, each one for one specificity.

What you must know:

• MiningMath uses coordinates (X,Y,Z) for which Z, which represents the elevation, starts upwards (Figure 3a).

• Other mining software may use indexes with IZ starting downwards (Figure 3b). MineSight is an example that uses this notation.

There is no right or wrong convention, but there is a correct procedure for each software.

To invert coordinates use the following formula to convert:
$$new(Z) = max(Z) + 1 – current(Z)$$

## Air Blocks

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.

###### More Details on Air Blocks

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.

Video 1: Removing air blocks using filters on MS Excel.

## Block Model File

To import the block model, select the option Import Model on the left panel of MiningMath. Notice in Figure 1 that 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.

## Project Naming

In the next window, shown in Figure 2, 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.

## Decimal separator

MiningMath does not recognize CSV’s using semicolon as a decimal separator.

To change it, go to:

Control Panel > Clock, Language, and Region > Region > Change date, time, or number formats > Additional Settings then 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.

## Imported Fields & Validation

Upon clicking Next, the following window will provide a statistical summary of information for the block model that will be imported, as shown in Figure 3.

Check the parameters carefully.

## Geo-reference system, Origin and Dimension

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 coordinates or index. The next steps are to place the origin accordingly with your mining package and the block dimension as illustrated in Figure 4. The origin of this project was x=3,475, y=6,480, and z=285, and the block dimensions were 30 meters in each coordinate.

## Field Type Assignment

When Next is selected, the following form will appear (Figure 5), 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. Note: 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 on the next page.

## Notes

• 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. Figure 6 shows, in green, a Field Type correctly assigned for the column IY. In red, the grade columns are assigned to the Field Type Other instead of Average. Consequently, the Next button is disabled.

MiningMath has mandatory variables (columns) to be assigned to the proper Field Type:

• Indexes (IX, IY, IZ) or coordinates (X, Y, Z).

• Average.

• Economic Values (at least two).

After clicking Next, it will demand grade units. As you can see in Figure 7, 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.

## View Your Model and Surfaces

After filling in the required fields, the options View Model and Scenarios will be enabled. Before setting up your first scenario you can view it by clicking in the Viewer and Load scenario. Select all the tooltip options and click in load. This option also allows you to view surfaces created, just place them in the scenario folder before loading and do the first validation.

## Questions:

• Where are the high grades distributed?

• Does the process economic values, above zero, match with the regions identified in the last question?

• How are waste economic values distributed? Are maximum and minimum values reasonable when you compare them with the process?

Note: A warning message can appear as no scenario was run before. Just press ok, check your block model and proceed to set up your project.

The concept of cut-off grade has been conceived to delineate what is ore and waste, considering the life of mine. Usually, manual assumptions are made to pre-define what must be considered ore or not, while using the LG or Pseudoflow methodologies. These approaches do not consider the value of the money through time in the decision-making process, which could generate a whole different mining sequence due to the choices of what and when it should be mined. Another challenge, that is faced when planning projects which involve multiple destinations, blending constraints, restrict mining areas, and all the complexities present in a real global optimization. MiningMath allows for such Global Optimization and you can still combine it with your current strategies!

MiningMath has no pre-defined assumptions in order to identify the cut-off limit, which is based on a math optimization considering a discounted cash flow while respecting production capacity, blending constraints, vertical advances, widths, and any other assumption. Another key aspect in this regard is that MiningMath is not constrained by fixed pits, pushbacks, or phases. Instead, the mining sequence is an optimized output, which is a consequence of each set of parameters used, allowing more flexibility to find completely new solutions. The advantages of these differences are even more evident for more complex cases with multiple destinations, or complex constraints that could be neglected, hiding opportunities.

As the algorithm here has no manual destinations appointments, it always sends the less valuable blocks to the dump, considering the set of constraints imposed, what means that MiningMath tries to comply with all the constraints inserted, by respecting this priority orderto define an optimized cut-off that can meet all of the requirements and increase the NPV as a consequence of a global optimization. Meanwhile, blocks that have positive values when processed can also be discarded to increase NPV based on the minimum economic value (economic value cut-off) going to the plant at that a specific period. Scenarios without stockpiling policy could have even higher positive values going to the waste since they do not have any other destination. Considering these examples, MiningMath can deliver quite different results from what you were expecting from your previous assumptions. However, you can also get closer, as much as you wish, to any solution by using the approaches suggested below.

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 use either to compare different approaches, to understand the practical effects of using it, or not, etc. The approaches mentioned could also be used to forbid any material type on the plant, and the use of the item 2.1. could even reduce the complexity of the algorithm, since it could use fewer constraints to deal with it.

## Using Economic Values

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 it is shown in Figure 1, 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]

Figure 1: Block model setup to incorporate cut-off grades when defining economic values.

## Using Average tab

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 viewed in Figure 2Once again, the math is:

Ore_Grade1 = If [Ore_Grade] < [0.5], then [-999,999,999.00], else [Ore_Grade]

Figure 2: Block model setup to incorporate cut-off grades using average.

## Using Sum tab

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 is seen in Figure 3. 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]

Figure 3: Block model setup to incorporate cut-off grades using sum.

## Understanding results

The mined blocks file, as seen in Figure 4, 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. Check process economic values of those blocks, which were processed, identify the lower one (which means the cut-off value at the plant), and compare it 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, which are 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 change the destination of the block at any period.

Figure 4: Mined blocks output file.

## 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. The average grade that delineates whether blocks are classified as ore or waste will be a dynamic consequence of the optimization process.

## Destinations required

MiningMath requires two mandatory destinations at least:

Therefore, each block must be associated with:
• 1 Economic value for the processing plant

• 1 Economic value for the waste dump

• 1 Processing stream

• 1 Waste dump

Notes:
• 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.

## Calculation

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
• Block Tonnes = BlockVolume * BlockDensity

• Block Tonnes  = 30*30*30*[Density]

###### Tonnes Cu
• Tonnes Cu = Block Tonnes x (Grade Cu/100)

• Tonnes Cu = [BlockTonnes]*([CU]/100)

###### Mass Au
• Mass Au = Block Tonnes x Grade Au

• Mass Au = [BlockTonnes]*[AU]

###### Economic Value Process
• 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.6)) – ([BlockTonnes] * (4.00 + 0.90))

###### Economic Value Waste
• 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.

## Data Validation

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 an efficient workflow to structure your project. It is important to mention that you can run each topic of this content individually at any time you find suitable, but, we strongly recommend you to take it step by step to understand the main idea of the process

The next pages use the example below within Marvin Deposit and aim to exemplify the following set of constraints:

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)
150m per year
Limited until 0.7%
Minimum Mining Width
50m
Minimum Bottom Width
100m
Restrict Mining Surface
Surface-RM-offset-400m.csv
Due to a processing plant in the area
Fixed Mining (Stockpiling)
0.9$/t Rehandling cost (Stockpiling) 0.2$/t

Table 1: Set of constraints example.

## Validate it First

In order to validate your data and cut its runtime, we strongly recommend running MiningMath Full with a bigger production capacity than the expected reserves. Thus, you will get and analyze results faster. This execution also generates the topography surface so that you can create a force or restrict mining areas.

Example:

• The expected life of mine vs production rate: 35-year project producing 10 Mt per year.

• Expected reserve: 350 Mt.

• Set up a scenario with 1,000 Mt in the processing plants per period without stockpiles and any other constraint.

• Timeframe: Years (1), since it would all be processed in 1 period.

## Questions:

• Did the scenario run properly?

• Are most of the positive economic values from the process inside this surface?

• Is the mining happening in reseanable areas?

• Is there a reasonable number of periods of life of mine?

## Constraints Validation

Continuing the 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.

Example:

• 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.

• 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.

## Let's make everything clear

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.

## Exporting the Model

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.

## Freely disclosed datasets

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.

## DB Information

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

## Economic Values

• Process Function = BlockSize * Density * [GradeCU/100 * RecoveryCu * (SellingPriceCU – SellingCostCU) + GradeAU * RecoveryCu * (SellingPriceAU – SellingCostAU) - (ProcessingCost + MiningCost)]
• Waste Function = BlockSize * Density * MiningCost

## DB Information

Below 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 (15ft)
AU - Selling Price
900 $/oz AU - Recovery 0.90 Mining Cost 1.32$/ton
Processing Cost

## Current Best Practices

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:

1. Nested pits: when finding nested pits it is possible to employ the Lerchs-Grossmann (LG) algorithm, the Pseudoflow algorithm, destination optimization, direct block scheduling, or even more recent  heuristic mechanisms.
2. Pushback definition: having the nested pits defined, the next step would usually be to perform the definition of pushbacks in a manual way by some expert mine planning engineers using a number of empirical rules.  Automatic ways focused on NPV optimization could also be employed for pushback design, but these are usually under resource constraints and do not consider enough geometric requirements.
3. Schedules: finally, starting from a chosen pushback, the scheduling is performed. A myriad of techniques can be employed for that, such as direct block scheduling, genetic algorithms, (fuzzy) clustering algorithms, dynamic programming, and heuristic methods in general. All with different rates of success, but limited variety of solutions due to the single pushback input.

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, 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 these issues through math optimization models that integrate multiple areas of the business. 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 Uniqueness

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.

## How can it be used?

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.

##### 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.

###### Discounted Cash flow x Undiscounted Cash flow

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.

##### Pushbacks

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.

##### Schedules

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.

##### Decision Trees

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.

## Guaranteed Solutions

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 infeasible 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.

The constraints priority order, from the highest to the lowest, is depicted in Figure 1.

1. Force+Restrict Mining together using the same surface.

2. Force or Restrict Mining, same concept as above, but the surfaces here are corrected according to slopes and it might have some differences.

3. Minimum Bottom and Mining width, mining length.

4. Total Production Capacity

5. Average and Sum, modeled as strong penalties in the objective function

6. Time limit

7. Improve the NPV

Figure 1: Constraints hierarchy order.

## Theory Validation

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 ©.

## In-depth Algorithm

MiningMath has a flexible algorithm that 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, 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 [1] [2] , instead of usual block precedences. Block precedence methods might lead to higher errors [3] , 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.

## Algorithm’s flowchart and mathematical formulation

MiningMath employs an innovative mathematical formulation and powerful proprietary Branch & Cut algorithm. A description of this mathematical formulation and the three main steps of the algorithm employed are given below.

## Step 1: Initial assessment

The first step 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.

## Step 2: Problem linearization and optimization

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.
• $S$: number of simulated orebody models considered
• $s$: simulation index, $s = 1,...,S$
• $D$: number of destinations
• $d$: destination index, $d = 1,...,D$
• $Z$: number of levels in the orebody model
• $z$: level index, $z = 1,...,Z$
• $T$: number of periods over which the orebody is being scheduled and also defines the number of surfaces considered
• $t$: period index, $t = 1,...,T.$
• $M$: number of cells in each surface; where $M = x \times y$ represents the number of mining blocks in x and y dimensions.
• $c$: cell index, $c = 1, \ldots ,M$.
• $G$: number of unique destination groups defined. Each group might contain 1, all, or any combination of destinations.
• $g$: group index, $g = 1, \ldots ,G$.
• $x_{c,t,d}^{z}$: simulation-independent binary variable that assumes 1 if block $(c, z)$ is being mined in period $t$ and sent to destination $d$, and 0 otherwise.
• $e_{c,t}$: simulation-independent continuous variables associated with each cell $c$ for each period $t$, representing cell elevations.
• $\overline{f_{t,g,s}},\underline{f_{t,g,s}}$: continuous variables to penalize sum constraints violated for each period, group of destinations, and simulation. One pair of variables is necessary for each quantifiable parameter modeled block by block whose sum is being constrained. An example would be variables used to control fleet hours spent in different periods, groups of destinations, and simulations. More information about possible parameters here. Note also that the software allows the control of the average of simulations, instead of dealing with each simulation individually, and the control by the sum of destinations, instead of each destination individually.
• $\overline{\alpha_{t,g}},\underline{\alpha_{t,g}}$: user defined weights for variables $\overline{f_{t,g,s}},\underline{f_{t,g,s}}$ with the same destination group $g$ and period $t$. These can only be defined in the .ssscn files.
• $\overline{j_{t,g,s}},\underline{j_{t,g,s}}$: continuous variables to penalize average constraints violated for each period, destination, and simulation. One pair of variables is necessary for each quantifiable parameter modeled block by block whose average is being constrained. An example would be variables used to control the average grade of blocks mined in different periods, destination groups, and simulations. More information about possible parameters here. Note also that the software allows the control of the average of simulations, instead of dealing with each simulation individually, and the control by the sum of destinations, instead of each destination individually.
• $\overline{\beta_{t,g}},\underline{\beta_{t,g}}$: user defined weights for variables $\overline{j_{t,g,s}},\underline{j_{t,g,s}}$ with the same destination $d$ and period $t$. These can only be defined in the .ssscn files.
• $e_{c,t} \in \mathbb{R},\,\,$  $t = 1,...,T$,$c=1,...,M$
• $x_{c,t,d}^{z} \in \{0,1\},\,\,$  $c=1,...,M$, $t = 1,...,T$, $z=1,...,Z$, $d=1,...,D$
• $\overline{f_{t,d,s}},\underline{f_{t,d,s}} \in \mathbb{R_{\geq 0}}$, $t = 1,...,T$, $s=1,...,S$, $d=1,...,D$
• $\overline{j_{t,d,s}},\underline{j_{t,d,s}} \in \mathbb{R_{\geq 0}}$, $t = 1,...,T$, $s=1,...,S$, $d=1,...,D$

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

1. Sum of the economic value of blocks mined per period, destination, and simulation.
2. Average the result by the number of simulations.
3. 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

• $e_{c,t-1} - e_{c,t} \ge 0, c=1,...,M, t=2,...,T$
[caption id="attachment_14191" align="alignnone" width="5532"] Figure 3: Two surfaces (blue and yellow): a) not crossing each other and respecting constraint (2); b) crossing each other and not respecting constraint (2).[/caption]

Intuitive idea

• Adjacent elevations in a single surface need to respect a maximum difference. This maximum will change based on which direction they are adjacent: x, y, or diagonally.

Requirements

• $H_x, H_y, H_d$: maximum difference in elevation for adjacent cells in $x$, $y$ and diagonal directions
• $X_c, Y_c, D_c$: equivalent to $H_x, H_y, H_d$concept, the sets of adjacent cells, laterally in $x$, in $y$, and diagonally, for a given cell $c$, respectively.

Formulation

• $e_{c,t} - e_{x,t} \ge H_x, c=1,...,M, t=1,...,T, x \in X_c$
• $e_{c,t} - e_{y,t} \ge H_y, c=1,...,M, t=1,...,T, y \in Y_c$
• $e_{c,t} - e_{d,t} \ge H_d, c=1,...,M, t=1,...,T, d \in D_c$
[caption id="attachment_14202" align="alignnone" width="5260"] 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

• Surfaces will define when blocks will be mined. For example, blocks between surfaces associated with period 1 and 2, will be mined in period two. A block is between two surfaces if its centroid is between the two surfaces.

Requirements

• $E_{c}^{z}$: elevation of centroid for a given block $(c, z)$

Formulation

• $E_{c}^{z} \times \sum\limits_{d=1}^{D}x_{c,1,d}^{z} \ge e_{c,1}, c=1,...,M, z=1,...,Z$
• $e_{c,t-1} \ge E_{c}^{z} \times \sum\limits_{d=1}^{D}x_{c,t,d}^{z} \ge e_{c,t},$$c=1,...,M, t=2,...,T, z=1,...,Z$
[caption id="attachment_14206" align="alignnone" width="4192"] Figure 5: Distance between centroids above surfaces (green lines) and below surfaces (red lines) respecting constraints (6) and (7). Blue blocks are mined in period 1, while yellow blocks are mined in period 2.[/caption]
Intuitive idea
• Each mined block can only be sent to one destination.
Formulation
• $\sum\limits_{d =1}^{D}x_{c,t,d}^{z} = 1, c=1,....,M, t=1,...,T, z = 1,...,Z$

Intuitive idea

• For each period and destination groups there’s an upper and lower limit of total tonnage to be extracted. Destination groups might be formed by any unique combination of destinations, with 1, many or all. The sum of the tonnage of mined blocks sent to the same group of destinations in the same period must respect these limits.

Requirements

• $T_c^z$: tonnage for a given block $(c, z)$.
• $\overline{T_{t,g}}$: upper limits in total tonnage to be extracted during period $t$ and destinations in group $g$.
•

Formulation

• $\sum\limits_{c=1}^M\sum\limits_{z=1}^{Z}\sum\limits_{d \in g}T_c^z x_{c,t,d}^{z} \le T_{t,g}, t = 1,...,T, g = 1,..., G$

Intuitive idea

• The user can define a certain parameter (i.e. fleet hours spent) associated with each mined block to have its sum controlled. The sum of the values of this parameter associated to each mined block must respect lower and upper bounds for each period, destination groups (optional) and simulation (individually or on average). Destination groups might be formed by any unique combination of destinations, with 1, many or all.

Requirements

• $\underline{F_{t,g,s}},\overline{F_{t,g,s}}$: lower and upper limits, respectively, in sum of user defined parameter to be respected in period $t$, destination group $g$, and simulation $s$.
• $F_{c,d,s}^{z}$: value of user defined parameter related to a given block $(c, z)$ in destination $d$ and simulation $s$.

Formulation

• $\underline{F_{t,g,s}} \le \sum\limits_{c=1}^M\sum\limits_{z=1}^{Z}\sum\limits_{d \in g}F_{c,d,s}^{z}x_{c,t,d}^{z} + \underline{f_{t,g,s}} - \overline{f_{t,g,s}} \le \overline{F_{t,g,s}},$

$t = 1,...,T, g = 1,..., G, s = 1,..., S$

Intuitive idea

• The user can define a certain parameter (i.e. grade) associated with each mined block to be controlled in average. This average is weighted by the block’s tonnage and by an optional, user defined weight. It must respect lower and upper bounds for each period, destination group (optional) and simulation (individually or on average). Destination groups might be formed by any unique combination of destinations, with 1, many or all.

Requirements

• $\underline{J_{t,g,s}},\overline{J_{t,g,s}}$: lower and upper limits, respectively, for average value of user defined parameter to be respected in period $t$, simulation $s$, and destination group $g$.
• $T_{c}^{z}$: tonnage for a given block $(c, z)$.
• $J_{c,s,d}^{z}$: value of user defined parameter of block $(c, z)$ sent to destination $d$ in simulation $s$
• $P_{c,t,d,s}^{z}$: user defined weight for block $(c, z)$ in period $t$, destination $d$, and simulation $s$

Formulation

• $\underline{J_{t,g,s}} \le$$\frac{\sum\limits_{c=1}^M\sum\limits_{z=1}^Z\sum\limits_{d\in g}P_{c,t,d,s}^{z}T_{c}^{z}J_{c,s,d}^{z}x_{c,t,d}^{z}}{\sum\limits_{c=1}^M\sum\limits_{z=1}^Z\sum\limits_{d\in g}P_{c,t,d,s}^{z}T_{c}^{z}}$$+ \underline{j_{t,g,s}} - \overline{j_{t,g,s}} \le \overline{J_{t,g,s}}$

$t = 1,...,T, g = 1,..., G, s = 1,..., S$

Proprietary constraints not disclosed

Intuitive idea
• Surfaces should respect geometric parameters defined by the user, such as minimum bottom width, minimum mining width, and maximum vertical rate of advance, as depicted here.
Formulation
• $Geometric(e_{c,t}) \le \text{geometric restriction}, c=1,...,M, t=1,...,T$

## Step 3: Integer, non-linear solution and evaluation

The next step is to convert the linear solution to an integer, non-linear one. MiningMath’s Branch & Cut algorithm 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:

1. restrictions are violated due to transformation from linear to integer, non-linear solution, or due to problem being infeasible.

2. 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.

## Pseudo-code

The whole process, from input to output is summarized in the psudo-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.

				
INPUT: Block model,
Mining parameters,
Optional time limit T
OUTPUT: Excel report summarizing the main results of the optimization,
Outputs of mining optimization, topography, and pit surfaces using
.csv format that can also be imported into other mining packages.

EXECUTE initial assessment // Step 1
CREATE problem linearization P // Step 2
SET CURRENT_SOLUTION to empty
SET FEASIBLE_SOLUTION to empty
REPEAT // Step 3
SOLVE P // Optimization engine + proprietary Branch & Cut algorithm
SET LS to the integer, linear solution of P
TRANSFORM LS to an integer, non-linear solution RS

// Evaluate RS
IF RS has no violated constraints THEN
SET FEASIBLE_SOLUTION to RS
ENDIF

IF RS is better than CURRENT_SOLUTION THEN
SET CURRENT_SOLUTION to RS
ENDIF

// Evaluate if new iteration is necessary
IF FEASIBLE_SOLUTION is empty THEN
// Step 2 and Figure 6
CREATE new problem linearization P
with flexible constraints
CONTINUE // Go back to loop's start
ELSE IF T has been reached
BREAK // Leave loop
ELSE IF RS has violated constraints that were unviolated in LS OR
has constraints that can be discarded/modified THEN
CREATE new problem linearization P // Step 2
CONTINUE // Go back to loop's start
ELSE
BREAK // Leave loop
ENDIF
WHILE TRUE
EXPORT reports and outputs from CURRENT_SOLUTION




## Destination Policy of MiningMath

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 NPVrespecting, 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.

## Renaming

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.

## Process Recovery

Figure 3 shows the recovery panel, which is intended to input recoveries used during economic value calculationThe difference is that now it is for reporting purposes, which means it is not being considered twice.

## Economic Value

Figure 4 highlights the Economic Value panel. Here, the user can assign each economic function to the proper destination.

## Stockpile limits

As shown in Figure 5, stockpile limits are available only for processing streams, if activated in the General tabThese limits are valid for the life of mine.

## Mineral Processing

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.

## Recovery

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.

## How and where?

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.

## Why?

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.

## How?

When editing the data set, the user can add as many columns as needed, defining recoveries for each blockFigure 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.

## Step-by-step

The following video presents how to use a different recovery for each block.

Video 1: Varying recoveries for each block.

## How MiningMath deals with Stockpiles

Stockpiles are a post-processing unit of the algorithm. Therefore, after the optimization, which generates mining surfaces, the algorithm does its analysis among the discarded blocks. MiningMath checks if the block’s values (Revenue – Fixed Mining Cost – Rehandling Cost) is higher than the cost of discarding it, with the respective discount rates applied at the period of extraction and period of processing. Therefore, the stocks are considered as an optimization of the blocks that initially went to the dump.

When choosing the destination, the same logic of maximizing the project value is used and MiningMath will define which discarded blocks will be reclaimed, complementing production shortfalls over time, Figure 1 shows the process.

## Stockpiles setup

To enable the stockpiles on the interface the first step is on the General tab (Figure 2) where two inputs are required:

• Fixed Mining Cost: value used to decompose the economic value while considering stockpiles;

• Rehandling Cost: represents the cost to reclaim blocks from the stockpile to the process.

After that, on the Destinations tab, you can define stockpile limits (Figure3) for each processing plant added, remembering that this limit is based on the life of mine, not in a period timeframe.

Defining a Fixed Mining Cost is required because MiningMath does have an interface to enter these parameters when calculating the economic values. It is only used to decompose the block value so that the algorithm can make proper calculations to adjust values considering that part of its costs will occur when mined, while others may be charged when processed.

The Rehandling Cost is the cost to reclaim a block from a stockpile. Therefore, it is the way to break the Economic Values into parts and apply the discount rate at the time a block is processed.

##### Disclaimer: stockpiles and total tonnage

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.

## Tracing Stocked Blocks

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.

Currently, SimSched reclaims blocks selectively from stockpiles according to the highest Economic ValuesRead more about Reclamation Policy.

## How to trace blocks?

The user can analyze SimSched’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

Artificial Stockpiles is an advanced operation to incorporate external sources of material to your model and use them as an input on your scheduling.

## Related common needs

This artifice may be required for cases when the user needs to include into the optimization, any of the following cases:

• 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.

## How to incorporate artificial stockpiles

Two main ways to do it:

• Modelling the stockpile with its actual geometry.

• Creating a simplified artificial stockpile.

## Modelled Stockpile

Modelling an existing stockpile with its actual geometry is the best alternative to include it to the scheduling for cases where you need an operational control over:

• The stockpile and its adjacent areas.

• The stock reclamation.

For this process, use a modelling software to perform the following steps:

1. Use the previous topography for the base of the stockpile.

2. Use the current topography for the top of the stockpile.

3. Create blocks in-between these surfaces. These blocks will have the same size of the block model.

4. Assign an average quality (grade) and density to each block created.

5. Calculate the economic values for these stocked blocks.

6. Import the model back to SimSched to further scheduling.

## Simplified Stockpile

For a quicker process, the user can create as many blocks as needed using a spreadsheet application.

This is an alternative useful for cases where you need:

• A quicker process and evaluation.

• Less operational control.

## Rows vs Columns

You can model artificial stockpiles as rows or as columns.

## Rows

• To control a sequence, it may require surface constraints.

• A 1-line row will be affected by minimum widths used for the scenario.

• Thin rows may cause problems to be mined completely.

• Easier setup. Rows don't need geotechnical adjustments.

• Multiple rows 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.

## Columns

• Easier sequence. The precedence is defined by the vertical geometry.

• A 1-line column will be affected by minimum widths used for the scenario.

• Long columns may affect how deep the scheduling can go in a single period.

• Columns require a very vertical slope angle set to them and to the adjacent cells.

• 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.

## Step-by-step (rows)

1. Create rows of blocks above the topography (Figure 1).

2. Assign an average quality (grade) and density to each block created.

3. Calculate the economic values for these new blocks.

4. Import the model back to SimSched to further schedules.

## Requirements and observations

Consider checking the following requirements and observations.

Notes on modelling:

• The blocks created must have the same size of the ones from original model.

• Consider increasing densities for the blocks created to represent more material with a few blocks. The trade-off is a reduced selectivity.

• The more blocks you have, the more selective is the algorithm.

Notes on operational needs:

• The blocks created will be subject to the operational constraints, such as widths and vertical advance, from your scenarios. This means you need to consider these parameters to define:

• The stockpile base width.
• The stockpile height.

Notes on the placement within the model

The artificial stockpile should be placed in a peripheral area of your model to not affect the open-pit schedule.

Avoid borders to prevent any geotechnical issue, which will impede mining the artificial stockpile completely.