1 Introduction
2 Literature review
2.1 Project scheduling software
2.2 Project scheduling of nuclear facility dismantling
2.3 General project scheduling approaches
3 Problem description
3.1 Definition
3.2 Mathematical and constraint programming model
-
a set of activities A
-
a set of renewable resources \(\mathcal {R}\)
-
a set of non-renewable resources \(\mathcal {R}^n\) as in theMRCPSP (Mika et al. 2015)
-
a set of modes \(M_i\) for each activity \(i \in A\)
-
a set of precedence relations \(E \subset A \times A\) among the activities
-
a set of no-wait precedence relations \(E^{nw} \subset A \times A\) among the activities
-
durations \(d_{im} \in \mathbb {Z}^+_0\) for each activity i and each mode \(m \in M_i\)
-
resource requirements \(r_{imk} \in \mathbb {Z}^+_0\) for each activity i and each mode \(m \in M_i\) and each resource \(k \in \mathcal {R} \cup \mathcal {R}^n\)
-
resource unit cost factors \(c_k \in \mathbb {Z}^+_0\)
-
resource maximum capacities \(a_k^{\max } \in \mathbb {Z}^+\)
-
activity finish bonus/penalty cost factors \(b_i \in \mathbb {Z}\)
alternative
constraint in (12), we ensure that exactly one of the mode interval variables is processed and the start and end time of the corresponding act[i] interval variable coincide. Hence, each activity is processed in exactly one mode. With (13) and (14), we model the normal as well as the no-wait precedence constraints, respectively. The non-renewable resources are considered in (15) where we sum up the resource consumption of all present (i.e. chosen) modes. To model a renewable resource \(k \in \mathcal {R}\), we use a so-called cumulative function \(renewU\!sage_k\) and the pulse
expression in (16). This expression sums up the resource consumption \(r_{imk}\) between the start and end time of the interval variable mode[i, m]. Finally, (17) sets the bounds of the real-valued decision variables that represent the amount of allocated resources like in the MIP model.4 Methodology
4.1 Initial solution generation
i | m | \(d_{im}\) | \(r_{im1}\) | \(ES_i\) | \(LS_i\) | \(b_i\) | C |
---|---|---|---|---|---|---|---|
0 | 1 | 0 | 0 | 0 | 10 | 0 | \(C_0 = \{0\} \) |
1 | 1 | 5 | 2 | 0 | 10 | 0 | \(C_1 =\{1, 2, 3, 4\} \) |
2 | 1 | 3 | 1 | 5 | 15 | 0 | \(C_1 =\{1, 2, 3, 4\} \) |
3 | 1 | 2 | 1 | 5 | 16 | 0 | \(C_1 =\{1, 2, 3, 4\} \) |
2 | 4 | 1 | 5 | 14 | 0 | \(C_1 =\{1, 2, 3, 4\} \) | |
4 | 1 | 4 | 1 | 8 | 18 | 0 | \(C_1 =\{1, 2, 3, 4\} \) |
5 | 1 | 4 | 1 | 0 | 16 | 0 | \(C_2 =\{ 5, 6\} \) |
6 | 1 | 2 | 2 | 4 | 20 | 0 | \(C_2 =\{ 5, 6\} \) |
7 | 1 | 0 | 0 | 12 | 22 | 10 | \(C_3 =\{7\} \) |
4.2 Adaptive large neighbourhood search
freeVar
and varPerMode
. Here, freeVar
limits the total number of decision variables in the MP, and varPerMode
is an upper bound on the number of decision variables introduced for each mode of an activity. If the search encounters a better solution, the neighbourhood size and the iteration time limit are reset to their initial values. The implementation of the ALNS for the MRCPSP in Gerhards et al. (2017) also uses MIP techniques in the recreate step. However, there the neighbourhood size was only defined by the number of decision variables in the MIP and each activity could start at all possible starting times in the MIP. For the instances at hand, the respective MIP would not be solvable in reasonable time, and hence, we saw the need to limit the number of decision variables per activity. Furthermore, in this implementation, we obtain the schedule directly from the MIP without an additional SGS step. The ALNS implementation in Gerhards et al. (2017) used the MIP to obtain priority values for the activities and then translated them with an SGS into a feasible solution. Since constraint programming solvers have become a powerful tool for resource-constrained project scheduling problems (see e.g. Kreter et al. (2018) for a successful implementation of CP for the RIP), we also implement a CP solver as a recreate operator.initFreeVar
), for the number of decision variables for each mode (initVarPerMode
) as well as for the MIP solver time limit of each iteration (initTimePerIteration
). Lastly, the parameters \(\alpha \) and \(\beta \) are used to increase the size of the neighbourhood. In Sect. 5.2.1, we investigate which values for these parameters perform best.freeVar
and varPerMode
are used in the destroy step (see Sect. 4.2.1) as parameters, and timePerIteration
is used in the recreate step (see Sect. 4.2.2). Each iteration of the while loop (lines 5–23) can be divided into three parts: The destroy step (line 7), the recreate step (line 8), and the update and adapt step (lines 9–22).freeVar
and varPerMode
, respectively. The destruction process is explained in further detail in the next subsection.timePerIteration
, we limit the computation time of the solver. More information on how the exact optimiser is used is described in Sect. 4.2.2.freeVar
is increased by factor \(\alpha \) (line 15). Hence, in the destroy step of the next iteration, more parts of the current solution are destroyed. Also, every second iteration, we increase the parameter varPerMode
by factor \(\beta \) (lines 16–18) to enlarge the size of the destroyed parts. We extend the time for the MIP or CP solving (lines 19–21) since the neighbourhood that is investigated in the following iteration is larger. We set the time limit to the actual computation time of the current iteration and add one extra second. This is done because we expect a longer computation time for the increased neighbourhood; thus, we need to limit the overall computation time.4.2.1 Destroy operators
freeVar
, and the number of variables per mode varPerMode
as input parameters. The corresponding number of decision variables of such a destroyed candidate depends on the number of modes and possible starting times of the chosen activities.varPerMode
. Basically, we want to set \(ES^d_i\) and \(LS^d_i\) to such values that they form an interval with the old start \(s_i\) in the middle of it. The size of the interval is not larger than varPerMode
, i.e. \(LS^d_i - ES^d_i \le varPerMode\). Hence, we initially set \(ES^d_i := s_i - \frac{varPerMode}{2}\) and \(LS^d_i := s_i + \frac{varPerMode}{2}\). We adjust the borders of the interval if they extend over the earliest or latest starting times calculated by CPM (\(ES_i\) and \(LS_i\), see also 3.2). Hence, if \(ES^d_i < ES_i\), we shift the interval to the right by increasing \(LS^d_i\) by \(ES_i - ES^d_i\) and setting \(ES^d_i = ES_i\). Similarly, if \(LS^d_i > LS_i\), we shift the interval to the left by decreasing \(ES^d_i\) by \(LS^d_i -LS_i\) and setting \(LS^d_i = LS_i\). However, if both cases appear simultaneously, i.e. \(ES^d_i < ES_i\) and \(LS^d_i > LS_i\), we assign the earliest and latest starting times calculated by CPM. After a shift, the old start \(s_i\) may not be in the centre of the interval formed by \(ES^d_i\) and \(LS^d_i\) but it is still contained in the interval.freeVar
has been exceeded. All remaining activities are fixed activities. Hence, the sum of decision variables corresponding to a destroyed candidate is calculated as follows and has to be lower than or equal to the parameter freeVar
:DTI
). The main idea is to select activities that are processed in similar time periods. First, a random time period \(t \in \{1, \dots , c^{\max }\}\) is chosen with equal probability. Here, \(c^{\max }\) denotes the makespan of the current schedule and a period t starts at time \(t-1\) and ends at t. We use a time period to identify which activities are selected as free with initial lower bound \(t-1\) and upper bound t. Iteratively, DTI
selects free activities that fulfil one of the following criteria:-
The starting time point of the activity is contained in the time period.
-
The finish time point of the activity is included in the time period.
-
The time period contains both the start time point and the finish time point of the activity.
freeVar
, we increase the original interval. To make more activities eligible for selection in the next iteration, we increase the interval by 5 time units in both directions in order to speed up the selection process. The activity selection and interval enlargement alternation is repeated until either the bound freeVar
of corresponding variables is reached or all activities are selected. All activities that have not been selected are fixed activities in the destroyed candidate. Hence, the free activities all have relatively close-by starting or finish time points, and the change of the mode or starting time point of one of them will most likely influence the others.DPS
), exploits the precedence relations among activities. Iteratively, we select a random strong component \(C \in \mathcal {C}\) that has not been selected before and mark all activities belonging to it as free. Then, we also select all strong components that contain successor activities or predecessor activities of the current component’s activities and mark their activities as free in this order and if they were not marked previously. Furthermore, we also consider transitive successors and predecessors in this selection process, i.e. if \((i,j) \in E\) and \((j,k) \in E\), then k is a transitive successor of i. We repeat this procedure with another random strong component until the limit freeVar
is reached or exceeded. Again, all activities that have not been selected are fixed. Here, we want to focus on activities that have precedence relations between them since they often limit the starting or finish time. In the case of the no-wait precedence relations \(E^{nw}\), changing the start of one activity has effects on all activities in the same strong component, and thus, the solver can explore the neighbourhood more effectively if all activities of the strong component are free.4.2.2 Recreate operator
timePerIteration
. The recreate operator returns a feasible solution candidate \(c^{p}\).varPerMode
only a subset of the possible starting times. By design of the destroy operators, the total number of decision variables in the MIP is smaller than or equal to the parameter freeVar
. Similarly, in the CP case, we setup the formulation presented in (11)–(19). Here, we restrict the earliest start and finish times of the interval decision variables in (18) and remove the mode interval variables displayed in (19) if they are not present in the destroyed candidate.timePerIteration
to limit the running time for solving the MP. This is done to save time that could be wasted by the exact solver by proving the optimality of a solution.-
The current solution candidate is already optimal, but we do not know it since the lower bound information of the solver is only for a subproblem and not for the original problem.
-
The current solution candidate is locally optimal for the current neighbourhood defined by the destroyed candidate but a better solution candidate exists in a larger neighbourhood.
-
The solver was not able to find a better solution in the current neighbourhood because the iteration time limit
timePerIteration
was too small.
5 Case study
5.1 Real-life projects data
5.2 Computational experiments
5.2.1 Calibration of the algorithm parameters
irace
software package of the statistical computing software R to tune the algorithm parameters (cf. López-Ibáñez et al. (2016)). This software package performs iterated racing which is an extension of the iterated F-racing algorithm proposed by Birattari et al. (2010). The parameters of the MLS and ALNS algorithm were calibrated in separate irace
experiments. Furthermore, we distinguished between an ALNS using MIP methods (ALNSMIP
) and one using CP methods (ALNSCP
). For each calibration, we specified the maximum number of experiments, the time limit of a single experiment, and the possible values for each algorithm parameter. Here, it is especially important to balance the portion between total calibration time and gained precision of the estimated parameter values. Therefore, we limited the running time of the single experiments in order to speed up the calibration experiments to lower values than in the long-run experiments in Sect. 5.2.2. The comparison in Sect. 5.2.3 clearly shows that the proposed methodology outperforms a standard MIP solver. Longer calibration experiments would merely further improve the results of the MLS and ALNS.irace
calibration run shows that \(p^M = 0.04\) and \(p^S = 0.19\) performs best on the training data. Hence, we use this parameter configuration in the following experiments.irace
software package with the following parameter choices:-
initFreeVar
\(\in [1\,000, 100\,000]\) -
initVarPerMode
\(\in [10,5\,000]\) -
\(\alpha \in [1,1.5]\)
-
\(\beta \in [1, 1.5] \)
-
initTimePerIteration
\(\in [0.1, 10]\) -
\(P=\{p_1, p_2\}\) with \(p_1 \in [0,1]\), \(p_2 = 1-p_1\)
DTI
and DPS
, respectively. For each instance of the training set, we computed an initial solution by applying the MLS with the parameters calibrated above and a running time of 1 second. We set a fixed maximum running time of 600 seconds for each ALNS run in the calibration experiments and performed 2 000 ALNS runs for both the MIP and the CP version. Again, this was done to speed up the calibration process but we expect the calibrated parameters to be appropriate for longer running times of the ALNS as well. The irace
experiment results are depicted in Table 2.ALNSMIP | ALNSCP | |
---|---|---|
initFreeVar | 4 827 | 96 742 |
initVarPerMode | 82 | 3 369 |
\(\alpha \) | 1.45 | 1.32 |
\(\beta \) | 1.07 | 1.08 |
initTimePerIteration | 9.14 | 6.75 |
\((p_1,p_2)\) | (0.86, 0.14) | (0.22, 0.78) |
ALNSCP
. Since the parameter \(\texttt {initVarPerMode}\) is chosen rather large, a small value for its adoption rate \(\beta \) is efficient. The destroy operator DTI
, which is focusing on specific time intervals in the current schedule, seems to be more efficient for the MIP version, and therefore, it is selected with a higher probability. For the CP version, it is the other way around and the DPS
operator is chosen with a higher probability.BWR | Large | |||||
---|---|---|---|---|---|---|
Method / Running time | 60 | 600 | 3 600 | 60 | 600 | 3 600 |
\(\texttt {MLS}_{1}{} \texttt {ALNSCP}\) | 5.68% | 5.68% | 5.68% | 2.98% | 2.90% | 2.89% |
\(\texttt {MLS}_{60} \texttt {ALNSCP}\) | – | 5.68% | 5.68% | – | 2.89% | 2.89% |
\(\texttt {MLS}_{1\,800} \texttt {ALNSCP}\) | – | – | 5.68% | – | – | 2.89% |
\(\texttt {MLS}_{1} \texttt {ALNSMIP}\) | – | 5.68% | 5.68% | – | 3.83% | 3.82% |
\(\texttt {MLS}_{60} \texttt {ALNSMIP}\) | – | 5.68% | 5.68% | – | 3.71% | 3.71% |
\(\texttt {MLS}_{1\,800} \texttt {ALNSMIP}\) | – | – | 5.68% | – | – | 3.37% |
CP | 5.68% | 5.68% | 5.68% | 2.98% | 2.91% | 2.88% |
SA | 5.68% | 5.68% | 5.68% | 3.29% | 3.02% | 2.93% |
GA | 5.68% | 5.68% | 5.68% | 3.74% | 3.28% | 3.17% |
MLS | 5.72% | 5.72% | 5.71% | 3.71% | 3.56% | 3.29% |
5.2.2 Main experiments
CP
). It is interesting to see that the application of the ALNS improves the results for the BWR instances only slightly. We suspect that those instances, much like the PWR instances, are in fact solved optimally but the lower bound used in our comparison is too weak for these instances. The standalone CP experiment compute an average relative gap of \(0.47\%\) for these instances, but cannot detect optimality. The ALNS approaches and the standalone CP find the same results and simulated annealing and the MLS perform slightly worse.ALNSMIP
since setting up the time-indexed model required more than 60 seconds for most of the instances.ALNSCP
. It is interesting to see that the MIP solver is not able to cope with the large project instances. Even setting up the MIP model can take several minutes. The CP solver, on the other hand, sets up the model in a matter of seconds and is even able to achieve high quality results without the ALNS framework. The average relative gap computed with the CP lower bound after one hour of computation is \(1.45\%\) for the large project instances. The SA and the GA metaheuristics are superior to the MLS on both the BWR and the large project instances except for a run time limit of 60 seconds where the MLS achieves slightly better results than the GA. Furthermore, the SA performs better than the GA. However, SA is outperformed by ALNSCP
and the standalone constraint programming formulation. Compared to the solutions initially generated with the priority rules, the ALNSCP
procedure was able to improve them by \(0.97\%\) for the large instances and by \(0.09\%\) for the BWR instances. On first glance, this may not sound like much, but the absolute improvement is on average \(4.5\cdot 10^6\) monetary units in the case of the large projects. Hence, utilising our proposed method can help save millions.5.2.3 Evaluation against a MIP solver
ALNSCP
methodology, however, found an even better solution with a gap of \(2.80\%\) with respect to the simple lower bound. This solution is \(1.4\%\) better than the one found by CPLEX with a warmstart. ALNSCP
found the best-known solution after 2 585 seconds.\(\texttt {MLS}_{1}{} \texttt {ALNSCP}\) | NDPSP using CPLEX without warmstart | NDPSP using CPLEX with warmstart | ||
---|---|---|---|---|
PWR | Computation time [Seconds (Minutes)] | 1.33 (0.02) | 514 (8.57) | 215 (3.58) |
Objective function value [€] | 10 129 250 | 10 129 250 | 10 129 250 | |
Relative optimality gap [%] | 0.00 | 0.00 | 0.00 | |
BWR | Computation time [Seconds (Hours)] | 3 600 (1) | 495 509 (137.64)* | 253,753 (70.49)*** |
Objective function value [€] | 15 700 650 | 15 703 700* | 15 700 700*** | |
Relative optimality gap [%] | 5.55 | 0.37* | 0.35*** | |
large | Computation time [Seconds (Hours)] | 3 600 (1) | 434 532 (120.7) | 83 569 (23.21)*** |
Objective function value [€] | 469 928 989 | ** | 474 920 000*** | |
Relative optimality gap [%] | 2.80 | ** | *** |