4.9 Matheuristic Variants for the PVRPTW
4.9.2 Hybridizing the Multiple VNS and the Set Covering ILP
Here we investigate a Matheuristic composed of the multiple VNS and again the set covering ILP model. This hybrid variant is conceptually similar to the previous one when using the standard VNS, though the handling of the solutions as well as some details are different. The information exchange between the multiple VNS and the ILP, which can also be regarded an integrative combination, can be seen in Figure 4.8 as well as in Algorithm 14.
Concerning the hybridization with the multiple VNS a natural and suitable way is to apply the ILP solver after a block of section-wise executions. This way the number of solutions to consider for adding to the ILP model is given by the number of VNS instances, from which we always use the actual best solutions. Due to different search trajectories these solutions’ routes are further assumed to be diverse enough. Hence, we deem conditions (i)–
(iii) introduced in the previous section as fulfilled. Hence, contrary to [206] and the previous VNS-ILP hybrid we restrict ourselves to the actual best solutions only, yet now we have more VNS instances available. Due to this there is no need for handling intermediate solutions.
Similarly the ILP solver is allotted the same amount of CPU-time than the multiple VNS.
The application of the ILP solver can in some way be regarded as a recombination operator taking into account all available solutions provided by the “population” of the VNS instances, 108
start
better solutions by combining available routes mVNS/ILP Matheuristic
Figure 4.8:Information exchange between multiple VNS and ILP model/solver.
Algorithm 14: Multiple VNS / ILP Hybrid: #VNS refers to the number of VNS in-stances,#secto the number of sections per VNS instance and to the maximal number of ILP solver applications, anditermax is the total number of allowed iterations.
Ω0 ← ∅;// start with empty model
execute VNS[i] foritersec iterations
8
add VNS[i] solutions’ routes toΩ0sec;// gather columns
9
x∗←actual best solution
10
Ω0 ←Ω0∪Ω0sec;// enrich ILP model
11
x←apply ILP solver onΩ0, initialized withx∗
12
Replace solution of worst VNS instance byx
13
Return best solution of all VNS instances
14
hence realizing some kind of optimal merging. A novelty here is that in case a solution is not feasible as a whole, its feasible routes are added anyway, yet the ILP solver is only applied if at least one feasible solution exists. Again, the ILP solver is always initialized with the current best solution to speed up the process.
If the ILP solver is able to improve on the current best solution this new solution is transferred to the multiple VNS, where as usual the solution of the worst VNS instance is replaced. There are also two options regarding the lifetime of the routes added to the ILP model: Either we only consider the actual solutions’ routes, i.e. they are discarded afterwards, or we keep all inserted routes and the ILP model gradually grows, i.e. realizing a long term memory.
However, it is clear that a model of continuously increasing size in general demands more and more computation time to be solved. This could in turn lead to worse solutions when setting
4. PERIODICVEHICLEROUTINGPROBLEM WITHTIMEWINDOWS
a time limit as in our case. Nevertheless the larger induced search space might also contain better solutions. If routes are kept then the ILP solver is only applied if non-existing routes could be added after a multiple VNS section. Both variants are examined in the next section.
Previous Computational Results
The results presented here are mainly reported in [161], extended by tests on Pirkwieser and Raidl instances with a planning horizon of eight days. Like the multiple VNS (see Section 4.5) also the mVNS-ILP hybrid is allowed 106 VNS iterations in total and#sec is consistently set to 10 (as determined by preliminary tests); i.e. applying ten sequences of
#VNS VNS instances, each one running for106/(#VNS ·10)iterations per section. For solving the ILP model in the mVNS-ILP hybrid we applied the general purpose MIP solver IBM ILOG CPLEX 12.1. We experimented with 5, 8, 10, and 15 VNS instances, denoted by mVNS-ILP#VNS,#sec. As before each algorithm setting was run 30 times per instance.
Table 4.14 shows concise results of all mVNS-ILP variants considered, with the setting of storing all injected routes. We state how often they performed significantly better or worse than the corresponding mVNS, as well as how many times they were significantly better or worse than the standard VNS variants, again using a Wilcoxon rank sum test with an error level of 5% for testing statistical significance. As was observed in Section 4.5 mVNS was already able to often outperform standard VNS. However, combining the mVNS with ILP techniques in the mVNS-ILP hybrid consistently yields even more satisfying results.
Looking at the overall best variant, mVNS-ILP8,10, it significantly improves upon VNS with 106iterations in about 90% of all cases, and upon the corresponding mVNS as well as VNS with2·106 iterations in about 70%. Taking the average runtimes into account, which are given in Table 4.16, we see that the runtime of mVNS-ILP8,10is still notably less than that of the VNS with2·106iterations (which is per setting the upper limit). We note that already mVNS-ILP5,10 delivers good results, with the advantage of only a very small increase in runtime. Naturally, for an increasing number of VNS instances#VNS and especially for longer planning horizons we observe that the runtime of mVNS-ILP approaches that of VNS (2·106), i.e. the ILP solving consumes all of the allotted time, hence justifying a comparison to this latter VNS variant. For these cases a performance degradation can be observed, too.
In general, the mVNS-ILP hybrid approach achieves to a large extent significantly better results than the standard VNS variants as well as the corresponding mVNS, yet the runtime is very often below the limit.
So far we only considered the strategy to keep all routes in the model once they were added.
Therefore analog results of mVNS-ILP when resetting the columns after each application of the ILP solver are given in Table 4.15, again stating the results of the statistical significance tests, yet this time more condensed per planning horizon. Comparing these results to the pre-vious ones there is mostly no gain in solution quality observable, for neither of the planning horizons. Contrary, the results are in fact worse, i.e. it seems generally better to work with an ILP model of increasing size and hence exploit information from the search trajectory.
The only exception being mVNS-ILP15,10, especially when compared to its corresponding mVNS. Resetting the columns also leads, for obvious reasons, to shorter runtimes, which is 110
Table 4.14:Concise results of mVNS-ILP on all Pirkwieser and Raidl instances, partly reported in [161], stating how often mVNS-ILP performs significantly better/worse than mVNS and VNS.
Instances mVNS-ILP5,10 mVNS-ILP8,10 mVNS-ILP10,10 mVNS-ILP15,10
significantly better/worse than corresponding mVNS
p4r 2×/0× 5×/0× 5×/0× 5×/0×
p4c 1×/0× 3×/0× 5×/0× 5×/0×
p4rc 4×/0× 5×/0× 5×/0× 5×/0×
p6r 2×/0× 4×/0× 4×/0× 1×/0×
p6c 1×/0× 1×/0× 1×/0× 1×/0×
p6rc 1×/1× 5×/0× 4×/0× 2×/0×
p8r 2×/0× 4×/0× 4×/0× 2×/0×
p8c 1×/0× 1×/0× 1×/0× 2×/0×
p8rc 2×/0× 4×/0× 3×/0× 2×/0×
16×/1× 32×/0× 32×/0× 25×/0×
significantly better/worse than VNS (106)
p4r 5×/0× 5×/0× 5×/0× 5×/0×
p4c 5×/0× 5×/0× 5×/0× 5×/0×
p4rc 5×/0× 5×/0× 5×/0× 5×/0×
p6r 5×/0× 5×/0× 5×/0× 3×/0×
p6c 5×/0× 5×/0× 4×/0× 4×/0×
p6rc 5×/0× 5×/0× 4×/0× 2×/0×
p8r 5×/0× 4×/0× 3×/0× 2×/1×
p8c 2×/0× 3×/0× 3×/0× 2×/1×
p8rc 3×/0× 4×/0× 2×/0× 1×/1×
40×/0× 41×/0× 36×/0× 29×/3×
significantly better/worse than VNS (2·106)
p4r 4×/0× 5×/0× 5×/0× 5×/0×
p4c 4×/0× 5×/0× 5×/0× 5×/0×
p4rc 4×/0× 5×/0× 5×/0× 5×/0×
p6r 5×/0× 5×/0× 5×/0× 2×/0×
p6c 3×/0× 4×/0× 2×/0× 3×/0×
p6rc 0×/0× 3×/1× 2×/1× 1×/2×
p8r 2×/0× 2×/0× 2×/1× 2×/3×
p8c 1×/2× 1×/2× 1×/2× 1×/3×
p8rc 1×/1× 1×/1× 1×/2× 1×/3×
24×/3× 31×/4× 28×/6× 25×/11×
4. PERIODICVEHICLEROUTINGPROBLEM WITHTIMEWINDOWS
Table 4.15: Concise results of mVNS-ILP on all Pirkwieser and Raidl instances when resetting the columns.
Instances mVNS-ILP5,10 mVNS-ILP8,10 mVNS-ILP10,10 mVNS-ILP15,10 significantly better/worse than corresponding mVNS
p4 4×/0× 6×/0× 10×/0× 14×/0×
p6 2×/1× 8×/0× 4×/0× 9×/0×
p8 3×/0× 2×/0× 7×/0× 12×/0×
9×/1× 16×/0× 21×/0× 35×/0×
significantly better/worse than VNS (106)
p4 14×/0× 15×/0× 15×/0× 14×/0×
p6 14×/0× 13×/0× 12×/0× 11×/0×
p8 10×/0× 7×/0× 8×/0× 8×/0×
38×/0× 35×/0× 35×/0× 33×/0×
significantly better/worse than VNS (2·106)
p4 10×/0× 13×/0× 13×/0× 13×/0×
p6 6×/1× 7×/1× 6×/1× 8×/1×
p8 2×/4× 3×/6× 2×/4× 3×/8×
18×/5× 23×/7× 21×/5× 24×/9×
documented in Table 4.16.
Nevertheless, for other instances or settings (iterations and/or VNS instances) it might pay off to reset the columns, since due to the reduced size of the resulting model potentially more improvements could be possible in limited time.
4.9.3 Hybridizing the Column Generation Approach and the Evolutionary