Where to Split in Hybrid Genetic Search for the Capacitated Vehicle Routing Problem

Abstract

One of the best heuristic algorithms for solving the capacitated vehicle routing problem is a hybrid genetic search. A critical component of the search is a splitting procedure, where a solution encoded as a giant tour of nodes is optimally split into vehicle routes using dynamic programming. However, the current state-of-the-art implementation of the splitting procedure assumes that the start of the giant tour is fixed as a part of the encoded solution. This paper examines whether the fixed starting point is a significant drawback. Results indicate that simple adjustments of the starting point for the splitting procedure can improve the performance of the genetic search, as measured by the average primal gaps of the final solutions obtained, by 3.9%.

1. Introduction

The capacitated vehicle routing problem (CVRP) is an important optimization problem. It was first mentioned by Garvin et al. [1], after which it was described in more detail by Dantzig and Ramser [2], who also presented a heuristic solution method. The problem consists of finding routes for a fleet of identical vehicles, each route starting and ending at a central depot. The routes visit a set of customers, where each customer is associated with a given location and a given demand. The routes must make sure that each customer is visited exactly once, and the total demand of customers visited on a given route may not exceed the capacity of the vehicle. The aim is to find routes minimizing the total distance travelled.

Progress has been made on developing exact algorithms for the CVRP [3,4]. However, the problem is still hard to solve and has therefore become an important benchmark for developing heuristics. For a long time, genetic algorithms were considered uncompetitive for solving CVRPs [5], until Prins [6] presented the first successful implementation of a genetic algorithm for the CVRP. He proposed several important design changes with the new genetic algorithm, including (1) using a giant tour representation without trip delimiters as the solution encoding, (2) evaluating fitness exactly using a splitting procedure to create optimal routes conditional on the giant tour encoding, (3) using local search instead of a mutation operator, and (4) adjusting search parameters and components to allow maintaining a small and incrementally managed population of solutions.

Currently, the most successful genetic algorithms for vehicle routing problems are still based around the ideas of Prins [6]. Vidal et al. [7] solved vehicle routing problems with multiple depots and multiple periods by combining population-based evolutionary search, neighborhood-based search, and an advanced population-diversity-management scheme. Similar implementations for more general vehicle routing problems were described by Vidal et al. [8] and Vidal et al. [9]. This line of research led to an open-source implementation of a hybrid genetic search for solving the CVRP [10]. This implementation, and in particular how it deals with the splitting operator for converting a giant tour representation into feasible vehicle routes, is the focus of this paper.

The implementation by Vidal [10] uses an order crossover (OX) to combine two existing solutions, represented as giant tours, and create a new solution represented as a giant tour. The operator works by randomly selecting two cutting points, splitting the combined giant tours into two segments. In the new solution, one segment is copied directly from the first combined giant tour, before completing the new giant tour by inserting the remaining customers in the order in which they appear in the second combined giant tour. Hvattum [11] argued that this process is ineffective, as the order crossover inserts the remaining customers starting from the location in the second giant tour corresponding to the location where the copying of the first solution stopped. An adjusted order crossover (AOX) was proposed, where the insertion starts from the location in the second giant tour corresponding to the location of the customer that was last copied from the first giant tour.

Figure 1 and Figure 2 show a simple example of combining two giant tours with eight customers using the OX crossover and the AOX crossover, respectively. The grey area is the segment selected from the first combined giant tour. In the regular OX crossover, the next customer inserted in the new giant tour, following 3 and 4, is 8 (as it immediately follows the corresponding segment in the second giant tour), but with the AOX operator, the next customer inserted is 5, since it follows 4 in the second giant tour. This minor change led to an improved performance of the overall heuristic, reducing the primal gaps by 4.2%.

After applying the order crossover, the next step is to consider the splitting procedure that takes as input the giant tour and provides as output a solution in the form of a set of vehicle routes. The splitting procedure is an example of the route-first cluster-second idea, and has become common when solving vehicle routing problems [12]. While Prins [6] used it to solve CVRPs, it has been applied for a wide range of different vehicle routing problems, including with capacity and duration limits and time windows [8], with selection of customers to visit [13], or for heterogeneous fleets [14]. Prins et al. [15] explored several variants of the splitting procedure for both the CVRP and the capacitated arc routing problem.

The splitting procedure is typically implemented on an auxiliary graph where nodes correspond to customers and arcs correspond to routes. A standard dynamic programming algorithm can find the optimal routes subject to a given giant tour in $O\left(nB\right)$-time, where n is the number of customers and B is the average number of feasible trips starting from one node of the giant tour. However, the open-source implementation of Vidal [10] uses a linear-time method proposed by Vidal [16] for solving the CVRP without route-duration constraints.

There is, however, one implicit assumption made by the splitting procedures as implemented in the current academic literature: the giant tour is actually represented as a giant string of visits, where the first visit is predetermined. That is, in the example shown in Figure 2 the giant tours of the combined solutions are forced to start with a visit to customer 1, whereas the giant tours of the new solutions are forced to start with visits to customers 7 and 2, when using OX and AOX, respectively.

The research presented here is based on the idea that, having combined two solutions using the (adjusted) order crossover operator, the resulting permutation vector may not necessarily provide the best possible condition for a splitting procedure based on a giant tour with a fixed first customer visit. To test this, five alternative preprocessing steps to the splitting procedure are proposed and evaluated. The preprocessing shifts the permutation vector so as to change the first customer visited when splitting up the giant tour. The contribution of this paper is to show that this simple modification of the hybrid genetic search of Vidal [10] leads to an improved search performance.

In Section 2, we summarize the start-of-the-art of heuristic solvers for the CVRP. Then, Section 3 provides an overview of the hybrid genetic search. Section 4 outlines the preprocessing steps added to the splitting procedure. Computational results to evaluate the preprocessing steps are provided in Section 5, after which the conclusions are drawn in Section 6.

2. Heuristics for the Capacitated Vehicle Routing Problem

There is a long history of developing heuristics for the CVRP, but the following focuses on the most recent contributions. For earlier work, the reader may refer to Gendreau et al. [5], Laporte [17], and Laporte et al. [18]. Four recent and well-performing heuristic methods were used as benchmarks by Vidal [10], and this section starts by examining them.

First, Subramanian et al. [19] presented a hybrid iterated local search, capable of solving several variants of the vehicle routing problem. The method is based on iterated local search, while using a mathematical programming solver and a set-partitioning model to select routes. Second, Arnold and Sörensen [20] developed a guided local search, combining different local search techniques as well as using problem-specific knowledge to control the search. This knowledge-guided local search was also able to solve very large CVRP instances [21]. Third, a method called slack induction by string removals was introduced by Christiaens and Vanden Berghe [22]. It corresponds to a large neighborhood search, where there are specialized operators for removing and re-inserting customers into a solution. Fourth, a fast iterative localized optimization algorithm was proposed by Accorsi and Vigo [23]. This method is also based on iterated local search and targeted large-scale instances of the CVRP.

While the four methods above provide excellent results, the hybrid genetic search developed by Vidal [10] seems to perform even better. Hvattum [11] suggested a minor adjustment to the hybrid genetic search that allowed the method to find, on average, improved solutions. Simensen et al. [24] reimplemented the hybrid genetic search and hybridized it with the method of Christiaens and Vanden Berghe [22], considering the specialized operators for removing and re-inserting customers in a solution. They described two different parameter settings of the new hybrid method, which would outperform the hybrid genetic search according to either of two different evaluation criteria.

Queiroga et al. [25] started from good known solutions and applied a branch-cut-and-price algorithm to solve subproblems, interpreted as a local search over a large neighborhood. With very long running times, the method provided excellent results, improving several best-known solutions to standard benchmark instances. Cavaliere et al. [26] also improved several best-known solutions, using a refinement heuristic based on local search and set partitioning, with some similarities to the work of Subramanian et al. [19].

The attractiveness of using the CVRP as a benchmark shows in the large number of recent publications applying various heuristic ideas to produce solutions. However, some of the recent literature present their contributions without explicitly comparing the obtained methods to the state-of-the-art as described above. Examples of such methods include the hyper-heuristic of Hou et al. [27], the kernel search of Borčinová [28], the variable neighborhood search of Kalatzantonakis et al. [29], and the methods of Dalbah et al. [30] and Mahmood [31].

The evolutionary algorithm of Jiang et al. [32] is compared to a range of methods, including the knowledge-guided local search [20], and shows good performance on several types of benchmark instances, despite not being compared directly to the hybrid genetic search [10] or its successors. The evolutionary algorithm uses techniques to accelerate the convergence of the search and, interestingly, the method does not use a giant tour representation of solutions.

Máximo and Nascimento [33] presented an iterated local search with path-relinking that obtained better solutions than the hybrid iterated local search of Subramanian et al. [19], the slack induction by string removals by Christiaens and Vanden Berghe [22], as well as a unified version of hybrid genetic search by Vidal et al. [9]. Finally, Máximo et al. [34] introduced an improvement of the iterated local search with path-relinking, thereby producing the best results seen so far in terms of the average gap to the best known solutions on standard benchmark instances, although the hybrid genetic search still provided the best performance on small instances.

Despite the recent advances made with methods combining iterated local search and path-relinking, the hybrid genetic search is still among the best methods for solving the CVRP, both in terms of the accuracy and speed of the method, but also in terms of its simplicity and flexibility [35]. Thus, improvements to the method that maintain conceptual simplicity are still valuable: as summarized by Vidal [10], the goal of heuristic design should be to investigate concepts that are as simple and effective as possible and to properly understand the contribution of each search component.

3. Hybrid Genetic Search

The hybrid genetic search that we investigate in this paper was described in detail by Vidal [10]. In the following, we provide a short summary, sufficient to understand the main ideas of the overall method but with a particular focus on the role of the splitting procedure. Figure 3 identifies seven algorithmic components present in the search, which are connected by solid arcs showing the sequence of execution. The arcs are followed until a predetermined time limit is reached. The figure also indicates an eighth component, which is discussed in Section 4.

In the first search component (A), a set of initial solutions is created. The initial solutions are simply randomly generated and then improved by local search. These solutions form the initial population (B), which in general consists of both feasible and infeasible solutions. Solutions are stored in an encoded form, namely as giant tours without route delimiters. Figure 1 illustrates the format in which solutions are stored: the permutation vector $[1,2,3,4,5,6,7,8]$ could, for example, be the result of encoding a solution where one route visits customers 1, 2, and 3 (in order), a second route visits customers 4 and 5, whereas a third route visits customers 6, 7, and 8 (in that order).

To generate new solutions, the hybrid genetic search iterates over components (C), (D), (F), and (G). First, two giant tours from the population are selected (C) by running two binary tournaments. Each tournament involves selecting two giant tours from the population at random, and then selecting the best of these two. Next, a crossover operator (D) is applied that combines the two selected giant tours to create a new giant tour. The original hybrid genetic search of Vidal [10] uses the order crossover operator, whereas Hvattum [11] showed that improved results could be obtained by instead using an adjusted order crossover. Once a new giant tour has been obtained, it is decoded into a best possible solution using the splitting procedure (F). After this, the solution is improved using local search (G), after which it is encoded as a giant tour.

Finally, the population-management component (H) decides which giant tours to keep in the population. Feasible and infeasible solutions are handled separately. New giant tours are always added to the respective subpopulation immediately when generated. Once the number of giant tours corresponding to feasible (infeasible) solutions reaches a certain value, the subpopulation is trimmed down by removing any repeated solutions, and then by removing solutions with a worse evaluation. The evaluation, in this case, is based on a metric that combines the solution quality and a diversity measure.

4. The Splitting Procedure

The idea of the splitting procedure was first used by Prins [6] to decode solutions for the CVRP. Before applying the procedure, the encoded solution consists of a permutation vector that is interpreted as a giant tour of customer visits without route delimiters. Figure 4 gives an example of a permutation vector for six customers and illustrates the corresponding giant tour.

In the hybrid genetic search, as well as in other implementations of the splitting procedure found throughout the literature, the decoding of the giant tour makes the assumption that the starting point of the first route is given. That is, since the permutation vector in the example of Figure 4 starts with customer 1, the splitting procedure assumes that the first customer to be visited is customer 1. Subject to this assumption, the splitting procedure uses dynamic programming to find the optimal solution from the given giant tour.

The first step of the splitting is to create an auxiliary directed acyclic graph, where the nodes represent the depot and the customers in the sequence given by the permutation vector. Arcs represent feasible routes containing visits to the customers between the node from which the arc starts (excluding) and the node where the arc ends (including). A length is associated with the arc, which corresponds to the cost of performing the corresponding route. Only arcs representing feasible routes are created. Figure 5 illustrates the auxiliary graph for the example from Figure 4. Next, by finding the shortest path in the graph, the optimal solution corresponding to the giant tour is found. The shortest path in Figure 5 is shown with black arcs, whereas the other un-used routes are represented by gray arcs. Figure 6 shows the optimal solution, subject to following the giant tour.

This paper investigates the idea that the splitting procedure coupled with the OX crossover, or the newer AOX crossover, has a specific flaw: the splitting always assumes that the first route starts with the customer that is listed first in the permutation vector representing the giant tour and that the last route ends with the customer that is listed last. This is shown in Figure 4 with the dashed lines representing arcs that are forced to be included in the generated routes.

However, the OX crossover ignores the importance of the permutation vector’s initial position. As seen in the example from Figure 1 and Figure 2, the new permutations generated can be arbitrarily shifted, and the properties of a good initial customer are not considered. Due to this observation, this paper proposes to make an additional step before the splitting procedure is executed: namely to shift the permutation vector so that a suitable customer is located at the beginning of the vector.

4.1. Split-Preprocessing

The new preprocessing step for the splitting procedure, component (E) in Figure 3, is relatively simple and requires only a few additional lines of code, as given in Section 4.2. To properly investigate the importance of the preprocessing step, we consider five variants. The first split-preprocessing variant, which we refer to as SP1, is simply to shift the permutation vector randomly. This should destroy any information carried through by the OX crossover regarding good initial customers, and serves as a negative benchmark: it is expected to perform worst of all candidates, and also worse than simply not having any preprocessing step.

The second variant, SP2, can be motivated from the example in Figure 4. We note that customer 1, the first to be visited, is relatively far from the next customer in the sequence, customer 2. This means that the first route will either be a simple back-and-forth to customer 1, or will include a relatively long travel between customers 1 and 2. It may be preferable to avoid such long arcs. Thus, in SP2, we shift the permutation vector so that we are sure to avoid the longest arc occurring in the giant tour: the node with the largest distance to the next node is shifted to become the last node in the permutation vector. The calculations for the example are shown in

Table 1. Details of the example in Figure 4 and calculations for four variants of selecting the last (first) node in the giant tour, with the value of the selected node highlighted in bold.

Node	Coordinate	SP2	SP3	SP4	SP5
Depot	$(15,20)$	NA	NA	NA	NA
1	$(25,60)$	$36.4$	$0.88$	$-0.50$	$-25.4$
2	$(35,25)$	$32.0$	$\mathbf{1.55}$	$0.49$	$-36.4$
3	$(55,0)$	$\mathbf{55.2}$	$1.23$	$0.10$	$-\mathbf{10.7}$
4	$(0,5)$	$15.0$	$0.71$	$-0.66$	$-21.2$
5	$(0,20)$	$22.4$	$1.49$	$\mathbf{0.53}$	$-13.3$
6	$(10,40)$	$25.0$	$1.21$	$0.03$	$-36.8$

, resulting in customer 3 becoming the last node in the permutation vector, and customer 4 becoming the first.

Variant number 3, SP3, adds one more consideration to the calculations: while one may wish to avoid the travel between customers 3 and 4, customer 3 is also relatively far from the depot, so it may not be worthwhile to avoid the travel between customers 3 and 4 when instead forcing the travel from customer 3 to the depot. Thus, in SP3, we consider for each customer the distance to the next customer divided by the distance to the depot. The customer with the highest value of this ratio is shifted to the end of the permutation vector, so as to avoid a long arc when instead having the option to return to the depot with a short arc. In Table 1, we see that this leads to customer 2 being selected as the last customer to visit, thus making customer 3 the first customer in the permutation vector.

In the fourth variant, SP4, we acknowledge that several consecutive customers may share the property of having a high value of the distance to the next node divided by the distance to the depot. In that case, selecting one of them as the final customer to visit may be counterproductive. Thus, SP4 suggests that we consider the value of the ratio for a node and subtract the average ratios of the customers immediately before and immediately after the node. The permutation vector is then shifted so that the last customer has the highest value of this difference in ratios. In Table 1 we see that, for our example, this leads to customer 5 being selected as the last to visit: it is relatively close to the depot compared to the distance to the next customer, while customers 4 and 6 are relatively close to the next customer compared to the distance to the depot.

The first four variants are based on the idea of trying to avoid certain long journeys. Finally, in the fifth variant, SP5, the idea is instead to simply insert a visit to the depot in the cheapest possible location. That is, the final customer to visit is decided by trying to insert the depot into every point in the giant tour and fixing the point giving the cheapest travel when considering the first and last customers of the first and the last route, respectively. Table 1 shows the distance saved by inserting the depot at different points (this saving is negative, given that inserting the depot leads to an increased total distance), leading to customer 3 being selected as the last customer to visit, thus making customer 4 the first in the permutation vector.

The illustrating example was created to show that the proposed rules can provide different suggestions for which customer to visit last (respectively, first) in the giant tour. In practice, the different rules may sometimes make similar suggestions, and may also suggest to not shift the permutation vector relative to what was output from the crossover operator. Whether or not the proposed preprocessing variants lead to the hybrid genetic search finding better solutions faster is tested in Section 5.

4.2. Implementation of Preprocessing

The open-source implementation of hybrid genetic search by Vidal [10] is coded very efficiently, and consists of only 2073 non-empty lines of code, including comments. The adjusted crossover proposed by Hvattum [11] replaced 29 lines of code for the OX crossover with 43 lines of code, increasing the total line count by only 0.68%.

The split-preprocessing variants are coded in a very simplistic way, intended to make sure that the logic is correct without worrying about the efficiency of the code, and in a way that allowed minimal changes to the existing code base.

Table 2. Original code for starting the splitting procedure.

1	void Split::generalSplit(Individual * indiv, int nbMaxVehicles)
2	{
3	// Do not apply Split with fewer vehicles than the trivial (LP) bin packing bound
4	maxVehicles = std::max<int>(nbMaxVehicles,
	(int)std::ceil(params->totalDemand/params->vehicleCapacity));
5	// Initialization of the data structures for the linear split algorithms
6	// Direct application of the code located at https://github.com/vidalt/Split-Library
7	for (int i = 1; i <= params->nbClients; i++)
8	{
9	cliSplit[i].demand = params->cli[indiv->chromT[i - 1]].demand;
10	cliSplit[i].serviceTime = params->cli[indiv->chromT[i - 1]].serviceDuration;
11	cliSplit[i].d0_x = params->timeCost[0][indiv->chromT[i - 1]];
12	cliSplit[i].dx_0 = params->timeCost[indiv->chromT[i - 1]][0];
13	if (i < params->nbClients) cliSplit[i].dnext =
	params->timeCost[indiv->chromT[i - 1]][indiv->chromT[i]];
14	else cliSplit[i].dnext = -1.e30;
15	sumLoad[i] = sumLoad[i - 1] + cliSplit[i].demand;
16	sumService[i] = sumService[i - 1] + cliSplit[i].serviceTime;
17	sumDistance[i] = sumDistance[i - 1] + cliSplit[i - 1].dnext;
18	}
19	// We first try the simple split,
	// and then the Split with limited fleet if this is not successful
20	if (splitSimple(indiv) == 0)
21	splitLF(indiv);
22	// Build up the rest of the Individual structure
23	indiv->evaluateCompleteCost();
24	}

shows the function in the original code that calls the actual splitting procedure. It contains simple data preprocessing done before the splitting can take place, and is where the new preprocessing steps are included.

The code for the first preprocessing variant, which simply shifts the permutation vector randomly, is shown in

Table 3. Modification of code to allow randomized start of splitting procedure (SP1).

1	void Split::generalSplit(Individual * indiv, int nbMaxVehicles)
2	{
3	int indexOfLast = rand() % params->nbClients;
4	// Change the start of the chromosome
5	if (indexOfLast != params->nbClients - 1)
6	{
7	std::vector< int > chrom(params->nbClients, 0);
8	for (int i = 0; i < params->nbClients; i++)
9	chrom[i] = indiv->chromT[(i + indexOfLast + 1) % params->nbClients];
10	for (int i = 0; i < params->nbClients; i++)
11	indiv->chromT[i] = chrom[i];
12	}
13–33	(…) // Lines 3–23 from Table 2
34	}

. It requires one line of code to determine the index of the customer that should be visited last, and then nine lines of code to implement the shift, which is done by crudely copying the permutation vector twice.

Table 4. Modification of code to allow start of splitting procedure based on longest distance to next customer (SP2).

1	void Split::generalSplit(Individual * indiv, int nbMaxVehicles)
2	{
3	int indexOfLast = params->nbClients - 1;
4	// Using distance to next customer
5	double longestDistanceToNext = -1.0;
6	for (int i = 0; i < params->nbClients; i++)
7	{
8	double distanceToNext =
	params->timeCost[indiv->chromT[i]][indiv->chromT[(i + 1) % params->nbClients]];
9	if (longestDistanceToNext < distanceToNext)
10	{
11	longestDistanceToNext = distanceToNext;
12	indexOfLast = i;
13	}
14	}
15–23	(…) // Lines 4–12 from Table 3
24–44	(…) // Lines 3–23 from Table 2
45	}

shows the code for SP2, where the last customer is determined by the longest distance to the next customer in the giant tour. Then,

Table 5. Modification of code to allow start of splitting procedure based on longest distance to next customer relative to the distance to the depot (SP3).

1–8	(…) // Lines 1–8 from Table 4
9	double distanceToDepot =
	params->timeCost[indiv->chromT[(i + 1) % params->nbClients]][0];
10	if (longestDistanceToNext < distanceToNext / distanceToDepot)
11	{
12	longestDistanceToNext = distanceToNext / distanceToDepot;
13	indexOfLast = i;
14	}
15	}
16–24	(…) // Lines 4–12 from Table 3
25–45	(…) // Lines 3–23 from Table 2
46	}

presents the code for SP3,

Table 6. Modification of code to allow start of splitting procedure based on longer distance to next customer relative to the distance to the depot, compared to nodes directly before and after (SP4).

1	void Split::generalSplit(Individual * indiv, int nbMaxVehicles)
2	{
3	int indexOfLast = params->nbClients - 1;
4	// Distance next / distance depot, but largest relative to nodes before and after
5	std::vector< double > distanceValues(params->nbClients);
6	for (int i = 0; i < params->nbClients; i++)
7	{
8	double distanceToNext =
	params->timeCost[indiv->chromT[i]][indiv->chromT[(i + 1) % params->nbClients]];
9	double distanceToDepot =
	params->timeCost[indiv->chromT[(i + 1) % params->nbClients]][0];
10	distanceValues[i] = distanceToNext / distanceToDepot;
11	}
12	double longestDistanceToNextComparedToNeighbors = -1.0;
13	for (int i = 0; i < params->nbClients; i++)
14	{
15	// Checking distance-value compared to neighbors
16	double distMe = distanceValues[i];
17	double distNext = distanceValues[(i + 1 >= params->nbClients ? 0 : i + 1)];
18	double distPrev = distanceValues[(i - 1 < 0 ? params->nbClients - 1 : i - 1)];
19	double distanceScore = distMe - 0.5 * (distNext + distPrev);
20	if (distanceScore > longestDistanceToNextComparedToNeighbors)
21	{
22	longestDistanceToNextComparedToNeighbors = distanceScore;
23	indexOfLast = i;
24	}
25	}
26–34	(…) // Lines 4–12 from Table 3
35–55	(…) // Lines 3–23 from Table 2
56	}

provides the code for SP4, and

Table 7. Modification of code to allow start of splitting procedure based on cheapest insertion of depot into giant tour (SP5).

1	void Split::generalSplit(Individual * indiv, int nbMaxVehicles)
2	{
3	double cheapest =
4	params->timeCost[indiv->chromT[params->nbClients - 1]][indiv->chromT[0]] -
5	params->timeCost[indiv->chromT[0]][0] -
6	params->timeCost[indiv->chromT[params->nbClients-1]][0];
7	int indexOfLast = params->nbClients - 1;
8	for (int i = 1; i < params->nbClients; i++)
9	{
10	double cost = params->timeCost[indiv->chromT[i - 1]][indiv->chromT[i]] -
11	params->timeCost[indiv->chromT[i-1]][0] - params->timeCost[indiv->chromT[i]][0];
12	if (cost > cheapest)
13	{
14	cheapest = cost;
15	indexOfLast = i - 1;
16	}
17	}
18–26	(…) // Lines 4–12 from Table 3
27–47	(…) // Lines 3–23 from Table 2
48	}

shows the code for SP5. The original function contained 24 lines of code, whereas the five new variants require 34, 45, 46, 56, and 48 lines of code, respectively. The variant with the most lines of code, SP4, thus increases the total code by 32 lines, or 1.5%.

5. Computational Study

Our hypothesis is that the crossover operator used in hybrid genetic search may create permutation vectors where the initial customer is selected inappropriately. If this is correct, the alternatives that shift the permutation vector before applying the splitting procedure may lead to improved results. If the initial customer is unimportant, the variant with randomized shifting should perform equally well with the other methods. To test this, we design a computational experiment.

In the computational experiment we use 100 benchmark instances from the literature, known as the X-set [36]. The instances have between 100 and 1000 customers and no limit on the number of vehicles used, and the best-known solutions were obtained from CVRPLIB on 26 April 2022, using the link http://vrp.atd-lab.inf.puc-rio.br/index.php/en/, accessed on 26 April 2022. The computations were executed on an Intel i9-9900 CPU at 3.1 GHz with 32 GB of RAM. The allowed running time is set to $2.4n$ s, where n is the number of customers. For each variant of the hybrid genetic search tested, each instance is run 10 times with different random seeds.

We consider seven versions of the code: OX, the original code from Vidal [10] using the standard OX crossover; AOX, the code from Hvattum [11] using the adjusted OX crossover; and SP1–SP5, using the adjusted OX crossover and one of the split-preprocessing variants described in Section 4. All other search components and parameter settings are kept as initially proposed by Vidal [10]. In Section 5.1, we compare the performance of the different preprocessing variants, SP1–SP5, to determine which of them is better. Then, in Section 5.2 we compare the best of these to the previous variants of hybrid genetic search, OX and AOX.

5.1. Comparison of Preprocessing Variants

To determine the best preprocessing variant, among SP1–SP5, we investigate the primal gaps at the end of the runs. The primal gap was defined by Berthold [37]. In the context of the CVRP, the primal gap is simply the gap between the best-known solution and solution obtained at the end of a run, relative to the solution obtained.

Figure 7 plots the primal gaps for SP1–SP5 as a function of running time, normalized to the interval $[0,1]$ for each run. Visually, the randomized shift of variant SP1 separates itself from the other three methods. The final primal gaps are 0.118% for SP1, 0.105% for SP2, 0.104% for SP3, 0.101% for SP4, and 0.104% for SP5, thus suggesting that SP4 provides the best performance. While SP3 appears better than SP4 for shorter running times, this effect is countered by the improved performance of SP4 later on in the runs. We therefore conclude that SP4 is the best preprocessing variant.

It can also be concluded that the initial customer in the permutation vector representing the giant tour is indeed of some importance. The final primal gaps of SP1 and SP4 were compared using a paired t-test, showing a statistically significant difference. That is, the difference between SP1 and SP4 is 0.017 percentage points with a standard deviation of 0.08 percentage points, giving a test statistic of 6.9 and a two-way p-value of $6\times {10}^{-12}$, rejecting the null-hypothesis that there is no difference in performance between SP1 and SP4.

In additional experiments using SP4, the most complex of the five preprocessing variants examined, the time spent in the preprocessing step was also recorded. These experiments showed that the time spent in preprocessing, relative to the full duration of the run, ranged from 0.06% to 0.26%, with an average of 0.14%. In comparison, the time spent in the split procedure (including the preprocessing) varies from 0.24% to 11.5%. Thus, there are some runs where the time spent in the preprocessing is high relative to the time spent in the splitting procedure: up to 30.3% at the most. However, the time spent in the preprocessing is always low compared to the total run time.

To further shed some light on the performance of SP4 relative to the other preprocessing rules, the code was modified so that each of SP1–SP5 is run in every split and the best of the resulting five solutions is used to continue the search. This search does not provide a good performance overall, as it spends too much time in the splitting procedure, but allows a comparison of the five preprocessing rules in terms of providing the best starting point for the splitting: The SP4 rule results in the best solution in 82% of the iterations, while SP3 has the second best performance with 80.7% of the best solutions. SP2 yields the best solution in 79.6% of the iterations, followed by SP5 with 74.9% and SP1 with only 12.9%. This implies that the different rules frequently lead to finding the same solution, but also that there is a slight difference overall in their performance. It is also an indication that finding better solutions after the splitting in each iteration does improve the search overall, as witnessed by SP4 both being best in most iterations and providing the overall best performance.

5.2. Comparison with Former Splitting Procedure

We now thoroughly compare the performances of OX (the original hybrid genetic search), AOX (using the modified crossover operator), and SP4 (using the modified crossover operator and the new preprocessing for the splitting procedure). First, Figure 8 shows the primal gaps as a function of normalized running time. From the figure, it is clear that SP4 is an improvement over AOX, which again is an improvement over OX.

The final primal gaps are 0.110% for OX, 0.105% for AOX, and 0.101% for SP4. The reduction of 0.004 percentage points when going from AOX to SP4 corresponds to a 3.9% reduction in the average primal gap. A paired t-test shows that the difference in final primal gaps is significant: the average difference is 0.0041 percentage points, with a standard deviation of 0.063 percentage points, leading to a test statistic of 2.047, and a two-way p-value of 0.041. Compared to the original implementation of hybrid genetic search, this comes on top of the previous improvement of 4.2% in primal gaps when using AOX instead of OX, for a total improvement of 7.9% in terms of the primal gap. Adding to this, Figure 8 illustrates that the SP4 variant has a lower average primal gap throughout the entire runs.

Table A1. Average objective function values for each instance and each of OX, AOX, and SP4. Best values are highlighted in bold.

Instance	OX	AOX	SP4
X-n120-k6	13,332.0	13,332.0	13,332.0
X-n143-k7	15,700.0	15,700.0	15,700.0
X-n190-k8	16,983.7	16,980.9	16,981.5
X-n101-k25	27,591.0	27,591.0	27,591.0
X-n106-k14	26,377.5	26,373.1	26,371.5
X-n110-k13	14,971.0	14,971.0	14,971.0
X-n115-k10	12,747.0	12,747.0	12,747.0
X-n125-k30	55,539.0	55,539.0	55,539.0
X-n129-k18	28,940.0	28,940.0	28,940.0
X-n134-k13	10,916.0	10,916.0	10,916.0
X-n139-k10	13,590.0	13,590.0	13,590.0
X-n148-k46	43,448.0	43,448.0	43,448.0
X-n153-k22	21,225.0	21,225.0	21,224.8
X-n157-k13	16,876.0	16,876.0	16,876.0
X-n162-k11	14,138.0	14,138.0	14,138.0
X-n167-k10	20,557.0	20,557.0	20,557.0
X-n172-k51	45,607.0	45,607.0	45,607.0
X-n176-k26	47,812.0	47,812.0	47,812.0
X-n181-k23	25,569.0	25,569.0	25,569.0
X-n186-k15	24,145.0	24,145.0	24,145.0
X-n195-k51	44,226.2	44,225.0	44,225.0
X-n200-k36	58,578.0	58,578.0	58,578.0
X-n204-k19	19,565.0	19,565.0	19,565.0
X-n209-k16	30,656.0	30,656.0	30,656.0
X-n214-k11	10,862.1	10,859.6	10,859.5
X-n219-k73	117,596.0	117,595.0	117,595.0
X-n223-k34	40,437.0	40,437.0	40,437.0
X-n228-k23	25,742.8	25,742.7	25,742.4
X-n233-k16	19,230.0	19,230.0	19,230.0
X-n237-k14	27,042.0	27,042.0	27,042.0
X-n242-k48	82,793.6	82,792.6	82,791.4
X-n247-k50	37,283.2	37,277.3	37,281.7
X-n251-k28	38,693.0	38,690.9	38,689.2
X-n256-k16	18,839.7	18,839.0	18,839.0
X-n261-k13	26,558.8	26,565.2	26,562.0
X-n266-k58	75,607.2	75,607.2	75,604.7
X-n270-k35	35,303.4	35,303.0	35,303.0
X-n275-k28	21,245.0	21,245.0	21,245.0
X-n280-k17	33,543.7	33,526.9	33,535.3
X-n284-k15	20,250.3	20,245.6	20,249.1
X-n289-k60	95,280.2	95,252.1	95,273.5
X-n294-k50	47,187.5	47,191.5	47,187.5
X-n298-k31	34,235.1	34,232.1	34,233.7
X-n303-k21	21,748.2	21,744.1	21,745.5
X-n308-k13	25,866.4	25,868.8	25,868.5
X-n313-k71	94,115.7	94,112.3	94,118.7
X-n317-k53	78,355.8	78,355.0	78,355.4
X-n322-k28	29,858.6	29,846.1	29,847.6
X-n327-k20	27,554.2	27,539.3	27,538.8
X-n331-k15	31,103.2	31,103.0	31,103.1
X-n336-k84	139,286.0	139,292.0	139,300.0
X-n344-k43	42,070.8	42,074.4	42,082.1
X-n351-k40	25,946.8	25,944.6	25,945.4
X-n359-k29	51,599.5	51,614.0	51,586.5
X-n367-k17	22,814.0	22,814.0	22,814.0
X-n376-k94	147,714.0	147,714.0	147,715.0
X-n384-k52	66,048.9	66,038.3	66,028.9
X-n393-k38	38,260.9	38,260.0	38,260.0
X-n401-k29	66,234.7	66,235.4	66,227.9
X-n411-k19	19,720.4	19,719.3	19,718.4
X-n429-k61	65,495.8	65,499.3	65,476.2
X-n439-k37	36,396.4	36,395.0	36,396.1
X-n449-k29	55,362.5	55,378.2	55,355.9
X-n459-k26	24,165.1	24,154.8	24,160.4
X-n480-k70	89,499.5	89,537.3	89,524.9
X-n491-k59	66,631.1	66,607.4	66,626.2
X-n502-k39	69,244.7	69,240.8	69,243.8
X-n513-k21	24,201.0	24,201.0	24,201.0
X-n536-k96	95,072.2	95,063.1	95,079.3
X-n548-k50	86,756.9	86,774.8	86,765.3
X-n561-k42	42,742.3	42,747.2	42,742.4
X-n573-k30	50,839.7	50,770.4	50,781.3
X-n599-k92	108,673.0	108,680.0	108,644.0
X-n613-k62	59,663.1	59,691.0	59,656.7
X-n627-k43	62,347.4	62,354.9	62,339.9
X-n641-k35	63,885.6	63,851.2	63,848.6
X-n685-k75	68,375.2	68,376.2	68,363.6
X-n701-k44	82,251.2	82,221.6	82,162.5
X-n716-k35	43,494.1	43,496.1	43,497.7
X-n749-k98	77,654.4	77,642.2	77,607.9
X-n766-k71	114,757.0	114,744.0	114,726.0
X-n783-k48	72,767.5	72,743.7	72,740.8
X-n801-k40	73,477.4	73,468.6	73,436.6
X-n856-k95	89,048.1	89,036.7	89,034.9
X-n876-k59	99,708.0	99,702.3	99,729.3
X-n895-k37	54,127.5	54,107.3	54,097.1
X-n957-k87	85,553.9	85,549.8	85,529.2
X-n979-k58	119,322.0	119,232.0	119,244.0
X-n1001-k43	72,679.4	72,732.7	72,703.6
X-n420-k130	107,822.0	107,843.0	107,827.0
X-n469-k138	222,141.0	222,149.0	222,138.0
X-n524-k153	154,688.0	154,734.0	154,727.0
X-n586-k159	190,539.0	190,522.0	190,489.0
X-n655-k131	106,808.0	106,811.0	106,807.0
X-n670-k130	146,780.0	146,900.0	146,855.0
X-n733-k159	136,448.0	136,421.0	136,417.0
X-n819-k171	158,491.0	158,494.0	158,514.0
X-n837-k142	194,260.0	194,198.0	194,206.0
X-n916-k207	329,874.0	329,767.0	329,825.0
X-n936-k151	133,302.0	133,346.0	133,353.0
Average	63,204.6	63,202.1	63,199.1

in the appendix shows the average objective function values obtained by each of the three methods for each instance.

There are other angles from which to evaluate the performance of a heuristic than the average gaps obtained. Next, we consider the ability to match the best-known solutions, as it may be possible to obtain small average gaps without necessarily finding the best solution in many runs. Figure 9 shows the number of best-known solutions found, out of 1000 runs, for OX, AOX, and SP4.

The number of best-known solutions found is increasing faster for SP4 near the end of the runs, and it just surpasses AOX at the end, with 372 best-known solutions found, compared to 371 for AOX and 347 for OX. Since SP4 has the best average gaps of the three methods, the similarity in terms of number of best-known solutions found suggests that there is a larger variance in the quality of the results for AOX than for SP4. This is supported by the standard deviations of the final primal gaps, which are 0.143% for OX, 0.141% for AOX, and 0.136% for SP4. This means that the performances of OX and AOX are less predictable than the performance of SP4, and this unpredictability makes AOX more likely to obtain the very best solution, but also on average to obtain worse solutions.

Instead of comparing the methods to the best-known solutions, we can also compare the methods directly to each other. Figure 10 shows the number of runs for which each method has found the best solution during the runs. Based on the figure, out of the three methods, SP4 looks to be more likely to find the best solution if we run all three methods in parallel. This happens despite AOX being equally likely to find the best-known solution in any given run.

While Figure 10 suggests some differences between the three methods in terms of finding the best solution at the end of the run, these differences are not necessarily significant. To determine this, we use a non-parametric sign test [38]. In particular, we consider pairs of methods and count the number of runs where a given method performs better than another method. We consider a method to perform better if it either finds a better solution, or if it finds the same solution but uses less computational time to find it.

Table 8. Pairwise comparisons of runs and p-values from a two-sided sign-test [38].

	Wins	Losses	p-Value
SP4 vs. AOX	519	481	0.2420
SP4 vs. OX	583	417	0.0000
AOX vs. OX	554	446	0.0007

shows the results of pair-wise tests between SP4, AOX, and OX. The null hypothesis is that the two methods compared are equally likely to obtain the best performance, whereas the alternative hypothesis is that one of the methods performs better. That is, we use a two-sided test. The table shows that SP4 is better than AOX in 519 runs, while AOX is better than SP4 in 481 runs. The difference is not statistically significant. On the other hand, both SP4 and AOX perform statistically better than OX.

If runs leading to identical solutions are ignored, thus only considering runs where the methods identify different solutions, SP4 wins over AOX by 320 to 286 runs. Thus, the difference is larger in this case. If the 394 draws are ignored, the two-sided P-value is 0.18, and if the draws are distributed as half of a win for each method, as proposed by Derrac et al. [38], the p-value is 0.30. Thus, this difference between SP4 and AOX is still not unlikely to happen by chance. On the other hand, with these methods, SP4 is still better than OX with statistical significance (p-values less than 0.001), while the differences between AOX and OX are no longer statistically significant (p-values of 0.07 and 0.15, respectively).

6. Concluding Remarks

The development of heuristics for the capacitated vehicle routing problem is still an active field of research, and one of the best available heuristics is a hybrid genetic search implemented by Vidal [10]. The method includes a number of different operators to improve solutions using neighborhood search, but relies on a population of solutions to maintain diversity during the search and uses an order crossover operator to combine solutions from the population into new solutions. Solutions are then encoded as giant tours, or more precisely as permutation vectors of customer visits, and decoded using a splitting procedure. Hvattum [11] proposed an adjusted order crossover, which was shown to produce improved results. This paper has investigated the effect of an assumption in the splitting procedure, where the beginning of the permutation vector dictates the first customer visited on the first vehicle route.

We have examined four different preprocessing variants for the splitting procedure, where the permutation vector is shifted to modify the initial customer to be visited. Computational experiments reveal that this has an effect on the overall performance of the heuristic. In particular, on a standard set of benchmark instances, the resulting primal gap (considering the gaps to the best-known solutions) is reduced by 4.3% when using the best preprocessing variant, compared to not using any preprocessing step. With the new preprocessing step, the performance of the search is less variable. Thus the search seems less likely to obtain optimal or best-known solutions in each run, but is more likely to produce a better solution than the other methods.

It remains an open question whether the best way to improve the splitting procedure is to use a preprocessing step, as in this study, or to create more general dynamic programming algorithms to find an optimal split while explicitly considering all possible starting positions. In the case that a simple preprocessing step is to be preferred, there are many possibilities for how to do this step in addition to those examined in this study. For example, it would be natural to also consider the demands of each customer and the capacity of the vehicles when looking for a suitable starting position. This study considered a specific type of vehicle routing problem. Different variants of the problem may require different considerations to determine a suitable starting point for a splitting procedure.