Practical Graph Bipartization with Applications in Near-Term Quantum Computing

Practical Graph Bipartization with Applications in Near-Term Quantum Computing

Abstract

We experimentally evaluate the practical state-of-the-art in graph bipartization (Odd Cycle Transversal), motivated by recent advances in near-term quantum computing hardware and the related embedding problems. We assemble a preprocessing suite of fast input reduction routines from the odd cycle transversal and vertex cover literature, allowing the slower branching algorithms to be compared on identically-preprocessed data. In addition to combinatorial branching algorithms, we also study multiple methods for computing graph bipartization with integer linear programming solvers. Evaluating the practical performance of these algorithm, two use cases in quantum annealing are studied with a quadratic unconstrained binary optimization problem corpus. Finally, we provide all code and data in an open source suite, including a Python API for accessing reduction routines and branching algorithms, along with scripts for fully replicating our results.

Graph Bipartization, Odd Cycle Transversal, Near-Term Quantum Computing, Quantum Annealing, Vertex Cover, Integer Linear Programming
\extrafloats

50 \CopyrightTimothy D. Goodrich and Eric Horton and Blair D. Sullivan\subjclassG.2.2 Graph Theory, G.2.3 Applications

1 Introduction

Odd Cycle Transversal (OCT), the problem of computing a minimum set of vertex removals that will yield a bipartite graph, has been well-studied in the theory community over the last two decades. Techniques such as iterative compression [30, 16] and branch-and-reduce [23, 3] have led to significant improvements in both worst-case and experimental run times. These improvements are most drastically seen on Wernicke’s Minimum Site Removal dataset [35] (referred to here as WH), which has become the canonical OCT benchmark, where run times dropped from over 10 hours [35] to under 3 minutes [16] to under 1 second [3].

Recently, a need for practical graph bipartization algorithms has arisen in quantum computing, where physical constraints limit the topology of all near-term quantum hardware to bipartite structure. However, it is not clear that the existing experimental results for OCT generalize to this setting. Specifically, the datasets arising in quantum computing are not purportedly close-to-bipartite (like those in WH), and bipartization algorithms are typically employed by automated compilers where a heuristic that finds a ‘small enough’ OCT set is acceptable, introducing a run time vs. solution quality trade-off.

1.1 Related Work

Modern theoretical advances on OCT began with the seminal result of Reed, Smith, and Vetta [30] showing that the problem is fixed-parameter tractable (FPT) by introducing a technique called iterative compression. They gave a algorithm for minimum OCT size ; subsequent improved analysis [16, 24] led to a run time and simpler algorithms for the compression routines. The observation that any OCT instance can be naturally transformed into a VC (VC) instance led to an algorithm1 [23] where the parameter measures the gap between the size of a minimum vertex cover and the solution produced by an LP relaxation of that problem (commonly referred to as Vertex Cover Above LP). Recent work has explored reducing the polynomial run time by increasing the parameterized function to [19, 34, 20]. Other algorithmic results for OCT include a -approximation algorithm [1], a randomized algorithm based on matroids [22], and a subexponential algorithm on planar graphs [25].

On the practical side, the first implementation was a branch-and-bound algorithm by Wernicke in 2003 [35] used for studying single nucleotide polymorphisms. A greedy depth-first search heuristic was used to identify upper bounds on OCT, and several sparse-graph reduction routines were applied before branching. A Java implementation of this algorithm solved most WH instances within a 10 hour timeout. In 2009, Hüffner implemented a refined iterative compression algorithm  [16] with additional pruning for infeasible assignments and symmetry in the compression routine’s branching algorithm to achieve experimentally faster run times; all of the WH instances could now be solved within three minutes. Hüffner also compared against an ILP formulation using the GNU Linear Programming Kit (GLPK) [11], which had unfavorable run times. More recently, Akiba and Iwata [3] used a VC-solver based on branch-and-reduce to solve OCT using a standard transformation to VC [23]. The authors found that their open source Java implementation could solve all WH data within a second, while competitors based on maximum clique and an ILP formulation run using CPLEX [17] all finished within three seconds.

1.2 Our Contributions

In this work, we evaluate existing OCT implementations in a broader, quantum-computing–inspired experimental envelope (see Section 2.1). We introduce a new benchmark dataset commonly used in quantum annealing [28], and unify a corpus of preprocessing methods from [35, 3]. Next, we collect and implement a heuristic ensemble [35, 12] to compete in the time-limited setting, and engineer an improved version of Hüffner’s iterative compression code. We execute an extensive set of fully replicable experiments to evaluate the effectiveness of preprocessing and compare the performance of heuristic, combinatorial, and ILP-based solvers in both time-limited and exact solution use cases.

We start by addressing issues related to datasets. First, the canonical WH dataset is naturally close-to-bipartite (an unrealistic assumption in quantum computing applications) and any modern solver is expected to find an optimal solution within a few seconds on all instances. From the quantum annealing literature [28, 9] we identify the Beasley [5] and GKA [10] datasets as a suitable benchmark (Section 3.2). Second, some previous studies relied on preprocessing [35, 3] while others did not [16]. To even the playing field, we collect existing reduction routines [35, 3] into a suite and apply them to the raw datasets (Section 3.3) before running any OCT algorithm.

Since a quantum compiler may prefer speed over solution quality, we collect linear-time heuristics for OCT from the literature and provide them in a heuristic ensemble solver (Section 4.1). We then engineer an updated version of Hüffner’s iterative compression solver to benefit from starting with a non-optimal solution and a density-based ordering on the remaining vertices (Section 4.2). We find that starting from an initial heuristic solution generally provides a speed-up, and that the density ordering can further help in situations with larger timeouts.

Before proceeding to our comprehensive comparison of state-of-the-art solvers, we revisit seemingly contradictory results in prior evaluations of ILP-based solvers. Specifically, previous work by Hüffner [16] found that the ILP formulation of OCT was strictly worse than his iterative compression approach when using the GLPK [11] solver, whereas Akiba and Iwata [3] found that using an formulation with the CPLEX [17] solver was competitive with modern combinatorial approaches. We examine combinations of these choices along with hardware considerations (Section 5), and find that CPLEX with the formulation is most efficient, even when varying the number of threads and available system memory.

Finally, in Section 6 we benchmark the solvers in two use cases: (1) A heuristic solution is required within 0.01, 0.1, 1, and 10 seconds, and (2) A proven exact solution is required (within a 10 minute timeout). In the time-limited heuristic setting, our Improved Hüffner solver is the best performer for run times less than a second, with ILP pulling ahead for run times over a second. In the exact experiment we find that ILP also dominates, with the Akiba-Iwata VC-solver a constant factor slower.

Our work is fully replicable, with documented code open sourced with the BSD 3-Clause license at https://github.com/TheoryInPractice/practical-oct. For the interested reader, implementation considerations are documented in Appendix A, and full experimental results are included in Appendix B.

2 Background

2.1 Motivation from Quantum Computing

Motivation for practical graph bipartization implementations stems from advances in near-term quantum computing. While long-term quantum computing focuses on using quantum computers to unequivocally beat classical computing, the theoretical hardware requirements are quite far from modern production models. For example, running Shor’s Algorithm to factor integers in 2048-bit RSA keys is estimated to require three million qubits in a circuit-based model when error correction is taken into account [2]. In contrast, near-term quantum computing concentrates on using quantum computers obtainable now to achieve speedups in specific applications. Figure 1 depicts several such hardware models as graphs, where qubits and their couplers are represented as nodes and edges, respectively. Notably, physical constraints force modern hardware to have bipartite topology.

Figure 1: All modern topologies are natively bipartite (visually denoted by a blue-white two-coloring). Google’s announced Bristlecone hardware is expected to be the first hardware to achieve quantum supremacy over classical computers. Rigetti Computing [8] and IBM [18] both manufacture circuit-based quantum computers with 20- and 50-qubits, respectively. D-Wave Systems manufactures quantum annealers using ‘Chimera(, , )’ graphs: An grid of complete bipartite cells; the upper-left corner of this fabric is shown here.

Graph bipartization occurs during the compilation step, when a problem graph must be embedded into the hardware graph. The definition of “embedding” depends on the model of quantum computing, but at a high level it captures the notion of mapping logical qubits needed by the program to physical qubits present in the hardware.

In analog quantum computing (“quantum annealing”), a typical pipeline is for an optimization problem to be formulated as a Quadratic Unconstrained Binary Optimization Problem (QUBO), which then must be found as an graph minor of the hardware [7]. Researchers have had success running natively bipartite QUBOs (e.g. deep learning models) on D-Wave Systems annealers [31, 21, 6, 29]. Generalizing these tools to non-bipartite QUBOs is currently of interest to enable additional applications (e.g. Karp’s 21 NP-hard problems [27]). The area of automatic embedding tools is under active development (refer to, e.g., [12, 14, 33]).

In circuit-based quantum computing, the embedding problem is a more complex placement, routing and scheduling problem [32]. Unlike on quantum annealers, adjacent qubits on a circuit-based hardware can be swapped, allowing non-complete hardware topology to execute gates on all combinations of edges through a series of exchanges. However, these swaps should be minimized to decrease run time, highlighting the need for optimal initial placements. Fast graph bipartization routines would enable a better initial placement analysis, so that odd cycles in the problem circuit are most easily emulated on the bipartite hardware.

While the theory behind circuit-based models is older, production-level analog computers are more prevalent, so we will restrict our scope to quantum annealing. We will concentrate on two use cases of current relevance. First, a feasible bipartization of a graph is useful for certain embedding algorithms, regardless of minimality [12, 14]. An automated compiler might require this bipartization in as little as 0.01 seconds, whereas a computer-assisted researcher working in an interactive environment may wait closer to 10 seconds. In a second use case, OCT can be used to identify when a particular program cannot embed into hardware, as is shown for D-Wave System’s Chimera hardware in [12]. This scenario requires that the solver return a proven-minimum OCT solution, but longer run times are permissible since a hardware owner can compute forbidden configurations once per hardware model. We examine both of these use cases in more detail in Section 6.

2.2 Definitions and Notation

We denote a graph . For a set of vertices , denotes the graph resulting from deleting from . We now formally define OCT (and the related problem VC).

Odd Cycle Transversal (OCT) parametrised by

Vertex Cover (VC) parametrised by

As noted in [23], an instance of OCT can be solved as an instance of VC by creating an auxiliary graph , where and (for ), and . A solution to the VC instance can be mapped to a solution for the OCT instance with . Additionally, each problem can be reformulated as an Integer Linear Programming instance to be solved with an industrial-grade solver (e.g., CPLEX [17]):

Odd Cycle Transversal (ILP-Formulation) [16]

Vertex Cover (ILP-Formulation) [3]

The OCT solution can be recovered from the first formulation with , and a VC solution from the second with . See [16] and [3] for more details on how these ILP formulations are derived.

3 Experimental Setup

In this section we detail the experimental setup, including the hardware and software environment, the data used, and steps taken to preprocess the data.

3.1 Hardware and Software Environment

All experiments were run on a Dell T20 workstation with an Intel Xeon E3-1225 v3 CPU, 16GB ECC DDR3 system memory in a dual-channel configuration, and an Intel S3500 solid state drive as storage. This workstation ran Debian 4.9.82-1 with Linux kernel 4.9.0-6, CPLEX 12.8, and GLPK 4.61. C/C++ code was compiled with gcc/g++ 6.3.0, Java code was compiled and run with OpenJDK 1.8.0_162, and Python code was run with Python 3.5.3 (the newest version supported by CPLEX 12.8).

All code is available at https://github.com/TheoryInPractice/practical-oct. For information on reproducing the full results presented here, see REPLICABILITY.md. All algorithms are available as standalone solvers, and we provide scripts for downloading the original data source and nondeterministically parsing it into the graphs used in this work. Python scripts are provided to execute the experiments reported here and produce all associated results tables. Implementation details are provided in Appendix A.

3.2 Data

As mentioned in Section 1.1, the primary dataset studied in OCT literature originates from Wernicke and is distributed with Hüffner’s code; we refer to this data as the Wernicke-Hüffner (WH) dataset. This dataset is composed of 45 Afro-American graphs (denoted aa-10, , aa-54) and 29 Japanese graphs (denoted j-10, , j-28). Although files aa-12, j-12, and j-27 are provided in Hüffner’s code, they are empty and not included here.

While Wernicke’s implementation required over 10 hours to solve some of these datasets, Akiba and Iwata’s latest results show that any state-of-the-art solver can solve all these instances within three seconds, therefore we borrow a more difficult benchmark dataset from quantum computing. A recent survey [9] collected six datasets from the QUBO literature (see Section 2.1); of these, only the Beasley [5] and GKA [10] data have instances whose sizes are amenable to embedding in near-term quantum annealing hardware.

Specifically, we consider the 50-vertex instances (denoted b-50-1, , b-50-10) and the 100-vertex instances (denoted b-100-1, , b-100-10) of the Beasley dataset and the first 35 instances of the GKA dataset (denoted gka-1, , gka-35), which have varying numbers of vertices and densities.

All datasets are parsed as undirected, simple graphs with no vertex or edge weights. Vertices or edges with weight zero are excluded, and self-loops are removed. Additionally, graphs are relabeled with vertices and are written to files for each solver’s required format. (We refer the interested reader to Appendix A.1 for implementation details).

3.3 Reduction Routines and Preprocessed Data

Original Graph Reductions Reduced Graph
Dataset
aa-10 69 181 6 10 0 0 30 59 181 6
aa-11 103 298 11 10 0 0 62 93 298 11
aa-16 14 0 0 14 0 0 0 0 0 0
aa-21 31 0 9 22 0 9 0 0 0 0
aa-41 300 1585 40 39 0 0 172 261 1585 40
aa-42 237 1100 30 11 0 0 137 226 1100 30
j-10 57 97 3 20 0 0 13 37 97 3
j-11 51 198 5 14 0 0 8 37 198 5
j-15 45 0 1 44 0 1 0 0 0 0
j-16 14 0 0 14 0 0 0 0 0 0
gka-1 50 90 11 4 0 2 9 44 90 9
gka-2 60 149 17 1 0 1 1 58 149 16
gka-16 90 0 86 4 0 86 0 0 0 0
gka-17 100 0 96 4 0 96 0 0 0 0
gka-18 125 16 120 0 0 118 1 7 16 2
gka-25 100 495 42 0 0 0 1 100 495 42
b-50-1 50 108 11 0 0 0 5 50 108 11
b-50-2 50 118 11 3 0 0 4 47 118 11
b-100-1 100 464 41 0 0 0 0 100 464 41
b-100-2 100 482 42 0 0 0 0 100 482 42
Table 1: A representative sample of preprocessed datasets. Each instance initially has vertices and edges, and a min OCT size of . Preprocessing partitions , where are removed, () must (must not) be in the OCT set for some fixed, optimal OCT, and are remaining unlabeled vertices. Likewise, edges are partitioned into , where are removed edges and are remaining edges. The reduced graph has vertices, edges, and a min OCT size of .

Previous experiments have differed in the use of preprocessing methods: Wernicke uses them for moderately faster run times, Hüffner’s algorithm does not use any, and Akiba-Iwata’s VC-solver fundamentally depends on iteratively reducing the graph after branching. To remove the effect of non-uniform application initial reductions from our experiments, we preprocess the input corpus by applying both Wernicke’s and Akiba-Iwata’s reductions iteratively until none apply. We provide an implementation of Wernicke’s reductions in Python using NetworkX [13] and modify Akiba-Iwata’s implementation to compute one round of reductions; details are deferred to Appendix A.2. While some reduction routines are nondeterministic, we use sorting to ensure that our implementation provides deterministic results for a given dataset graph file, therefore our exact results are reproducible from the original graph files.

We denote reductions as a partition of the original vertex set . The vertices that may be removed without changing are denoted . For some fixed optimal solution , vertices must be in and vertices cannot be in . Finally, the remaining vertices are labeled . Analogously, the edges are partitioned into . The removed vertices/edges and fixed OCT vertices may be removed from the graph safely, therefore the preprocessed graph has vertices and edges .

Table 1 summarizes preprocessing results on several representative instances; full results are in Appendix B (Table 7). There are several noteworthy observations. First, a number of instances can be solved entirely with preprocessing; we leave the resulting empty graphs in our dataset for consistency with prior experiments, but remark that they provide no meaningful insights into solver performance. Second, the effects of preprocessing are highly variable across types of data. In the WH datasets, which are expected to be bipartite with errors based on domain knowledge, preprocessing typically removes a significant number of vertices, and is able to establish that many more can be fixed as bipartite. In contrast, the reduction routines identify vertices in the GKA datasets which can be fixed as OCT and removed from the graph, significantly reducing the complexity of solving (since OCT is FPT with respect to solution size), but almost no other preprocessing techniques apply. Finally, Beasley datasets saw little to no effect from preprocessing.

4 Heuristics and Iterative Compression

In this section we overview heuristics for upper-bounding OCT, and engineer improvements to Hüffner’s algorithm using a heuristic solution and subgraph density information to determine the order in which the iterative compression algorithm considers vertices.

4.1 Heuristic Algorithms

Heuristics for OCT typically compute a maximal bipartite induced subgraph, then label all remaining vertices as an odd cycle transversal. One strategy for finding a large bipartite subgraph is greedily 2-coloring the vertices using a depth-first search, adding incompatible vertices to an OCT set as needed [35]; this heuristic has a natural breadth-first search variant. Both of these methods are nondeterministic with the choice of the initial vertex and in the order which neighbors are added to the search queue. Another approach is to find an independent set for the first partite set, then repeat for a second partite set, for example as in Luby’s Algorithm [26]. Recent work showed that by using the minimum-degree heuristic for independent set, this strategy gives a -approximation in -degenerate graphs [12]. Both of these methods are nondeterministic; the former is stochastic by design, and the latter breaks ties between minimum degree vertices. We provide implementations of these four heuristics (DFS, BFS, Luby, and MinDeg), along with an ensemble solver that runs them round-robin for a specified timeout; see Appendix A.3 for implementation considerations.

4.2 Improving Hüffner’s Iterative Compression Algorithm

OCT Size
Dataset Mean S.D. Min 25% 50% 75% Max
Timeout: 1 (s)
aa-42 0 51.8 13.4 33 42 49 59 85
1 31.0 1.2 30 30 31 32 35
2 31.9 0.3 31 32 32 32 32
gka-2 0 16.8 0.9 16 16 17 17 19
1 16.0 0.0 16 16 16 16 16
2 16.0 0.0 16 16 16 16 16
Timeout: 10 (s)
aa-41 0 67.0 14.4 48 55 64 75 110
1 41.4 1.2 40 40 41 42 44
2 41.2 0.7 40 41 41 41 43
gka-3 0 25.2 1.6 23 24 25 26 29
1 23.3 0.5 23 23 23 24 24
2 23.4 0.5 23 23 23 24 24
Table 2: Heuristic solution sizes for select datasets at the three levels of preprocessing () for Improved Hüffner. The timeout level on each dataset was taken to be the maximum time in less than the time Hüffner at took to find an exact solution. Mean, standard deviation, and quintiles are computed over 50 samples per timeout, dataset, and preprocessing level.

The state-of-the-art implementation for solving OCT directly is by Hüffner, and is based on iterative compression, a standard technique from parameterized complexity [30], where a solution of size on a subgraph is compressed to a solution of size for the same subgraph in time . Although prior work has shown that iterative compression is slower than VC-based algorithms both in theory [23] and in practice [3], we observe that it may have an advantage in some quantum use cases. Specifically, since this approach maintains a lower bound on OCT and computes increasingly better upper bounds, it can be applied to improve non-optimal solutions in time-limited settings. We use an engineered version of Hüffner’s implementation in our experiments; in this section, we describe these modifications and their impacts on solution quality under varying timeouts.

Hüffner’s OCT implementation iterates over an ordering of , starting with both subgraph and OCT set equal to the initial vertices, then repeatedly compressing and incorporating the next unused vertex in the ordering. The algorithm’s performance can vary significantly depending on the ordering used.

We first show that a heuristic solution can be used to reduce the number of compressions executed. Hüffner (correctly) noted that starting with a heuristic solution on the full graph and compressing down would lead to an exponentially-slower algorithm. Instead of taking this approach, we instead use the bipartite subgraph identified in a heuristic solution to define the initial subgraph. By placing these bipartite vertices at the start of the vertex ordering, the initial compression routine will execute with the next vertices as an OCT set on a subgraph of the first vertices, effectively reducing the number of compression routine executions by .

Second, exploiting Hüffner’s branching speedups on dense graphs, we order the remaining vertices in based on their degree into the subgraph. Hüffner’s pruning of the search space of -sized solutions operates by eliminating (in)feasible solutions based on the presence of edges (e.g., two adjacent vertices cannot be assigned the same partite set), therefore the compression routine performs best when the graph is as dense as possible. We can maximize this density by adding vertices based on their degree into the current iteration’s subgraph. At a minimum, this heuristic improvement will eliminate the addition of vertices with no edges into the current graph, a clear worst-case.

Finally, we note that Hüffner’s branching rules for reducing the search space of size solutions using the connectivity of the OCT set can be improved with data from preprocessing. Specifically, vertices in will fix bipartite components and reduce the search space. However, given the lack of these preprocessing reductions in QUBO data (Section 3.3), we leave this extension as future work.

4.3 Improvement Evaluation

We implement our heuristic improvements in a version of Hüffner’s code improved for simplicity and compiler compatibility. Details are deferred to Appendix A.4. In this Improved Hüffner () algorithm we require two new parameter inputs: a preprocessing optimization level , and a preprocessing timeout. The preprocessing optimization levels are none (), bipartite-heuristic only (), and bipartite-heuristic with density sorting (). We found that setting the preprocessing timeout to 30% of the total timeout for a maximum of one second provided optimal performance.

To evaluate these preprocessing options, we selected a subset of the data (c.f., Table 3) with a mixture of easy and difficult problems. We then ran all three levels using 50 random seeds on each instance for each of four timeouts , and report mean, standard deviation, and quintiles of the OCT sizes found. A representative sample of results is in Table 2, with full results in Appendix B (Table 9). We find that always dominates , especially in max and standard deviation, suggesting that certain orderings (avoided with ) are significantly disadvantageous for iterative compression. Second, we find that tends to help on larger timeouts, where the run time cost of computing this ordering disappears. Both observations can be seen in Table 2, where aa-41 and aa-42 benefit slightly from , but gka-2 and gka-3 do not.

5 Integer Linear Programming Solvers

As noted in the introduction, previous work [16, 3] has conflicting reports on the effectiveness of Integer Linear Programming (ILP) solvers. In this section we identify the best configuration for solving OCT with ILP with the following options: choosing a solver from CPLEX [17] and GLPK [11], choosing a formulation from and , having one thread or multithreaded (4 physical cores), and having limited system memory (4MB) or plentiful memory (16GB). This memory limit is significant because [16] notes that Hüffner’s implementation only requires 4MB of memory and there may be a use case that requires minimal memory usage. We find that CPLEX and result in the fastest solutions, that multithreading can result in superlinear speedup, and that increased system memory can provide up to a speedup depending on the instance.

5.1 Experimental Evaluation

To evaluate ILP-based approaches, we use the same subset of data selected in Section 4.3 and solve with all possible combinations of solver, threads, and OCT formulation described above (denoted ). (Note that GLPK is single-threaded).

Preprocessed Graph Solver
Dataset Time (s)
gka-1 44 90 9 0.1
aa-43 58 303 18 0.1
aa-45 75 381 20 0.1
gka-2 58 149 16 0.1
aa-29 265 1048 21 0.1
aa-42 226 1100 30 0.3 -
aa-32 126 733 30 0.4 -
gka-3 70 223 23 0.8 -
aa-41 261 1585 40 0.7 -
gka-26 100 494 43 16.8 -
gka-24 90 400 37 17.8 -
gka-25 100 495 42 24.4 -
gka-29 100 2000 77 36.3 -
gka-27 100 1016 62 107.4 -
gka-28 100 1425 70 142.0 -
Table 3: Relative run times for solving exactly with the formulation and 16GB of memory. Multithreaded CPLEX is used as the baseline time. Times are not reported for configurations that required more than 10 minutes.
Figure 2: Run times for CPLEX configurations with 16GB of system memory. Times are not reported for configurations that required more than 10 minutes.

Comparing solvers, CPLEX dominated GLPK when using the same formulation, regardless of number of threads or system memory levels. Table 3 depicts the relative run times when fixing the formulation to and system memory to 16GB. Interestingly, often performed over four times faster than its single-threaded variant.

Comparing problem formulations, also dominated (Figure 2). This result may not be surprising given [23], but it suggests that there may also be alternative, faster formulations of OCT as an ILP that may lead to even better results. In extended results (Appendix B, Figure 3 and Table 6) we find that limiting the solvers to 4MB of system memory does not change the relative performance landscape, and only doubles the run time of the slowest dataset gka-28. However, our results together with the run times from Section 6 suggest that using ILP would still be preferable when time is not extremely limited.

6 Experimental Results

In this section, we evaluate all solvers in our two quantum-computing–inspired use cases.

Use Case: Heuristic Solutions

For the first use case, a quantum compiler may need a bipartization of an input program (e.g., a QUBO or circuit) in order to prune a search space of embeddings, but has a very small time budget for this step. We thus computed heuristic solutions for OCT on each preprocessed instance with timeouts of 0.01, 0.1, 1.0, and 10 seconds using three solvers: the heuristic ensemble from Section 4.1 (HE); Improved Hüffner from Section 4.2 with optimization level (); and the best ILP configuration from Section 5 using CPLEX with an formulation, 4 threads, and 16GB of memory (ILP). At the timeout, we recorded the current best solution known to the solver and the time taken to find it.

We report approximation factors in Table 4, with full results in Appendix B (Tables 11 and 12). Notably, a user could achieve worst-case approximation factors of and for timeouts 0.01(s) and 0.1(s) (respectively) by solving with , and approximation factors of and for timeouts 1(s) and 10(s) by solving with ILP.

Timeout: 0.01(s) 0.1(s) 1(s) 10(s)
Dataset HE ILP HE ILP HE ILP HE ILP
aa 1.38 1.29 8.05 1.27 1.17 2.19 1.19 1.12 1.00 1.19 1.06 1.00
j 1.11 1.23 1.60 1.11 1.11 1.00 1.00 1.00 1.00 1.00 1.00 1.00
b-50 1.11 1.09 1.56 1.09 1.07 1.21 1.08 1.00 1.00 1.00 1.00 1.00
b-100 1.10 1.10 1.17 1.07 1.07 1.17 1.05 1.05 1.10 1.05 1.05 1.02
gka 1.21 1.18 1.34 1.18 1.18 1.18 1.11 1.14 1.07 1.11 1.14 1.02
Table 4: Observed approximation factors for heuristic solutions over datasets aa, j, b-50, b-100, and gka. For each dataset, we report the worst-case approximation ratio over its instances. Approximation ratios are with respect to , computed and cross-validated with ILP and A-I.

Use Case: Exact Solutions

In the second use case, a researcher may want to compute the limits of particular configurations supported on a fixed hardware graph. By recognizing if the OCT size of a problem graph is too large for the hardware, we can reject a configuration without trying to embed. We thus computed exact solutions with a 10 minute timeout on preprocessed instances using the three solvers that could guarantee optimality: the Akiba-Iwata (A-I) VC-solver [3], , and ILP.

The majority of the results roughly mirror those of [3]: A-I and ILP solve optimally within three seconds, and run times rapidly increase with the OCT size. However, Table 5 lists the datasets that are more computationally difficult, and here we find that ILP bests A-I in the majority of instances. Full data is available in Appendix B (Table 10).

Graph Solver Graph Solver
Dataset A-I ILP Dataset A-I ILP
b-100-1 41 97.8 - 21.3 gka-21 40 1.7 22.2 0.3
b-100-2 42 185.5 - 52.7 gka-22 43 5.4 - 1.0
b-100-3 42 242.3 - 20.9 gka-23 46 42.6 - 16.9
b-100-4 41 199.8 - 33.1 gka-24 37 74.3 - 17.3
b-100-5 42 208.6 - 41.7 gka-25 42 122.9 - 28.6
b-100-6 43 143.6 - 99.6 gka-26 43 160.5 - 18.4
b-100-7 42 182.0 - 40.4 gka-27 62 535.3 - 192.6
b-100-8 43 356.7 - 39.3 gka-28 70 284.9 - 366.0
b-100-9 44 321.4 - 72.9 gka-29 77 64.3 - 42.5
b-100-10 44 188.6 - 118.3 gka-30 82 32.7 - 53.2
gka-3 23 1.4 58.0 0.9 gka-31 85 11.7 107.6 17.4
gka-8 28 7.2 - 4.8 gka-32 88 5.3 17.9 19.2
Table 5: Run times on select instances for solvers A-I, , and ILP. Times are not reported for configurations that required more than 10 minutes.

7 Conclusion

We experimentally evaluate state-of-the-art approaches to computing Odd Cycle Transversal on both the canonical WH dataset and on a new benchmark dataset from quantum annealing. On this expanded corpus, we find that there is no single implementation that dominates in all scenarios. Under extreme time constraints, low-overhead heuristics followed by iterative compression performs best. However, even with a 10 second time limit, heuristics quickly become ineffective when compared with modern ILP solvers (which come with the additional benefit of scaling with additional CPU and memory resources). If open source code is required, however, the Akiba-Iwata VC-solver becomes competitive. Our results identify several important directions for future work:

Development of lightweight solvers with efficient implementations. While suites such as CPLEX dominate the exact solver comparisons, there are opportunities to improve in the very short run time scenarios where low overhead is paramount. Efficient implementations of reduction routines, heuristics, and incremental improvement algorithms are needed here.

Increasing scalability of existing algorithms. Akiba-Iwata and Hüffner both leverage combinatorial structure for lightweight, competitive algorithms. However, both current implementations are written for serial processors and use relatively little system memory. CPU-based parallelism would benefit the branch-and-reduce strategy, while GPU-based Single-Instruction-Multiple-Data parallelism fits well with Hüffner’s compression routine.

Exploring formulations of OCT as ILP. We found that formulating OCT as VC led to a more efficient ILP formulation. Additional structures (such as those from biased graphs [34]) may lead to even faster ILP formulations.

Acknowledgments

This work supported in part by the Gordon Betty Moore Foundations Data-Driven Discovery Initiative through Grant GBMF4560 to Blair D. Sullivan, and a fellowship by the National Defense Science Engineering Graduate Program to Timothy D. Goodrich.

Appendix A Implementation Details

a.1 Data Implementation

Original data comes from two sources. Wernicke-Hüffner data is provided in the Hüffner code download [15], and Beasley and GKA data comes from Beasley’s repository [4].

When parsing the graphs with Python we read them into NetworkX graph and remove edges with zero weights (used to denote non-edges in some problems) and self-loops. We then relabel the vertices to . To remove possible non-determinism in how vertices are relabeled, we specify that convert node labels in sorted order, guaranteeing that each graph is always converted in the same way.

See the DATA.md document in our repository for information on how to use our scripts for automating this download and parsing process.

a.2 Preprocessing Routines

Reduction routines for preprocessing come from two papers: Wernicke [35] and Akiba and Iwata [3].

While Wernicke originally implemented his in Java, the code does not appear to have been open sourced. We implement his reduction routines in Python3 with NetworkX. Some care must be taken that these reductions operate nondeterministically so the results can be reproduced. Specifically, reduction rules 4 and 6 require vertex cuts, which are computed by NetworkX are returned in arbitrary order; we convert the cuts to tuples and sort them by vertex name (recall vertices are named from ). Additionally, reduction rules 7, 8, and 9 find and remove particular configurations in the graph based on degree 2 and 3 vertices; we sort these sets of vertices and the related neighborhoods.

For Akiba and Iwata’s reduction routines, we modify their GitHub code2 so that no branching is done after the first iteration of reduction routines, and the preprocessed graph is output instead. To preprocess a graph, we apply Wernicke reductions first, then Akiba-Iwata reductions, and repeat until the graph does not change. This was done primarily because some of Akiba-Iwata’s reductions will not apply after the Wernicke reductions, simplifying the conversion from VC to OCT.

In order to make our experiments replicable, we verified that these reductions are nondeterminstic by performing multiple rounds of preprocessing on different machines and checking that the resulting graphs were isomorphic, if small enough to be feasible, and had matching degree, triangle, and number of cliques sequences using the NetworkX could_be_isomorphic method otherwise. To verify that these reductions are safe, we saved and verified a certificate from each run of a solver that returned a feasible solution.

See the PREPROCESSING.md document in our repository for information on how to run our scripts for preprocessing.

a.3 Heuristics

We implemented the heuristic ensemble in Modern C++14. Given a graph file and a timeout, the ensemble will run greedy independent set (MinDeg), Luby’s Algorithm (Luby), DFS 2-coloring (DFS), and BFS 2-coloring (BFS) in a round-robin fashion until the time limit is reached, returning the single best solution found by any heuristic. See [12] for more on MinDeg, [26] for more on Luby, and [35] for more on DFS.

See the HEURISTIC.md document in our repository for information on how to run the heuristic ensemble solver.

a.4 Hüffner Improvements

We implemented our improvements to Hüffner’s implementation [16, 15] in Modern C++14, and rewrote the original solver to compile in C11. By default, the enum2col solver is run, with the preprocessing level specified by the user: The default algorithm (), the default algorithm with a heuristic bipartite subgraph starting the ordering (), and the default algorithm with a heuristic bipartite subgraph starting the ordering and the remaining vertices sorted such that the most number of edges appear in the subgraph the earliest ().

See the IC.md document in our repository for information on how to download, install, and run this improved iterative compression solver.

Appendix B Extended Results

Figure 3: Run times for CPLEX configurations with 4MB of system memory. Times are not reported for configurations that required more than 10 minutes.
Preprocessed Graph Solver
Dataset Time (s)
gka-1 44 90 9 0.1
aa-43 58 303 18 0.1 -
aa-45 75 381 20 0.1 -
gka-2 58 149 16 0.1 -
aa-29 265 1048 21 0.1 -
aa-42 226 1100 30 0.3 -
aa-32 126 733 30 0.4 -
gka-3 70 223 23 0.7 -
aa-41 261 1585 40 0.7 -
gka-26 100 494 43 26.1 -
gka-24 90 400 37 20.7 -
gka-25 100 495 42 35.3 -
gka-29 100 2000 77 44.1 -
gka-27 100 1016 62 139.0 -
gka-28 100 1425 70 317.1 -
Table 6: Relative run times for solving exactly with the formulation and 4MB of memory. Multithreaded CPLEX is used as the baseline time. Times are not reported for configurations that required more than 10 minutes.
Original Graph Results Reduced Graph
Dataset
aa-10 69 181 6 10 0 0 30 59 181 6
aa-11 103 298 11 10 0 0 62 93 298 11
aa-13 131 375 12 10 0 0 79 121 375 12
aa-14 127 512 19 16 0 0 66 111 512 19
aa-15 67 146 7 15 0 1 21 51 146 6
aa-16 14 0 0 14 0 0 0 0 0 0
aa-17 153 628 25 7 0 0 91 146 628 25
aa-18 90 373 14 11 0 0 33 79 373 14
aa-19 192 636 19 11 0 0 120 181 636 19
aa-20 225 760 19 7 0 0 161 218 760 19
aa-21 31 0 9 22 0 9 0 0 0 0
aa-22 167 636 16 5 0 0 115 162 636 16
aa-23 143 492 18 21 0 0 69 122 492 18
aa-24 261 1099 21 12 0 0 169 249 1099 21
aa-25 15 0 1 14 0 1 0 0 0 0
aa-26 95 255 13 21 0 1 33 73 255 12
aa-27 120 322 11 12 0 0 61 108 322 11
aa-28 167 841 27 13 0 0 89 154 841 27
aa-29 277 1048 21 12 0 0 197 265 1048 21
aa-30 39 61 4 9 0 0 12 30 61 4
aa-31 30 0 2 28 0 2 0 0 0 0
aa-32 151 733 30 25 0 0 61 126 733 30
aa-33 194 481 4 12 0 0 143 182 481 4
aa-34 134 440 13 12 0 0 85 122 440 13
aa-35 82 264 10 6 0 0 38 76 264 10
aa-36 112 309 7 9 0 0 68 103 309 7
aa-37 74 120 5 24 0 1 22 49 120 4
aa-38 171 852 26 10 0 0 94 161 852 26
aa-39 145 689 23 4 0 0 82 141 689 23
aa-40 140 604 22 20 0 0 60 120 604 22
aa-41 300 1585 40 39 0 0 172 261 1585 40
aa-42 237 1100 30 11 0 0 137 226 1100 30
aa-43 64 303 18 6 0 0 18 58 303 18
aa-44 60 157 10 7 0 0 23 53 157 10
aa-45 83 381 20 8 0 0 32 75 381 20
aa-46 163 514 13 17 0 0 89 146 514 13
aa-47 65 195 14 17 0 1 13 47 195 13
aa-48 90 330 17 14 0 0 35 76 330 17
aa-49 27 0 5 22 0 5 0 0 0 0
aa-50 113 463 18 5 0 0 48 108 463 18
aa-51 79 268 11 8 0 0 27 71 268 11
aa-52 68 183 14 20 0 2 14 46 183 12
aa-53 89 224 12 9 0 0 37 80 224 12
aa-54 90 222 12 13 0 0 31 77 222 12
j-10 57 97 3 20 0 0 13 37 97 3
j-11 51 198 5 14 0 0 8 37 198 5
j-13 78 153 6 22 0 2 28 54 153 4
j-14 72 55 4 52 0 1 3 19 55 3
j-15 45 0 1 44 0 1 0 0 0 0
j-16 14 0 0 14 0 0 0 0 0 0
j-17 81 304 10 20 0 0 20 61 304 10
j-18 73 284 9 15 0 0 11 58 284 9
j-19 101 116 3 63 0 0 20 38 116 3
j-20 241 0 1 240 0 1 0 0 0 0
j-21 33 16 9 18 0 7 1 8 16 2
j-22 76 384 9 9 0 0 23 67 384 9
j-23 76 345 19 25 0 0 1 51 345 19
j-24 150 265 4 83 0 1 20 66 265 3
j-25 14 0 0 14 0 0 0 0 0 0
j-26 66 126 6 29 0 0 10 37 126 6
j-28 96 552 13 22 0 0 17 74 552 13
Table 7: Results of preprocessing the WH datasets. Each instance initially has vertices and edges, and a min OCT size of . Preprocessing partitions , where are removed, () must (must not) be in the OCT set for some fixed, optimal OCT, and are remaining unlabeled vertices. Likewise, edges are partitioned into , where are removed edges and are remaining edges. The reduced graph has vertices, edges, and a min OCT size of .
Original Graph Results Reduced Graph
Dataset
b-50-1 50 108 11 0 0 0 5 50 108 11
b-50-2 50 118 11 3 0 0 4 47 118 11
b-50-3 50 132 14 0 0 0 3 50 132 14
b-50-4 50 108 11 4 0 0 8 46 108 11
b-50-5 50 131 13 0 0 0 3 50 131 13
b-50-6 50 97 9 7 0 0 5 43 97 9
b-50-7 50 116 10 1 0 1 4 48 116 9
b-50-8 50 137 14 0 0 0 4 50 137 14
b-50-9 50 118 12 4 0 0 2 46 118 12
b-50-10 50 106 11 2 0 0 6 48 106 11
b-100-1 100 464 41 0 0 0 0 100 464 41
b-100-2 100 482 42 0 0 0 0 100 482 42
b-100-3 100 490 42 0 0 0 1 100 490 42
b-100-4 100 475 41 0 0 0 0 100 475 41
b-100-5 100 459 42 0 0 0 0 100 459 42
b-100-6 100 510 43 0 0 0 0 100 510 43
b-100-7 100 469 42 0 0 0 0 100 469 42
b-100-8 100 492 43 0 0 0 0 100 492 43
b-100-9 100 502 44 0 0 0 1 100 502 44
b-100-10 100 485 44 0 0 0 0 100 485 44
gka-1 50 90 11 4 0 2 9 44 90 9
gka-2 60 149 17 1 0 1 1 58 149 16
gka-3 70 223 23 0 0 0 4 70 223 23
gka-4 80 304 28 0 0 0 0 80 304 28
gka-10 30 60 26 0 0 18 0 12 60 8
gka-11 40 84 36 0 0 26 0 14 84 10
gka-12 50 264 46 0 0 26 0 24 264 20
gka-13 60 180 56 0 0 40 0 20 180 16
gka-14 70 312 66 0 0 44 0 26 312 22
gka-15 80 0 76 4 0 76 0 0 0 0
gka-16 90 0 86 4 0 86 0 0 0 0
gka-17 100 0 96 4 0 96 0 0 0 0
gka-18 125 16 120 0 0 118 1 7 16 2
gka-19 40 588 32 0 0 1 0 39 588 31
gka-20 50 763 39 0 0 0 0 50 763 39
gka-21 60 701 40 0 0 0 0 60 701 40
gka-22 70 720 43 0 0 0 0 70 720 43
gka-23 80 641 46 0 0 0 0 80 641 46
gka-24 90 400 37 0 0 0 0 90 400 37
gka-25 100 495 42 0 0 0 1 100 495 42
gka-26 100 494 43 0 0 0 0 100 494 43
gka-27 100 1016 62 0 0 0 0 100 1016 62
gka-28 100 1425 70 0 0 0 0 100 1425 70
gka-29 100 2000 77 0 0 0 0 100 2000 77
gka-30 100 2414 82 0 0 0 0 100 2414 82
gka-31 100 2948 85 0 0 0 0 100 2948 85
gka-32 100 3434 88 0 0 0 0 100 3434 88
gka-33 100 3907 90 0 0 0 0 100 3907 90
gka-34 100 4346 92 0 0 0 0 100 4346 92
gka-35 100 0 96 4 0 96 0 0 0 0
Table 8: Results of preprocessing the Beasley and GKA datasets. Each instance initially has vertices and edges, and a min OCT size of . Preprocessing partitions , where are removed, () must (must not) be in the OCT set for some fixed, optimal OCT, and are remaining unlabeled vertices. Likewise, edges are partitioned into , where are removed edges and are remaining edges. The reduced graph has vertices, edges, and a min OCT size of .
OCT Size
Dataset Mean S.D. Min 25% 50% 75% Max
Timeout: 0.01 (s)
aa-43 0 21.4 3.0 18 19 21 23 29
1 18.9 0.7 18 18 19 19 20
2 19.5 0.6 18 19 20 20 20
aa-45 0 29.6 4.2 22 27 30 32 41
1 21.8 0.9 20 21 22 22 24
2 22.7 0.7 21 22 23 23 24
gka-1 0 9.0 0.0 9 9 9 9 9
1 9.0 0.0 9 9 9 9 9
2 9.0 0.0 9 9 9 9 9
Timeout: 0.1 (s)
aa-29 0 35.9 16.2 21 23 32 39 97
1 22.2 1.3 21 21 22 23 26
2 23.9 1.7 21 23 24 25 28
Timeout: 1 (s)
aa-42 0 51.8 13.4 33 42 49 59 85
1 31.0 1.2 30 30 31 32 35
2 31.9 0.3 31 32 32 32 32
gka-2 0 16.8 0.9 16 16 17 17 19
1 16.0 0.0 16 16 16 16 16
2 16.0 0.0 16 16 16 16 16
Timeout: 10 (s)
aa-32 0 31.6 2.4 30 30 30 32 38
1 30.8 0.9 30 30 31 31 33
2 30.8 0.4 30 31 31 31 31
aa-41 0 67.0 14.4 48 55 64 75 110
1 41.4 1.2 40 40 41 42 44
2 41.2 0.7 40 41 41 41 43
gka-24 0 47.1 1.6 44 46 47 48 50
1 37.9 0.3 37 38 38 38 38
2 37.9 0.3 37 38 38 38 38
gka-25 0 56.2 2.6 49 55 56 58 62
1 44.0 0.0 44 44 44 44 44
2 44.0 0.0 44 44 44 44 44
gka-26 0 57.0 2.3 52 55 57 58 62
1 43.8 0.4 43 44 44 44 44
2 43.8 0.4 43 44 44 44 44
gka-27 0 72.3 1.7 68 71 72 74 75
1 63.0 0.1 62 63 63 63 63
2 63.0 0.0 63 63 63 63 63
gka-28 0 78.0 1.2 75 77 78 79 80
1 72.0 0.2 71 72 72 72 73
2 72.0 0.2 72 72 72 72 73
gka-29 0 82.4 0.8 81 82 82 83 84
1 77.0 0.0 77 77 77 77 77
2 77.0 0.0 77 77 77 77 77
gka-3 0 25.2 1.6 23 24 25 26 29
1 23.3 0.5 23 23 23 24 24
2 23.4 0.5 23 23 23 24 24
Table 9: Heuristic solution sizes for select datasets at the three levels of preprocessing () for Improved Hüffner. The timeout level on each dataset was taken to be the maximum time in less than the time Hüffner at took to find an exact solution. Mean, standard deviation, and quintiles are computed over 50 samples per timeout, dataset, and preprocessing level.
Graph Solver Graph Solver
Dataset A-I ILP Dataset A-I ILP
aa-10 6 0.2 1.0 0.0 j-25 0 0.1 1.0 0.0
aa-11 11 0.1 1.0 0.1 j-26 6 0.1 1.0 0.0
aa-13 12 0.1 1.0 0.1 j-28 13 0.1 1.0 0.0
aa-14 19 0.2 4.7 0.1 b-50-1 11 0.1 1.0 0.1
aa-15 6 0.1 1.0 0.0 b-50-2 11 0.1 1.0 0.0
aa-16 0 0.1 1.0 0.0 b-50-3 14 0.2 1.2 0.0
aa-17 25 0.4 6.4 0.1 b-50-4 11 0.1 1.0 0.0
aa-18 14 0.1 1.0 0.0 b-50-5 13 0.2 1.1 0.1
aa-19 19 0.2 2.7 0.2 b-50-6 9 0.1 1.0 0.0
aa-20 19 0.3 1.1 0.1 b-50-7 9 0.1 1.0 0.0
aa-21 0 0.1 1.0 0.0 b-50-8 14 0.2 1.4 0.1
aa-22 16 0.2 1.0 0.1 b-50-9 12 0.2 1.1 0.1
aa-23 18 0.2 1.0 0.1 b-50-10 11 0.1 1.0 0.1
aa-24 21 0.3 1.4 0.1 b-100-1 41 97.8 - 21.3
aa-25 0 0.1 1.0 0.0 b-100-2 42 185.5 - 52.7
aa-26 12 0.1 1.0 0.0 b-100-3 42 242.3 - 20.9
aa-27 11 0.2 1.0 0.1 b-100-4 41 199.8 - 33.1
aa-28 27 0.2 1.1 0.1 b-100-5 42 208.6 - 41.7
aa-29 21 0.3 1.1 0.1 b-100-6 43 143.6 - 99.6
aa-30 4 0.1 1.0 0.0 b-100-7 42 182.0 - 40.4
aa-31 0 0.1 1.0 0.0 b-100-8 43 356.7 - 39.3
aa-32 30 0.6 10.2 0.5 b-100-9 44 321.4 - 72.9
aa-33 4 0.1 1.0 0.0 b-100-10 44 188.6 - 118.3
aa-34 13 0.2 1.0 0.1 gka-1 9 0.1 1.0 0.1
aa-35 10 0.1 1.0 0.0 gka-2 16 0.4 2.2 0.1
aa-36 7 0.1 1.0 0.0 gka-3 23 1.4 58.0 0.9
aa-37 4 0.1 1.0 0.0 gka-4 28 4.4 - 2.3
aa-38 26 0.3 1.5 0.1 gka-5 22 0.7 3.4 0.1
aa-39 23 0.3 2.7 0.1 gka-6 16 0.1 1.0 0.1
aa-40 22 0.3 1.5 0.1 gka-7 18 0.1 1.0 0.0
aa-41 40 0.8 48.0 0.4 gka-8 28 7.2 - 4.8
aa-42 30 0.4 2.1 0.3 gka-9 2 0.1 1.0 0.0
aa-43 18 0.1 1.0 0.1 gka-10 8 0.1 1.0 0.0
aa-44 10 0.1 1.0 0.0 gka-11 10 0.1 1.0 0.0
aa-45 20 0.2 1.1 0.1 gka-12 20 0.1 1.0 0.0
aa-46 13 0.2 1.0 0.1 gka-13 16 0.1 1.0 0.0
aa-47 13 0.1 1.0 0.0 gka-14 22 0.1 1.0 0.0
aa-48 17 0.1 1.0 0.1 gka-15 0 0.1 1.0 0.0
aa-49 0 0.1 1.0 0.0 gka-16 0 0.1 1.0 0.0
aa-50 18 0.2 1.0 0.1 gka-17 0 0.1 1.0 0.0
aa-51 11 0.1 1.0 0.0 gka-18 2 0.1 1.0 0.0
aa-52 12 0.1 1.0 0.1 gka-19 31 0.2 1.0 0.1
aa-53 12 0.1 1.0 0.1 gka-20 39 0.6 1.2 0.1
aa-54 12 0.2 1.0 0.1 gka-21 40 1.7 22.2 0.3
j-10 3 0.1 1.0 0.0 gka-22 43 5.4 - 1.0
j-11 5 0.1 1.0 0.0 gka-23 46 42.6 - 16.9
j-13 4 0.1 1.0 0.0 gka-24 37 74.3 - 17.3
j-14 3 0.1 1.0 0.0 gka-25 42 122.9 - 28.6
j-15 0 0.1 1.0 0.0 gka-26 43 160.5 - 18.4
j-16 0 0.1 1.0 0.0 gka-27 62 535.3 - 192.6
j-17 10 0.1 1.0 0.0 gka-28 70 284.9 - 366.0
j-18 9 0.1 1.0 0.0 gka-29 77 64.3 - 42.5
j-19 3 0.1 1.0 0.0 gka-30 82 32.7 - 53.2
j-20 0 0.1 1.0 0.0 gka-31 85 11.7 107.6 17.4
j-21 2 0.1 1.0 0.0 gka-32 88 5.3 17.9 19.2
j-22 9 0.1 1.0 0.0 gka-33 90 4.0 3.1 2.2
j-23 19 0.1 1.1 0.1 gka-34 92 2.5 1.2 1.4
j-24 3 0.1 1.0 0.0 gka-35 0 0.1 1.0 0.0
Table 10: Run times for solvers Akiba-Iwata (A-I), improved Hüffner ( for preprocessing with heuristics, and for preprocessing with heuristics and density sort), and (ILP). Times are not reported for configurations that required more than 10 minutes.
Timeout: 0.01(s) 0.1(s) 1(s) 10(s)
Dataset HE ILP HE ILP HE ILP HE ILP
Wernicke-Hüffner Afro-American Graphs
aa-10 6 7

6

8 6

6

6

6

6

6

6

6

6

aa-11 11 12

11

15 12

11

13 11

11

11

11

11

11

aa-13 12 15

12

22 15

12

12 14

12

12

13

12

12

aa-14 19 21 19 35 19 19 27 19 19

19

19

19

19

aa-15 6 8

6

12 6

6

6

6

6

6

6

6

6

aa-16 0 0

0

0

0

0

0

0

0

0

0

0

0

aa-17 25 28 28 41 28 27 34 26 27

25

26

25

25

aa-18 14 18

14

21 17

14

14 14

14

14

14

14

14

aa-19 19 22 22 38 21 21 20 21 19

19

21

19

19

aa-20 19 23 24 129 22 20 25 22 20

19

22 20

19

aa-21 0 0

0

0

0

0

0

0

0

0

0

0

0

aa-22 16 17 17 37 17 16 16 17

16

16

17

16

16

aa-23 18 21 21 35 21

18

19 19

18

18

19

18

18

aa-24 21 25 27 150 25 24 46 24

21

21

24

21

21

aa-25 0 0

0

0

0

0

0

0

0

0

0

0

0

aa-26 12 13

12

14 12

12

12

12

12

12

12

12

12

aa-27 11 14

11

13 14

11

11 13

11

11

12

11

11

aa-28 27 33 32 106 31 29 32 30

27

27

30 28

27

aa-29 21 26 26 169 22 24 23 22

21

21

22

21

21

aa-30 4 4

4

4

4

4

4

4

4

4

4

4

4

aa-31 0 0

0

0

0

0

0

0

0

0

0

0

0

aa-32 30 39 35 47 32 35 37 32 33

30

32 31

30

aa-33 4 4

4

31 4

4

4

4

4

4

4

4

4

aa-34 13 16

13

27 13

13

13 13

13

13

13

13

13

aa-35 10 10

10

10

10

10

10

10

10

10

10

10

10

aa-36 7 7

7

18 7

7

7

7

7

7

7

7

7

aa-37 4 5

4

7 4

4

4

4

4

4

4

4

4

aa-38 26 33 31 102 31 27 35 31

26

26

31

26

26

aa-39 23 28 27 40 26 26 26 24 25

23

24

23

23

aa-40 22 25 28 33 22 23 28 22

22

22

22

22

22

aa-41 40 50 46 172 48 45 60 46 45

40

46 41

40

aa-42 30 36 35 160 36 33 43 34 32

30

34

30

30

aa-43 18 19 19 20 19 19 18 19 19

18

19 19

18

aa-44 10 10

10

15 10

10

12 10

10

10

10

10

10

aa-45 20 22 22

20

21 22 20 21

20

20

21

20

20

aa-46 13 18 13 37 16

13

13

14

13

13

14

13

13

aa-47 13 14

13

15 14

13

13 13

13

13

13

13

13

aa-48 17 19 18 21 17 17 17 17

17

17

17

17

17

aa-49 0 0

0

0

0

0

0

0

0

0

0

0

0

aa-50 18 21 19 27 21 18 19 20

18

18

19

18

18

aa-51 11 13

11

16 11

11

11

11

11

11

11

11

11

aa-52 12 13

12

15 12

12

12 12

12

12

12

12

12

aa-53 12 15 12 18 14

12

13 14

12

12

13

12

12

aa-54 12 14 12 21 14

12

14 13

12

12

12

12

12

Wernicke-Hüffner Japanese Graphs
j-10 3 3

3

3

3

3

3

3

3

3

3

3

3

j-11 5 5

5

5

5

5

5

5

5

5

5

5

5

j-13 4 4

4

4

4

4

4

4

4

4

4

4

4

j-14 3 3

3

3

3

3

3

3

3

3

3

3

3

j-15 0 0

0

0

0

0

0

0

0

0

0

0

0

j-16 0 0

0

0

0

0

0

0

0

0

0

0

0

j-17 10 10

10

16 10

10

10

10

10

10

10

10

10

j-18 9 10 10 12 10 10

9

9

9

9

9

9

9

j-19 3 3

3

3

3

3

3

3

3

3

3

3

3

j-20 0 0

0

0

0

0

0

0

0

0

0

0

0

j-21 2 2

2

2

2

2

2

2

2

2

2

2

2

j-22 9 9

9

9

9

9

9

9

9

9

9

9

9

j-23 19 19 19

19

19 19 19 19

19

19

19

19

19

j-24 3 3

3

3

3

3

3

3

3

3

3

3

3

j-25 0 0

0

0

0

0

0

0

0

0

0

0

0

j-26 6 6

6

7 6

6

6

6

6

6

6

6

6

j-28 13 13 16 16 13 13

13

13

13

13

13

13

13

Table 11: Heuristic solution sizes after 0.01, 0.1, 1, and 10 seconds for the Heuristic Ensemble (HE), Improved Hüffner ( for preprocessing with heuristics, and for preprocessing with heuristics and density sort), and (ILP) when run on Wernicke-Hüffner datasets. Highlighting indicates instances where the solver found an exact solution before the provided time limit.
Timeout: 0.01(s) 0.1(s) 1(s) 10(s)
Dataset HE ILP HE ILP HE ILP HE ILP
Beasley 50-Vertex Graphs
b-50-1 11 12 11 15 11 11 12 11

11

11

11

11

11

b-50-2 11 12 11 13 12

11

11

11

11

11

11

11

11

b-50-3 14 15 15 16 14 14 14 14

14

14

14

14

14

b-50-4 11 12 12 14 11

11

11 11

11

11

11

11

11

b-50-5 13 13 13 16 13 13 15 13

13

13

13

13

13

b-50-6 9 9

9

14 9

9

9 9

9

9

9

9

9

b-50-7 9 10

9

12 9

9

9

9

9

9

9

9

9

b-50-8 14 15 15 20 15 15 17 15

14

14

14

14

14

b-50-9 12 13 12 16 13 12 12 13

12

12

12

12

12

b-50-10 11 12 11 13 12

11

11 11

11

11

11

11

11

Beasley 100-Vertex Graphs
b-100-1 41 43 44 46 43 44 46 43 43 43 43 43 42
b-100-2 42 44 44 47 43 44 47 43 43 43 43 43 42
b-100-3 42 46 45 49 45 45 49 44 44 46 44 44 42
b-100-4 41 43 45 45 42 42 45 42 42 42 42 42 42
b-100-5 42 45 44 47 44 44 47 43 43 45 42 43 43
b-100-6 43 45 46 48 45 45 48 45 45 45 45 45 44
b-100-7 42 45 45 47 44 44 47 44 44 43 44 44 42
b-100-8 43 47 46 48 45 45 48 45 45 47 45 45 43
b-100-9 44 46 47 49 45 45 49 45 45 46 45 45 44
b-100-10 44 46 48 50 45 46 50 45 45 46 45 45 45
GKA Graphs
gka-1 9 9

9

12 9

9

9

9

9

9

9

9

9

gka-2 16 16 16 19 16 16 17 16 16

16

16

16

16

gka-3 23 24 24 24 24 24 24 24 23

23

23 23

23

gka-4 28 31 31 33 31 30 33 30 30 28 30 30

28

gka-5 22 22 22 23 22 22 23 22 22

22

22

22

22

gka-6 16 16 16

16

16

16

16

16

16

16

16

16

16

gka-7 18 18

18

18

18

18

18

18

18

18

18

18

18

gka-8 28 34 33 33 33 33 33 31 32 28 31 32

28

gka-9 2 2

2

2

2

2

2

2

2

2

2

2

2

gka-10 8 8

8

8

8

8

8

8

8

8

8

8

8

gka-11 10 10

10

10

10

10

10

10

10

10

10

10

10

gka-12 20 20

20

20

20

20

20

20

20

20

20

20

20

gka-13 16 16

16

16

16

16

16

16

16

16

16

16

16

gka-14 22 22

22

22

22

22

22

22

22

22

22

22

22

gka-15 0 0

0

0

0

0

0

0

0

0

0

0

0

gka-16 0 0

0

0

0

0

0

0

0

0

0

0

0

gka-17 0 0

0

0

0

0

0

0

0

0

0

0

0

gka-18 2 2

2

2

2

2

2

2

2

2

2

2

2

gka-19 31 31 31 32 31

31

31

31

31

31

31

31

31

gka-20 39 39 39 40 39 39 39 39

39

39

39

39

39

gka-21 40 41 42 41 41 42 41 41 41

40

40 41

40

gka-22 43 46 46 49 44 46 46 44 46 43 43 45

43

gka-23 46 48 48 52 48 48 51 47 47 47 46 46 46
gka-24 37 39 38 44 38 38 43 38 38 39 37 38 37
gka-25 42 45 46 47 44 44 47 44 44 45 44 44 43
gka-26 43 44 44 50 44 44 50 44 44 43 44 44 43
gka-27 62 65 64 75 64 63 65 63 63 63 63 63 63
gka-28 70 73 73 94 72 72 74 72 72 71 72 72 71
gka-29 77 77 77 95 77 77 80 77 77 79 77 77 78
gka-30 82 83 84 96 83 83 85 83 83 83 83 83 82
gka-31 85 86 87 95 86 87 88 86 86 87 86 86 85
gka-32 88 89 89 97 89 89 90 89 89 89 88 88 88
gka-33 90 91 91 98 91 90 98 90 90 90 90

90

90

gka-34 92 93 93 98 93 92 98 93

92

92 92

92

92

gka-35 0 0

0

0

0

0

0

0

0

0

0

0

0

Table 12: Heuristic solution sizes after 0.01, 0.1, 1, and 10 seconds for the Heuristic Ensemble (HE), Improved Hüffner ( for preprocessing with heuristics, and for preprocessing with heuristics and density sort), and (ILP) when run on GKA and Beasley datasets. Highlighting indicates instances where the solver found an exact solution before the provided time limit.

Footnotes

  1. denotes for some constant
  2. https://github.com/wata-orz/vertex_cover

References