Faster and Better Nested Dissection Orders for Customizable Contraction Hierarchies

Abstract

Graph partitioning has many applications. We consider the acceleration of shortest path queries in road networks using Customizable Contraction Hierarchies (CCH). It is based on computing a nested dissection order by recursively dividing the road network into parts. Recently, with FlowCutter and Inertial Flow, two flow-based graph bipartitioning algorithms have been proposed for road networks. While FlowCutter achieves high-quality results and thus fast query times, it is rather slow. Inertial Flow is particularly fast due to the use of geographical information while still achieving decent query times. We combine the techniques of both algorithms to achieve more than six times faster preprocessing times than FlowCutter and even faster queries on the Europe road network. We show that, using 16 cores of a shared-memory machine, this preprocessing needs four minutes.

1. Introduction

The goal of graph partitioning is to divide a graph into a given number of roughly equally sized parts by removing a small number of edges or nodes. Graph partitioning has many practical applications, such as accelerating matrix multiplication, dividing compute workloads, image processing, circuit design, and the focus of this work, accelerating shortest path computations in road networks. For an overview of the state-of-the-art in graph partitioning, we refer the reader to a survey article [1].

Computing shortest paths in road networks is a fundamental building block in applications such as navigation systems (e.g., Google Maps), logistics planning, and traffic simulation. Unfortunately, Dijkstra’s algorithm [2] takes over a second for a single query on continental-size road networks with tens of millions of nodes, rendering it infeasible for interactive scenarios. This has led to a large amount of research on speedup techniques [3], which often use an expensive preprocessing phase to enable fast queries. Arc-Flags [4,5] is one of the early techniques that use graph partitioning. It has been frequently used to enhance other techniques, e.g., SHARC [6], combining shortcuts [7] and Arc-Flags, ReachFlags [8], combining Reach [9] and Arc-Flags as well as CHASE [8], combining Contraction Hierarchies [10] and Arc-Flags. In navigation systems, the graph topology changes infrequently, but the metric (arc weights) changes frequently, e.g., due to traffic congestion or road closures. To accommodate this, modern speedup techniques split the preprocessing phase into an expensive metric-independent preprocessing phase and a fast metric-dependent customization phase. The two state-of-the-art techniques are Multilevel Overlays, also known as Customizable Route Planning [11], which use nested k-way partitions and Customizable Contraction Hierarchies (CCHs) [12], which use nested dissection orders [13]. In this work, we focus on CCHs, which extend classic two-phase Contraction Hierarchies [10] to the three-phase approach with customization.

Contraction Hierarchies simulate contracting all nodes in a given order and insert shortcut arcs between the neighbors of a contracted node. These represent paths via the contracted nodes. Shortest s–t path queries are answered by, e.g., a bidirectional Dijkstra search [2] from s and t, which only considers shortcut and original arcs to higher-ranked nodes. Thus, nodes which lie on many shortest paths should be ranked high in the order. Customizable Contraction Hierarchies [12] use contraction orders computed via recursive balanced node separators (nested dissection) in order to achieve a logarithmic search space depth with few added shortcuts. Node separators are considered to lie on many shortest paths, as any path between the components crosses the separator. The weights of the contraction hierarchy can then be quickly customized to any metric, allowing, e.g., the incorporation of real-time traffic information. The running time needed for the customization and the shortest path queries depends on the quality of the calculated order. Previously proposed partitioning tools for computing separators in road networks include FlowCutter [14], Inertial Flow [15], KaHiP [16], Metis [17], PUNCH [18], and Buffoon [19]. KaHiP and Metis are general-purpose graph partitioning tools. PUNCH and Buffoon are special-purpose partitioners, which aim to use geographical features of road networks such as rivers or mountains. Rivers and mountains form very small cuts and were dubbed natural cuts in [18]. PUNCH identifies and deletes natural cuts, then contracts the remaining components and subsequently runs a variety of highly randomized local search algorithms. Buffoon incorporates the idea of natural cuts into KaHiP, running its evolutionary multilevel partitioner instead of the flat local searches of PUNCH. In [14], it was shown that FlowCutter is also able to identify and leverage natural cuts. Inertial Flow is another special-purpose partitioner that is even based on using the geographic embedding of the road network.

We combine the idea of Inertial Flow to use geographic coordinates with the incremental cut computations of FlowCutter. This allows us to compute a series of cuts with suitable balances much faster than FlowCutter while still achieving high quality. In an extensive experimental evaluation, we compare our new algorithm InertialFlowCutter to the state-of-the-art. Thus far, FlowCutter has been the best method for computing CCH orders. InertialFlowCutter computes slightly better CCH orders than FlowCutter and is a factor of 5.7 and 6.6 faster on the road networks of the USA and Europe, respectively—our two most relevant instances. Using 16 cores of a shared-memory machine, we can compute CCH orders for these instances in four minutes.

In Section 2, we briefly present the existing Inertial Flow and FlowCutter algorithms and describe how we combined them. In Section 3, we describe the setup and results of our experimental study. We conclude with a discussion of our results and future research directions in Section 4.

This paper recreates the experiments from [14] and uses a lot of the same setup. Therefore, there is substantial content overlap. To keep this paper self-contained, we repeat the parts we use. Our contributions are the InertialFlowCutter algorithm, an improved Inertial Flow implementation and a reproduction of the experiments from [14], including InertialFlowCutter and a newer KaHiP version.

2. Materials and Methods

After introducing preliminaries, we describe the existing biparitioning algorithms FlowCutter and Inertial Flow on a high level, before discussing how to combine them into our new algorithm InertialFlowCutter. We refer the interested reader to [14] for implementation details and a more in-depth discussion of the FlowCutter algorithm. Then, we discuss our application Customizable Contraction Hierarchies (CCH), what makes a good CCH order, and how we use recursive bisection to compute them.

2.1. Preliminaries

An undirected graph $G=(V,E)$ consists of a set of nodesV and a set of edges $E\subseteq \left(\genfrac{}{}{0pt}{}{V}{2}\right)$. A directed graph $G=(V,A)$ has directed arcs $A\subseteq V\times V$ instead of undirected edges. It is symmetric if for every arc $(x,y)\in A$, the reverse arc $(y,x)$ is in A. For ease of notation, we do not distinguish between undirected and symmetric graphs in this paper, and we use them interchangeably, whichever better suits the description. Let $n:=\left|V\right|$ denote the number of nodes and let $m:=\left|E\right|$ denote the number of edges of an undirected graph. All graphs in this paper contain neither self-loops $(x,x)$ nor multiedges. $H=(V^{\prime },A^{\prime })$ is a subgraph of G if $V^{\prime }\subseteq V$ and $A^{\prime }\subseteq A$. The subgraph induced by a node set $U\subseteq V$ is defined as $G\left[U\right]:=(U,\{(u,v)\in A\cap (U\times U)\left\}\right)$, the graph with nodes U and all arcs of G with endpoints in U. The degree $deg\left(x\right)=\left|\right\{(x,y)\in A\left\}\right|$ is the number of outgoing arcs of x. A path is a sequence of edges such that consecutive edges overlap in a node. A graph is called k-connected if there are k node-disjoint paths between every pair of nodes. The k-connected components of a graph are the node-induced subgraphs, which are inclusion-maximal regarding k-connectivity. 1-connected components are called connected components, while 2-connected components are called biconnected components.

2.1.1. Separators and Cuts

Let $V_1,V_2\subset V$ be a bipartition of $V=V_1\cup V_2$ into two non-empty disjoint sets, called blocks. The cut induced by $(V_1,V_2)$ is the set of edges $cut(V_1,V_2):=\{(v_1,v_2)\subseteq E\cap (V_1\times V_2)\}$ between $V_1$ and $V_2$. The cut size is $|cut(V_1,V_2\left)\right|$. We often use the terms cut and bipartition interchangeably. Sometimes, we say a bipartition is induced by a set of cut edges. A node separator partition is a partition of $V=Q\cup V_1\cup V_2$ into three disjoint sets $(Q,V_1,V_2)$ such that there is no edge between $V_1$ and $V_2$. We call Q the separator and $V_1,V_2$ the blocks or components of the separator. $\left|Q\right|$ is the separator size. For an $\epsilon \in [0,1]$, a cut or separator is $\epsilon$-balanced if $max\left(\right|V_1|,|V_2\left|\right)\le \lceil (1+\epsilon )n/2\rceil$. We often call $\epsilon$ the imbalance, as larger values correspond to less balanced cuts. The balanced graph bipartitioning [balanced node separator] problem is to find an $\epsilon$-balanced cut [separator] of minimum size. Let $S,T\subset V$ be two fixed, disjoint, non-empty subsets of V. An edge cut [node separator] is an S–T edge cut [node separator] if $S\subseteq V_1$ and $T\subseteq V_2$.

2.1.2. Maximum Flows

A flow network $\mathcal{N}=(V,A,S,T,c)$ is a simple symmetric directed graph $(V,A)$ with two disjoint non-empty terminal node sets $S,T⊊V$, also called the source and target node set, as well as a capacity function $c:A\to {\mathbb{R}}_{\ge 0}$. A flow in $\mathcal{N}$ is a function $f:A\to \mathbb{R}$ subject to the capacity constraint $f\left(a\right)\le c\left(a\right)$ for all arcs a, flow conservation ${\sum }_{(u,v)\in A}f\left((u,v)\right)=0$ for all nonterminal nodes v, and skew symmetry $f\left(\right(u,v\left)\right)=-f\left(\right(v,u\left)\right)$ for all arcs $(u,v)$. In this paper, we consider only unit flows and unit capacities, i.e., $f:A\to \{-1,0,1\}$, $c:A\to \{0,1\}$. The value of a flow $\left|f\right|:={\sum }_{s\in S,(s,u)\in A}f\left((s,u)\right)$ is the amount of flow leaving S. The residual capacity $r_f\left(a\right):=c\left(a\right)-f\left(a\right)$ is the additional amount of flow that can pass through a without violating the capacity constraint. The residual network with respect to f is the directed graph ${\mathcal{N}}_f=(V,A_f)$, where $A_f:=\{a\in A|r_f\left(a\right)>0\}$. An augmenting path is an S–T path in ${\mathcal{N}}_f$. A node v is called source-reachable if there is a path from S to v in ${\mathcal{N}}_f$. We denote the set of source-reachable nodes by $S_r$, and define the set of target-reachable nodes $T_r$ analogously. The flow f is a maximum flow if $\left|f\right|$ is maximal among all possible flows in $\mathcal{N}$. This is the case if and only if there is no augmenting path in ${\mathcal{N}}_f$. The well-known max-flow–min-cut theorem [20] states that the value of a maximum flow equals the capacity of a minimum S–T edge cut. $(S_r,V\backslash S_r)$ is the source-side cut, and $(V\backslash T_r,T_r)$ is the target-side cut of a maximum flow.

2.2. Flowcutter

FlowCutter is an algorithm for the balanced graph bipartitioning problem. The idea of its core algorithm is to solve a sequence of incremental max flow problems, which induce cuts with monotonically increasing cut size and balance, until the latest cut induces an $\epsilon$-balanced bipartition. The flow problems are incremental in the sense that the terminal nodes $S,T$ of the previous flow problem are subsets of the terminals in the next flow problem. This nesting allows us to reuse the flow computed in previous iterations.

Given randomly chosen starting terminal nodes $s,t$, we set $S:=\left\{s\right\},T:=\left\{t\right\}$ and compute a maximum S–T flow. Then, we transform the S-reachable nodes $S_r$ to sources if $|S_r|\le |T_r|$, or $T_r$ to targets otherwise. Assume $|S_r|\le |T_r|$ without loss of generality. Now S induces a minimum S–T cut $C_S$. If $C_S$ is $\epsilon$-balanced, the algorithm terminates. Otherwise, we transform one additional node, called piercing node, to a source. The piercing node is chosen from the nodes incident to the cut $C_S$ and not in S. This step is called piercing the cut $C_S$. It ensures that we will find a different cut in the next iteration. Subsequently, we augment the previous flow to a maximum flow that considers the new source node. These steps are repeated until the latest cut induces an $\epsilon$-balanced bipartition. Algorithm 1 shows pseudocode for FlowCutter.

Algorithm 1: FlowCutter

A significant detail of the piercing step is that piercing nodes which are not reachable from the opposite side are preferred. Choosing such nodes for piercing does not create augmenting paths. Thus, the cut size does not increase in the next iteration. This is called the avoid-augmenting-paths heuristic. A secondary distance-based piercing heuristic is used to break ties, when the avoid-augmenting-paths heuristic gives multiple choices. It chooses the node p which minimizes $dist(p,t)-dist(s,p)$, where dist is the hop distance, precomputed via Breadth-First-Search from s and t. Roughly speaking, this attempts to prevent the cut sides from meeting before perfect balance. It also has a geometric interpretation, which is explained in [14].

We choose the starting terminal nodes s and t uniformly at random. Experiments [14] indicate that 20 terminal pairs are sufficient to obtain high quality partitions of road networks.

For computing maximum flows, we use the basic Ford–Fulkerson algorithm [20], with Pseudo- Depth-First-Search for finding augmenting paths. Pseudo-Depth-First-Search directly marks all adjacent nodes as visited when processing a node. It can be implemented like Breadth-First-Search using a stack instead of a queue.

A major advantage of FlowCutter over other partitioning tools is the fact that it computes multiple cuts. From this set of cuts, we derive the Pareto cutset, which we define as the set of all nondominated cuts. A cut $C_2$ is dominated by a cut $C_1$ if $C_2$ has neither better balance nor smaller cut size than $C_1$. Instead of selecting a maximum imbalance a priori, we can select a good trade-off between cut size and imbalance from the Pareto cutset.

2.3. Inertial Flow

Given a line $l\in {\mathbb{R}}^2$, Inertial Flow projects the geographic coordinates of the nodes onto their closest points on l. The nodes are sorted by order of appearance on l. For a parameter $\alpha \in [0,0.5]$, the first $\lfloor \alpha ·n\rfloor$ nodes are chosen as S. Analogously, the last $\lfloor \alpha ·n\rfloor$ nodes are chosen as T. In the next step, a maximum S–T flow is computed from which a minimum S–T cut is derived. Figure 1 illustrates the initialization. Instead of line, we use the term direction. In [15], $\alpha$ is set to $0.2$ and four directions are used: West–East, South–North, Southwest–Northeast, and Southeast–Northwest. This simple approach works surprisingly well for road networks.

2.4. Combining Inertial Flow and Flowcutter into InertialFlowCutter

One drawback of Inertial Flow is the restriction to an a priori chosen imbalance, i.e., a value of $\alpha$. We enhance FlowCutter by initializing S and T in the same way as Inertial Flow, though with a smaller parameter $\alpha$ than proposed for Inertial Flow. Additionally, we pierce cuts with multiple nodes from the Inertial Flow order at once. We call this bulk piercing. This way, we enumerate multiple Inertial Flow cuts simultaneously, without having to restart the flow computations. Furthermore, we can skip some of the first, highly imbalanced cuts of FlowCutter that are irrelevant for our application.

We introduce three additional parameters ${\gamma }_a,{\gamma }_o\in (0,0.5]$ and $\delta \in (0,1)$ to formalize bulk piercing. Let L be a permutation of the nodes, ordered according to a direction. For the source side, we use bulk piercing as long as S contains at most ${\gamma }_a·n$ nodes. Furthermore, we limit ourselves to piercing the first ${\gamma }_o·n$ nodes of L. Parameter $\delta$ influences the step size. The idea is to decrease the step size as the cuts become more balanced. When we decide to apply bulk piercing, we settle the next $\delta (\frac{1-\delta }{2}n-|S\left|\right)$ nodes to S, when piercing the source side. To enforce the limit set by ${\gamma }_o$, we pierce fewer nodes if necessary. For the target side, we apply this analogously starting from the end of the order. If bulk piercing can not be applied, we revert to the standard FlowCutter method of selecting single piercing nodes incident to the cut. Additionally, we always prioritize the avoid-augmenting-paths heuristic over bulk piercing. In our experiments, we conduct a parameter study which yields $\alpha =0.05,{\gamma }_a=0.4,{\gamma }_o=0.25$ and $\delta =0.05$ as reasonable choices. In Figure 2, we show an example for the InertialFlowCutter piercing step.

2.5. Running Multiple InertialFlowCutter Instances

To improve solution quality, we run $q\in \mathbb{N}$ instances of InertialFlowCutter with different directions. An instance is called a cutter. We use the directions $(cos(\phi ),sin(\phi \left)\right)$ for $\phi =\frac{k\pi }{q}$ and $k\in [0,\cdots ,q-1]$. To include the directions proposed in [15], q should be a multiple of 4. To improve running time, we run cutters simultaneously in an interleaved fashion as already proposed in [14]. We always schedule the cutters with the currently smallest flow value to either push one additional unit of flow or derive a cut. For the latter, we improve the balance by piercing the cut as long as this does not create an augmenting path. One standalone cutter runs in $\mathcal{O}\left(cm\right)$, where c is the size of the largest output cut. Roughly speaking, this stems from performing one graph traversal, e.g., Pseudo-DFS, per unit of flow. The exact details can be found in [14]. Flow-based execution interleaving ensures that no cutter performs more flow augmentations than the other cutters. Thus, the running time for q cutters is $\mathcal{O}\left(qcm\right)$, where c is the size of the largest found cut among all cutters. We specifically avoid computing some cuts that the standalone cutters would find. Consider the simple example with $q=2$, where the second cutter immediately finds a perfectly balanced cut with cut size c, but the first cutter only finds one cut with cut size $C\gg c$. If the first cutter runs until a cut is found, we invested $Cm$ work but should only have invested $cm$.

In the case of InertialFlowCutter, it is actually important to employ flow-based interleaving and not just run a cutter until the next cut is found, as after a bulk piercing step, the next cut might be significantly larger. For road networks and FlowCutter, this difference is insignificant in practice, as the cut increases by just one most of the time.

2.6. Customizable Contraction Hierarchies

A Customizable Contraction Hierarchy (CCH) is an index data structure which allows fast shortest path queries and fast adaptation to new metrics (arc weights) in road networks. It consists of three phases: a preprocessing phase which only uses the network topology but not the arcs weights, a faster customization phase which adapts the index to new arc weights, and a query phase which quickly answers shortest path queries.

The preprocessing phase computes a contraction order of the nodes, e.g., via nested dissection, and then simulates contracting all nodes in that order, inserting shortcut arcs between all neighbors of a contracted node. Shortcuts represent two-arc paths via the contracted node.

The customization phase assigns correct weights to shortcuts by processing all arcs $(u,v)$ in the order ascending by rank of u, i.e., the position of u in the order. To process an arc $(u,v)$, it enumerates all triangles $\langle u,w,v\rangle$ where w has lower rank than u and v, and updates the weight of $(u,v)$ if the path $(u,w,v)$ is shorter.

There are two different algorithms for s–t queries. For every shortest s–t path in the original graph, there is a shortest s–t path in the CCH that consists of two paths $(s,\cdots ,x)$ and $(x,\cdots ,t)$ such that the arcs in the first path are from lower-ranked to higher-ranked nodes, whereas the arcs in the second path are from higher-ranked to lower-ranked nodes [10]. The first, basic query algorithm performs bidirectional Dijkstra search from s and t and relaxes only arcs to higher-ranked nodes. The second query algorithm uses the elimination tree of a CCH to avoid priority queues, which are typically a bottleneck. In the elimination tree, the parent of a node is its lowest-ranked upward neighbor. The ancestors of a node v are exactly the nodes in the upward search space of v in the basic query [21]. For the s–t query, the outgoing arcs of all nodes on the path from s to the root and all incoming arcs of all nodes on the path from t to the root are relaxed. The node z minimizing the distance from s to z plus the distance from z to t determines the distance between s and t.

The query complexity is linear in the number of arcs incident to nodes on the paths from s and t to the root. Similarly, the customization running time depends on the number of triangles in the CCH. Fewer shortcuts result in less memory consumption and faster queries. We aim to minimize these metrics by computing high quality contraction orders.

2.7. Nested Dissection Orders for Road Networks

The framework to compute contraction orders is the same as for FlowCutter in [14] and our implementation builds upon theirs [22]. We only exchange the partitioning algorithm and parallelize it. For self-containedness, we repeat it here.

2.7.1. Recursive Bisection

We compute contraction orders via recursive bisection, using node separators instead of edge cuts. This method is also called nested dissection [13]. Let $(Q,V_1,V_2)$ be a node separator partition. Then, we recursively compute orders for $G\left[V_1\right]$ and $G\left[V_2\right]$ and return the order of $G\left[V_1\right]$ followed by the order of $G\left[V_2\right]$ followed by Q. Q can be in an arbitrary order. We opt for the input order. Recursion stops once the graphs are trees or cliques. For cliques, any order is optimal. For trees, we use an algorithm to compute an order with minimal elimination tree depth in linear time [23,24].

In the nested dissection implementation from [22], a recursive call first computes a node separator Q, then deletes the edges $\left\{\right(u,v)\in E\mid u\in Q\mathrm{or}v\in Q\}$ incident to that separator and then reorders the nodes in preorder. Preorder is the order in which nodes are first visited in a Depth-First-Search from some starting node—in this implementation, the one with smallest ID. The preorder identifies connected components of the new graph, which are the subgraphs to recurse on, as well as assigns local node and arc identifiers for them. This is also done once at the beginning, without computing a separator, in case the input graph is disconnected.

2.7.2. Separators

InertialFlowCutter computes edge cuts. We use a standard construction [25] to model node capacities as edge capacities in flow networks. It expands the undirected input graph $G=(V,E)$ into a directed graph $G^{\prime }=(V^{\prime },A^{\prime })$. For every node $v\in V$, there is an in-node $v_i$ and an out-node $v_o$ in $V^{\prime }$, joined by a directed arc $(v_i,v_o)$, called the bridge arc of v. Furthermore, for every edge $\{u,v\}\in E$, there are two directed external arcs $(u_o,v_i)$ and $(v_o,u_i)\in A^{\prime }$. Since we restrict ourselves to unit capacity flow networks, we can not assign infinite capacity to external arcs, and thus, the cuts contain both bridge arcs and external arcs. Bridge arcs directly correspond to a node in the separator. For the external arcs in the cut, we place the incident node on the larger side of the cut in the separator.

2.7.3. Choosing Cuts from the Pareto Cutset

InertialFlowCutter yields a sequence of nondominated cuts with monotonically increasing cut size and balance, whereas standard partitioners yield a single cut for some prespecified imbalance. We need to choose one cut, to recurse on the sides of the corresponding separator. The expansion of a cut is its cut size divided by the number of nodes on the smaller side. This gives a certain trade-off between cut size and balance. We choose the cut with minimum expansion and $\epsilon <0.6$, i.e., at least 20% of the nodes on the smaller side. While this approach is certainly not optimal, it works well enough. It is not clear how to choose the optimum cut without considering the whole hierarchy of cuts in deeper levels of recursion.

2.7.4. Special Preprocessing

Road networks contain many nodes of degree 1 or 2. The graph size can be drastically reduced by eliminating them in a preprocessing step that is performed only once. First, we compute the largest biconnected component B in linear time using [26] and remove all edges between B and the rest of the graph G. The remaining graph usually consists of a large B and many tiny, often tree-like components. We compute orders for the components separately and concatenate them in an arbitrary order. The order for B is placed after the orders of the smaller components.

A degree-2-chain is a path $(x,y_1,\cdots ,y_k,z)$ where all $deg\left(y_i\right)=2$ but $deg\left(x\right)>2$ and $deg\left(z\right)\ne 2$. We divide the nodes into two graphs $G_{\ge 3}$ and $G_{\le 2}$ with degrees at least 3 and at most 2, by computing all degree-2-chains in linear time and splitting along them. If $deg\left(z\right)>2$, we insert an edge between x and z since z is in $G_{\ge 3}$. We compute contraction orders for the connected components of $G_{\le 2}$ separately and concatenate them in an arbitrary order. Since these are paths, we can use the algorithm for trees. The order for $G_{\ge 3}$ is placed after the one for $G_{\le 2}$. We compute degree-2 chains by iterating over all arcs $(x,y)$. If $deg\left(x\right)>2$ and $deg\left(y\right)\le 2$, then x is the start of a degree-2 chain. We follow this chain recursively: As long as $deg\left(y\right)=2$, the only arc of y that is not $(y,x)$ comes next in the chain. If $deg\left(y\right)=1$ or $deg\left(y\right)\ge 3$, the chain is finished at y. This algorithm runs in linear time as it considers every arc at most twice.

2.8. Parallelization

Recursive bisection is straightforward to parallelize by computing orders on the separated blocks independently, using task-based parallelism. This only employs parallelism after the first separators have been found.

Therefore, we additionally parallelize InertialFlowCutter. The implementation of FlowCutter [22] contains a simple parallelization. In a round, all cutters with the currently smallest cut are advanced to their next cut in parallel. Before the next round, all threads synchronize. This approach exhibits poor core utilization since only a few cutters may have the smallest cut in a round and threads perform different amounts of work, leading to skewed load distribution.

Instead, we employ a simple wait-free task-based parallelization scheme, which guarantees that the cutters with the t currently smallest flow values are making progress, for t threads executing in parallel. Algorithm 2 illustrates this scheme in pseudocode. For every cutter, we store two atomic flags: a free flag, which indicates that currently no task holds this cutter, and an active flag, which indicates that this cutter can still yield a cut with better expansion than previously found cuts. In the beginning, every cutter is active and free.

Recall that q is the number of cutters. We create q tasks, and the task scheduler launches $t\le q$ parallel tasks, potentially adding more when resources from other parts of the recursive bisection become available. A task executes a loop in which it first acquires a cutter with the currently smallest flow out of the free and active cutters, then performs a chunk of work on it and releases the cutter again. A chunk of work consists of deactivating the cutter, if it can not improve expansion and otherwise running one Pseudo-Depth-First-Search, which either pushes one unit of flow or derives a cut. If the cut has at least $20\%$ of the nodes on the smaller side and improves expansion, we acquire a lock and store the cut. A task terminates once it fails to acquire a free and active cutter, as there are now more tasks than active cutters.

If less than q tasks are running simultaneously, the tasks switch between cutters. If all cutters are acquired and the task’s currently acquired cutter remains active, we continue working on it, to avoid the overhead of releasing and immediately re-acquiring the same cutter. Note that, due to the parallelization, cuts are not necessarily enumerated in the order of increasing cut size, and dominated cuts may also be reported.

Algorithm 2: Parallel InertialFlowCutter

3. Results

In this section, we discuss our experimental setup and results.

3.1. Experimental Setup

In Section 3.6, we discuss our parameter study to obtain reasonable parameters for InertialFlowCutter. Our remaining experiments follow the setup in [14], comparing FlowCutter, KaHiP, Metis, and Inertial Flow to InertialFlowCutter, regarding CCH performance as well as cut sizes for different imbalances on the input graph without biconnectivity and degree-2 chain preprocessing. The latter are referred to as top-level Pareto cut experiments. Our benchmark set consists of the road networks of Colorado, California, and Nevada, the USA and Western Europe, see

Table 1. Benchmark road networks.

Graph	n	m
Colorado	$436·{10}^3$	${10}^6$
California and Nevada	$1.9·{10}^6$	$4.6·{10}^6$
USA	$24·{10}^6$	$57·{10}^6$
Europe	$18·{10}^6$	$44·{10}^6$

, made available during the DIMACS implementation challenge on shortest paths [27].

The CCH performance experiments compare the different partitioners based on the time to compute a contraction order, the median running time of nine customization runs, the average time of ${10}^6$ random s–t queries, as well as the criteria introduced in Section 2.6. Unless explicitly stated as parallel, all reported running times are sequential on an Intel Xeon E5-1630 v3 Haswell processor clocked at 3.7 GHz with 10 MB L3 cache and 128 GB DDR4 RAM (2133 MHz). We additionally report running times for computing contraction orders in parallel on a shared-memory machine with two 8-core Intel Xeon Gold 6144 Skylake CPUs, clocked at 3.5GHz with 24.75 MB L3 cache and 192 GB DDR4 RAM (2666 MHz). InertialFlowCutter is implemented in C++, and the code is compiled with g++ version 8.2 with optimization level 3. We use Intel’s Threading Building Blocks library for shared-memory parallelism. Our InertialFlowCutter implementation and evaluation scripts are available on GitHub [28].

3.2. CCH Implementation

We used the CCH implementation in RoutingKit [29]. There are different CCH customization and query variants. RoutingKit implements basic customization with upper triangles instead of lower triangles, no witness searches, no precomputed triangles, and no instruction-level parallelism. We used the sequential customization. For queries, we used elimination tree search. There has been a recent, very simple improvement [30], which drastically accelerates elimination tree search for short-range queries. It is not implemented in RoutingKit, but random s–t queries tend to be long-range, so the effect would be negligible for our experiments.

3.3. Partitioner Implementations and Nested Dissection Setup

In [14], the KaHiP versions 0.61 and 1.00 are used. We did not re-run the preprocessing for those old versions of KaHiP but used the orders and order computation running times of [14]. We did re-run customizations and queries. The order computation running times are comparable as the experiments ran on the same machine. We added the latest KaHiP version 2.11, which is available on GitHub [31]. For all three versions, the strong preset of KaHiP was used. We refer to the three KaHiP variants as K0.61, K1.00, and K2.11. For the CCH order experiments, we kept versions K0.61 and K1.00 but omitted them for the top-level cut experiments because K2.11 is better for top-level cuts.

We used Metis 5.1.0, available from the authors’ website [32], which we denote by M in our tables.

We used InertialFlowCutter with $\langle 4,8,12,16\rangle$ directions and denote the configurations by IFC4, IFC8, IFC12, and IFC16, respectively.

We used our own Inertial Flow implementation with the four directions proposed in [15]. It is available at our repository [28]. Instead of Dinic algorithm [33], we used Ford–Fulkerson, as preliminary experiments indicate it is faster. Furthermore, we filtered source nodes that are only connected to other sources and target nodes that are only connected to other targets. Instead of sorting nodes along a direction, we partitioned the node-array such that the first and last $\alpha ·n$ nodes are the desired terminals, using std::nth_element. These optimizations reduce the running time from 1017 s [14] down to 450 s for a CCH order on Europe. Additionally, we used flow-based interleaving on Inertial Flow. This was already included in the Inertial Flow implementation used in [14]. We denote Inertial Flow by I in our tables.

The original FlowCutter implementation used in [14] is available on GitHub [22]. We used a slightly modified version that has been adjusted to use Intel’s Threading Building Blocks instead of OpenMP for optional parallelism. All parallelism is disabled for FlowCutter in our experiments. We used FlowCutter with $\langle 3,20,100\rangle$ random source-target pairs and denote the variants by F3, F20, and F100, respectively.

Implementations of Buffoon [19] and PUNCH [18] are not publicly available. Therefore, these are not included in our experiments.

We now discuss the different node ordering setups used in the experiments. Metis offers its own node ordering tool ndmetis, which we used. For Inertial Flow, K1.00 and K2.11, we used a nested dissection implementation, which computes one edge cut per level and recurses until components are trees or cliques, which are solved directly. Separators are derived by picking the nodes incident to one side of the edge cut. For comparability with [12,14], we used an older nested dissection implementation for K0.61, which, on every level, repeatedly computes edge cuts until no smaller cut is found for ten consecutive iterations. For InertialFlowCutter and FlowCutter, we employed the setup that was proposed for FlowCutter in [14] that has also been described in Section 2.7. Our nested dissection implementation is based on the implementation in the FlowCutter repository [22]. We made minor changes and parallelized it, as described in Section 2.8.

We tried to employ the special preprocessing techniques for KaHiP 2.11. While this made order computation faster, the order quality was much worse regarding all criteria.

Starting with version 1.00, KaHiP includes a more sophisticated multilevel node separator algorithm [34]. It was omitted from the experiments in [14] because it took 19 hours to compute an order for the small California graph, using one separator per level, and did not finish in reasonable time on the larger instances. Therefore, we still exclude it.

3.4. Order Experiments

In this section, we compare the different partitioners with respect to the quality of computed CCH orders and running time of the preprocessing.

Table 2. Customizable Contraction Hierarchy (CCH) order experiments. The best values (smallest) per metric and graph are highlighted.

		Search Space				CCH		Up.	Running Times
		Nodes		Arcs [$·{10}^3$]		Arcs	#Tri.	Tw.	Order	Cust.	Query
		Avg.	Max.	Avg.	Max.	[$·{10}^6$]	[$·{10}^6$]	Bd.	[s]	[ms]	[$\mathsf{\mu }$s]
Col	M	155.6	354	6.1	22.0	13.7	63.9	102	1.8	58.8	21.1
	K0.61	135.1	357	4.6	21.6	16.7	72.4	103	3837.1	66.4	16.9
	K1.00	136.4	357	4.8	22.1	15.0	69.1	99	1052.4	62.0	17.1
	K2.11	135.1	363	4.7	22.8	14.9	68.4	100	924.6	61.8	16.9
	I	151.3	543	6.2	37.7	15.0	73.9	119	3.0	63.7	20.1
	F3	127.2	277	4.1	14.4	12.8	47.4	85	9.4	46.7	15.8
	F20	122.5	263	3.8	13.8	12.5	43.8	87	55.9	44.3	14.7
	F100	122.3	263	3.8	13.8	12.5	43.7	87	274.5	44.4	14.6
	IFC4	123.2	261	3.9	13.7	12.5	44.1	100	6.9	43.5	14.9
	IFC8	123.3	261	3.9	13.7	12.5	43.9	100	12.9	43.4	14.9
	IFC12	123.1	263	3.9	14.0	12.5	43.6	87	18.7	43.3	14.8
	IFC16	123.1	262	3.9	14.0	12.5	43.5	87	24.3	43.2	14.8
Cal	M	275.5	543	17.3	53.2	65.0	364.1	180	9.8	310.1	47.9
	K0.61	187.7	483	7.0	37.0	74.8	342.4	160	18,659.3	316.4	24.9
	K1.00	184.9	471	6.8	37.9	69.5	334.4	143	6023.6	302.3	24.7
	K2.11	184.8	449	6.8	36.5	69.5	332.4	162	4374.9	300.8	24.7
	I	191.4	605	7.1	53.4	68.8	341.3	161	16.0	301.7	25.4
	F3	178.8	361	6.2	24.9	59.2	235.4	132	57.9	240.2	23.3
	F20	169.6	383	5.6	26.3	58.0	218.5	132	358.5	229.7	21.9
	F100	169.6	386	5.6	26.3	58.0	218.3	132	1759.2	229.9	21.9
	IFC4	170.0	380	5.6	26.2	58.0	217.6	132	42.3	225.1	21.7
	IFC8	169.8	380	5.6	26.2	58.0	217.7	132	79.0	225.1	21.7
	IFC12	169.4	380	5.6	26.2	57.9	217.2	132	115.2	224.8	21.6
	IFC16	170.2	381	5.7	26.2	58.0	218.4	132	151.9	225.8	21.9
Eur	M	1167.3	1914	373.1	765.9	697.4	13,238.1	828	124.6	8302.3	645.3
	K0.61	638.6	1224	114.3	284.1	739.2	5782.5	482	213,091.1	4464.5	229.1
	K1.00	652.5	1279	113.4	286.7	683.3	5745.4	451	242,680.5	4169.7	223.7
	K2.11	652.6	1198	113.5	262.4	683.1	5637.7	449	49,553.1	4125.0	224.1
	I	732.6	1569	149.6	413.6	674.0	5897.3	516	450.3	4177.1	280.0
	F3	743.7	1156	138.1	283.7	602.1	5004.2	493	2227.9	3682.0	262.0
	F20	622.3	1142	106.6	262.1	588.3	4624.1	454	16,130.5	3527.4	211.4
	F100	615.5	1101	103.2	237.2	588.4	4606.6	449	79,176.6	3511.0	206.7
	IFC4	663.0	1087	108.8	246.7	589.3	4644.9	447	1245.7	3506.8	223.1
	IFC8	608.6	1092	102.1	246.7	588.6	4587.1	454	2448.1	3508.5	203.8
	IFC12	611.1	1094	103.3	247.2	588.8	4627.5	454	3608.6	3511.9	205.7
	IFC16	609.5	1092	102.8	246.7	588.7	4616.6	454	4780.2	3505.0	204.2
USA	M	1020.9	1763	273.6	666.7	861.7	12,738.5	733	171.9	7804.3	491.4
	K0.61	575.5	1041	71.3	185.0	979.0	7371.2	366	265,567.3	5449.2	158.4
	K1.00	540.3	1063	62.3	208.1	887.4	6483.3	439	315,942.6	4717.3	135.6
	K2.11	543.7	1015	63.2	190.2	887.4	6454.6	336	68,828.1	4711.4	137.2
	I	533.7	1371	62.0	290.9	887.9	6820.5	384	439.5	4821.1	135.5
	F3	512.0	929	57.5	163.0	758.9	4845.6	332	1813.0	3812.8	126.2
	F20	491.2	861	52.9	154.0	743.4	4425.2	312	11,443.1	3610.6	119.0
	F100	491.1	864	52.8	153.9	743.6	4431.6	311	56,934.7	3608.3	118.5
	IFC4	491.7	865	52.8	153.4	743.1	4421.9	310	1028.4	3608.2	118.4
	IFC8	491.4	859	52.8	153.4	743.0	4423.6	312	2022.9	3606.8	121.7
	IFC12	490.7	865	52.7	153.4	742.8	4409.7	311	2977.3	3599.6	118.1
	IFC16	491.1	860	52.8	153.4	742.9	4421.8	312	3938.5	3592.8	118.2

contains a large collection of metrics and measurements for the four road networks of California, Colorado, Europe, and the USA. Recall that the query time is averaged over ${10}^6$ queries with distinct start and end nodes chosen uniformly at random, the customization time is the median over nine runs. The order computation time is from a single run, since it is infeasible to run certain partitioners multiple times in a reasonable timeframe.

3.4.1. Quality

Over all nodes v, we report the average and maximum number of ancestors in the elimination tree, as well as the number of arcs incident to the ancestors. These metrics assess the search space sizes of an elimination tree query. The query times in Table 2 are correlated with search space size, as expected. The partitioner with the smallest average number of nodes and arcs in the search space always yields the fastest queries. Furthermore, we report the number of arcs in the CCH, i.e., shortcut and original arcs, the number of triangles, and an upper bound on the treewidth, which we obtained using the CCH order as an elimination ordering. A CCH is essentially a chordal supergraph of the input. Thus, CCHs are closely related to tree decompositions and elimination orderings. The relation between tree decompositions and Contraction Hierarchies is further explained in [35]. A low treewidth usually corresponds to good performance with respect to the other metrics. However, as the treewidth is defined by the largest bag in the tree decomposition which may depend on the size of few separators and disregards the size of all smaller separators, this is not always consistent. In the context of shortest path queries, a better average is preferable to a slightly reduced maximum.

On the California and USA road networks, IFC12 yields the fastest queries and smallest average search space sizes, while on Europe IFC8 does. On Colorado, our smallest road network, F100 is slightly ahead of the InertialFlowCutter variants by $0.2$ to $0.3$ microseconds query time. IFC16 yields the fastest customization times for Colorado, Europe, and the USA, while IFC12 yields the fastest customization times for California. Customization times are correlated with the number of triangles. However, for Europe and the USA, the smallest number does not yield the fastest customizations. Even though we take the median of nine runs, this may still be due to random fluctuations.

FlowCutter with at least 20 cutters has slightly worse average search space sizes and query times than InertialFlowCutter for California and the USA but falls behind for Europe. Thus, InertialFlowCutter computes the best CCH orders, with FlowCutter close behind. The different KaHiP variants and Inertial Flow compute the next best orders, while Metis is ranked last by a large margin.

The ratio between maximum and average search space size is most strongly pronounced for Inertial Flow. This indicates that Inertial Flow works well for most separators, but the quality degrades for a few. InertialFlowCutter resolves this problem.

There is an interesting difference in the number of cutters necessary for good CCH orders with InertialFlowCutter and FlowCutter. In [14], F20 is the recommended configuration. The performance differences between F20 and F100 are marginal (except for Europe). However, using just three cutters seems insufficient to get rid of bad random choices.

For the InertialFlowCutter variants, four cutters suffice most of the time. The search space sizes, query times and customization times are very similar. This is also confirmed by the top-level cut experiments in Section 3.5. It seems the Inertial Flow guidance is sufficiently strong to eliminate bad random choices. Again, only for Europe, the queries for IFC4 are slower, which is why we recommend using IFC8. The better query running times justify the twice as long preprocessing.

Europe also stands out when comparing Inertial Flow query performances. For Europe, Inertial Flow only beats Metis, but, for the USA, it beats all KaHiP versions and Metis. The query performance difference of 57 microseconds between Inertial Flow and IFC4 for Europe suggests that the incremental cut computations of InertialFlowCutter make a significant difference and are worth the longer preprocessing times compared to Inertial Flow.

3.4.2. Preprocessing Time

Previously, CCH performance came at the cost of high preprocessing time. We compute better CCH orders than FlowCutter in a much shorter time.

KaHiP 0.61 and KaHiP 1.00 are by far the slowest. KaHiP 2.11 is faster than F100 but slower than F20. All InertialFlowCutter variants are faster than F20. IFC8 and F3 have similar running times. Metis is the fastest by a large margin, and Inertial Flow is the second fastest.

The two old KaHiP versions are slow for different reasons. As already mentioned, K0.61 computes at least 10 cuts, as opposed to K1.00 and K2.11. K1.00 is slow because the running time for top-level cuts with $\epsilon \ge 0.2$ increases unexpectedly, according to [14].

Using 16 cores and IFC8, we compute a CCH order of Europe in just 242 s, with 2258 s sequential running time on the Skylake machine. This corresponds to a speedup of 9.3 over the sequential version. See

Table 3. Running times in seconds of IFC8, using up to 16 cores of the Skylake CPU.

Graph		Cores
		1	2	4	8	16
Col	Time [s]	11.6	6.1	3.3	2.1	1.7
	Speedup	1.0	1.9	3.5	5.5	6.8
Cal	Time [s]	71.5	36.7	19.2	11.3	7.2
	Speedup	1.0	1.9	3.7	6.3	9.9
Eur	Time [s]	2257.8	1160.0	600.7	334.2	241.8
	Speedup	1.0	1.9	3.8	6.8	9.3
USA	Time [s]	1869.5	947.9	497.0	275.5	173.2
	Speedup	1.0	2.0	3.8	6.8	10.8

. Note that, due to using eight cutters, at most eight threads work on a single separator. Therefore, in particular for the top-level separator, at most 8 of the 16 cores are used. The top-level separator alone needs about 50 s using eight cores. Due to unfortunate scheduling and unbalanced separators, it happens also at later stages that a single separator needs to be computed before any further tasks can be created. Using eight cores, we get a much better speedup of 6.8 for Europe; up to four cores, we see an almost perfect speedup for all but the smallest road network. This is because some cutters need less running time than others. Thus, there is actually less potential for parallelism than the number of cutters suggests.

3.5. Pareto Cut Experiments

For the top-level cut experiments, we permute the nodes in preorder from a randomly selected start node, using the same start node for all partitioners. As discussed in Section 2.7, this is part of the recursive calls in the nested dissection implementation from [22]. We include it here to recreate the environment of a nested dissection on the top level.

In

Table 4. Pareto cuts of Colorado.

$max\mathit{\epsilon }$	Achieved $\mathit{\epsilon }$ [%]								Cut Size
	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I
0	0.0	0.0	0.0	0.0	0.0	$\cancel{1.0}$	–	0.0	60	48	48	44	44	$\cancel{35}$	–	259
1	0.4	0.6	0.2	0.8	0.8	1.0	0.0	0.1	47	41	38	28	28	34	37	96
3	2.8	2.8	1.9	0.8	0.8	2.8	0.0	0.7	36	36	36	28	28	33	57	70
5	4.3	4.3	4.3	0.8	0.8	4.4	2.7	0.9	28	28	28	28	28	32	39	60
10	8.9	8.9	8.9	0.8	9.1	8.9	<0.1	1.4	22	22	22	28	22	22	43	46
20	11.6	11.6	11.6	18.8	18.8	18.8	16.7	14.0	20	20	20	19	19	19	230	27
30	27.6	27.6	27.6	27.6	27.6	10.3	<0.1	23.1	14	14	14	14	14	21	44	21
50	40.6	40.6	40.6	40.6	40.6	34.1	44.3	36.4	12	12	12	12	12	13	22	14
70	57.6	57.6	57.6	40.6	57.6	40.6	41.2	48.8	11	11	11	12	11	12	1287	12
90	81.2	89.0	81.2	83.5	87.3	89.4	47.4	81.5	9	6	9	11	8	5	971	9
$\mathbf{max}\mathit{\epsilon }$	Are Sides Connected?								Running Time [s]
	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I
0	•	•	•	•	•	•	–	∘	0.6	0.8	1.2	1.6	10.8	2.1	–	0.1
1	•	•	•	•	•	•	•	∘	0.5	0.7	1.0	1.3	8.5	2.4	0.1	0.1
3	•	•	•	•	•	•	•	∘	0.4	0.6	0.9	1.3	8.5	3.4	0.1	0.1
5	•	•	•	•	•	•	•	∘	0.3	0.5	0.7	1.3	8.5	4.6	0.1	0.1
10	•	•	•	•	•	•	•	∘	0.2	0.4	0.6	1.3	7.1	13.4	0.1	0.1
20	•	•	•	•	•	•	∘	•	0.2	0.4	0.5	0.9	6.4	26.2	0.1	0.1
30	•	•	•	•	•	•	•	•	0.2	0.3	0.4	0.7	5.0	26.7	0.1	0.1
50	•	•	•	•	•	•	•	∘	0.1	0.3	0.3	0.6	4.4	17.8	0.1	0.1
70	•	•	•	•	•	•	∘	•	0.1	0.2	0.3	0.6	4.0	43.7	0.1	0.1
90	•	•	•	•	•	•	∘	•	0.1	0.2	0.3	0.6	3.0	27.7	0.1	0.2

,

Table 5. Pareto cuts of California and Nevada.

$max\mathit{\epsilon }$	Achieved $\mathit{\epsilon }$ [%]								Cut Size
	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I
0	0.0	0.0	0.0	0.0	0.0	$\cancel{1.0}$	–	0.0	57	46	46	80	43	$\cancel{48}$	–	306
1	1.0	1.0	1.0	0.2	0.2	0.2	0.0	0.6	39	35	35	61	31	31	63	93
3	2.3	2.3	2.3	2.4	2.3	2.3	<0.1	1.1	29	29	29	50	29	29	51	64
5	2.3	2.3	2.3	4.3	2.3	2.3	<0.1	1.6	29	29	29	34	29	29	56	62
10	2.3	2.3	2.3	5.3	2.3	2.3	0.3	0.6	29	29	29	29	29	29	44	37
20	16.7	16.7	16.7	5.3	16.7	16.7	<0.1	2.7	28	28	28	29	28	28	47	29
30	16.7	16.7	16.7	5.3	16.7	2.3	<0.1	5.5	28	28	28	29	28	29	50	29
50	42.3	42.3	42.3	5.3	49.1	2.3	33.3	40.8	25	25	25	29	24	29	3118	27
70	42.3	42.3	42.3	67.0	49.1	2.3	41.2	42.6	25	25	25	28	24	29	3343	26
90	85.4	85.4	85.4	90.0	89.8	49.1	47.4	85.6	18	18	18	15	14	24	3040	18
$\mathbf{max}\mathit{\epsilon }$	Are Sides Connected?								Running Time [s]
	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I
0	•	•	•	•	•	•	–	∘	2.5	3.5	5.0	11.8	58.9	10.6	–	0.3
1	•	•	•	•	•	•	•	∘	1.9	3.0	4.3	11.1	49.6	13.0	0.7	0.3
3	•	•	•	•	•	•	•	∘	1.4	2.5	3.5	10.1	47.5	22.7	0.7	0.3
5	•	•	•	•	•	•	•	∘	1.4	2.5	3.5	8.1	47.5	36.8	0.7	0.4
10	•	•	•	•	•	•	•	∘	1.4	2.5	3.5	7.2	47.5	74.5	0.7	0.4
20	•	•	•	•	•	•	•	•	1.4	2.3	3.4	7.2	46.0	104.0	0.7	0.5
30	•	•	•	•	•	•	•	•	1.4	2.3	3.4	7.2	46.0	172.6	0.7	0.6
50	•	•	•	•	•	•	∘	∘	1.2	2.0	2.9	7.2	40.2	210.8	0.7	1.1
70	•	•	•	•	•	•	∘	∘	1.2	2.0	2.9	6.9	40.2	227.6	0.7	1.5
90	•	•	•	•	•	•	∘	•	0.8	1.4	2.1	3.9	23.5	110.5	0.7	1.6

,

Table 6. Pareto cuts of Europe.

$max\mathit{\epsilon }$	Achieved $\mathit{\epsilon }$ [%]								Cut Size
	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I
0	0.0	0.0	0.0	0.0	0.0	$\cancel{1.0}$	–	0.0	311	289	288	273	271	$\cancel{148}$	–	1578
1	1.0	1.0	0.3	0.7	0.3	1.0	<0.1	0.3	274	274	243	246	224	148	393	417
3	3.0	3.0	2.3	0.7	1.3	2.6	<0.1	0.4	259	241	238	246	219	130	434	340
5	4.8	4.8	4.2	4.6	5.0	2.9	<0.1	0.2	226	226	215	211	207	129	452	299
10	9.5	9.5	9.5	9.5	9.5	7.9	<0.1	0.2	188	188	188	188	188	112	468	284
20	9.5	9.5	9.5	9.5	9.5	7.8	<0.1	7.5	188	188	188	188	188	113	403	229
30	9.5	9.5	9.5	9.5	9.5	26.8	<0.1	9.1	188	188	188	188	188	104	463	202
50	49.0	49.0	49.0	9.5	43.7	8.2	33.3	9.5	23	23	23	188	39	111	16,151	188
70	49.0	70.0	49.0	64.5	67.5	32.1	41.2	64.7	23	20	23	58	22	86	23,021	38
90	72.8	72.8	72.8	72.8	72.8	72.8	72.8	72.8	2	2	2	2	2	2	2	2
$\mathbf{max}\mathit{\epsilon }$	Are Sides Connected?								Running Time [s]
	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I
0	•	•	•	•	•	•	–	∘	98.4	183.3	253.0	503.6	3240.0	141.5	–	5.1
1	•	•	•	•	•	•	∘	∘	91.9	179.3	232.1	475.1	2965.1	193.9	8.1	3.9
3	•	•	•	•	•	•	•	∘	89.2	169.0	229.7	475.1	2930.9	352.4	8.1	4.8
5	•	•	•	•	•	•	∘	∘	81.9	162.5	216.3	428.0	2839.4	639.1	8.1	6.4
10	•	•	•	•	•	∘	∘	•	67.1	138.5	192.9	390.1	2647.1	2256.7	8.1	11.2
20	•	•	•	•	•	∘	∘	∘	67.1	138.5	192.9	390.1	2647.1	3618.4	8.1	23.6
30	•	•	•	•	•	∘	∘	•	67.1	138.5	192.9	390.1	2647.1	2406.7	8.1	41.7
50	•	•	•	•	•	∘	∘	•	10.7	16.7	24.1	390.1	613.5	4233.7	8.2	86.5
70	•	•	•	•	•	∘	∘	•	10.7	14.9	24.1	124.1	361.8	3351.5	8.2	23.7
90	•	•	•	•	•	•	•	•	4.3	7.9	11.9	6.5	49.1	3353.0	8.1	4.8

and

Table 7. Pareto cuts of the USA.

$max\mathit{\epsilon }$	Achieved $\mathit{\epsilon }$ [%]								Cut Size
	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I
0	0.0	0.0	0.0	0.0	0.0	$\cancel{0.8}$	–	0.0	115	115	115	115	115	$\cancel{118}$	–	1579
1	0.6	0.6	0.6	0.6	0.6	0.5	0.0	0.4	82	82	82	82	82	94	178	406
3	2.3	2.3	2.3	2.3	2.3	2.4	<0.1	0.1	76	76	76	76	76	73	192	257
5	3.8	3.8	3.8	3.8	3.8	3.8	0.0	0.1	61	61	61	61	61	61	289	186
10	3.8	3.8	3.8	3.8	3.8	3.8	<0.1	3.2	61	61	61	61	61	61	253	81
20	3.8	3.8	3.8	3.8	3.8	3.8	<0.1	3.9	61	61	61	61	61	61	222	61
30	3.8	3.8	3.8	3.8	3.8	3.8	<0.1	3.9	61	61	61	61	61	61	232	61
50	3.8	3.8	3.8	3.8	3.8	3.8	3.7	3.9	61	61	61	61	61	61	242	61
70	69.6	69.6	69.6	69.6	69.6	3.8	41.2	66.5	46	46	46	46	46	61	41,976	61
90	69.6	69.6	69.6	69.6	69.6	69.6	47.4	70.3	46	46	46	46	46	46	45,409	46
$\mathbf{max}\mathit{\epsilon }$	Are Sides Connected?								Running Time [s]
	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I	IFC4	IFC8	IFC12	F3	F20	K2.11	M	I
0	•	•	•	•	•	•	–	∘	60.6	102.0	145.3	246.9	1963.9	179.2	–	6.5
1	•	•	•	•	•	•	•	∘	43.7	81.5	117.4	234.5	1628.9	246.5	10.9	5.1
3	•	•	•	•	•	∘	∘	∘	40.4	75.7	108.2	223.9	1533.5	691.4	10.9	5.5
5	•	•	•	•	•	•	•	∘	31.8	60.2	86.0	198.0	1290.5	1329.8	10.9	6.0
10	•	•	•	•	•	•	•	•	31.8	60.2	86.0	198.0	1290.5	1710.7	10.9	6.2
20	•	•	•	•	•	•	∘	•	31.8	60.2	86.0	198.0	1290.5	2983.5	10.9	9.3
30	•	•	•	•	•	•	•	•	31.8	60.2	86.0	198.0	1290.5	4891.8	10.9	16.6
50	•	•	•	•	•	•	∘	•	31.8	60.2	86.0	198.0	1290.5	5307.4	10.9	32.4
70	•	•	•	•	•	•	∘	•	24.4	44.7	63.2	154.2	985.1	5445.2	11.2	50.9
90	•	•	•	•	•	•	∘	•	24.4	44.7	63.2	154.2	985.1	10,637.7	11.2	61.2

, we report the found cuts for various values of $\epsilon$ for all road networks. We use the partitioners KaHiP 2.11, IFC4, IFC8, IFC12, F3, F20, Metis, and Inertial Flow. We also report the actually achieved imbalance, the running time, and whether the sides of the cut are connected (•) or not (∘). We report $\epsilon =0.0$ only if perfect balance was achieved; otherwise, if the rounded value is $0.0$, we report $<0.1\%$. KaHIP was not able to achieve perfect balance for any of the graphs if perfect balance was desired. We note this by crossing out the respective values. This is due to our use of the KaHiP library interface that does not support enforcing balance. Metis simply rejects $\epsilon =0$, which is why we mark the corresponding entries with a dash. Perfect balance is not actually useful for the application. We solely include it to analyze the different Pareto cuts.

Note that for FlowCutter and InertialFlowCutter, the running time always includes the computation of all more imbalanced cuts, i.e., to generate the full set of cuts, only the running time of the perfectly balanced cut is needed, while for all other partitioners, the sum of all reported running times is needed.

Concerning the performance, Metis wins, but almost all reported cuts are larger than the cuts reported by FlowCutter, InertialFlowCutter, and KaHiP. Inertial Flow is also quite fast but, due to its design, produces cuts that are much more balanced than desired and thus can not achieve as small cuts as the other partitioners.

KaHIP achieves exceptionally small, highly balanced cuts on the Europe road network. On the other road networks, it is similar to or worse than F20 in terms of cut size. This is due to the special geography of the Europe road network. It excludes large parts of Eastern Europe, which is why there is a cut of size 2 and $\epsilon =72.8\%$ imbalance that separates Norway, Sweden, and Finland from the rest of Europe. For $\epsilon =10\%$, KaHiP computes a cut with 112 edges, which separates the European mainland from the Iberian peninsula, Britain, Scandinavia minus Denmark, Italy, and Austria [14]. The Alps separate Italy from the rest of Europe. Britain is only connected via ferries, and the Iberian peninsula is separated from the remaining mainland by the Pyrenees. One side of the cut is not connected because the only ferry between Britain and Scandinavia runs between Britain and Denmark. FlowCutter is unable to find cuts with disconnected sides without a modified initialization. By handpicking terminals for FlowCutter, a similar cut with only 87 edges and $15\%$ imbalance, which places Austria with the mainland instead, is found in [14]. However, it turns out that the FlowCutter CCH order using the 87 edge cut as a top-level separator is not much better than plain FlowCutter. This indicates that it does not matter at what level of recursion the different cuts are found.

For large imbalances, KaHIP seems unable to leverage the additional freedom to achieve the much smaller but more unbalanced cuts, like the ones reported by InertialFlowCutter and FlowCutter. This has already been observed for previous versions of KaHIP [14]. In terms of running time, KaHIP and F20 are the slowest algorithms. InertialFlowCutter is in all three configurations an order of magnitude faster than F20. Up to a maximum $\epsilon$ of $10\%$, the three variants report almost the same cuts. Apart from the very imbalanced $\epsilon =90\%$ cuts, the cuts are also at most one edge worse than F20. Only for more balanced cuts more cutters give a significant improvement. Here, in particular on the Europe road network, F20 is also significantly better than InertialFlowCutter. In the range between $\epsilon =60\%$ and $\epsilon =10\%$, which is most relevant for our application, there is thus no significant difference between F20 and InertialFlowCutter, regardless of the number of cutters. This indicates that on the top level, the first four directions seem to cover most cuts already. On the other hand, for highly balanced cuts, the geographic initialization does not help much, as can be seen from the much worse cuts for InertialFlowCutter. Here, just having more cutters seems to help.

3.6. Parameter Configuration

In this section, we tune the parameters $\alpha ,\delta ,{\gamma }_a,{\gamma }_o$ of InertialFlowCutter. Our goal is to achieve much faster order computation without sacrificing CCH performance. Recall that $\alpha$ is the fraction of nodes initially fixed on each side, $\delta$ is—roughly speaking—a stepsize, ${\gamma }_o$ is the threshold up to how many nodes on a side of the projection we perform bulk piercing, and similarly, ${\gamma }_a$ for how many settled nodes on a side.

Table 8. CCH performance of different parameter configurations of IFC8 on Europe. Bold values are the best in their category. Darker shades indicate better values.

				Search Space				CCH		Up.	Running Times
Configuration				Nodes		Arcs [$·{10}^3$]		Arcs	#Tri.	Tw.	Order	Cust.	Query
$\mathit{\alpha }$	$\mathit{\delta }$	${\mathit{\gamma }}_{\mathit{a}}$	${\mathit{\gamma }}_{\mathit{o}}$	Avg.	Max.	Avg.	Max.	[$·{10}^6$]	[$·{10}^6$]	Bd.	[s]	[ms]	[$\mathsf{\mu }$s]
0.05	0.05	0.3	0.1	610.2	1092	102.8	248.9	588.7	4586.6	454	2933	3388	204.1
0.05	0.05	0.3	0.15	608.6	1093	102.2	248.9	588.6	4578.1	454	2644	3380	203.2
0.05	0.05	0.35	0.15	608.6	1093	102.2	248.9	588.6	4577.8	454	2655	3385	203.2
0.05	0.05	0.3	0.2	610.6	1096	103.0	248.9	588.9	4621.6	454	2505	3400	204.1
0.05	0.05	0.35	0.2	610.5	1098	103.0	246.4	588.9	4620.8	454	2487	3396	203.9
0.05	0.05	0.4	0.2	610.3	1098	102.9	246.7	588.9	4622.2	454	2495	3400	204.4
0.05	0.05	0.3	0.25	610.5	1096	103.0	248.9	588.9	4630.8	454	2476	3404	204.4
0.05	0.05	0.35	0.25	610.6	1092	103.1	246.4	588.9	4629.6	454	2464	3403	204.3
0.05	0.05	0.4	0.25	608.6	1092	102.1	246.7	588.6	4587.1	454	2448	3401	202.9
0.05	0.05	0.35	0.3	610.6	1092	103.0	246.4	588.8	4628.0	454	2457	3396	204.2
0.05	0.05	0.4	0.3	609.5	1092	102.9	246.7	588.7	4625.6	454	2445	3398	203.7
0.05	0.05	0.4	0.35	609.6	1094	102.9	246.7	588.8	4626.7	454	2445	3404	203.9
0.05	0.1	0.3	0.1	610.3	1092	102.9	248.9	588.8	4594.8	454	2904	3391	204.4
0.05	0.1	0.3	0.15	610.7	1116	103.1	248.9	588.8	4603.4	454	2595	3413	204.5
0.05	0.1	0.35	0.15	608.5	1116	102.2	248.9	588.7	4586.1	454	2589	3399	208.2
0.05	0.1	0.3	0.2	612.4	1094	103.8	248.9	588.9	4628.5	454	2508	3402	205.8
0.05	0.1	0.35	0.2	610.1	1093	102.8	246.4	588.8	4611.8	454	2480	3396	203.8
0.05	0.1	0.4	0.2	610.3	1093	102.9	246.7	588.9	4616.6	454	2489	3398	203.9
0.05	0.1	0.3	0.25	612.3	1094	103.7	248.9	588.9	4628.7	454	2516	3400	205.6
0.05	0.1	0.35	0.25	610.1	1099	102.8	246.4	588.8	4610.3	454	2497	3392	204.1
0.05	0.1	0.4	0.25	608.2	1099	102.0	246.7	588.6	4579.1	454	2478	3388	203.4
0.05	0.1	0.35	0.3	610.2	1093	102.9	246.4	588.8	4614.8	454	2489	3396	204.0
0.05	0.1	0.4	0.3	609.5	1093	102.9	246.7	588.8	4622.7	454	2482	3395	203.8
0.05	0.1	0.4	0.35	609.6	1095	102.9	246.7	588.8	4623.1	454	2475	3397	203.6
0.05	0.15	0.3	0.1	610.3	1092	102.9	248.9	588.8	4594.8	454	2906	3396	204.8
0.05	0.15	0.3	0.15	610.7	1116	103.1	248.9	588.8	4603.0	454	2572	3393	204.5
0.05	0.15	0.35	0.15	608.6	1116	102.2	248.9	588.7	4588.0	454	2568	3396	203.1
0.05	0.15	0.3	0.2	612.6	1116	103.8	248.9	589.0	4637.0	454	2523	3407	205.9
0.05	0.15	0.35	0.2	610.3	1114	102.9	246.6	588.9	4617.3	454	2494	3400	204.4
0.05	0.15	0.4	0.2	610.5	1114	102.9	246.7	588.9	4622.6	454	2504	3402	204.5
0.05	0.15	0.3	0.25	612.6	1100	103.8	248.9	589.1	4644.5	454	2521	3406	205.7
0.05	0.15	0.35	0.25	610.3	1100	102.9	246.4	588.9	4619.2	454	2507	3398	203.9
0.05	0.15	0.4	0.25	608.8	1100	102.1	246.7	588.7	4588.6	454	2489	3393	203.1
0.05	0.15	0.35	0.3	610.4	1100	102.9	246.4	588.9	4624.2	454	2506	3401	204.2
0.05	0.15	0.4	0.3	609.6	1100	102.9	246.7	588.8	4626.9	454	2495	3393	203.8
0.05	0.15	0.4	0.35	609.7	1100	102.9	246.7	588.9	4634.3	454	2492	3408	203.9
0.01	0.05	0.4	0.25	609.0	1095	102.4	248.5	588.7	4596.3	454	2817	3387	203.6
0.025	0.05	0.4	0.25	607.6	1095	101.9	248.5	588.6	4585.2	454	2658	3394	203.1
0.075	0.05	0.4	0.25	633.0	1131	110.8	265.8	588.9	4638.9	450	2402	3416	216.1
0.1	0.05	0.4	0.25	641.9	1140	112.7	274.9	589.0	4650.9	451	2182	3417	219.0
0.125	0.05	0.4	0.25	651.5	1118	106.2	263.8	589.1	4618.0	475	1800	3386	211.9
0.15	0.05	0.4	0.25	651.6	1108	106.2	263.3	589.2	4616.1	475	1656	3390	216.6

shows a large variety of tested parameter combinations for InertialFlowCutter with eight directions on the road network of Europe. We selected the parameter set $\alpha =0.05,\delta =0.05,{\gamma }_a=0.4,{\gamma }_o=0.25$ based on query and order computation time. The best entries per column are highlighted in bold. Furthermore, color shades are scaled between values in the columns. Darker shades correspond to lower values, which are better for every measure.

First, we consider the top part of Table 8, where we fix $\alpha$ to $0.05$ and try different combinations of $\delta ,{\gamma }_o,{\gamma }_a$. While the number of triangles and customization times are correlated, the top configurations for these measures are not the same interestingly. The variations in search space sizes, customization time (27 ms), and query time (3 $\mathsf{\mu }$s) are marginal. At the bottom part of Table 8, we try different values of $\alpha$ with the best choices for the other parameters. As expected, larger values for $\alpha$ accelerate order computation and slightly slow down queries. In summary, InertialFlowCutter is relatively robust to parameter choices other than for $\alpha$, which means users do not need to invest much effort on parameter tuning.

4. Discussion

We have presented InertialFlowCutter, an algorithm that exploits geographical information to quickly compute high-quality bipartitions of road networks. Our experiments show that we are able to compute nested dissection orders, as used for CCHs, six times faster than the previous state-of-the-art. Using 16 cores, we can compute a nested dissection order of the Europe road network in four minutes. This makes CCHs even more attractive to be applied in practice.

An open question is how to transfer the ideas of large initial terminal node sets and piercing multiple nodes simultaneously to graphs without geographical information. As FlowCutter also achieved quite good results on general graphs, albeit with slow running times [14], this might be an interesting direction for future research.