In the following the computational experiments and their results will be discussed. Additional illustrative material can be found in an accompanying technical report, Pferschy and Staněk (2015), which is an extended version of this paper.
Setup of the computational experiments
All tests were run on an Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz with 16 GB RAM under Linux
Footnote 1 and all programs were implemented in C++
Footnote 2 by using the SCIP MIP-solverFootnote 3 (see Achterberg 2009) together with CPLEX as LP-solver. It has often been discussed in the literature (see e.g. Naddef and Thienel 2002) and in personal communications that ILP-solvers are relatively unrobust and often show high variations in their running time performance, even if the same instance is repeatedly run on the same hardware and same software environment. Our first test runs also exhibited deviations up to a factor of 2 when identical tests were repeated. Thus we took special care to guarantee the relative reproducibility of the computational experiments: No additional swap memory was made available during the tests, only one thread was used and no other parallel user processes were allowed. This leads to a high degree of reproducibility in our experiments. However, this issue makes a comparison to other simple approaches, which were tested on other computers under other hardware and software conditions, extremely difficult.
We used two groups of test instances: The first group is taken from the well-known TSPLIB95 (Reinelt 1995), which contains the established benchmarks for TSP and related problems. From the collection of instances we chose all those with (i) at least 150 and at most 1000 vertices and (ii) which could be solved in at most 12 hours by our BasicIntegerTSP. It turned out that 25 instances of the TSPLIB95 fall into this category (see Table 6), the largest having 783 vertices.
We also observed some drawbacks of these instances: Most of them (23 out of 25) are defined as point sets in the Euclidean plane with distances corresponding to the Euclidean metric or as a set of geographical cities, i.e. points on a sphere. Moreover, they often contain substructures like meshes or sets of colinear points and finally, since all distances are rounded to the nearest integer, there are many instances which have multiple optimal solutions. These instances are relatively unstable with respect to solution time, number of iterations, and—important for our approach—cardinality of the set of violated SEC. For our approach instances with a mesh geometry (e.g. ts225 from TSPLIB95) were especially prone to unstable behavior, such as widely varying running times for minor changes in the parameter setting. This seems to be due to the fact that these instances contain many 2-matchings with the same objective function value, and thus the search process for a feasible TSP tour can vary widely (for more details see Pferschy and Staněk 2015).
In order to provide further comparisons, we also defined a set of instances based on random Euclidean graphs: In a unit square \([0, 1]^2\) we chose n uniformly distributed points and defined the distance between every two vertices as their respective Euclidean distance.Footnote 4 These random Euclidean instances eliminate the potential influence of substructures and always have only one unique optimal solution in all stages of the solving process. We created 40 such instances named RE_X_n where \(n \in \{150, 200, 250, \ldots , 500\}\) indicates the number of vertices and \(X \in \{A, B, C, D, E\}\).
The running times of our test instances, most of them containing between 150 and 500 vertices, were often within several hours. Since we tested many different variants and configurations of our approach, we selected a subset of these test instances to get faster answers for determining the best algorithm settings for use in the final tests. This subset contains 12 (of the 25) TSPLIB instances and one random instances for every number of vertices n (see e.g. Table 1).
All our running time tables report the name of the instance, the running time (t (s)) in wall-clock seconds (rounded down to nearest integers), the number of iterations (#iter), i.e. the number of calls to the ILP-solver in the main part of our algorithm (without the TSP solutions for the clusters) and the number of SEC (#SEC) added to the ILP model in the last iteration, i.e. the number of constraints of the model which yielded an optimal TSP solution. We often compare two approaches in a table by taking the mean ratio, i.e. we compute the quotients between the particular columns t (s)/#iter/#SEC of the compared method over the first “reference” method on the same instances and then we report the arithmetic mean of these quotients.
Computational details for selected examples
Let us now take a closer look at two instances in detail. While this serves only as an illustration, we studied lots of these special case scenarios visually during the development of the clustering approach to gain a better insight into the structure of subtours generated by BasicIntegerTSP.
We selected instances kroB150 and u159 whose vertices are depicted in Figs. 4 and 5 in the “Appendix”. Both instances consist of points in the Euclidean plane and the distances between every two vertices correspond to their respective Euclidean distances, however, they represent two very different instance types: The instance kroB150 consists of relatively uniformly distributed points, the instance u159 is more structured and it contains e.g. mesh substructures which are the worst setting for our algorithm (recall Sect. 4.1).
Figure 19 in the “Appendix” illustrates the behavior of the running time t in seconds as a function of the parameter c for the instances kroB150 and u159. The full lines correspond to standard clustering approach \(C {\mid } c\) described in Sect. 3.2 (see Algorithm 2), while the dashed line corresponds to the restricted clustering \(RC_3 {\mid } c\) of Sect. 3.3 with minimum cluster size 3. The standard BasicIntegerTSP without clustering arises for \(c=1\).
Instance kroB150 consists of relatively uniformly distributed points in the Euclidean plane, but has a specific property: By using Algorithm 2 we can observe the occurrence of two main components also for relatively small coefficient c (already for \(c = 6\)). This behavior is rather atypical for random Euclidean graphs, cf. (Penrose 2003, ch. 13), but it provides an advantage for our approach since we do not have to solve cluster instances of the same order of magnitude as the original graph but have several clusters of moderate size also for small cluster numbers c.
Considering the standard clustering approach (Algorithm 2) in Fig. 19, upper graph, it can be seen that only a small improvement occurs for c between 2 and 5. Looking at the corresponding clusterings in detail, it turns out in these cases that there exists only one “giant connected component” and all other clusters have size 1. This structure also implies that for the restricted clustering these isolated vertices are merged with the giant component and the effect of clustering is lost completely. For larger cluster numbers c, a considerable speedup is obtained, with some variation, but more or less in the same range for almost all values of \(c\ge 6\) (in fact, the giant component splits in these cases). Moreover, the restricted clustering performs roughly as good as the standard clustering for \(c \ge 6\).
Instance u159 is much more structured and has many colinear vertices. Here, we can observe a different behavior. While the standard clustering is actually beaten by BasicIntegerTSP for smaller cluster numbers and has a more or less similar performance for larger cluster numbers, the restricted clustering is almost consistently better than the other two approaches. For c between 2 and 10 there exists a large component containing many mesh substructures which consumes as much computation time as the whole instance.
These two instances give some indication of how to characterize “good” instances for our algorithm: They should
General computational results
A summary of the computational results for BasicIntegerTSP and the most promising variants of clustering based subtour generations can be found in Table 6. For random Euclidean instances we report only the mean values of all five instances of the same size [detailed results for all random Euclidean instances can be found in our accompanying technical report, Pferschy and Staněk (2015)]. It turns out that \(\textit{HCD} {\mid } 4 \frac{n}{\log _2{n}}\), i.e. the hierarchical clustering approach combined with dropping SEC and fixing them only if they are generated again in the subsequent iteration and with the upper bound on the maximum cluster size \(u = 4 \frac{n}{\log _2{n}}\), gives the best overall performance. A different behavior can be observed for instances taken from the TSPLIB and for random Euclidean instances. On the TSPLIB instances this algorithm \(\textit{HCD} {\mid } 4 \frac{n}{\log _2{n}}\) is on average about 20 % faster than pure BasicIntegerTSP and beats the other clustering based approaches for most instances. In those cases, where it is not the best choice, it is usually not far behind.
As already mentioned, best results are obtained with \(\textit{HCD} {\mid } 4 \frac{n}{\log _2{n}}\) for instances with a strong cluster structure and without mesh substructures (e.g. pr299). For instances with mesh substructures it is difficult to find an optimal 2-matching which is also a TSP tour. For random Euclidean instances the results are less clear but approaches with fixed number of clusters seem to be better then the hierarchical ones.
It was a main goal of this study to find a large number of “good” SEC, i.e. subtours that are present in the last iteration of the ILP-model of BasicIntegerTSP. Therefore, we show the potentials and limitations of our approach in reaching this goal. In particular, we will report the relation between the set \(S_1\) consisting of all subtours generated by running a hierarchical clustering algorithm with an upper bound u (set as in the computational tests to \(u = 4 \frac{n}{\log _2{n}}\)) before solving the original problem (i.e. the root vertex) and the set \(S_2\) containing only the SEC included in the final ILP model of BasicIntegerTSP. We tested the hierarchical clustering with and without the dropping of non-repeated subtours.
There are two aspects we want to describe: At first, we want to check whether \(S_1\) contains a relevant proportion of “useful” subtour contraints, i.e. constraints also included in \(S_2\), or whether \(S_1\) contains “mostly useless” subtours. Therefore, we report the proportion of used subtours defined as
$$\begin{aligned} p_{used} :=\frac{\left| S_1\cap S_2\right| }{\left| S_1\right| }. \end{aligned}$$
(7)
Secondly, we want to find out to what extend it is possible to find the “right” subtours by our approach. Hence, we define the proportion of covered subtours defined as
$$\begin{aligned} p_{cov} :=\frac{\left| S_1 \cap S_2\right| }{\left| S_2\right| }. \end{aligned}$$
(8)
The values of \(p_{used}\) and \(p_{cov}\) are given in Table 3. It can be seen that empirically there is the chance to find about 26–31% (\(p_{cov}\)) of all required violated SEC. If SEC are allowed to be dropped, we are able to find fewer such constraints, but our choice has a better quality (\(p_{cov}\) is smaller, but \(p_{used}\) is larger), i.e. the solver does not have to work with a large number of constraints which only slow down the solving process and are not necessary to reach an optimal solution.
Table 3 Proportion of used and proportion of covered subtours for our hierarchical clustering approaches with the upper bound \(u = 4 \frac{n}{\log _2{n}}\) which (i) does not allow (\(\textit{HC} {\mid } 4 \frac{n}{\log _2{n}}\)) and which (ii) does allow (\(\textit{HCD} {\mid } 4 \frac{n}{\log _2{n}}\)) to drop the unused SEC
Furthermore, we can observe a relative big difference between the values of the proportion of used SEC (\(p_{used}\)) for the TSPLIB instances and for random Euclidean instances if the dropping of redundant constraints is allowed.
Adding a starting heuristic
Of course, there are many possibilities of adding improvements to our basic approach. Lower bounds and heuristics can be introduced, branching rules can be specified, or cutting planes can be generated. We did not pursue these possibilities since we want to focus on the simplicity of the approach. Moreover, we wanted to take the ILP solver as a “black box” and not interfere with its execution.
Just as an example which immediately comes to mind, we added a starting heuristic to give a reasonably good TSP solution as a starting solution to the ILP solver. We used the improved version of the classical Lin–Kernighan heuristic in the code written by Helsgaun (2008). The computational results reported in Table 4 show that a considerable speedup (roughly a factor of 3, but also much more) can be obtained in this way.
Table 4 Results for BasicIntegerTSP used without/with the Lin–Kernighan heuristic for generating an initial solution: Using the starting heuristic yields faster running times for all instances