1. Scenario Setup
1.1 Model tab
The software automatically starts on the Model screen, as shown in Figure 1.
Then, in the Recent Projects list, expand your selected project and double-click the scenario you want to work with.
Figure 1: Recent Projects list.
1.2 General Parameters
MiningMath automatically switches to the Scheduling screen in the General tab once a scenario is opened, as shown in Figure 2. The General parameters used in the Marvin cases are summarized below:
Default value: 2.75 t/m³.
Default value: 45 degrees.
Discount rate: 10 %.
Fixed mining cost: 0.9 $/t.
Rehandling cost: 0.2 $/t.
Figure 2: General tab and general parameters.
Field boxes for density and slope angle allow using data varying by block. The user must import such columns and assign them to the proper field type in order to enable them on the interface. Default values are mandatory fields and will be used in case the field is set to <none> or if there are blocks without information in the selected field.
The Discount rate is an obligatory field that considers a periodic (monthly, yearly, etc.) discount rate to calculate the discounted cash flow for each period. We used a 10% annual discount rate for this example.
Optionally, the user can use Stockpiles, which enables two mandatory fields:
Fixed mining cost is the average mining cost used for the economic function. This cost is informed just to recognize the value used before and then do reverse engineering to calculate NPV for stocked blocks.
Rehandling cost represents the cost to reclaim blocks from the stockpile to the process. This is an additional cost, that should not be present in the economic values.
After entering the required parameters, the destinations option on the toolbar will be enabled and it must be clicked.
1.3 Destinations: Process, Dump, and Stockpile
On the Destinations tab, the user 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.
1.3.1 Process & Dump
To add destinations, in the bottom corner of the window, click on:
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.
This value on the interface serves only for purposes of generating reports, as it has been considered during the economic calculation. Use the following values for the processing stream:
The user can also define a tonnage limit for the stockpile if activated in the General tab (see Step 2).
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 <unlimited> capacity to stock. Read more about stockpiles.
Figure 3: Destinations tab, Recoveries for each element/mineral and destination, and Stockpile limit in tonnages.
1.3.4 Economic Value
In the column of Economic value, the user 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 4 zooms in the destination fields, showing how they should look like for this example.
Figure 4: Economic values for each destination.
1.4 Production Inputs
After completing the previous fields, move to the Production tab. The user can define limits (in tonnes) for each destination and for the total amount of material moved per period and also add different time frame ranges in the optimization.
For this example, use the following values (as shown in Figure 5):
Process 1: 30,000,000 t
Dump 1: 50,000,000 t
Total: 80,000,000 t
Figure 5: Production tab and production limits for each destination.
1.5 Geometric Inputs
On the Geometric tab, the user can define parameters intending to find mathematical solutions that already consider basic requirements to be operationally feasible.
Figure 6 highlights (1) operational fields:
As well as (2) optional fields:
Figure 6: Operational constraints.
For this example, use the constraints shown in Figure 7, also listed below:
Mining: 50 m
Bottom: 90 m
Vertical rate of advance
Maximum: 150 m
Figure 7: Operational constraints zoomed in.
On MiningMath, the user can 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 and allow the user to impose one's understanding and take control of prior results and operational aspects.
Using surfaces, the user is 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 tutorial.
When comparing MiningMath with software that works with Lerchs-Grossmann, you will probably need to adopt fair parameters in order to obtain reasonable conclusions. In this case, it is suggested you use small values for minimum widths and great values for Vertical Rate of Advance on MiningMath, making it less operational as the traditional ones.
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 want to input a cut-off a good way to do it is by filtering these blocks and assigning the mass of them as a sum field as mentioned here.
Figure 8: Blending constraints.
Figure 9: Other constraints.
Click in Overview, for a single page summary of all parameters related to the direct block scheduling, as illustrated in the figure below.
The Save as option can be used to redefine name and description for an edited scenario. With this functionality, the user is able to play with parameters and save different scenarios without losing previous results.
Figure 10: Overview screen for final verification of inputted parameters.