362
in Constraint (15) indicates the set of blocks allocated to shovel s. Constraints (18) and (19)
ensure that blocks are extracted in the specified order, and that the time taken to move the
shovel from one block to another (if any) is accounted for. Constraint (20) forces the entire
volume of the target to be removed before it can be marked as finished
1
.
t T
t b
x
b
s
t b
B
∑
∈
,
(13)
t T
f
t b
x
b
f
t b
B
∑
∈
,
(14)
b
t b
s
x
t
t b
T s S
∈
∑ ≤ ∀ ∈ ∈
T s
Γ
,
,
(15)
x
x
x
x
t T b B
t b
t b
s
t b
f
t b
,
,
b
t
,
,
b
t
,
=
+
x t b
−
∀
x
f
t b
T b
,
(16)
x
b B
b
−
∈
1,
(17)
x
x
t T
b B if w exists
s
t b
f
t
w
b
b B if w
b
b
w
,b
t b
\
=
∀
x
f
t
w
∈ T \ {
}
b
,
}
{
, b
…
,
b
b
δ b b −
,
…
,
b b b
(18)
x
b B
s
t b
,
,
∀ {
}
b
, ,
…
,
−
0
t
∀ ∈ {
δ b b
(19)
a x
a v
t T b B
b
f
t b
b
t
v b
,
,
b
b
t
,
≤ −
a
∀ ∈
t
(20)
4 NUMERICAL RESULTS
To evaluate the performance of the Flow Planner, we run it on a conceptually generated mine.
The entire code was written in Python and run on a personal computer with Intel Core i7
CPU at 3.40 gigahertz, 16 gigabytes of RAM, operating under Microsoft Windows 7. Gurobi
7.5 was used to solve our MIP.
While the data for our instance is conceptual in nature, it is based on real operational
scenarios with block size, tonnages, grades, resource limitations and sequencing interactions
reflective of real-world open pit mining operations.
4.1 Initial scenario
The scenario consists of two excavators, five blocks, and five dumps (three process plants and
two stockpiles). Blocks B1 and B2 are assigned to one of the excavators, and blocks B3, B4,
and B5 are assigned to the other one. The planning time is a 12-hour shift, and blocks B1, B3
and B4 are high priority blocks in that the penalty of not digging them by the end of the shift is
higher—in practise, this might be due to the fact that the grade in the block is important in that
shift, or it is a waste block that must be removed to reach an important block. The other input
data can be seen in Figure 1, which shows the optimal flow rates calculated by Flow Planner.
Figures 1(a) and 1(b) show an upper graph for the total flow rate out of the excavator, and one
or more graphs below this for the flow of each block to each dump. The lower graphs sum to
the total in the top graph. In Figures 1(a)–1(c), the red lines on dig/dump flow rates indicate the
maximum flow rate capacity of the excavator/dump; the flow rates are constrained by this value.
The dashed red line on the summary graph (Figure 1(d)) shows the total truck capacity.
The whole system is constrained by this, with the total truck capacity shared amongst all
material flows at any point in time. The dashed green line is the total truck utilisation, and
in time periods where this is equal to the dashed red line, the system is truck-constrained.
The legend in each graph shows, for each flow target: 1) Target: the total target for the shift;
1. If block-switching is desirable, small repeated production targets can be specified, or a block specified
in the optimisation could represent a local mix of real-world mining blocks.
in Constraint (15) indicates the set of blocks allocated to shovel s. Constraints (18) and (19)
ensure that blocks are extracted in the specified order, and that the time taken to move the
shovel from one block to another (if any) is accounted for. Constraint (20) forces the entire
volume of the target to be removed before it can be marked as finished
1
.
t T
t b
x
b
s
t b
B
∑
∈
,
(13)
t T
f
t b
x
b
f
t b
B
∑
∈
,
(14)
b
t b
s
x
t
t b
T s S
∈
∑ ≤ ∀ ∈ ∈
T s
Γ
,
,
(15)
x
x
x
x
t T b B
t b
t b
s
t b
f
t b
,
,
b
t
,
,
b
t
,
=
+
x t b
−
∀
x
f
t b
T b
,
(16)
x
b B
b
−
∈
1,
(17)
x
x
t T
b B if w exists
s
t b
f
t
w
b
b B if w
b
b
w
,b
t b
\
=
∀
x
f
t
w
∈ T \ {
}
b
,
}
{
, b
…
,
b
b
δ b b −
,
…
,
b b b
(18)
x
b B
s
t b
,
,
∀ {
}
b
, ,
…
,
−
0
t
∀ ∈ {
δ b b
(19)
a x
a v
t T b B
b
f
t b
b
t
v b
,
,
b
b
t
,
≤ −
a
∀ ∈
t
(20)
4 NUMERICAL RESULTS
To evaluate the performance of the Flow Planner, we run it on a conceptually generated mine.
The entire code was written in Python and run on a personal computer with Intel Core i7
CPU at 3.40 gigahertz, 16 gigabytes of RAM, operating under Microsoft Windows 7. Gurobi
7.5 was used to solve our MIP.
While the data for our instance is conceptual in nature, it is based on real operational
scenarios with block size, tonnages, grades, resource limitations and sequencing interactions
reflective of real-world open pit mining operations.
4.1 Initial scenario
The scenario consists of two excavators, five blocks, and five dumps (three process plants and
two stockpiles). Blocks B1 and B2 are assigned to one of the excavators, and blocks B3, B4,
and B5 are assigned to the other one. The planning time is a 12-hour shift, and blocks B1, B3
and B4 are high priority blocks in that the penalty of not digging them by the end of the shift is
higher—in practise, this might be due to the fact that the grade in the block is important in that
shift, or it is a waste block that must be removed to reach an important block. The other input
data can be seen in Figure 1, which shows the optimal flow rates calculated by Flow Planner.
Figures 1(a) and 1(b) show an upper graph for the total flow rate out of the excavator, and one
or more graphs below this for the flow of each block to each dump. The lower graphs sum to
the total in the top graph. In Figures 1(a)–1(c), the red lines on dig/dump flow rates indicate the
maximum flow rate capacity of the excavator/dump; the flow rates are constrained by this value.
The dashed red line on the summary graph (Figure 1(d)) shows the total truck capacity.
The whole system is constrained by this, with the total truck capacity shared amongst all
material flows at any point in time. The dashed green line is the total truck utilisation, and
in time periods where this is equal to the dashed red line, the system is truck-constrained.
The legend in each graph shows, for each flow target: 1) Target: the total target for the shift;
1. If block-switching is desirable, small repeated production targets can be specified, or a block specified
in the optimisation could represent a local mix of real-world mining blocks.