ILP-based Local Search for Graph Partitioning

ILP-based Local Search for Graph Partitioning

Alexandra Henzinger Stanford University, Stanford, CA, USA
ahenz@stanford.edu
Alexander Noe University of Vienna, Vienna, Austria
alexander.noe@univie.ac.at
Christian Schulz University of Vienna, Vienna, Austria
christian.schulz@univie.ac.at
today
Abstract

Computing high-quality graph partitions is a challenging problem with numerous applications. In this paper, we present a novel meta-heuristic for the balanced graph partitioning problem. Our approach is based on integer linear programs that solve the partitioning problem to optimality. However, since those programs typically do not scale to large inputs, we adapt them to heuristically improve a given partition. We do so by defining a much smaller model that allows us to use symmetry breaking and other techniques that make the approach scalable. For example, in Walshaw’s well-known benchmark tables we are able to improve roughly half of all entries when the number of blocks is high.

Graph Partitioning, Integer Linear Programming
\Copyright

Alexandra Henzinger, Alexander Noe, Christian Schulz\subjclassG.2.2 Graph Theory

1 Introduction

Balanced graph partitioning is an important problem in computer science and engineering with an abundant amount of application domains, such as VLSI circuit design, data mining and distributed systems [37]. It is well known that this problem is NP-complete [8] and that no approximation algorithm with a constant ratio factor exists for general graphs unless P=NP [8]. Still, there is a large amount of literature on methods (with worst-case exponential time) that solve the graph partitioning problem to optimality. This includes methods dedicated to the bipartitioning case [3, 4, 12, 13, 14, 15, 23, 21, 29, 38] and some methods that solve the general graph partitioning problem [16, 39]. Most of these methods rely on the branch-and-bound framework [27]. However, these methods can typically solve only very small problems as their running time grows exponentially, or if they can solve large bipartitioning instances using a moderate amount of time [12, 13], the running time highly depends on the bisection width of the graph. Methods that solve the general graph partitioning problem [16, 39] have huge running times for graphs with up to a few hundred vertices. Thus in practice mostly heuristic algorithms are used.

Typically the graph partitioning problem asks for a partition of a graph into blocks of about equal size such that there are few edges between them. Here, we focus on the case when the bounds on the size are very strict, including the case of perfect balance when the maximal block size has to equal the average block size.

Our focus in this paper is on solution quality, i.e. minimize the number of edges that run between blocks. During the past two decades there have been numerous researchers trying to improve the best graph partitions in Walshaw’s well-known partitioning benchmark [40, 41]. Overall there have been more than forty different approaches that participated in this benchmark. Indeed, high solution quality is of major importance in applications such as VLSI Design [1, 2] where even minor improvements in the objective can have a large impact on the production costs and quality of a chip. High-quality solutions are also favorable in applications where the graph needs to be partitioned only once and then the partition is used over and over again, implying that the running time of the graph partitioning algorithms is of a minor concern [11, 18, 26, 28, 31, 30]. Thirdly, high-quality solutions are even important in areas in which the running time overhead is paramount [40], such as finite element computations [36] or the direct solution of sparse linear systems [20]. Here, high-quality graph partitions can be useful for benchmarking purposes, i.e. measuring how much more running time can be saved by higher quality solutions.

In order to compute high-quality solutions, state-of-the-art local search algorithms exchange vertices between blocks of the partition trying to decrease the cut size while also maintaining balance. This highly restricts the set of possible improvements. Recently, we introduced new techniques that relax the balance constraint for vertex movements but globally maintain balance by combining multiple local searches [35]. This was done by reducing this combination problem to finding negative cycles in a graph. In this paper, we extend the neighborhood of the combination problem by employing integer linear programming. This enables us to find even more complex combinations and hence to further improve solutions. More precisely, our approach is based on integer linear programs that solve the partitioning problem to optimality. However, out of the box those programs typically do not scale to large inputs, in particular because the graph partitioning problem has a very large amount of symmetry – given a partition of the graph, each permutation of the block IDs gives a solution having the same objective and balance. Hence, we adapt the integer linear program to improve a given input partition. We do so by defining a much smaller graph, called model, and solve the graph partitioning problem on the model to optimality by the integer linear program. More specifically, we select vertices close to the cut of the given input partition for potential movement and contract all remaining vertices of a block into a single vertex. A feasible partition of this model corresponds to a partition of the input graph having the same balance and objective. Moreover, this model enables us to use symmetry breaking, which allows us to scale to much larger inputs. To make the approach even faster, we combine it with initial bounds on the objective provided by the input partition, as well as providing the input partition to the integer linear program solver. Overall, we arrive at a system that is able to improve more than half of all entries in Walshaw’s benchmark when the number of blocks is high.

The rest of the paper is organized as follows. We begin in Section 2 by introducing basic concepts. After presenting some related work in Section 3 we outline the integer linear program as well as our novel local search algorithm in Section 4. Here, we start by explaining the very basic idea that allows us to find combinations of simple vertex movements. We then explain our strategies to improve the running time of the solver and strategies to select vertices for movement. A summary of extensive experiments done to evaluate the performance of our algorithms is presented in Section 5. Finally, we conclude in Section 6.

2 Preliminaries

2.1 Basic concepts

Let be an undirected graph. We consider positive, real-valued edge and vertex weight functions resp. and extend them to sets, i.e., and . Let denote the neighbors of . The degree of a vertex is . A vertex is a boundary vertex if it is incident to at least one vertex in a different block. We are looking for disjoint blocks of vertices ,…, that partition ; i.e., . The balancing constraint demands that each block has weight for some imbalance parameter . We call a block  overloaded if its weight exceeds . The objective of the problem is to minimize the total cut subject to the balancing constraints. We define the gain of a vertex as the maximum decrease in the cut value when moving it to a different block.

3 Related Work

There has been a huge amount of research on graph partitioning and we refer the reader to the surveys given in [6, 9, 36, 42] for most of the material. Here, we focus on issues closely related to our main contributions. All general-purpose methods that are able to obtain good partitions for large real-world graphs are based on the multi-level principle. Well-known software packages based on this approach include Jostle [42], KaHIP [33], Metis [24] and Scotch [32].

Chris Walshaw’s well-known benchmark archive has been established in 2001 [40, 41]. Overall it contains 816 instances (34 graphs, 4 values of imbalance, and 6 values of ). Ever since there have been more than forty different approaches that participated in this benchmark. In this benchmark, the running time of the participating algorithms is not measured or reported. Submitted partitions will be validated and added to the archive if they improve on a particular result. This can either be an improvement in the number of cut edges or, if they match the current best cut size, an improvement in the weight of the largest block. Most entries in the benchmark have as of Feb. been obtained by Galinier et al. [19] (more precisely an implementation of that approach by Frank Schneider), Hein and Seitzer [22] and the Karlsruhe High-Quality Graph Partitioning (KaHIP) framework [35]. More precisely, Galinier et al. [19] use a memetic algorithm that is combined with tabu search to compute solutions and Hein and Seitzer [22] solve the graph partitioning problem by providing tight relaxations of a semi-definite program into a continuous problem.

The Karlsruhe High-Quality Graph Partitioning (KaHIP) framework implements many different algorithms, for example flow-based methods and more-localized local searches, as well as several coarse-grained parallel and sequential meta-heuristics. KaBaPE [35] is a coarse-grained parallel evolutionary algorithm, i.e. each processor has its own population (set of partitions) and a copy of the graph. After initially creating the local population, each processor performs multi-level combine and mutation operations on the local population. This is combined with a meta-heuristic that combines local searches that individually violate the balance constraint into a more global feasible improvement. For more details, we refer the reader to [35].

4 Local Search based on Integer Linear Programming

We now explain our algorithm that combines integer linear programming and local search. We start by explaining the integer linear program that can solve the graph partitioning problem to optimality. However, out-of-the-box this program does not scale to large inputs, in particular because the graph partitioning problem has a very large amount of symmetry. Thus, we reduce the size of the graph by first computing a partition using an existing heuristic and based on it collapsing parts of the graph. Roughly speaking, we compute a small graph, called model, in which we only keep a small amount of selected vertices for potential movement and perform graph contractions on the remaining ones. A partition of the model corresponds to a partition of the input network having the same objective and balance. The computed model is then solved to optimality using the integer linear program. As we will see this process enables us to use symmetry breaking in the linear program, which in turn drastically speeds up computation times.

4.1 Integer Linear Program for the Graph Partitioning Problem

We now introduce a generalization of an integer linear program formulation for balanced bipartitioning [7] to the general graph partitioning problem. First, we introduce binary decision variables for all edges and vertices of the graph. More precisely, for each edge , we introduce the variable which is one if is a cut edge and zero otherwise. Moreover, for each and block , we introduce the variable which is one if is in block and zero otherwise. Hence, we have a total of variables. We use the following constraints to ensure that the result is a valid -partition: {ceqn}

(1)
(2)
(3)
(4)

The first two constraints ensure that is set to one if the vertices and are in different blocks. For an edge and a block , the right-hand side in this equation is one if one of the vertices and is in block and the other one is not. If both vertices are in the same block then the right-hand side is zero for all values of . Hence, the variable can either be zero or one in this case. However, since the variable participates in the objective function and the problem is a minimization problem, it will be zero in an optimum solution. The third constraint ensures that the balance constraint is satisfied for each partition. And finally, the last constraint ensures that each vertex is assigned to exactly one block. To sum up, our program has constraints and non-zeros. Since we want to minimize the weight of cut edges, the objective function of our program is written as:

{ceqn}
(5)

4.2 Local Search

The graph partitioning problem has a large amount of symmetry – each permutation of the block IDs gives a solution with equal objective and balance. Hence, the integer linear program described above will scan many branches that contain essentially the same solutions so that the program does not scale to large instances. Moreover, it is not immediately clear how to improve the scalability of the program by using symmetry breaking or other techniques.

Our goal in this section is to develop a local search algorithm using the integer linear program above. Given a partition as input to be improved, our main idea is to contract vertices “that are far away” from the cut of the partition. In other words, we want to keep vertices close to the cut and contract all remaining vertices into one vertex for each block of the input partition. This ensures that a partition of the contracted graph yields a partition of the input graph with the same objective and balance. Hence, we apply the integer linear program to the model and solve the partitioning problem on it to optimality. Note, however, that due to the performed contractions this does not imply an optimal solution on the input graph.

We now outline the details of the algorithm. Our local algorithm has two inputs, a graph  and a partition of its vertices. For now assume that we have a set of vertices which we want to keep in the coarse model, i.e. a set of vertices which we do not want to contract. We outline in Section 4.4 which strategies we have to select the vertices . For the purpose of contraction we define sets . We obtain our coarse model by contracting each of these vertex sets. The contraction of a vertex set works as follows: the set of vertices is contracted into a single vertex . The weight of is set to the sum of the weight of all vertices in the set that is contracted. There is an edge between two vertices and in the contracted graph if there is an edge between a vertex of the set and in the original graph . The weight of an edge is set to the sum of the weight of edges that run between the vertices of the set and . After all contractions have been performed the coarse model contains vertices, and potentially much less edges than the input graph. Figure 1 gives an abstract example of our model.

There are two things that are important to see: first, due to the way we perform contraction, the given partition of the input network yields a partition of our coarse model that has the same objective and balance simply by putting into block and keeping the block of the input for the vertices in . Moreover, if we compute a new partition of our coarse model, we can build a partition in the original graph with the same properties by putting the vertices  into the block of their coarse representative together with the vertices of that are in this block. Hence, we can solve the integer linear program on the coarse model to compute a partition for the input graph. After the solver terminates, i.e. found an optimum solution of our mode or has reached a predefined time limit , we transfer the best solution to the original graph. Note that the latter is possible since an integer linear program solver typically computes intermediate solutions that may not be optimal.

Figure 1: From left to right: a graph that is partitioned into four blocks, the set close to the boundary that will stay in the model, and lastly the model in which the sets have been contracted.

4.3 Optimizations

Independent of the vertices that are selected to be kept in the coarse model, the approach above allows us to define optimizations to solve our integer linear program faster. We apply four strategies: (i) symmetry breaking, (ii) providing a start solution to the solver, (iii) add the objective of the input as a constraint as well as (iv) using the parallel solving facilities of the underlying solver. We outline the first three strategies in greater detail:

Symmetry Breaking.

If the set is small, then the solver will find a solution much faster. Ideally, our algorithms selects the vertices such that . In other words, no two contracted vertices can be clustered in one block. We can use this to break symmetry in our integer linear programming by adding constraints that fix the block of to block , i.e. we set and for . Moreover, for those vertices we can remove the constraint which ensures that the vertex is assigned to a single unique block—since we assigned those vertices to a block using the new additional constraints.

Providing a Start Solution to the Solver.

The integer linear program performs a significant amount of work in branches which correspond to solutions that are worse than the input partitioning. Only very few - if any - solutions are better than the given partition. However, we already know a fairly good partition (the given partition from the input) and give this partition to the solver by setting according initial values for all variables. This ensures that the integer linear program solver can omit many branches and hence speeds up the time needed to solve the integer linear program.

Solution Quality as a Constraint.

Since we are only interested in improved partitions, we can add an additional constraint that disallows solutions which have a worse objective than the input partition. Indeed, the objective function of the linear program is linear, and hence the additional constraint is also linear. Depending on the objective value, this reduces the number of branches that the linear program solver needs to look at. However, note that this comes at the cost of an additional constraint that needs to be evaluated.

4.4 Vertex Selection Strategies

The algorithm above works for different vertex sets that should be kept in the coarse model. There is an obvious trade-off: on the one hand, the set should not be too large, otherwise the coarse model would be large and hence the linear programming solver needs a large amount of time to find a solution. On the other hand, the set should also not be too small, since this restricts the amount of possible vertex movements, and hence the approach is unlikely to find an improved solution. We now explain different strategies to select the vertex set . In any case, while we add vertices to the set , we compute the number of non-zeros in the corresponding ILP. We stop to add vertices when the number of non-zeros in the corresponding ILP is larger than a parameter .

Vertices Close to Input Cut.

The intuition of the first strategy, Boundary, is that changes or improvements of the partition will occur reasonable close to the input partition. In this simple strategy our algorithm tries to use all boundary vertices as the set . In order to adhere to the constraint on the number of non-zeros in the ILP, we add the vertices of the boundary uniformly at random and stop if the number of non-zeros is reached. If the algorithm managed to add all boundary vertices whilst not exceeding the specified number of non-zeros, we do the following extension: we perform a breadth-first search that is initialized with a random permutation of the boundary vertices. All additional vertices that are reached by the BFS are added to . As soon as the number of non-zeros is reached, the algorithm stops.

Start at Promising Vertices.

Especially for high values of the boundary contains many vertices. The Boundary strategy quickly adds a lot of random vertices while ignoring vertices that have high gain. However, note that even in good partitions it is possible that vertices with positive gain exist but cannot be moved due to the balance constraint.

Hence, our second strategy, Gain, tries to fix this issue by starting a breadth-first search initialized with only high gain vertices. More precisely, we initialize the BFS with each vertex having gain where  is a tuning parameter. Our last strategy, TopVertices, starts by sorting the boundary vertices by their gain. We break ties uniformly at random. Vertices are then traversed in decreasing order (highest gain vertices first) and for each start vertex our algorithm adds all vertices with distance to the model. The algorithm stops as soon as the number of non-zeros exceeds .

Early gain-based local search heuristics for the -balanced graph partitioning problem searched for pairwise swaps with positive gain [17, 25]. More recent algorithms generalized this idea to also search for cycles or paths with positive total gain [35]. An important advantage of our new approach is that we solve the combination problem to optimality, i.e. our algorithm finds the best combination of vertex movements of the vertices in w.r.t to the input partition of the original graph. Therefore we can also find more complex optimizations that cannot be reduced to positive gain cycles and paths.

5 Experiments

5.1 Experimental Setup and Methodology

We implemented the algorithms using C++-17 and compiled all codes using g++-7.2.0 with full optimization (-O3). We use Gurobi 7.5.2 as an ILP solver and always use its parallel version. We perform experiments on the Phase 2 Haswell nodes of the SuperMUC supercomputer. The Phase 2 of SuperMUC consists of 3072 nodes, each with two Haswell Xeon E5-2697 v3 processors. Each node has 28 cores at 2.6GHz, as well as 64GB of main memory and runs the SUSE Linux Enterprise Server (SLES) operating system. Unless otherwise mentioned, our approach uses the shared-memory parallel variant of Gurobi using all 28 cores of a single node of the machine. In general, we perform five repetitions per instance and report the average running time as well as cut. Unless otherwise mentioned, we use a time limit for the integer linear program. When the time limit is passed, the integer linear program solver outputs the best solution that has currently been discovered. This solution does not have to be optimal. Note that we do not perform experiments with Metis [24] and Scotch [32] in here, since previous papers, e.g. [33, 34], have already shown that solution quality obtained is much worse than results achieved in the Walshaw benchmark. When averaging over multiple instances, we use the geometric mean in order to give every instance the same influence on the final score.

Performance Plots.

These plots relate the fastest running time to the running time of each other ILP-based local search algorithm on a per-instance basis. For each algorithm, these ratios are sorted in increasing order. The plots show the ratio on the y-axis to highlight the instances in which each algorithm performs badly. For plots in which we measure solution quality, the y-axis shows the ratio cutcut. A point close to zero indicates that the running time/quality of the algorithm was considerably worse than the fastest/best algorithm on the same instance. A value of one therefore indicates that the corresponding algorithm was one of the fastest/best algorithms to compute the solution. Thus an algorithm is considered to outperform another algorithm if its corresponding ratio values are above those of the other algorithm. In order to include instances that hit the time limit, we set the corresponding values below zero for ratio computations.

Instances.

We perform experiments on two sets of instances. Set is used to determine the performance of the integer linear programming optimizations and to tune the algorithm. We obtained these instances from the Florida Sparse Matrix collection [10] and the 10th DIMACS Implementation Challenge [5] to test our algorithm. Set are all graphs from Chris Walshaw’s graph partitioning benchmark archive [40, 41]. This archive is a collection of instances from finite-element applications, VLSI design and is one of the default benchmarking sets for graph partitioning.

Table 1 gives basic properties of the graphs from both benchmark sets. We ran the unoptimized integer linear program that solves the graph partitioning problem to optimality from Section 4.1 on the five smallest instances from the Walshaw benchmark set. With a time limit of minutes, the solver has only been able to compute a solution for two graphs with . For higher values of the solver was unable to find any solution in the time limit. Even applying feasible optimizations does not increase the amount of ILPs solved. Hence, we omit further experiments in which we run an ILP solver on the full graph.

Graph Graph
Walshaw Graphs (Set B) Walshaw Graphs (Set B)
add20 2 395 7 462 wing 62 032 K
data 2 851 15 093 brack2 62 631 K
3elt 4 720 13 722 finan512 74 752 K
uk 4 824 6 837 fe_tooth 78 136 K
add32 4 960 9 462 fe_rotor 99 617 K
bcsstk33 8 738 K 598a 110 971 K
whitaker3 9 800 28 989 fe_ocean 143 437 K
crack 10 240 30 380 144 144 649 M
wing_nodal 10 937 75 488 wave 156 317 M
fe_4elt2 11 143 32 818 m14b 214 765 M
vibrobox 12 328 K auto 448 695 M
bcsstk29 13 992 K
4elt 15 606 45 878 Parameter Tuning (Set A)
fe_sphere 16 386 49 152 delaunay_n15 32 768 98 274
cti 16 840 48 232 rgg_15 32 768 K
memplus 17 758 54 196 2cubes_sphere 101 492 K
cs4 22 499 43 858 cfd2 123 440 M
bcsstk30 28 924 M boneS01 127 224 M
bcsstk31 35 588 K Dubcova3 146 689 M
fe_pwt 36 519 K G2_circuit 150 102 K
bcsstk32 44 609 K thermal2 1 227 087 M
fe_body 45 087 K as365 3 799 275 M
t60k 60 005 89 440 adaptive 6 815 744 M
Table 1: Basic properties of the our benchmark instances.

5.2 Impact of Optimizations

We now evaluate the impact of the optimization strategies for the ILP that we presented in Section 4.3. In this section, we use the variant of our local search algorithm in which is obtained by starting depth-one breadth-first search at the highest gain vertices, and set the limit on the non-zeros in the ILP to . However, we expect the results in terms of speedup to be similar for different vertex selection strategies. To evaluate the ILP performance, we run KaFFPa using the strong preconfiguration on each of the graphs from set using and and then use the computed partition as input to each ILP (with the different optimizations). As the optimizations do not change the objective value achieved in the ILP, we only report running times of our different approaches. We set the time limit of the ILP solver to 30 minutes.

We use five variants of our algorithm: Basic does not contain any optimizations; BasicSym enables symmetry breaking; BasicSymSSol additionally gives the input partitioning to the ILP solver. The two variants BSSSConst= and BSSSConst are the same as BasicSymSSol with additional constraints: BSSSConst= has the additional constraint that the objective has to be smaller or equal to the start solution, BSSSConst has the constraint that the objective value of a solution must be better than the objective value of the start solution. Figure 3 summarises the results.

In our experiments, the basic configuration reaches the time limit in 95 out of the 300 runs. Overall, enabling symmetry breaking drastically speeds up computations. On all of the instances which the Basic configuration could solve within the time limit, each other configuration is faster than the Basic configuration. Symmetry breaking speeds up computations by a factor of 41 in the geometric mean on those instances. The largest obtained speedup on those instances was a factor of 5663 on the graph adaptive for . The configuration solves all but the two instances (boneS01, ) and (Dubcova3, ) within the time limit. Additionally providing the start solution (BasicSymSSol) gives an addition speedup of 22% on average. Over the Basic configuration, the average speedup is 50 with the largest speedup being 6495 and the smallest speedup being 47%. This configuration can solve all instances within the time limit except the instance boneS01 for . Providing the objective function as a constraint (or strictly smaller constraint) does not further reduce the running time of the solver. Instead, the additional constraints even increase the running time. We adhere this to the fact that the solver has to do additional work to evaluate the constraint. We conclude that BasicSymSSol is the fastest configuration of the ILP. Hence, we use this configuration in all the following experiments. Moreover, from Figure 2 we can see that this configuration can solve most of the instance within the time limit if the number of non-zeros in the ILP is below . Hence, we set the parameter to  in the following section.

Figure 2: Left: performance plot for five variants of our algorithm: Basic does not contain any optimizations; BasicSym enables symmetry breaking; BasicSymSSol additionally gives the input partitioning to the ILP solver. The two variants BSSSConst= and BSSSConst are the same as BasicSymSSol with additional constraints: BSSSConst= has the additional constraint that the objective has to be smaller or equal to the start solution, BSSSConst has the constraint that the solution must be better than the start solution. Right: performance of the slowest (Basic) and fastest ILPs (BasicSymSSol) depending on the number of non-zeros in the ILP.

5.3 Vertex Selection Rules

We now evaluate the vertex selection strategies to find the set of vertices that model the ILP. We look at all strategies described in Section 4.4, i.e. Boundary, Gain with the parameter as well as TopVertices for . To evaluate the different selection strategies, we use the best of five runs of KaFFPa strong on each of the graphs from set using and and then use the computed partition as input to the ILP (with different sets ). Table 2 summarizes the results of the experiment, i.e. the number of cases in which our algorithm was able to improve the result, the average running time in seconds for these selection strategies as well as the number of cases in which the strategy computed the best result (the partition having the lowest cut). We set the time limit to days to be able to finish almost all runs without running into timeout. For the average running time we exclude all graphs in which at least one algorithm did not finish in days (rgg_15 , delaunay_n15 , G2_circuit ). If multiple runs share the best result, they are all counted. However, when no algorithm improves the input partition on a graph, we do not count them.

Gain TopVertices Boundary
Relative Number of Improvements
2 70% 70% 70% 50% 70% 70% 70%
4 50% 60% 80% 70% 70% 70% 80%
8 50% 60% 78% 60% 60% 60% 48%
16 30% 50% 70% 40% 30% 30% 40%
32 60% 60% 46% 50% 50% 20% 20%
64 70% 70% 50% 30% 20% 20% 0%
Average Running Time
2 189.943s 292.573s 357.145s 34.045s 61.152s 92.452s 684.198s
4 996.934s 628.950s 428.353s 87.357s 255.223s 558.578s 1467.595s
8 552.183s 244.470s 244.046s 105.737s 167.164s 340.900s 96.763s
16 118.532s 52.547s 90.363s 53.385s 141.814s 243.957s 34.790s
32 40.300s 24.607s 94.146s 27.156s 80.252s 116.023s 7.596s
64 15.866s 21.908s 24.253s 14.627s 30.558s 44.813s 4.187s
Relative Number Best Algorithm
2 20% 60% 50% 10% 10% 0% 60%
4 10% 0% 50% 10% 0% 0% 30%
8 0% 20% 30% 10% 10% 10% 26%
16 0% 10% 54% 10% 0% 10% 20%
32 0% 8% 38% 0% 0% 0% 4%
64 0% 16% 36% 0% 0% 0% 0%
Table 2: From top to bottom: Number of improvements found by different vertex selection rules relative to the total number of instances, average running time of the strategy on the subset of instances (graph, ) in which all strategies finished within the time limit, and the relative number of instances in which the strategy computed the lowest cut. Best values are highlighted in bold.

Figure 3: Left: performance plot for all vertex selection strategies Right: cut value of vertex selection strategies in comparison to the best result given by any strategy.

Looking at the number of improvements, the Boundary strategy is able to improve the input for small values of , but with increasing number of blocks improvements decrease to no improvement in all runs with . Because of the limit on the number of non-zeros, the ILP contains only random boundary vertices for large values of in this case. Hence, there are not sufficiently many high gain vertices in the model and fewer improvements for large values of are expected. For small values of , the Boundary strategy can improve as many as the Gain strategy but the average running times are higher.

For , the strategy Gain has the highest number of improvements, for it is surpassed by the strategy Gain. However, the strategy Gain finds the best cuts in most cases among all tested strategies. Due to the way these strategies are designed, they are able to put a lot of high gain vertices into the model as well as vertices that can be used to balance vertex movements. The TopVertices strategies are overall also able to find a large number of improvements. However, the found improvements are typically smaller than the Gain strategies. This is due to the fact that the TopVertices strategies grow BFS balls with a predefined depth around high gain vertices first, and later on are not able to include vertices that could be used to balance their movement. Hence, there are less potential vertex movements that could yield an improvement.

For almost all strategies, we can see that the average running time decreases as the number of blocks increases. This happens because we limit the number of non-zeros in our ILP. As the number of non-zeros grows linear with the underlying model size, the models are far smaller for higher values of . Using symmetry breaking, we already fixed the block of the vertices which represent the vertices not part of . Thus the ILP solver can quickly prune branches which would place vertices connected heavily to one of these vertices in a different block. Additionally, our data indicate that a large number of small areas in our model results faster in solve times than when the model contains few large areas. The performance plot in Figure 3 shows that the strategies Boundary, TopVertices and Gain have lower running times than other strategies. These strategies all select a large number of vertices to initialize the breadth-first search. Therefore they output a vertex set that is the union of many small areas around these vertices. Variants that initialize the breadth-first search with fewer vertices have fewer areas, however each of the areas is larger.

5.4 Walshaw Benchmark

In this section, we present the results when running our best configuration on all graphs from Walshaw’s benchmark archive. Note that the rules of the benchmark imply that running time is not an issue, but algorithms should achieve the smallest possible cut value while satisfying the balance constraint. We run our algorithm in the following setting: We take existing partitions from the archive and use those as input to our algorithm. As indicated by the experiments in Section 5.3, the vertex selection strategies Gain perform best for different values of . Thus we use the variant Gain for and both Gain and Gain otherwise in this section. We repeat the experiment once for each

/
2
4
8
16
32
64
sum
Table 3: Relative number of improved instances in the Walshaw Benchmark starting from current entries reported in the Walshaw benchmark.

instance (graph, ) and run our algorithm for and . For larger values of , we strengthen our strategy and use as a bound for the number of non-zeros. Table 3 summarizes the results and Table 7 in the Appendix gives detailed per-instance results.

When running our algorithm using the currently best partitions provided in the benchmark, we are able to improve 38% of the currently reported perfectly balanced results. We are able to improve a larger amount of results for larger values of , more specifically, out of the partitions with , we can improve of all perfectly balanced partitions. This is due to the fact that the graph partitioning problem becomes more difficult for larger values of . There is a wide range of improvements with the smallest improvement being for graph auto with and and with the largest improvement that we found being for fe_body for and . The largest absolute improvement we found is  for bcsstk32 with and . In general, the total number of improvements becomes less if more imbalance is allowed. This is also expected since traditional local search methods have a larger amount of freedom to move vertices. However, the number of improvements still shows that the method is also able to improve a large number of partitions for large values of even if more imbalance is allowed.

6 Conclusions and Future Work

We presented a novel meta-heuristic for the balanced graph partitioning problem. Our approach is based on an integer linear program that solves a model to combine unconstraint vertex movements into a global feasible improvement. Through a given input partition, we were able to use symmetry breaking and other techniques that make the approach scale to large inputs. In Walshaw’s well known benchmark tables, we were able to improve a large amount of partitions given in the benchmark.

In the future, we plan to further improve our implementation and integrate it into the KaHIP framework. We would like to look at other objective functions as long as they can be modelled linearly. Moreover, we want to investigate weather this kind of contractions can be useful for other ILPs. It may be interesting to find cores for contraction by using the information provided an evolutionary algorithm like KaFFPaE [34], i.e. if many of the individuals of the population of the evolutionary algorithm agree that two vertices should be put together in a block then those should be contracted in our model. Lastly, besides using other exact techniques like branch-and-bound to solve our combination model, it may also be worthwhile to use a heuristic algorithm instead.

Acknowledgements

The research leading to these results has received funding from the European Research Council under the European Community’s Seventh Framework Programme (FP7/2007-2013) /ERC grant agreement No. 340506. Moverover, the authors gratefully acknowledge the Gauss Centre for Supercomputing e.V. (www.gauss-centre.eu) for funding this project by providing computing time on the GCS Supercomputer SuperMUC at Leibniz Supercomputing Centre (www.lrz.de).

References

  • [1] C. J. Alpert and A. B. Kahng. Recent Directions in Netlist Partitioning: A Survey. Integration, the VLSI Journal, 19(1-2):1–81, 1995.
  • [2] C. J. Alpert, A. B. Kahng, and S. Z. Yao. Spectral Partitioning with Multiple Eigenvectors. Discrete Applied Mathematics, 90(1):3–26, 1999.
  • [3] M. Armbruster. Branch-and-Cut for a Semidefinite Relaxation of Large-Scale Minimum Bisection Problems. PhD thesis, 2007.
  • [4] M. Armbruster, M. Fügenschuh, C. Helmberg, and A. Martin. A Comparative Study of Linear and Semidefinite Branch-and-Cut Methods for Solving the Minimum Graph Bisection Problem. In Proc. of the 13th International Conference on Integer Programming and Combinatorial Optimization, volume 5035 of LNCS, pages 112–124. Springer, 2008.
  • [5] D. A. Bader, H. Meyerhenke, P. Sanders, C. Schulz, A. Kappes, and D. Wagner. Benchmarking for Graph Clustering and Partitioning. In Encyclopedia of Social Network Analysis and Mining, pages 73–82. Springer, 2014.
  • [6] C. Bichot and P. Siarry, editors. Graph Partitioning. Wiley, 2011.
  • [7] R. Brillout. A Multi-Level Framework for Bisection Heuristics. 2009.
  • [8] T. N. Bui and C. Jones. Finding Good Approximate Vertex and Edge Partitions is NP-Hard. Information Processing Letters, 42(3):153–159, 1992.
  • [9] A. Buluç, H. Meyerhenke, I. Safro, P. Sanders, and C. Schulz. Recent Advances in Graph Partitioning. In Algorithm Engineering, pages 117–158. Springer, 2016.
  • [10] T. Davis. The University of Florida Sparse Matrix Collection.
  • [11] D. Delling, A. V. Goldberg, T. Pajor, and R. F. Werneck. Customizable Route Planning. In Proc. of the 10th International Symposium on Experimental Algorithms, volume 6630 of LCNS, pages 376–387. Springer, 2011.
  • [12] D. Delling, A. V. Goldberg, I. Razenshteyn, and R. F. Werneck. Exact Combinatorial Branch-and-Bound for Graph Bisection. In Proc. of the 12th Workshop on Algorithm Engineering and Experimentation (ALENEX’12), pages 30–44, 2012.
  • [13] D. Delling and R. F. Werneck. Better Bounds for Graph Bisection. In Proc. of the 20th European Symposium on Algorithms, volume 7501 of LNCS, pages 407–418, 2012.
  • [14] A. Feldmann and P. Widmayer. An Time Algorithm to Compute the Bisection Width of Solid Grid Graphs. In Proc. of the 19th European Conference on Algorithms, volume 6942 of LNCS, pages 143–154. Springer, 2011.
  • [15] A. Felner. Finding Optimal Solutions to the Graph Partitioning Problem with Heuristic Search. Annals of Mathematics and Artificial Intelligence, 45:293–322, 2005.
  • [16] C. E. Ferreira, A. Martin, C. C. De Souza, R. Weismantel, and L. A. Wolsey. The Node Capacitated Graph Partitioning Problem: A Computational Study. Mathematical Programming, 81(2):229–256, 1998.
  • [17] C. M. Fiduccia and R. M. Mattheyses. A Linear-Time Heuristic for Improving Network Partitions. In Proc. of the 19th Conference on Design Automation, pages 175–181, 1982.
  • [18] J. Fietz, M. Krause, C. Schulz, P. Sanders, and V. Heuveline. Optimized Hybrid Parallel Lattice Boltzmann Fluid Flow Simulations on Complex Geometries. In Proc. of Euro-Par 2012 Parallel Processing, volume 7484 of LNCS, pages 818–829. Springer, 2012.
  • [19] P. Galinier, Z. Boujbel, and M. C. Fernandes. An Efficient Memetic Algorithm for the Graph Partitioning Problem. Annals of Operations Research, 191(1):1–22, 2011.
  • [20] A. George. Nested Dissection of a Regular Finite Element Mesh. SIAM Journal on Numerical Analysis, 10(2):345–363, 1973.
  • [21] W. W. Hager, D. T. Phan, and H. Zhang. An Exact Algorithm for Graph Partitioning. Mathematical Programming, 137(1-2):531–556, 2013.
  • [22] M. Hein and S. Setzer. Beyond Spectral Clustering - Tight Relaxations of Balanced Graph Cuts. In Advances in Neural Information Processing Systems, pages 2366–2374, 2011.
  • [23] S. E. Karisch, F. Rendl, and J. Clausen. Solving Graph Bisection Problems with Semidefinite Programming. INFORMS Journal on Computing, 12(3):177–191, 2000.
  • [24] G. Karypis and V. Kumar. A Fast and High Quality Multilevel Scheme for Partitioning Irregular Graphs. SIAM Journal on Scientific Computing, 20(1):359–392, 1998.
  • [25] B. W. Kernighan and S. Lin. An Efficient Heuristic Procedure for Partitioning Graphs. The Bell System Technical Journal, 49(1):291–307, 1970.
  • [26] T. Kieritz, D. Luxen, P. Sanders, and C. Vetter. Distributed Time-Dependent Contraction Hierarchies. In Proc. of the 9th International Symposium on Experimental Algorithms, volume 6049 of LNCS, pages 83–93. Springer, 2010.
  • [27] A. H. Land and A. G. Doig. An Automatic Method of Solving Discrete Programming Problems. Econometrica, 28(3):497–520, 1960.
  • [28] U. Lauther. An Extremely Fast, Exact Algorithm for Finding Shortest Paths in Static Networks with Geographical Background, 2004.
  • [29] A. Lisser and F. Rendl. Graph Partitioning using Linear and Semidefinite Programming. Mathematical Programming, 95(1):91–101, 2003. doi:10.1007/s10107-002-0342-x.
  • [30] D. Luxen and D. Schieferdecker. Candidate Sets for Alternative Routes in Road Networks. In Proc. of the 11th International Symposium on Experimental Algorithms (SEA’12), volume 7276 of LNCS, pages 260–270. Springer, 2012.
  • [31] R. H. Möhring, H. Schilling, B. Schütz, D. Wagner, and T. Willhalm. Partitioning Graphs to Speedup Dijkstra’s Algorithm. Journal of Experimental Algorithmics (JEA), 11(2006), 2007.
  • [32] F. Pellegrini. Scotch Home Page. http://www.labri.fr/pelegrin/scotch.
  • [33] P. Sanders and C. Schulz. Engineering Multilevel Graph Partitioning Algorithms. In Proc. of the 19th European Symp. on Algorithms, volume 6942 of LNCS, pages 469–480. Springer, 2011.
  • [34] P. Sanders and C. Schulz. Distributed Evolutionary Graph Partitioning. In Proc. of the 12th Workshop on Algorithm Engineering and Experimentation (ALENEX’12), pages 16–29, 2012.
  • [35] P. Sanders and C. Schulz. Think Locally, Act Globally: Highly Balanced Graph Partitioning. In Proc. of the 12th Int. Symp. on Experimental Algorithms (SEA’13), LNCS. Springer, 2013.
  • [36] K. Schloegel, G. Karypis, and V. Kumar. Graph Partitioning for High Performance Scientific Simulations. In The Sourcebook of Parallel Computing, pages 491–541, 2003.
  • [37] C. Schulz and D. Strash. Graph Partitioning Formulations and Applications to Big Data. In Encyclopedia on Big Data Technologies, 2018, to appear.
  • [38] M. Sellmann, N. Sensen, and L. Timajev. Multicommodity Flow Approximation used for Exact Graph Partitioning. In Proc. of the 11th European Symposium on Algorithms, volume 2832 of LNCS, pages 752–764. Springer, 2003.
  • [39] N. Sensen. Lower Bounds and Exact Algorithms for the Graph Partitioning Problem Using Multicommodity Flows. In Proc. of the 9th European Symposium on Algorithms, volume 2161 of LNCS, pages 391–403. Springer, 2001.
  • [40] A. J. Soper, C. Walshaw, and M. Cross. A Combined Evolutionary Search and Multilevel Optimisation Approach to Graph-Partitioning. Journal of Global Optimization, 29(2):225–241, 2004.
  • [41] C. Walshaw. Walshaw Partitioning Benchmark. http://staffweb.cms.gre.ac.uk/~wc06/partition/.
  • [42] C. Walshaw and M. Cross. JOSTLE: Parallel Multilevel Graph-Partitioning Software – An Overview. In Mesh Partitioning Techniques and Domain Decomposition Techniques, pages 27–58. 2007.

Appendix A Additional Tables

Graph / k 2 4 8 16 32 64
add20 596 596 1151 1151 1681 1681 2040 2040 *2360 2361 ^2947 2949
data 189 189 382 382 668 668 1127 1127 1799 1799 2839 2839
3elt 90 90 201 201 345 345 573 573 960 960 1532 1532
uk 19 19 41 41 83 83 145 145 *^246 247 408 408
add32 11 11 34 34 67 67 118 118 213 213 485 485
bcsstk33 10171 10171 21717 21717 34437 34437 54680 54680 77414 77414 107185 107185
whitaker3 127 127 381 381 656 656 1085 1085 1668 1668 2491 2491
crack 184 184 366 366 679 679 1088 1088 *1678 1679 2535 2535
wing_nodal 1707 1707 3575 3575 5435 5435 *8333 8334 11768 11768 *^15774 15775
fe_4elt2 130 130 349 349 607 607 1007 1007 1614 1614 2475 2478
vibrobox 10343 10343 18976 18976 24484 24484 *^31848 31850 *39474 39477 *46568 46571
bcsstk29 2843 2843 8035 8035 13975 13975 21905 21905 *34733 34737 55241 55241
4elt 139 139 326 326 545 545 *^933 934 1551 1551 ^2564 2565
fe_sphere 386 386 768 768 1156 1156 1714 1714 2488 2488 3543 3543
cti 334 334 954 954 1788 1788 2793 2793 4046 4046 5629 5629
memplus *5499 5513 *9442 9448 *^11710 11712 ^12893 12895 *^13947 13953 ^16188 16223
cs4 369 369 932 932 1440 1440 2075 2075 *2907 2928 ^4025 4027
bcsstk30 6394 6394 16651 16651 34846 34846 *^70407 70408 113336 113336 *171148 171153
bcsstk31 2762 2762 7351 7351 *13280 13283 *23857 23869 *37143 37158 *57354 57402
fe_pwt 340 340 705 705 1447 1447 2830 2830 *^5574 5575 ^8177 8180
bcsstk32 4667 4667 9311 9311 *^20008 20009 *^36249 36250 *60013 60038 *90778 90895
fe_body 262 262 599 599 1033 1033 *1722 1736 ^2797 2846 *4728 4730
t60k 79 79 209 209 456 456 ^812 813 1323 1323 *^2074 2077
wing 789 789 1623 1623 2504 2504 ^3870 3876 ^5592 5594 ^7622 7625
brack2 731 731 3084 3084 7140 7140 11570 11570 ^17382 17387 *25805 25808
finan512 162 162 324 324 648 648 1296 1296 2592 2592 10560 10560
fe_tooth 3816 3816 *6888 6889 *11414 11418 *^17352 17355 *24879 24885 *34234 34240
fe_rotor 2098 2098 7222 7222 ^12838 12841 *20389 20391 *31132 31141 *45677 45687
598a 2398 2398 8001 8001 *15921 15922 *25694 25702 *38576 38581 *^56094 56097
fe_ocean 464 464 1882 1882 4188 4188 7713 7713 ^12667 12684 ^20061 20069
144 6486 6486 ^15194 15196 25273 25273 *37566 37571 *55467 55475 *77391 77402
wave 8677 8677 *17193 17198 *29188 29198 *42639 42646 *61100 61108 ^83987 83994
m14b 3836 3836 *13061 13062 *25834 25838 *42161 42172 *65469 65529 ^96446 96452
auto *^10101 10103 *27092 27094 *45991 46014 ^77391 77418 *121911 121944 ^172966 172973
Table 4: Improvement of existing partitions from the Walshaw benchmark with using our ILP approach. In each -column the results computed by our approach are on the left and the current Walshaw cuts are on the right. Results achieved by Gain are marked with ^and results achieved by Gain are marked with *.
Graph / k 2 4 8 16 32 64
add20 585 585 1147 1147 *^1680 1681 2040 2040 2361 2361 2949 2949
data 188 188 376 376 656 656 1121 1121 1799 1799 2839 2839
3elt 89 89 199 199 340 340 568 568 953 953 1532 1532
uk 19 19 40 40 80 80 142 142 246 246 408 408
add32 10 10 33 33 66 66 117 117 212 212 485 485
bcsstk33 10097 10097 21338 21338 34175 34175 54505 54505 77195 77195 106902 106902
whitaker3 126 126 380 380 654 654 1083 1083 1664 1664 2480 2480
crack 183 183 362 362 676 676 1081 1081 1669 1669 2523 2523
wing_nodal 1695 1695 3559 3559 5401 5401 8302 8302 *11731 11733 *^15734 15736
fe_4elt2 130 130 349 349 603 603 1000 1000 1608 1608 ^2470 2472
vibrobox 10310 10310 18943 18943 24422 24422 *^31710 31712 *^39396 39400 *46529 46541
bcsstk29 2818 2818 8029 8029 13891 13891 21694 21694 34606 34606 *^54950 54951
4elt 138 138 320 320 532 532 927 927 1535 1535 2546 2546
fe_sphere 386 386 766 766 1152 1152 1708 1708 2479 2479 3534 3534
cti 318 318 944 944 1746 1746 2759 2759 3993 3993 5594 5594
memplus *5452 5457 9385 9385 11672 11672 12873 12873 ^13931 13933 ^16091 16110
cs4 366 366 925 925 1434 1434 2061 2061 2903 2903 ^3981 3982
bcsstk30 6335 6335 16583 16583 34565 34565 69912 69912 112365 112365 170059 170059
bcsstk31 2699 2699 7272 7272 *^13134 13137 *23333 23339 *37057 37061 *57000 57025
fe_pwt 340 340 704 704 1432 1432 2797 2797 5514 5514 ^8128 8130
bcsstk32 4667 4667 9180 9180 *19612 19624 35617 35617 *59501 59504 *89893 89905
fe_body 262 262 598 598 1023 1023 1714 1714 ^2748 2756 *^4664 4674
t60k 75 75 208 208 454 454 805 805 1313 1313 2062 2062
wing 784 784 1610 1610 2474 2474 3857 3857 ^5576 5577 ^7585 7586
brack2 708 708 3013 3013 7029 7029 11492 11492 *17120 17128 ^25604 25607
finan512 162 162 324 324 648 648 1296 1296 2592 2592 10560 10560
fe_tooth 3814 3814 *6843 6844 11358 11358 *^17264 17265 *24799 24804 ^34159 34170
fe_rotor 2031 2031 7158 7158 12616 12616 ^20146 20152 *30975 30982 *45304 45321
598a 2388 2388 7948 7948 15831 15831 *25620 25624 ^38410 38422 *55867 55882
fe_ocean ^385 387 1813 1813 *4060 4063 7616 7616 ^12523 12524 *19851 19852
144 *6476 6478 15140 15140 *25225 25232 *37341 37347 *55258 55277 *76964 76980
wave *^8656 8657 ^16745 16747 *28749 28758 *42349 42354 *60617 60625 ^83451 83466
m14b 3826 3826 12973 12973 *^25626 25627 *42067 42080 *64684 64697 ^96145 96169
auto 9949 9949 *26611 26614 *45424 45429 *76533 76539 *120470 120489 ^171866 171880
Table 5: Improvement of existing partitions from the Walshaw benchmark with using our ILP approach. In each -column the results computed by our approach are on the left and the current Walshaw cuts are on the right. Results achieved by Gain are marked with ^and results achieved by Gain are marked with *.
Graph / k 2 4 8 16 32 64
add20 560 560 1134 1134 1673 1673 2030 2030 2346 2346 2920 2920
data 185 185 369 369 638 638 1088 1088 1768 1768 *2781 2783
3elt 87 87 198 198 334 334 561 561 944 944 1512 1512
uk 18 18 39 39 78 78 139 139 240 240 397 397
add32 10 10 33 33 66 66 117 117 212 212 476 476
bcsstk33 10064 10064 20762 20762 34065 34065 54354 54354 76749 76749 *105737 105742
whitaker3 126 126 378 378 649 649 1073 1073 1647 1647 *2456 2459
crack 182 182 360 360 671 671 1070 1070 1655 1655 *^2487 2489
wing_nodal 1678 1678 3534 3534 5360 5360 8244 8244 *11630 11632 *^15612 15613
fe_4elt2 130 130 341 341 595 595 990 990 1593 1593 ^2431 2435
vibrobox 10310 10310 18736 18736 24153 24153 *^31440 31443 *39197 39201 *46231 46235
bcsstk29 2818 2818 7971 7971 13710 13710 21258 21258 33807 33807 54382 54382
4elt 137 137 319 319 522 522 901 901 1519 1519 2512 2512
fe_sphere 384 384 764 764 1152 1152 1696 1696 2459 2459 *^3503 3505
cti 318 318 916 916 1714 1714 2727 2727 3941 3941 *5522 5524
memplus *^5352 5353 9309 9309 *^11584 11586 12834 12834 *13887 13895 *15950 15953
cs4 360 360 917 917 *^1423 1424 2043 2043 *2884 2885 ^3979 3980
bcsstk30 6251 6251 16372 16372 34137 34137 69357 69357 110334 110334 *168271 168274
bcsstk31 2676 2676 7148 7148 12962 12962 *22949 22956 *36567 36587 *56025 56038
fe_pwt 340 340 700 700 1410 1410 2754 2754 5403 5403 8036 8036
bcsstk32 4667 4667 8725 8725 19485 19485 *^34869 34875 ^58739 58740 *89478 89479
fe_body 262 262 598 598 1016 1016 1693 1693 *^2708 2709 *^4522 4523
t60k 71 71 203 203 449 449 792 792 1302 1302 *^2034 2036
wing 773 773 1593 1593 2451 2451 ^3783 3784 5559 5559 7560 7560
brack2 684 684 2834 2834 6778 6778 *11253 11256 *^16981 16982 *^25362 25363
finan512 162 162 324 324 648 648 1296 1296 2592 2592 10560 10560
fe_tooth 3788 3788 6756 6756 11241 11241 *17107 17108 *24623 24625 *33779 33795
fe_rotor 1959 1959 *^7049 7050 12445 12445 *19863 19867 *30579 30587 *44811 44822
598a 2367 2367 7816 7816 15613 15613 *^25379 25380 *38093 38105 *55358 55364
fe_ocean 311 311 1693 1693 3920 3920 7405 7405 ^12283 12288 19518 19518
144 *^6430 6432 15064 15064 *24901 24905 *^36999 37003 *54800 54806 *76548 76557
wave 8591 8591 ^16633 16638 28494 28494 42139 42139 *60334 60356 *82809 82811
m14b 3823 3823 12948 12948 25390 25390 41778 41778 ^64354 64364 *^95575 95587
auto 9673 9673 25789 25789 *^44724 44732 *^75665 75679 ^119131 119132 ^170295 170314
Table 6: Improvement of existing partitions from the Walshaw benchmark with using our ILP approach. In each -column the results computed by our approach are on the left and the current Walshaw cuts are on the right. Results achieved by Gain are marked with ^and results achieved by Gain are marked with *.
Graph / k 2 4 8 16 32 64
add20 536 536 1120 1120 1657 1657 2027 2027 2341 2341 2920 2920
data 181 181 363 363 628 628 1076 1076 1743 1743 2747 2747
3elt 87 87 197 197 329 329 557 557 930 930 1498 1498
uk 18 18 39 39 75 75 137 137 236 236 394 394
add32 10 10 33 33 63 63 117 117 212 212 476 476
bcsstk33 9914 9914 20158 20158 33908 33908 54119 54119 ^76070 76079 *105297 105309
whitaker3 126 126 376 376 644 644 1068 1068 1632 1632 *^2425 2429
crack 182 182 360 360 666 666 1063 1063 1655 1655 *^2479 2489
wing_nodal 1668 1668 3520 3520 5339 5339 8160 8160 *11533 11536 *^15514 15515
fe_4elt2 130 130 335 335 578 578 979 979 1571 1571 ^2406 2412
vibrobox 10310 10310 18690 18690 23924 23924 ^31216 31218 *^38823 38826 *45987 45994
bcsstk29 2818 2818 7925 7925 13540 13540 20924 20924 33450 33450 53703 53703
4elt 137 137 315 315 515 515 887 887 1493 1493 ^2478 2482
fe_sphere 384 384 762 762 1152 1152 1678 1678 2427 2427 3456 3456
cti 318 318 889 889 1684 1684 2701 2701 3904 3904 ^5460 5462
memplus *^5253 5263 *9281 9292 *^11540 11543 12799 12799 *13857 13867 *15875 15877
cs4 353 353 908 908 1420 1420 ^2042 2043 *2855 2859 *^3959 3962
bcsstk30 6251 6251 16165 16165 34068 34068 68323 68323 109368 109368 *166787 166790
bcsstk31 *^2660 2662 7065 7065 *^12823 12825 *22718 22724 *36354 36358 *55250 55258
fe_pwt 340 340 700 700 1405 1405 2737 2737 ^5305 5306 ^7956 7959
bcsstk32 4622 4622 8441 8441 18955 18955 34374 34374 58352 58352 *88595 88598
fe_body 262 262 588 588 1012 1012 1683 1683 *^2677 2678 ^4500 4501
t60k 65 65 195 195 441 441 787 787 *1289 1291 *^2013 2015
wing 770 770 *1589 1590 2440 2440 3775 3775 *^5512 5513 ^7529 7534
brack2 660 660 2731 2731 6592 6592 *11052 11055 16765 16765 *25100 25108
finan512 162 162 324 324 648 648 1296 1296 2592 2592 10560 10560
fe_tooth 3773 3773 6687 6687 *^11147 11151 *16983 16985 ^24270 24274 *33387 33403
fe_rotor 1940 1940 6779 6779 *12308 12309 *19677 19680 *30355 30356 *44368 44381
598a 2336 2336 *7722 7724 15413 15413 25198 25198 ^37632 37644 *54677 54684
fe_ocean 311 311 1686 1686 3886 3886 7338 7338 ^12033 12034 *^19391 19394
144 6345 6345 ^14978 14981 *24174 24179 *^36608 36608 *54160 54168 *75753 75777
wave 8524 8524 *16528 16531 28489 28489 *^42024 42025 *^59608 59611 *81989 82006
m14b 3802 3802 *^12858 12859 25126 25126 *41097 41098 *63397 63411 *94123 94140
auto 9450 9450 25271 25271 44206 44206 *74266 74272 *118998 119004 ^169260 169290
Table 7: Improvement of existing partitions from the Walshaw benchmark with using our ILP approach. In each -column the results computed by our approach are on the left and the current Walshaw cuts are on the right. Results achieved by Gain are marked with ^and results achieved by Gain are marked with *.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
""
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
   
Add comment
Cancel
Loading ...
106696
This is a comment super asjknd jkasnjk adsnkj
Upvote
Downvote
""
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters
Submit
Cancel

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test
Test description