Optimization Runtime
The optimization run time is a common concern for professionals dealing with robust models. This page aims to provide context and guidance to improve run times, which might be quite useful for having a big picture of the project’s behavior under different assumptions and hypotheses.
Runtime Barriers
The runtime depends on a combination of multiple aspects. It is directly related to the complexity of the deposit and it is proportional to the number of:
- Blocks.
- Multiple destinations (+3).
- Constraints in use and conflicting goals with the same hierarchy order.
- Variables imported.
- Period ranges.
- Parameters changing over time.
- Multi-mine deposits.
- RAM memory available. You can check it using Windows Task Manager. More details about recommended hardware can be found here.
Often, users are concerned with the limits to handle models with +20M blocks. MiningMath can virtually handle any model size. It has successfully made tests with models up to 240M blocks without reblocking, which took three weeks to run, and over a 32 Gb desktop machine.
Typically, datasets with 5 million blocks take a few hours (in an 8GB RAM machine). In the future, the technology will be capable of concurrently running multiple scenarios on the same computer. There is no need for special servers with extra RAM capabilities for deposits of average size.
Hardware Improvements
Memory
Overall, the main bottleneck for MininingMath is memory consumption. Hardware upgrades that most positively impact the optimization run time are:
- RAM capacity
- RAM frequency
Cores and threads
MiningMath is a single-thread application, which means:
- Additional cores and threads do not affect the optimization run time.
- Processors with higher clock speeds improve the run time.
Multithreading
MiningMath utilizes the linear programming solver provided by CLP to implement the Simplex algorithm. Each execution of CLP utilizes one core/nucleus/processor because Simplex is not easily parallelizable (meaning it can’t run faster by using multiple processors). As far as our studies have shown, there hasn’t been a market solution for this, and scientific research hasn’t yielded very satisfactory results yet.
Strategies to reduce the runtime
Use surfaces
The most recommended strategy is passing through the tutorial steps of validating data and constraints validations then starting using the surfaces as a guide to reduce the complexity, without losing dilution aspects on your approach.
To get such guidance on a broader view with a reduced runtime you can for example create optimized pushbacks. The last step is to get a detailed Schedule since the model has such complexity. If such approaches do not offer a proper runtime, try to get intermediate results by splitting the total production into 2 or 3 periods.
Reblocking
Reblocking is a method used to decrease the number of blocks in a block model by combining some of the smaller blocks to create larger ones. This can be done using MM Labs as described here.
Note: when reblocking your model it is important to evaluate dilution aspects that can be lost by increasing the block size.
Time limit
It is possible to indicate a time limit in hours before running a scenario. The time limit is defined in hours due to the usual complexity of mining projects and by the fact that MiningMath will always try to deliver a reasonable solution.
This is a complex parameter that may not always be feasible to adhere to. It could also hinder the final solution, since it is restricting the algorithm from exploring a broader range of potential solutions. However, even if better results are not obtained, fast solutions will still give you a quicker assessment of your project. To better understand how the time limit works, you can visit this page.
Timeframes
Another strategy to reduce runtime might be the use of timeframes. MiningMath allows the integration between the short and long term visions in the same optimization process, facilitating the analysis and strategic definitions.
For example, it is possible to consider less detail for longer time horizons. Such horizons need to be considered in the overall view of the mine, up to exhaustion, but they consume optimization processing time that can be more focused on the early years of operation. The figure below depicts an example with monthly time frames in the initial periods of the project, transitioning to yearly periods, and extending to decennial periods in the final stages. You can visit this page for more information on how to use timeframes.
