Tackling the Partner Units Configuration Problem

Conference Paper (PDF Available) · July 2011with18 Reads
DOI: 10.5591/978-1-57735-516-8/IJCAI11-091 · Source: DBLP
Conference: IJCAI 2011 - 22nd International Joint Conference on Artificial Intelligence, At Barcelona, Catalonia, Spain
The Partner Units Problem is a specific type of configuration problem with important applications in the area of surveillance and security. In this work we show that a special case of the problem, that is of great interest to our partners in industry, can directly be tackled via a structural problem decompostion method. Combining these theoretical insights with general purpose AI techniques such as constraint satisfaction and SAT solving proves to be particularly effective in practice.


Computing Science
Markus Aschinger, Conrad Drescher, Gerhard Friedrich, Georg Gottlob,
Peter Jeavons, Anna Ryabokon, Evgenij Thorstensen
Oxford University Computing Laboratory
Wolfson Building, Parks Road, Oxford OX1 3QD
Tackling the Partner Units Configuration Problem
Markus Aschinger, Conrad Drescher, Gerhard Friedrich§, Georg Gottlob, Peter
Jeavonsk, Anna Ryabokon∗∗, Evgenij Thorstensen††
The Partner Units Problem is a type of configuration problem, that frequently occurs in in-
dustry. Unfortunately, it can be shown that in the general case (the optimization version of) the
problem is intractable. In this technical report we identify a tractable class of problem instances
that can be solved by a novel algorithm exploiting the notion of a path decomposition. We also
present and evaluate encodings for the general version of the problem in the optimization frame-
works of answer set programming, propositional satisfiability testing, constraint solving, and
integer programming.
Keywords: Configuration, structural decomposition methods, constraint optimisation, SAT solv-
ing, integer programming, answer set programming
Further copies of this Research Report may be obtained from the Librarian, Oxford University Com-
puting Laboratory, Computing Science, Wolfson Building, Parks Road, Oxford OX1 3QD, England (Tele-
phone: +44-1865-273837, Email: library@comlab.ox.ac.uk).
Computing Laboratory, University of Oxford
Computing Laboratory, University of Oxford
§Institut f¨
ur Angewandte Informatik, Alpen-Adria-Universit¨
at Klagenfurt
Computing Laboratory, University of Oxford, Oxford Man Institute of Quantitative Finance
kComputing Laboratory, University of Oxford
∗∗Institut f ¨
ur Angewandte Informatik, Alpen-Adria-Universit¨
at Klagenfurt
††Computing Laboratory, University of Oxford
1 Introduction
The Partner Units Problem (PU P) has recently been proposed as a new benchmark configuration
problem [8]. It captures the essence of a specific type of configuration problem that frequently
occurs in industry.
Informally the PUP can be described as follows: Consider a set of sensors that are grouped
into zones. A zone may contain many sensors, and a sensor may be attached to more than one
zone. The PUP then consists of connecting the sensors and zones to control units, where each
control unit can be connected to the same fixed maximum number UnitCap of zones and sensors.1
Moreover, if a sensor is attached to a zone, but the sensor and the zone are assigned to different
control units, then the two control units in question have to be (directly) connected. However, a
control unit cannot be connected to more than InterUnitCap other control units (the partner units).
For an application scenario consider e.g. a museum where we want to keep track of the num-
ber of visitors that populate certain parts (zones) of the building. To this end the doors leading
from one zone to another are equipped with sensors. To keep track of the visitors the zones and
sensors are attached to control units; the adjacency constraints on the control units ensure that
communication between control units can be kept simple.
It is worth emphasizing that the PU P is not limited to this application domain: It occurs when-
ever sensors that are grouped into zones have to be attached to control units, and communication
between units should be kept simple like e.g. intelligent traffic management, or surveillance and
security applications. The PU P is used as a novel benchmark instance at the 2011 answer set
programming competition [1].
Figure 1 shows a PU P instance and a solution for the case UnitCap =InterUnitCap = 2
six sensors (left) and six zones (right) which are completely inter-connected are partitioned into
units (shown as squares) respecting the adjacency constraints. Note that for the given parameters
this is a maximal solvable instance; it is not possible to connect a new zone or sensor to any of
the existing ones.
In this technical report we will show that the case where InterUnitCap = 2 and UnitCap =k
for some fixed kis tractable by giving a specialized NLOG SPACE algorithm that is based on the
notion of a path decomposition. While already this case is of great importance for our partners in
industry, the general case is quite interesting in its own right: Consider e.g. a grid of rooms, where
every room is accessible from each neighboring room, and all the doors are fitted with a sensor.
Moreover, there are doors to the outside on two sides of the building; the respective instance is
shown in figure 2 with rooms as black squares, and doors as cyan circles. It is not hard to see that
this instance is unsolvable for InterUnitCap = 2 and UnitCap = 2, whereas it is easily solved
for InterUnitCap = 4 and UnitCap = 2: Every room goes on a distinct unit, together with the
sensors to the west and to the north; the connections between units correspond to those between
rooms. Clearly this solution is optimal in the sense of using the least possible number of units.
In this work we hence also present encodings in the optimization frameworks of answer set
programming, constraint satisfaction, SAT-solving, and integer programming that can be used to
solve the general version of the PU P. We also show how to adapt these encodings to the special
case InterUnitCap = 2. For both cases we evaluate the performance.
1For ease of presentation and without loss of generality we assume that UnitCap is the same for zones and sensors.
Figure 1: Solving a K6,6Partner Units Instance — Partitioning Sensors and Zones into Units on
a Circular Unit Layout
Figure 2: A Grid-like PUP Instance
The remainder of this technical report is organized as follows:
In section 2 we give the basic formal definitions, and identify general properties of the PUP.
In section 3 we establish our recent tractability results for the case InterUnitCap = 2.
In section 4 we present problem models in the frameworks of answer set programming,
propositional satisfiability testing, integer programming, and constraint solving. These
problem models can be used for arbitrary values of InterUnitCap, but we also show how
they can be adapted to the special case of InterUnitCap = 2.
In section 5 we evaluate the performance.
In section 6 we conclude.
2 Formal Definition of the Partner Units Problem and Basic Facts
In this section we present the basic formal definitions of the PUP, some basic properties of PU P
instances that affect the existence, shape, or size of solutions, as well as basic complexity results.
2.1 Formal definition
Formally, the PUP consists of partitioning the vertices of a bipartite graph G= (V1,V2,E)into a
set Uof bags such that each bag
contains at most UnitCap vertices from V1and at most UnitCap vertices from V2; and
has at most InterUnitCap adjacent bags, where the bags U1and U2are adjacent whenever
ViU1and VjU2and (Vi, Vj)∈ E.
To every solution of the PUP we can associate a solution graph. For this we associate to every
bag Ui∈ U a vertex VUi. Then the solution graph Ghas the vertex set V1∪ V2∪ {VUi|Ui∈ U }
and the set of edges {(V, VUi)|VUiUi U} ∪ {(VUi, VUj)|Uiand Ujare adjacent.}. In
the following we will refer to the subgraph of the solution graph induced by the vUias the unit
The following are the two most important reasoning tasks for the PUP: Decide whether there
is a solution, and find an optimal solution, that is, one that uses the minimal number of control
units. We are especially interested in the latter problem. For this we consider the corresponding
decision problem: Is there a solution with a specified number of units? The rationale behind the
optimization criterion is that (a) units are expensive, and (b) connections are cheap.
2.2 The Partner Units Problem is Intractable
By a reduction from BIN PACK ING it can be shown that the optimization version of the PUP is
intractable when InterUnitCap = 0, and UnitCap is part of the input. Observe that clearly the
PUP is in NP (cf. also section 4).
Theorem 2.1 (Intractability of the PU OP).The PUOP is NP-complete when InterUnitCap = 0,
and UnitCap is part of the input.
Proof. We reduce from BI NPACKIN G, given as items S1, . . . , Sn, binsize band number of bins k.
We make a PUOP instance by creating for every ia biclique with Sizones and Sisensors, setting
UnitCap =band InterUnitCap = 0. A packing with kof fewer bins exists iff there exists a
solution to the PUO P with kor fewer units. Finally note that BINPACKI NG remains NP-complete
when all the numbers are expressed in unary [9].
Observe that for practical applications the value of UnitCap will not be arbitrary.
2.3 Forbidden Subgraphs of the PUP
It is also not hard to show the following:
Lemma 2.2 (Forbidden Subgraphs of the PU P).APU P instance has no solution if it contains
K1,n or Kn,1as a subgraph, where n= ((InterUnitCap + 1) UnitCap)+1.
Proof. Assume some sensor Shas nneighbors, and is assigned to some unit Uin a solution.
There can be at most InterUnitCap neighbors Unb of U, each with at most UnitCap zones at-
tached. Hence one of the neighbors of Shas to be on a unit different from Uand all of the Unb.
2.4 K-regular Graphs
Next let us discuss the connection between most general solutions to the PU P and k-regular unit
graphs: A graph is k-regular if every vertex has exactly kneighbors. Having k-regular unit graphs
in solutions means that we are exploiting the InterUnitCap capacity for connections between units
to the fullest. In a sense k-regular unit graphs thus are most general solutions.
In the case where k= 2, there is exactly one k-regular graph, the cycle; we exploit this fact in
section 3. In the case where kis odd, k-regular unit graphs only exist if there is an even number
of units (”hand-shaking lemma”). Moreover, for k > 2the number of distinct most general unit
graphs grows rapidly: E.g. for k= 4 there are six distinct graphs on eight vertices, and 8037418
on sixteen vertices; for twenty vertices not all distinct graphs have been constructed [16]. It can
be shown that all these solution topologies can be forced:
Observation 1 (PU P Instances and k-regular Graphs).For every k-regular graph Gkthere exists
aPUP instance Gwith InterUnitCap =ksuch that in every solution of Gthe unit graph is Gk.
Proof. Construct the instance Gas follows:
1) First connect 2UnitCap vertices (i.e. sensors and zones) to each node in Gk. Let the set
of all sensors (zones) be V1(V2).
2) The instance Gcontains all edges (v1, v2), where v1∈ V1and v2∈ V2are connected to
either the same or adjacent nodes in Gk.
We show that every solution is isomorphic to Gk. We consider two cases:
0InterUnitCap 1: The result is immediate.
k > 1: Let U0be a node in Gkwith neighbors, and let Uj: 1 jkbe the neighbors.
Denote by VUi
1and VUi
2the sensors and zones created in Gfor Ui: 0 ik. Let G0
an optimal solution for G. We need to show two things: (1) For each 0ikboth VUi
and VUi
2are on the same unit in G0
k. (2) For 0i<jkif VUi
1∪ VUi
2and VUj
1∪ VUj
are connected in Gthen their units are connected in G0
k. Both (1) and (2) follow from the
following: Consider a path of three units U1, U2, U3. Consider the instance constructed by
applying steps 1) and 2) to this path. Any solution for this instance has three units. Here
we consider only solutions where the unit graphs are paths, say U4, U5, U6. The sensors
and zones originally attached to the middle unit U2have to be on the middle unit U5
otherwise their 2UnitCap neighbors won’t fit. Moreover, the sensors and zones from U1
have to be on the same unit, either U4or U6; the sensors and zones from U3are on the unit
at the other end of the path. With the exception of the cycle of length two, all k-regular unit
graphs are composed from such path segments of length three. As every “end” of a path
segment is the “middle” of another path segment we did not consider cyclic solutions for
the path segments. Conditions (1) and (2) are now easily seen to hold.
Hence, if InterUnitCap >2, and there are no restrictions on the solution topology in the
application domain, then it is practically not feasible to iteratively try all most general solution
topologies. The solution topology will have to be inferred instead.
2.5 An Upper Bound on the Number of Units
In this section we address the question of how many units are necessary (or sufficient, respec-
tively) for finding a solution for a PUP instance G= (V1,V2,E). These bounds are useful in that
they help to limit the depth of iterative deepening search: For finding optimal solutions in most
problem models introduced in the sequel we first try to find a solution with lb units; if that fails
increase lb by one. Clearly this has the effect that the first solution found will be optimal.
Clearly the number of units in a solution is bounded from below by lb =dmax (|V1|,|V2|)
UnitCap e
then at least every unit but one is filled to the maximum. For the upper bound we start with the
simple observation that ub =|V1|+|V2|certainly is always enough — otherwise there would be
empty units in the solution. Next we observe that if there are multiple connected components in
the instance, each with upper bound ubi, then we can safely set ub =Pubi.
Next we are going to show that the stronger upper bound ub = max (|V1|,|V2|)holds if
UnitCap >1and InterUnitCap = 2. The instance depicted in figure 3 shows that this ub does not
hold for UnitCap = 1 and InterUnitCap = 2. It is constructed starting from the solution shown,
using the same construction as in the proof of observation 1. Intuitively, it enforces a “hole” in
the units on the left-hand side that can not be closed without violating one of the partner unit
Proposition 2.3 (Upper Bound for UnitCap >1and InterUnitCap = 2).For a PUP-instance
G= (V1,V2,E)with UnitCap >1and InterUnitCap = 2 there exists a solution if and only if
there exists a solution that uses at most ub = max (|V1|,|V2|)units.
Proof. Let n= max (|V1|,|V2|), i.e. the upper bound to be proved. Assume there is a solution
with m=n+ounits. We need to show that then there are at least opairs of connected units
that can be merged. Without loss of generality we may assume that |V1|=|V2|and UnitCap = 2
— if this does not hold the number of mergeable pairs of units can only be greater. We may
also assume that the solution is cyclic. A pair of adjacent units can be merged if the sum of the
respective sensors and zones respects UnitCap.
We distinguish the five types of solution building blocks depicted in figure 4. Let xidenote the
number of units of type iin the solution. In general we have that m= 3x1+3x2+3x3+2x4+x5.
Figure 3: An instance requiring more than max (|V1|,|V2|)units
In the simplest case the solution contains only Type 4 and Type 5 units, i.e. x4= 2oand x5=
no. Here alternatingly picking edges on the cycle yields bm
2cpairs of units that can be merged.
The maximum number of non-mergeable units is reached for maximum values of x1. W.l.o.g. we
assume that x2=x3=x5= 0, i.e. nomod 3 = 0, and consequently have that x1=no
and x4= 2o. The key observation is that for every ”full” unit we introduce two mergeable units.
The number of ”full” units is given by no
3, and the total number of units that can be blocked
from being mergeable is then given by no
31, i.e. less than the number of units introduced due
to full units.
Figure 4: The different types of solution building-blocks for UnitCap = 2
Note that this upper bound is not tight — by doing a proper case analysis it is certainly
possible to obtain an upper bound that depends on the value of UnitCap, and takes into account
the possibility of merging more than two units at a time.
2.6 Symmetry breaking
If we don’t use iterative deepening search then in some problem models there might be empty
units. Here we can do symmetry breaking by demanding that whenever unit jhas a sensor or
zone assigned to it, then every unit j0< j also has some sensor or zone assigned to it.
We can also rule out a quarter of the connections between sensors (or alternatively, zones)
and units immediately. Consider sensors and units: Sensor 1must be somewhere, so it might as
well be on unit 1. Sensor 2can either be on unit 1or on a new unit, let’s say 2. Unfortunately,
we cannot do the same for zones (or for sensors if we do zones), since the edges may disallow a
zone and a sensor on the same unit.
3 The Case of InterUnitCap = 2
We now turn to the announced special Partner Units Problem where the number of neighbors of
any given unit in a solution is bounded by 2, i.e. InterUnitCap = 2. This version of the PUP
the SPUP—, which is of high industrial relevance, can be tackled directly. We will do this by
giving an algorithm that decides the SPUP in NLOG SPACE by exploiting the notion of a path
decomposition of a given graph.
For ease of presentation in the sequel we make the simplifying assumption that the underlying
bipartite graph is connected. This does not affect solutions of the SPUD P and the SPUS P, where
the connected components can be tackled independently. For optimal solutions, however, the
connected components of an underlying graph will have to be considered simultaneously; cf. the
discussion in section 3.4.
3.1 Path Decompositions
As already stated our algorithm exploits the notion of a path decomposition of a certain width.
We next recall the respective definitions; we assume the reader is familiar with the basic notions
from graph theory.
A path decomposition of a graph G= (V,E)is a pair (P, χ)such that Pis a simple path
— i.e. Pdoes not contain cycles. The function χassociates to every vertex Wof the path Pa
subset B ⊆ V such that
(1) for every vertex Vin Vthere is a vertex Won Pwith Vχ(W);
(2) for every edge (V1, V2)in Ethere is a vertex Wwith {V1, V2} ⊆ χ(w); and
(3) for every vertex Vin Vthe set {W|Vχ(W)}induces a subpath of P.
Condition (3) is called the connectedness condition. The subsets Bassociated with the path
vertices are called bags. The width of a path decomposition is maxW(|χ(W)1|). The pathwidth
pw(G)of a graph is the minimum width over all its path decompositions.
3.2 Basic Properties of the SPUP
We proceed by identifying basic properties of the SPUP. The key observation is that the units
and their interconnections form a special kind of unit graph in any solution: either a simple
path, or a simple cycle. This holds because each unit is connected to at most two partner units.
Moreover, cycles are more general unit graphs than paths: Every solution can be extended to a
cyclic solution; hence in the sequel we only consider cyclic solutions.
Exploiting this observation, we can transform the SPUP into the problem of finding a suitable
path decomposition of the zones-and-sensors-graph G:
Theorem 3.1 (SPUP is Path-Decomposable).Assume a SP UP instance given by a graph G=
(V1,V2,E)is solvable with a solution graph Gwith |U| =n. Let fbe the unit function that
associates vertices from Gto U. Then there is a path decomposition (P, χ)of Gof pathwidth
(3 2UnitCap)1, with the following special properties:
(a) The length of Pis n1;P=W1,...Wn1.
(b) There are sets S1⊆ V1,S2⊆ V2with |Si| ≤ UnitCap such that S1∪ S2are in every bag
of the path decomposition.
(c) Apart from S1∪ S2each bag contains at most 2UnitCap elements from V1(or V2,
(d) For any vertex V∈ V1∪ V2all neighbors of Vappear in three consecutive bags of the
path decomposition (assuming the first and last bag to be connected).
(e) For each bag χ(Wi)of it holds χ(Wi) = f1(U1)f1(Ui)f1(Ui+1)for 1i
(f) S1=f1(U1)∩ V1and S2=f1(U1)∩ V2.
Proof. If Gis solvable then there is a solution Gwhose unit graph is a cycle U1, . . . , Un, U1.
Consider the path decomposition (P=W1, . . . , Wn1, χ)where χ(wi) = f1(U1)f1(Ui)
f1(Ui+1). This is indeed a path decomposition:
Every edge (V1, V2)is in some bag. Assume V1and V2are assigned to two different
connected units Uiand Ui+1. Then {V1, V2} ⊆ χ(Wi).
The connectedness condition is satisfied: For the vertices connected to unit U1the induced
subgraph is P. All other vertices occur in at most two consecutive bags.
Every bag contains (3 2UnitCap)elements; hence pw(G)(3 2UnitCap)1.
An optimal path decomposition of the complete bipartite graph Kn,n with n= 3 UnitCap has
width (3 2UnitCap)1; cf. figure 1. Hence the bound is tight. The conditions (af)are
easily seen to hold for the path decomposition constructed above.
Intuitively, the vertices in the sets S1and S2from condition (b)above are those that close the
cycle (i.e. that are connected to unit U1). These have to be in every bag as some of their neighbors
might only appear on the last unit Un. If all neighbors of S1and S2already appear in U1U2
then we need consider only paths as unit graphs instead of cycles, and the pathwidth is hence
decreased by 2UnitCap.
3.3 An Algorithm for the SPUP
By Theorem 3.1 we know that if a SPUP instance is solvable then there is a path decomposition
with specific properties. But we still need an algorithm for finding such suitable path decompo-
sitions. Many algorithms for finding path decompositions of bounded width have been proposed
in the literature. But, for the SPUP we want to find path decompositions with specific properties:
The paths should be short (the number of bags reflects the number of units); and hence,
The bags should be rather full (in ”good” solutions the units will be filled up).
The construction of the bags must be interleaved with checking the additional constraints.
Below we introduce an algorithm that fits the bill; it is inspired by the algorithm for finding
hypertree decompositions from [12]. This non-deterministic algorithm does the following: The
bags on the path decomposition are guessed. The initial bag partitions the graph into a set of
remaining components that are recursively processed simultaneously. A single bag suffices to
remember which part of the graph has already been processed; the bag separates the processed
part of the graph from the remaining components. Consequently, all we have to store is the
current bag and the remaining components. It turns out that for this we only need logarithmic
space, and thus the algorithm runs in NLO GSPACE, and hence in polynomial time [4].
In addition to the bags the unit function is guessed, too. According to condition (d)from
above all neighbors of any vertex in Goccur in three consecutive bags in the path decomposition.
Hence, for checking locally that the unit function is correct it suffices to remember three bags at
each step.
Due to the different roles played by the units that make up a bag, the DECIDESPUP algorithm
operates at the level of units rather than bags.
1 Guess disjoint non-empty U1, U2⊆ V(G)
with |Ui∩ V1| ≤ UnitCap ≥ |Ui∩ V2|
3if DECIDESPUP (CR,hU1, U2i,hU1, U2i)
4then ACCEPT
5else REJECT
DECIDESPUP(CR,hU1, U2i,hUi1, Uii)
1if CR=
3if VU1nb(V)U1U2Uiand
4then ACCEPT
5else REJECT
7 Guess non-empty Ui+1 ⊆ V(SCR)
with |Ui+1 ∩ V1| ≤ UnitCap ≥ |Ui+1 ∩ V2|
8 For VUicheck nb(V)(Ui1UiUi+1)
R,hU1, U2i,hUi, Ui+1i)
Upon initialization (l. 1–5) the first two units are guessed as subsets of the vertices of the
input G(l. 1). Throughout a run of the algorithm the remaining components are stored in CR(l.
2). We then proceed to the recursive case (l. 3–5).
While recursively processing G(l. 1–10) we consider two cases: (1) If there are no remaining
components (l. 1) we check the termination condition in l. 3. The neighbors of U1have to appear
somewhere on the first, second, or last unit, while the neighbors of the last unit have to appear
somewhere on the second-to-last, last, or first unit. Hence we store U1and U2, as well as a a
“predecessor” unit Ui1and a “middle” unit Uithroughout a run of the algorithm; upon termi-
nation Ui1is the second-to-last, and Uiis the last unit in the cycle. The recursive procedure is
first called with Ui1=U1and Ui=U2, and at each step the contents of the current bag is given
by the union of U1with Ui1Ui. (2) Otherwise, a “successor” unit Ui+1 is guessed (l. 7). In a
solution, all neighbors of vertices assigned to Uiare guaranteed to appear in Ui1UiUi+1
this is checked in l. 8. For Ui1this will already have been established (if i > 2), and hence in
the next step Uiand Ui+1 together with U1are again a proper separator. In l. 9 the vertices just
assigned to Ui+1 are deleted from the remaining components, and in l. 10 the same procedure is
called recursively.
Using this algorithm we can show the following:
Theorem 3.2 (Tractability of SPUD P).The decision problem for the SPU P is solvable by the
algorithm DECIDESPUP in NLOGSPACE for InterUnitCap = 2 and any given fixed value of
Proof. First observe that if the algorithm accepts then there is a solution for the SPU P; moreover,
if there is a solution of the SPU P, this clearly can be guessed. We still have to show that the
workspace required by DECIDES PUP is logarithmic in the size of the input. The size of the
currently retained units is bounded; hence these can be stored in logarithmic space. Moreover,
the currently retained units separate the part of the input graph that has already been processed
from the remaining components. Hence we only have to represent the remaining components.
At each step their number is bounded by 22UnitCap: For the current units Ui1and Ui
there can be at most 2UnitCap neighbors not yet assigned; in the worst case these can all
belong to different connected components. Each of the remaining connected components can be
represented by a single vertex; hence we can get by with logarithmic space.
3.3.1 Answer Extraction
For actually obtaining a solution to a SPUP instance we face the following problem: In general
it is not possible to remember the contents of all the bags in logarithmic space. Theoretically
this problem can be solved as follows: On a first accepting run of DECIDESPU P we clearly can
remember the first bag’s contents in logarithmic space. We can then run DECIDESPU P again with
a fixed first bag, and so forth. Hence the following holds:
Theorem 3.3 (Tractability of SPUS P).The problem of finding a solution to the SPU P is solvable
in NLOGSPACE for InterUnitCap = 2 and any given fixed value of UnitCap.
Note that the problem of answer extraction disappears when actually implementing the non-
deterministic algorithm on a deterministic computer; cf. Section 3.5.
3.3.2 Towards an Efficient Algorithm
We next make a number of observations that can be exploited to turn DECIDESPU P into a prac-
tically efficient algorithm.
Guiding the Guessing Not all zones and sensors assigned to units have to be chosen randomly.
At most UnitCap neighbors of sensors and zones on the first unit can be assigned to the last unit.
Hence the following holds:2
|nbs(U1)\(U1U2)| ≤ UnitCap ≥ |nbz(U1)\(U1U2)|.
Moreover, the neighbors of U1not assigned to U1or U2may only be guessed in the last step,
where the number of unprocessed sensors (or zones) is at most UnitCap.
Starting from i2we have the stronger:
(nbs(Ui)\(UiUi1)) Ui+1 (nbz(Ui)\(UiUi1)).
Finding Optimal Solutions First Next recall that “good” solutions correspond to short path de-
compositions with filled-up bags, and the number of units used in the solution of a SPU P instance
G= (V1,V2,E)is bounded by lb =dmax (|V1|,|V2|)
UnitCap efrom below and by ub = max (|V1|,|V2|)
from above. Hence we can apply iterative deepening search: First, try to find a solution with lb
units; if that fails increase lb by one; hence the first solution found will be optimal. This yields
the following:
Corollary 3.4 (Tractability of SPUO P).On connected input graphs the SPUO P is solvable in
Note that branch-and-bound-search (on the number of units used) can not be used: E.g. a
K6,6graph does not admit solutions with more than three units.
2We denote by nbs(U)(nbz(U)) the set of sensors (zones) that are adjacent in the input graph to zones (sensors)
assigned to U.
Symmetry Breaking We already observed that cycles are more general unit graphs than paths.
But with cycles for unit graphs there are two types of rotational symmetry: For a solution with unit
graph VU1, . . . , VUn, VU1there is (1) a solution VU2, . . . , VUn, VU1, VU2, etc.; in addition there also
is (2) the solution VU1, VUn, VUn1, . . . , VU2, VU1. We can break these symmetries by stipulating
the first sensor is assigned to unit U1; and
the second sensor appears somewhere on the first half of the cycle.
3.4 SPUOP and Multiple Connected Components
Next let us discuss the problem of finding optimal solutions when the input graph consists of more
than one connected component. Here, part of the problem is that any two connected components
may either have to be assigned to the same, or to two distinct unit graph(s). A priori it is unclear
which of the two choices leads to better results. E.g. if we assume that UnitCap = 2 then two
K3,3should be placed on one cyclic unit graph, while a K6,6must stand alone. We leave the
complexity of the SPUOP on arbitrary input graphs as an open problem — but we are able to
show the following:
Theorem 3.5 (Tractability of SPUO P on Multiple Connected Components).For InterUnitCap =
2and any given value of UnitCap the optimization problem for the SPUP on multiple connected
components is solvable in NLO GSPACE if there are only logarithmically many connected com-
ponents in the input graph.
Proof. (Sketch) Let a graph with cconnected components be given as the union Si=1..c Giof
bipartite graphs Gi= (V1,i,V2,i ,Ei). The possible number of unit graphs in optimal solutions
ranges from 1to c. Set V1=SiV1,i and V2=SiV2,i. The number of units used is bounded
by lb =dmax (|V1|,|V2|)
UnitCap efrom below and ub =Pimax (|V1,i|,|V2,i|)from above. For the lower
bound we assume all components fit on a single unit graph; for the upper bound we consider the
cindividual upper bounds separately.
Next observe that also in the case of multiple connected components a solution to the SPUP
gives rise to a path decomposition of a special form: Assume a SPUP instance given by a graph
G=SGiis solvable with a solution graph Gconsisting of mconnected components, and
using nunits in total. By concatenating the path decompositions as constructed in the proof
of Theorem 3.1, we obtain a single path decomposition of length nm. Mutatis mutandis an
appropriate version of Theorem 3.1 is obtained.
Likewise the algorithm DECIDESPU P can be adjusted to guess appropriate path decomposi-
tions: We have to distinguish between remaining components that are currently being processed
and those that are still untouched. The key is then to ensure that a new “cyclic” segment of the
path decomposition may only be started if the set of remaining components that are still currently
being processed is empty; i.e. there are no unassigned neighboring sensors or zones left.
Observe that the total number of remaining connected components at each step is now bounded
by (4 UnitCap) + c, where cis the number of connected components in the input graph. Hence
we stay within the logarithmic space bound if there are not more than logarithmically many con-
nected components in the input graph.
3.5 Implementation
We prototypically implemented the D ECIDESPU P algorithm in Java, replacing the non-determinism
by a backtracking search mechanism. Our implementation can only handle connected input
In [13] a deterministic backtracking version of the non-deterministic hypertree decomposition
algorithm from [12] is described, and the issues we face when making DECIDESPUP determin-
istic are very similar. To avoid repeated sub-computations we store pairs of bags and remaining
components that could not be decomposed:
Observation 2 (Avoidable Sub-Computations).Assume a pair of a bag Band a set of remaining
components CRcould not be decomposed by DECIDESPU P. If the same pair hB, CRioccurs
again on a run of DECIDESP UP it also cannot be decomposed.
If we use iterative deepening search we also have to store the number of remaining units when
encountering a dead-end — it may be possible to decompose the remaining components using
more units. We don’t store successful pairs — the first such pair occurs when finding a solution.
It turns out that for identifying unsuccessful pairs of bags and remaining components it is
enough to store the bag plus the unassigned neighbors:
Lemma 3.6 (Identifying Remaining Components).Given the contents of a bag and the set of
currently unassigned neighbors at any step throughout a run of DECIDESPUP the remaining
components are uniquely determined.
Proof. Assume to the contrary that we have calls
1) DECIDESPUP(CR,hU1, U2i,hUi1, Uii, and
R,hU1, U2i,hUi1, Uii,
both with the same unassigned neighbors V(of U1and Ui).
First assume that we have different remaining connected components CRand C0
Ron the same
set of vertices. This immediately leads to a contradiction.
Next assume that there is a vertex V0CRthat is not in C0
R, and hence not in V. This V0
cannot be part of the current bag B=U1Ui1Uias this is the same in the calls 1) and 2).
Hence assume that, in the run leading to the call 2), V0is assigned to Ujwhere j < (i1). We
know that there is a path V0, V1, . . . , Vnin CRleading from V0to some Vn∈ V such that none of
the Vi,0inis in B. Hence, in the run leading to the call 2), for one of the pairs Vi, Vi+1 the
test nb(Vi)(Uk1UkUk+1)(k < i) must have failed.
As there are only polynomially many possible pairs of current bags and unassigned neighbors,
and each of them is constructed at most once, the overall runtime of our implementation of the
DECIDESPUP algorithm is polynomial, too.
In order to detect no-good branches in the search tree early we implemented a form of two-
step forward-checking: We check whether there is enough space for the open neighbours of the
current unit on the current plus the next unit (step one), and do the same for the open neighbours
of these open neighbours (step two).
Finally observe that for the backtracking search we have to store the choices made, and hence
answer extraction is easy.
4 Standard Models for the General Case
We are next going to outline encodings of the PUP where InterUnitCap is an arbitrary fixed
constant. Due to cost considerations we are especially interested in the optimization version of
the PU P: We want to minimize the number of expensive units used, but do not consider the cost
for the cheap connections between them.
In particular, we show how the problem can be encoded in the frameworks of propositional
satisfiability testing (SAT), integer programming (IP), and constraint solving (CS P), all of which
can be considered as state-of-the-art for optimization problems [14]. In addition we will also
describe an encoding in answer set programming (ASP), a currently very successful knowledge
representation formalism.
4.1 Answer Set Programming
First, we show how to encode the PUP in answer set programming [10, 15] which has its roots
in logic programming and deductive databases. This knowledge representation language is based
on a decidable fragment of first-order logic and is extended with language constructs such as
aggregation and weight constraints. Already the propositional variant allows the formulation of
problems beyond the first level of the polynomial hierarchy. In case standard propositional logic
is employed 3, an answer set corresponds to a minimal logical model by definition of [15].
In our encodings a solution (i.e. a configuration) is the restriction of an answer set to those
literals that satisfy the defined solution schema.
To encode a P UP instance in ASP we represent the zones and sensors by the unary predicates
zone/1and sensor/1. The edges between zones and sensors are represented by the binary
predicate zone2sensor/2. The number of available units lower =lmax(|Sensors|,|Z ones|)
UnitCap m,
unitCap and interUnitCap are each specified by a constant. The PU P is then encoded via the
following logical sentences employing the syntax described in [2]:
(1) unit(1..lower).
(2) 1 {unit2zone(U,Z) : unit(U) }1 :- zone(Z).
(3) 1 {unit2sensor(U,S) : unit(U) }1 :- sensor(S).
(4) :- unit(U), unitCap+1 {unit2zone(U,Z): zone(Z) }.
(5) :- unit(U), unitCap+1 {unit2sensor(U,S): sensor(S) }.
(6) partnerunits(U,P) :- unit2zone(U,Z), zone2sensor(Z,S),
unit2sensor(P,S), U!=P.
(7) partnerunits(U,P) :- partnerunits(P,U), unit(U), unit(P).
(8) :- unit(U), interUnitCap+1 {partnerunits(U,P): unit(P) }.
The first statement unit(1).unit(2). . . . unit(lower).generates the required number of units
represented as facts. The second and the third clause ensure that each zone and sensor is con-
nected to exactly one unit. The edges between units and zones (rsp. sensors) are expressed by
3All literals in rules are negation free. ,,,are used to formulate (disjunctive) rules.
unit2zone/2(rsp. unit2sensor/2) predicates. We use cardinality constraints [20] of the form
l{L1, . . . , Ln}uspecifying that at least lbut at most uliterals of L1, . . . , Lnmust be true. So
called conditions (expressed by the symbol “:”) restrict the instantiation of variables to those val-
ues that satisfy the condition. For example, in the second rule, for any instantiation of variable Z
a collection of ground literals unit2zone(U,Z)is generated where the variable Uis instantiated
to all possible values s.t. unit(U)is true. In this collection at least one and at most one literal
must be true.
The fourth and the fifth rule guarantee that one unit controls at most UnitCap zones and
UnitCap sensors. In these rules the head of the rule is empty which implies a contradiction in
case the body of the rule is fulfilled. The last three rules define the connections between units and
limit the number of partner units to InterUnitCap. Note that rules 4, 5 and 8 can be rephrased by
moving the cardinality constraint on the left-hand-side of the rule and adapting the boundaries.
We used the depicted encoding because it follows the Guess/Check/Optimize pattern formulated
in [15]. Depending on the particular encoding runtimes may vary.
Alternatively, AS P solvers provide built-in support for optimization by restricting the set of
answer sets according to an objective function. For example, for minimizing the number of
units, the upper bound on the number of units used has to be provided as a constant upper =
max(|Zones|,|Sensors|)for the SPU P, or upper =|Z ones|+|Sensors|for the PUP. The
unit generation rule of the original program (line 1) then has to be replaced by:
(1’) unit(1..upper).
(2’) unitUsed(U):- unit2zone(U,Z).
(3’) unitUsed(U):- unit2sensor(U,S).
(4’) lower {unitUsed(X):unit(X) }upper.
(5’) unitUsed(X):- unit(X), unit(Y), unitUsed(Y), X<Y.
(6’) #minimize[unitUsed(X)].
Here, the second and the third rule express the property that a used unit always has to be
non-empty. Rule 4’ states that the number of used units must be between lower and upper.
Rule 5’ expresses an ordering on the units: units with smaller numbers should be used first. This
statement improves the performance of the solver. The last rule expresses that the optimization
criterion is the number of units used in a solution.
4.2 Propositional Satisfiability Testing
We next show how to encode the PU P as a propositional satisfiability problem. We are given
sensors [1, S], zones [1, Z ], and units [1, U], as well as UnitCap and InterUnitCap.
Let suij denote that sensor iis assigned to unit j, and zuij that zone iis assigned to unit j.
First of all, every sensor and zone must belong to a unit, so
suij and 1iZ_
zuij .
Furthermore, every sensor and zone belongs to at most one unit, therefore we have
1iS.1j < j0U. ¬suij ∨ ¬suij0
and the same for zones.
Now we need to count both the number of zones and sensors on a unit, and forbid both
numbers to be above UnitCap. For this we use a sequential counter, similar to the one presented
in [21]. Let scijk mean that unit jhas ksensors assigned (ignore the ifor now). We need to say
that every sensor counts as one,
1iS.1jU. (suij scij1),
and also that we increment this number when we see something new:
sui0jscijk sci0j(k+1)
The fact that we keep track of what we have seen (using index i) is to make sure, for example, that
scij5is only true if there are five distinct sensors on a unit. Finally, we forbid too many sensors
on a unit via
Repeat this trick for zones using zcij k.
Finally, we need to use the edges. Let szij be given, and mean that sensor ihas an edge to
zone j. Also, let uuij mean that units iand jare partnered. We need to define this as
1iS.1jZ.1k < k0U.
((suik zuj k0)(suik0zujk )) szij uukk 0
and also, by symmetry,
1i<jU. (uuij uuj i).
Now we can count the partnered units like we did before, using pcijk , and then forbidding
pcij(y+1). Technically, we don’t need both uuij and uuji, but having both makes the encoding
simpler in the definitions above. We may skip uuii — but we may also leave them in, as the
clauses forcing uuij have i<j, and thus uuii is never forced. Therefore,
1ijU. (uuij pcij1),
1i<i0U.1jU. uui0jpcijk pci0j(k+1).
Finally, we forbid too many partners, and we are done:
4.3 Integer Programming
We next show how the PU P can be encoded into integer programming. If InterUnitCap = 2 we
set |Units|= max(|Sensors|,|Zones|); otherwise it is |Units|=|Sensors|+|Zones|. Then we
make matrices of Boolean variables suij (and zuij , respectively) sensor si(zone zi) is assigned
to unit uj. These matrices are constrained to enforce that each sensor/zone is assigned exactly
one unit, and that no unit is assigned more than UnitCap sensors/zones:
su1,1su2,1su3,1. . . PUnitCap
su1,2su2,2. . . . . . PUnitCap
su1,3. . . . . . . . . PUnitCap
. . . . . . . . . . . . . . .
P= 1 P= 1 . . . . . .
The zone-units matrix looks identical. Next we need a Boolean variable UnitUsedithat in-
dicates whether uiis assigned any sensors/zones. This can be achieved by constraints suji
UnitUsediand zuj i UnitUsedi, for all j. Observe that in principle even for unused units
UnitUsedican be set to one — a possibility that will be excluded by the objective function.
For the constraints on the connections between units it is convenient to increase InterUnitCap
by one, and stipulate that every unit is connected to itself. We then obtain a symmetric matrix of
Boolean uuij variables, which can be used to indicate whether unit iis connected to unit j:
1uu1,2uu1,3. . . PInterUnitCap + 1
uu2,11. . . . . . PInterUnitCap + 1
uu3,1. . . 1. . . PInterUnitCap + 1
In addition to enforcing that InterUnitCap is not exceeded, the entries in this matrix are sub-
ject to the following constraints:
uuij =uuji (symmetry); and
uuij (suki +zul j )1, for all connections (sk, zl)between sensors and zones — if a
sensor skand a zone zlare connected yet assigned different units ui,ujthen these units
are connected.
This model allows more connections between units than are actually needed, in this case
mandating a post-processing step for solutions.
As a last constraint we add that the number of units used is bounded from below:
dmax (|Sensors|,|Zones|)
2e ≤ X
Finally, we add the objective function PjUnitUsedj, subject to minimization. As usual, first
a linear relaxation with cost Cis solved, and only then is the problem solved over the integers,
posting the cost Cas a lower bound.
4.4 Constraint Satisfaction Problem
Finally, we model the PUP as a CSP by letting sensors and zones be variables S={s1, . . . , sn}
and Z={z1, . . . , zm}. For the domains we use (a numbering of) the units U1, . . . , Un.
We post a global cardinality constraint gcc(Ui,[s1, . . . , sn],c)on the sensors for every
Ui, where cis a variable with domain {0,...,UnitCap}, and do likewise for the zones. These
constraints ensure that each unit occurs at most UnitCap times in any assignment to Sand Z.
Tracking connections between units via Boolean variables is done using a matrix of Boolean
uuij variables as in the integer programming model, but using cardinality constraints to count the
number of ones.
In addition for each connection (S, Z)we post implicational constraints that exclude the value
jfrom the domain of sensor sif zis assigned to unit iand uuij = 0 (and vice versa):
(s=Uiuuij = 0) z6=Ujand (z=Uiuuij = 0) s6=Uj
4.5 Adapting the Encodings to InterUnitCap = 2
To some extent ideas developed in the context of the DECIDESPU P algorithm can be incorporated
into the other problem models:
All models allow symmetry breaking as defined in section 3.3 above, assuming a fixed
cyclic layout of the units.
In the ASP-, the SAT- and the CSP-model we can assume a fixed circular layout of the
unit graph because we use iterative deepening search for optimization. We can then post
conditional constraints, for each connection between a sensor Sand a zone Z, stating that
if Sis assigned to unit uithen Zhas to be assigned to one of Ui1,Ui, or Ui+1 (and
vice versa). It is not clear how to express this in the integer programming model without
sacrificing the objective function.
In the CSP model we can do something additional: Via a suitable variable ordering we
can enforce that a unit for a sensor (or a zone) is chosen only if the sensor (the zone) is
connected to an already assigned zone (or sensor). This variable ordering can be computed
e.g. by a simple greedy algorithm.Consequently, the number of choices per zone (or sensor)
is bounded by three throughout the search, instead of NoOfUnits. Both ASP- and SAT-
solvers do not usually provide this level of control to the user.
5 Evaluation
We have evaluated our encodings on a set of benchmark instances that we received from our
partners in industry. All experiments were conducted on a 3 GHz dual core machine with 4
GB RAM running Fedora Linux, release 13 (Goddard). In general in our experiments we have
imposed a ten minute time limit for finding solutions.
For the evaluation of the different encodings of the PUP we use the SAT-solver MINISAT
v2.0 [17], the constraint logic programming language ECLiPSe-Prolog v6.0 [7], and CLINGO
v3.0 [2] from the Potsdam Answer Set Solving Collection (Potassco). For evaluating the integer
programming model we have used CB C v2.6.2 in combination with CLP v1.13.2 from the COIN-
OR project [3], and IBM’s CPLE X v12.1 [5].
In the ASP, SAT and CS P models, as well as in DECIDESPUP, we use iterative deepening
search for finding optimal solutions, as this has proven to be the most efficient. We did not try
this in the integer programming model, as we would lose the objective function in doing so.
The reader is advised to digest the results presented below with caution: We are using both the
SAT and the integer programming solvers out of the box, whereas for the CSP model we employ
the variable ordering heuristics outlined in the previous section. Moreover, if InterUnitCap >2,
for the ASP model we employ the following advanced feature: a portfolio solver CLASPFOLIO,
which is a part of Potassco [2], comes with a machine learning algorithm (support vector ma-
chine) that has been trained on a large set of AS P programs. CLASPFOLIO analyzes a new AS P
program (in our case the PUP program), and configures CLINGO to run with options that have
already proved successful on similar programs. It is likely that such machine learning techniques
could also be developed and fruitfully applied in the other frameworks.
5.1 Experimental Results
InterUnitCap = 2 All instances are based on rectangular floor plans, and all instance graphs
are connected. In all instances there is one zone per room, and by default there are sensors on
all doors. Only the tri-* instances feature external doors. For an illustration see Figure 2, which
shows a rectangular 8×3floor plan with external doors on two sides of the building.
Apart from that, the instances are structured as follows:
dbl-* consist of two rows of rooms with all interior doors equipped with a sensor.
dblv-* are the same, only that there are additional zones that cover the columns.
tri-* are grids with only some of the doors equipped with sensors. There are additional
zones that cover multiple rooms.
The runtimes we obtained for the various problem encodings described above are shown in
seconds in Table 1 (a “*” indicates a timeout). The Cost column contains the number of units in
an optimal solution; a slash “/” in that column indicates that no solution exists.
InterUnitCap >2For the general case we have also tested our encodings on a set of benchmark
instances where InterUnitCap = 4 that we obtained from our partners in industry:
tri-* are exactly as before, only with InterUnitCap = 4.
grid-* are not full grids, but some doors are missing, and there are no rooms (zones) without
5.2 Analysis
Any conclusions drawn from our experimental results have to be qualified by the remark that,
of course, in every solution framework there are many different problem models, and there is no
guarantee that our problem models are the best ones possible.
Table 1: Structured Problems with InterUnitCap =UnitCap = 2
dbl-20 28 20 56 14 0.02 0.48 0.01 0.16 14.12 1.53
dbl-40 58 40 116 29 0.28 2.36 0.05 3.93 224.14 13.58
dbl-60 88 60 176 44 0.42 29.74 0.08 * * 213.58
dbl-80 118 80 236 59 1.14 * 0.16 * * 522.50
dbl-100 148 100 296 74 1.89 * 0.41 * * *
dbl-120 178 120 356 89 3.21 * 0.39 * * *
dbl-140 208 140 416 104 5.01 * 0.59 * * *
dbl-160 238 160 476 119 13.94 * 0.71 * * *
dbl-180 268 180 536 134 20.07 * 0.87 * * *
dbl-200 298 200 596 149 14.4 * 1.08 * * *
dblv-30 28 30 92 15 0.09 0.42 65.49 0.26 37.18 2.93
dblv-60 58 60 192 30 0.26 3.15 * 1.94 * *
dblv-90 88 90 292 45 0.82 12.54 * 27.35 * *
dblv-120 118 120 392 60 1.85 41.65 * 13.92 * *
dblv-150 148 150 492 75 3.48 20.97 * 29.54 * *
dblv-180 178 180 592 90 6.20 44.28 * 54.50 * *
tri-30 40 30 78 20 1.07 0.79 0.50 0.41 45.17 78.75
tri-32 40 32 85 20 0.64 0.74 * 0.26 55.20 4.66
tri-34 40 34 93 / 21.10 22.77 * 0.89 74.78 5.06
tri-60 79 60 156 40 158.49 315.42 114.08 4.40 * 108.01
tri-64 79 64 170 / * 379.36 * 43.88 * 76.26
Let us begin our analysis of the results by highlighting a peculiarity of the PU P: While it
is possible to construct instances that require more than the minimum number of units, it is not
straight-forward to do so, and such instances also appear to be rare in practice: In our experiments
in no solution are there more units than the bare minimum required. It is clear that iterative
deepening search thrives on this fact, whereas the integer programming model suffers.
InterUnitCap = 2 The combination of assuming a fixed cyclic unit graph together with iterative
deepening search resulted in drastic speedups for the ASP, S AT, and CSP solvers. Symmetry
breaking did not have much effect — except on the unsolvable instances.
The AS P and the SAT encoding show broadly similar behavior: Both CLINGO and MINISAT
use variations of the DPLL-procedure [6] for reasoning. Oddly, they even both get faster at some
point as problem size increases on the dblv-* instances. However, CLINGO does significantly
better on the grid-like instances. Interestingly, machine learning did not help for the ASP encod-
ing specialized to InterUnitCap = 2; hence the results shown were obtained using both solvers
out of the box.
For the CS P encoding the variable ordering is the key to the good results: Without the vari-
able ordering the CSP model performs quite poorly. The absence of a similar variable selection
Table 2: Structured Problems with InterUnitCap = 4 and UnitCap = 2
Name |S| |Z|Edges Cost CSP SAT ASP CBC CP LEX
tri-30 40 30 78 20 0.12 2.40 0.40 182.91 24.79
tri-32 40 32 85 20 0.14 1.91 0.66 270.27 20.84
tri-34 40 34 93 20 * 1.98 0.60 331.29 *
tri-60 79 60 156 40 0.52 * 11.07 * *
tri-64 79 64 170 40 * * 7.61 * *
tri-90 118 90 234 59 1.50 401.44 332.34 * *
tri-120 157 120 312 79 3.37 * * * *
grid-1 100 79 194 50 * 78.19 31.45 * *
grid-2 100 77 194 50 * 90.89 18.91 * *
grid-3 100 78 194 50 * 88.87 25.72 * *
grid-4 100 80 194 50 * 95.12 24.66 * *
grid-5 100 76 194 50 * 454.42 48.88 * *
grid-6 100 78 194 50 * 204.85 9.15 * *
grid-7 100 79 194 50 * 112.36 12.89 * *
grid-8 100 78 194 50 * * 11.89 * *
grid-9 100 76 194 50 * 91.62 19.71 * *
grid-10 100 80 194 50 * 545.16 13.54 * *
mechanism from both ASP and SAT in our experiments might explain the surprising superiority
of CS P on most benchmarks.
The inconsistent results for DECIDESPUP are particularly striking. On the one hand, it per-
forms excellently on the dbl-* instances. But in general, it disappoints. Possibly this might be
due to the following: DECIDESPU P has a “local” perspective on the problem, that is, it only can
see the current and past units; the subsequent units are only created at runtime. In all the other
encodings all units are present from the beginning, something which, in one way or another,
facilitates propagating the current variable assignment to other units.
The IPencoding is not yet fully competitive. It particularly struggles with the dblv-* in-
stances. In general, the commercial CPLE X is at least one order of magnitude faster than the open
source CB C.
It is also interesting to compare the dbl-* with the dblv-* instances, as the latter are obtained
from the former by adding constraints. Both C LINGO and MINISAT thrive on the additional
constraints, contrary to ECLiPSe, CB C, CPLE X and DECIDES PUP.
InterUnitCap >2In this setting, for finding solutions the symmetry breaking methods from
section 2.6 did increase computation time for the CSP, the SAT, and the IPmodel. However,
symmetry breaking again does help when proving an instance unsatisfiable. The results in Table 2
were obtained without symmetry breaking.
If CLASPFOLIO’s machine learning database is not used to configure options of CLINGO, then
the two DPLL-based programs again perform quite similar, with Clingo slightly having the edge
(results not shown). With machine learning CLINGO clearly is the winner, with the main benefits
stemming from the following: Use the VSIDS heuristics [18] instead of the BerkMin heuristics
[11], and exploit local restarts [19]. Note that MINISAT also uses the VSIDS heuristics.
Interestingly, the CSP-encoding now disappoints. Given that the same variable ordering is
used, this may have to be attributed to insufficient propagation when tracking the connections
between units.
Again our IPencoding is not on par yet. But for this encoding comparing the instances tri-
30,32,34 in Tables 1 and 2 is particularly instructive: This is basically the same model in both
settings, only that in the latter case there are more variables due to the higher upper bound on the
number of required units.
6 Conclusion
In this work we have advanced the state-of-the-art of the Partner Units Problem, a new hard
configuration problem. We have presented and evaluated encodings of this problem in the frame-
works of answer set programming, constraint solving, integer programming, and satisfiability
testing. We have also evaluated our prototypical implementation of a dedicated algorithm for the
PUP that has recently allowed us to prove the tractability of one class of problem instances that is
of great interest for our partners in industry.
Interestingly, integer programming methods are of no avail for this problem in general. Also,
our prototype implementation of the dedicated algorithm did not perform to our satisfaction. For
the class of problem instances where the number of partner units is limited to two the encoding
of the problem as a CSP in ECLiPSe-Prolog proved to be practically the most efficient. For the
general case the encoding as an ASP in CLINGO is the best that we have.
There is still significant work to be done on the PU P: Almost all interesting complexity ques-
tions are still open. We believe that a thorough investigation of these questions is the prerequisite
for eventually finding better algorithms for the general case of the PUP.
Acknowledgment. Work in Klagenfurt funded by FFG FIT-IT SemSys 825071. Work in Ox-
ford funded by EPSRC Grant EP/G055114/1 ”Constraint Satisfaction for Configuration: Logical
Fundamentals, Algorithms and Complexity”. G. Gottlob’s work, in particular, with respect to
specific topics arising in the context of the co-operation with Siemens Austria and the University
of Klagenfurt, was also partially funded by the FFG FIT-IT project R ECONCILE. G. Gottlob
would also like to acknowledge the Royal Society Wolfson Research Merit Award.
[1] Third International Answer Set Programming Competition 2011.
https://www.mat.unical.it/aspcomp2011/, 2011.
[2] The Potsdam Answer Set Solving Collection.
[3] COIN-OR CLP/CBC IP solver. http://www.coin-or.org/.
[4] S. A. Cook. Characterizations of pushdown machines in terms of time-bounded computers.
Journal of the ACM, 4:4–18, 1971.
[5] IBM ILOG CPLEX IP solver. http://www.ibm.com/.
[6] Martin Davis and Hilary Putnam. A Computing Procedure for Quantification Theory. Jour-
nal of the ACM, 7(3), 1960.
[7] ECLiPSe-Prolog. http://eclipseclp.org/.
[8] A. Falkner, A. Haselb¨
ock, and G. Schenner. Modeling Technical Product Configuration
Problems. In Proceedings of the Workshop on Configuration at ECAI 2010, Lisbon, Portu-
gal, 2010.
[9] M. R. Garey and D. S. Johnson. Computers and Intractability. W. H. Freeman, 1979. p.
[10] Michael Gelfond and Vladimir Lifschitz. The stable model semantics for logic program-
ming. In Proceedings of ICLP’88, 1988.
[11] E. Goldberg and Y. Novikov. BerkMin: A fast and robust SAT-solver. In Proceedings of
DATE’02, 2002.
[12] G. Gottlob, N. Leone, and F. Scarcello. Hypertree Decomposition and Tractable Queries.
Journal of Computer and System Sciences, 64(3):579–627, 2002.
[13] G. Gottlob and M. Samer. A backtracking-based algorithm for hypertree decomposition.
ACM Journal of Experimental Algorithmics, 13, 2008.
[14] J. N. Hooker. Integrated Methods for Optimization. Springer, New York, 2006.
[15] N. Leone, G. Pfeifer, W. Faber, T. Eiter, G. Gottlob, S. Perri, and F. Scarcello. The DLV
system for knowledge representation and reasoning. ACM Transactions on Computational
Logic, 7(3), 2006.
[16] M. Meringer. Regular Graphs Page.
[17] Minisat SAT solver. http://www.minisat.se.
[18] Matthew W. Moskewicz, Conor F. Madigan, Ying Zhao, Lintao Zhang, and Sharad Malik.
Chaff: Engineering an Efficient SAT Solver. In Proceedings of DAC’01, 2001.
[19] Vadim Ryvchin and Ofer Strichman. Local restarts. In Proceedings of SAT’08, 2008.
[20] Patrik Simons, Ilkka Niemel¨
a, and Timo Soininen. Extending and implementing the stable
model semantics. Artificial Intelligence, 138(1-2), 2002.
[21] Carsten Sinz. Towards an Optimal CNF Encoding of Boolean Cardinality Constraints. In
Proceedings of the 11th International Conference on Principles and Practice of Constraint
Programming - CP 2005. Springer, 2005.
    • "A number of PUP heuristics are suggested in the literature (Aschinger et al. 2011b;). We consider the QUICKPUP (Teppan et al. 2012 ) heuristic and its derivatives, since ad hoc algorithms based on them outperform the best off-the-shelf ASP solvers: @BULLET QUICKPUP first generates an order of zones and sensors. "
    [Show abstract] [Hide abstract] ABSTRACT: Answer Set Programming (ASP) is a popular logic programming paradigm that has been applied for solving a variety of complex problems. Among the most challenging real-world applications of ASP are two industrial problems defined by Siemens: the Partner Units Problem (PUP) and the Combined Configuration Problem (CCP). The hardest instances of PUP and CCP are out of reach for state-of-the-art ASP solvers. Experiments show that the performance of ASP solvers could be significantly improved by embedding domain-specific heuristics, but a proper effective integration of such criteria in off-the-shelf ASP implementations is not obvious. In this paper the combination of ASP and domain-specific heuristics is studied with the goal of effectively solving real-world problem instances of PUP and CCP. As a byproduct of this activity, the ASP solver WASP was extended with an interface that eases embedding new external heuristics in the solver. The evaluation shows that our domain-heuristic-driven ASP solver finds solutions for all the real-world instances of PUP and CCP ever provided by Siemens. This paper is under consideration for acceptance in TPLP.
    Full-text · Article · Aug 2016
    • "Factorised representations are a natural fit whenever we deal with a large space of possibilities and can be used to represent, e.g., AND/OR trees used in design specification [5] and world-set decompositions used for incomplete information [1]. They can also be used to compactly represent the space of feasible solutions to configuration problems in constraint satisfaction , where we need to connect a set of components so as to meet an objective while respecting given constraints [2]. The focus of this demonstration is our query engine FDB. "
    [Show abstract] [Hide abstract] ABSTRACT: FDB is an in-memory query engine for factorised databases, which are relational databases that use compact factorised representations at the physical layer to reduce data redundancy and boost query performance. We demonstrate FDB using real data sets from IMDB, DBLP, and the NELL repository of facts learned from Web pages. The users can inspect factorisations as well as plans used by FDB to compute factorised results of select-project-join queries on factorised databases.
    Article · Aug 2012
    • "Formalisms for incomplete information, such as world-set decompositions [4] [17], rely on factorisations of universal relations encoding very large sets of possible worlds; they are products of unions of products of tuples. Outside data management scenarios, factorised relations can be used to compactly represent the space of feasible solutions to configuration problems in constraint satisfaction, where we need to connect a fixed finite set of given components so as to meet a given objective while respecting given constraints [5]. Factorised representations have several key properties that make them appealing in the above mentioned scenarios. "
    [Show abstract] [Hide abstract] ABSTRACT: Factorised databases are relational databases that use compact factorised representations at the physical layer to reduce data redundancy and boost query performance. This paper introduces FDB, an in-memory query engine for select-project-join queries on factorised databases. Key components of FDB are novel algorithms for query optimisation and evaluation that exploit the succinctness brought by data factorisation. Experiments show that for data sets with many-to-many relationships FDB can outperform relational engines by orders of magnitude.
    Article · Mar 2012
Show more