MiningMath

MiningMath

Loading...

Improve your strategic analysis through risk assessments unconstrained by stepwise processes

Optimization Runtime

Estimated reading: 5 minutes 3267 views

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.

Strategies to reduce the runtime

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

Constraints chosen in the interface for an example with different timeframes.

Use surfaces

A number of surfaces can be used as a guide in order to reduce the complexity of the problem and to achieve better runtime. Remember that surfaces can be imported as combined force and restrict constraints reaching the exact shape of a pit. Some possible surfaces that could be applied for that are described next.

1) Locking Final Periods

Commonly, most of the project’s value is generated in the early mining periods. Due to discounting, the final years of mine life could contribute only marginally to cumulative NPV, while still adding significant computational complexity to the optimization problem.

A practical strategy to reduce runtime is to lock the solution of the final periods based on a previously executed base scenario. Hence, the the quality of early-period decisions remains the same. A recommended criterion could be to lock periods after reaching a high percentage (e.g., 90–98%) of cumulative NPV, ensuring that optimization effort remains focused on the years that drive the most project value.

2) Surfaces from validation

The tutorial steps of validating data and constraints validations will return initial surfaces that can be used as a reference for the next run, either as Force Mining and/or Restrict Mining constraints.

3) Optimized pushbacks

Another possible approach is to generate optimized pushbacks first. This provides a high-level strategic view with reduced runtime. If the resulting guidance is appropriate, these surfaces can then be applied in a full scheduling scenario to refine the plan. However, keep in mind that this strategy splits the problem into separate stages. By doing so, it reduces some of the key advantages of MiningMath’s Single-Step Optimization, where all decisions are optimized simultaneously in a fully integrated way.

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.

Share this Doc

Optimization Runtime

Or copy link

CONTENTS
Chat Icon

Hi, it's Mima here 😇 Ask me any questions!