# Tackling the Partner Units Configuration Problem

**Abstract**

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

TACKLING THE PARTNER UNITS CONFIGURATION PROBLEM

Markus Aschinger, Conrad Drescher, Gerhard Friedrich, Georg Gottlob,

Peter Jeavons, Anna Ryabokon, Evgenij Thorstensen

CS-RR-10-28

Oxford University Computing Laboratory

Wolfson Building, Parks Road, Oxford OX1 3QD

Tackling the Partner Units Conﬁguration Problem∗

Markus Aschinger†, Conrad Drescher‡, Gerhard Friedrich§, Georg Gottlob¶, Peter

Jeavonsk, Anna Ryabokon∗∗, Evgenij Thorstensen††

Abstract

The Partner Units Problem is a type of conﬁguration 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 satisﬁability testing, constraint solving, and

integer programming.

Keywords: Conﬁguration, 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 conﬁguration

problem [8]. It captures the essence of a speciﬁc type of conﬁguration 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 ﬁxed 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 trafﬁc 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 ﬁxed 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 ﬁtted with a sensor.

Moreover, there are doors to the outside on two sides of the building; the respective instance is

shown in ﬁgure 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.

1

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 deﬁnitions, 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 satisﬁability 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

2 Formal Deﬁnition of the Partner Units Problem and Basic Facts

In this section we present the basic formal deﬁnitions 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 deﬁnition

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

Vi∈U1and Vj∈U2and (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 G∗has the vertex set V1∪ V2∪ {VUi|Ui∈ U }

and the set of edges {(V, VUi)|V∈Ui∧Ui∈ 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

graph.

The following are the two most important reasoning tasks for the PUP: Decide whether there

is a solution, and ﬁnd 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 speciﬁed 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.

3

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.

Contradiction.

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 2∗UnitCap 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:

•0≤InterUnitCap ≤1: The result is immediate.

•k > 1: Let U0be a node in Gkwith neighbors, and let Uj: 1 ≤j≤kbe the neighbors.

Denote by VUi

1and VUi

2the sensors and zones created in Gfor Ui: 0 ≤i≤k. Let G0

kbe

an optimal solution for G. We need to show two things: (1) For each 0≤i≤kboth VUi

1

and VUi

2are on the same unit in G0

k. (2) For 0≤i<j≤kif VUi

1∪ VUi

2and VUj

1∪ VUj

2

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

4

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 2∗UnitCap neighbors won’t ﬁt. 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 sufﬁcient, respec-

tively) for ﬁnding 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 ﬁnding optimal solutions in most

problem models introduced in the sequel we ﬁrst try to ﬁnd a solution with lb units; if that fails

increase lb by one. Clearly this has the effect that the ﬁrst 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 ﬁlled 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 ﬁgure 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

constraints.

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 ﬁve types of solution building blocks depicted in ﬁgure 4. Let xidenote the

number of units of type iin the solution. In general we have that m= 3x1+3x2+3x3+2x4+x5.

5

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=

n−o. 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. n−omod 3 = 0, and consequently have that x1=n−o

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 n−o

3, and the total number of units that can be blocked

from being mergeable is then given by n−o

3−1, 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

6

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 deﬁnitions; 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.

7

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 ﬁnding 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 G∗with |U| =n. Let fbe the unit function that

associates vertices from Gto U. Then there is a path decomposition (P, χ)of Gof pathwidth

≤(3 ∗2∗UnitCap)−1, with the following special properties:

(a) The length of Pis n−1;P=W1,...Wn−1.

(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 2∗UnitCap elements from V1(or V2,

respectively).

(d) For any vertex V∈ V1∪ V2all neighbors of Vappear in three consecutive bags of the

path decomposition (assuming the ﬁrst and last bag to be connected).

(e) For each bag χ(Wi)of it holds χ(Wi) = f−1(U1)∪f−1(Ui)∪f−1(Ui+1)for 1≤i≤

n−1.

(f) S1=f−1(U1)∩ V1and S2=f−1(U1)∩ V2.

Proof. If Gis solvable then there is a solution G∗whose unit graph is a cycle U1, . . . , Un, U1.

Consider the path decomposition (P=W1, . . . , Wn−1, χ)where χ(wi) = f−1(U1)∪f−1(Ui)∪

f−1(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 satisﬁed: 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 ∗2∗UnitCap)elements; hence pw(G)≤(3 ∗2∗UnitCap)−1.

An optimal path decomposition of the complete bipartite graph Kn,n with n= 3 ∗UnitCap has

width (3 ∗2∗UnitCap)−1; cf. ﬁgure 1. Hence the bound is tight. The conditions (a−f)are

easily seen to hold for the path decomposition constructed above.

8

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 U1∪U2

then we need consider only paths as unit graphs instead of cycles, and the pathwidth is hence

decreased by 2∗UnitCap.

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 speciﬁc properties. But we still need an algorithm for ﬁnding such suitable path decompo-

sitions. Many algorithms for ﬁnding path decompositions of bounded width have been proposed

in the literature. But, for the SPUP we want to ﬁnd path decompositions with speciﬁc properties:

•The paths should be short (the number of bags reﬂects the number of units); and hence,

•The bags should be rather full (in ”good” solutions the units will be ﬁlled up).

•The construction of the bags must be interleaved with checking the additional constraints.

Below we introduce an algorithm that ﬁts the bill; it is inspired by the algorithm for ﬁnding

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 sufﬁces 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 sufﬁces 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.

DECIDESPUP(G)

1 Guess disjoint non-empty U1, U2⊆ V(G)

with |Ui∩ V1| ≤ UnitCap ≥ |Ui∩ V2|

2CR←G\(U1∪U2)

3if DECIDESPUP (CR,hU1, U2i,hU1, U2i)

4then ACCEPT

5else REJECT

9

DECIDESPUP(CR,hU1, U2i,hUi−1, Uii)

1if CR=∅

2then

3if ∀V∈U1nb(V)⊆U1∪U2∪Uiand

∀V∈Uinb(V)⊆Ui−1∪Ui∪U1

4then ACCEPT

5else REJECT

6else

7 Guess non-empty Ui+1 ⊆ V(SCR)

with |Ui+1 ∩ V1| ≤ UnitCap ≥ |Ui+1 ∩ V2|

8 For V∈Uicheck nb(V)⊆(Ui−1∪Ui∪Ui+1)

9C0

R←(CR\Ui+1)

10 DECIDESPUP (C0

R,hU1, U2i,hUi, Ui+1i)

Upon initialization (l. 1–5) the ﬁrst 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 ﬁrst, second, or last unit, while the neighbors of the last unit have to appear

somewhere on the second-to-last, last, or ﬁrst unit. Hence we store U1and U2, as well as a a

“predecessor” unit Ui−1and a “middle” unit Uithroughout a run of the algorithm; upon termi-

nation Ui−1is the second-to-last, and Uiis the last unit in the cycle. The recursive procedure is

ﬁrst called with Ui−1=U1and Ui=U2, and at each step the contents of the current bag is given

by the union of U1with Ui−1∪Ui. (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 Ui−1∪Ui∪Ui+1 —

this is checked in l. 8. For Ui−1this 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 ﬁxed value of

UnitCap.

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 2∗2∗UnitCap: For the current units Ui−1and Ui

there can be at most 2∗UnitCap neighbors not yet assigned; in the worst case these can all

10

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 ﬁrst accepting run of DECIDESPU P we clearly can

remember the ﬁrst bag’s contents in logarithmic space. We can then run DECIDESPU P again with

a ﬁxed ﬁrst bag, and so forth. Hence the following holds:

Theorem 3.3 (Tractability of SPUS P).The problem of ﬁnding a solution to the SPU P is solvable

in NLOGSPACE for InterUnitCap = 2 and any given ﬁxed 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 Efﬁcient Algorithm

We next make a number of observations that can be exploited to turn DECIDESPU P into a prac-

tically efﬁcient 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 ﬁrst unit can be assigned to the last unit.

Hence the following holds:2

|nbs(U1)\(U1∪U2)| ≤ UnitCap ≥ |nbz(U1)\(U1∪U2)|.

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 i≥2we have the stronger:

(nbs(Ui)\(Ui∪Ui−1)) ⊆Ui+1 ⊇(nbz(Ui)\(Ui∪Ui−1)).

Finding Optimal Solutions First Next recall that “good” solutions correspond to short path de-

compositions with ﬁlled-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 ﬁnd a solution with lb

units; if that fails increase lb by one; hence the ﬁrst 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

NLOGSPACE.

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.

11

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, VUn−1, . . . , VU2, VU1. We can break these symmetries by stipulating

that

•the ﬁrst sensor is assigned to unit U1; and

•the second sensor appears somewhere on the ﬁrst half of the cycle.

3.4 SPUOP and Multiple Connected Components

Next let us discuss the problem of ﬁnding 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 ﬁt 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 G∗consisting 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 n−m. 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.

12

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

graphs.

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 ﬁrst such pair occurs when ﬁnding 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,hUi−1, Uii, and

2) DECIDESPUP(C0

R,hU1, U2i,hUi−1, 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 V0∈CRthat is not in C0

R, and hence not in V. This V0

cannot be part of the current bag B=U1∪Ui−1∪Uias 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 < (i−1). We

know that there is a path V0, V1, . . . , Vnin CRleading from V0to some Vn∈ V such that none of

the Vi,0≤i≤nis in B. Hence, in the run leading to the call 2), for one of the pairs Vi, Vi+1 the

test nb(Vi)⊆(Uk−1∪Uk∪Uk+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).

13

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 ﬁxed

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

satisﬁability 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 ﬁrst-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 ﬁrst level of the polynomial hierarchy. In case standard propositional logic

is employed 3, an answer set corresponds to a minimal logical model by deﬁnition of [15].

In our encodings a solution (i.e. a conﬁguration) is the restriction of an answer set to those

literals that satisfy the deﬁned 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 speciﬁed 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 ﬁrst 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.

14

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 ﬁfth 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 fulﬁlled. The last three rules deﬁne 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 ﬁrst. 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 Satisﬁability Testing

We next show how to encode the PU P as a propositional satisﬁability 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

∀1≤i≤S_

1≤j≤U

suij and ∀1≤i≤Z_

1≤j≤U

zuij .

Furthermore, every sensor and zone belongs to at most one unit, therefore we have

∀1≤i≤S.∀1≤j < j0≤U. ¬suij ∨ ¬suij0

15

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,

∀1≤i≤S.∀1≤j≤U. (suij →scij1),

and also that we increment this number when we see something new:

∀1≤i<i0≤S.∀1≤j≤U.∀1≤k≤UnitCap.

sui0j∧scijk →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 ﬁve distinct sensors on a unit. Finally, we forbid too many sensors

on a unit via

∀1≤i≤S.∀1≤j≤U.¬scij(UnitCap+1).

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 deﬁne this as

∀1≤i≤S.∀1≤j≤Z.∀1≤k < k0≤U.

((suik ∧zuj k0)∨(suik0∧zujk )) ∧szij →uukk 0

and also, by symmetry,

∀1≤i<j≤U. (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 deﬁnitions 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,

∀1≤i≤j≤U. (uuij →pcij1),

and

∀1≤i<i0≤U.∀1≤j≤U. uui0j∧pcijk →pci0j(k+1).

Finally, we forbid too many partners, and we are done:

∀1≤i≤j≤U.¬pcij(InterUnitCap+1).

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

16

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. . . P≤UnitCap

su1,2su2,2. . . . . . P≤UnitCap

su1,3. . . . . . . . . P≤UnitCap

. . . . . . . . . . . . . . .

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. . . P≤InterUnitCap + 1

uu2,11. . . . . . P≤InterUnitCap + 1

uu3,1. . . 1. . . P≤InterUnitCap + 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

j

UnitUsedj.

Finally, we add the objective function PjUnitUsedj, subject to minimization. As usual, ﬁrst

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.

17

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=Ui∧uuij = 0) →z6=Ujand (z=Ui∧uuij = 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 deﬁned in section 3.3 above, assuming a ﬁxed

cyclic layout of the units.

•In the ASP-, the SAT- and the CSP-model we can assume a ﬁxed 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 Ui−1,Ui, or Ui+1 (and

vice versa). It is not clear how to express this in the integer programming model without

sacriﬁcing 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 ﬁnding 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].

18

In the ASP, SAT and CS P models, as well as in DECIDESPUP, we use iterative deepening

search for ﬁnding optimal solutions, as this has proven to be the most efﬁcient. 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 conﬁgures 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 ﬂoor 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×3ﬂoor 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

doors.

5.2 Analysis

Any conclusions drawn from our experimental results have to be qualiﬁed 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.

19

Table 1: Structured Problems with InterUnitCap =UnitCap = 2

Name |S| |Z|Edges Cost CS P SAT DECIDESPUP AS P CBC CPL EX

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 ﬁxed 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 signiﬁcantly

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

20

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 ﬁnding 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 unsatisﬁable. The results in Table 2

were obtained without symmetry breaking.

If CLASPFOLIO’s machine learning database is not used to conﬁgure 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 beneﬁts

21

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 insufﬁcient 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

conﬁguration problem. We have presented and evaluated encodings of this problem in the frame-

works of answer set programming, constraint solving, integer programming, and satisﬁability

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 efﬁcient. For the

general case the encoding as an ASP in CLINGO is the best that we have.

There is still signiﬁcant 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 ﬁnding 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 Conﬁguration: Logical

Fundamentals, Algorithms and Complexity”. G. Gottlob’s work, in particular, with respect to

speciﬁc 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.

References

[1] Third International Answer Set Programming Competition 2011.

https://www.mat.unical.it/aspcomp2011/, 2011.

[2] The Potsdam Answer Set Solving Collection.

http://potassco.sourceforge.net/.

[3] COIN-OR CLP/CBC IP solver. http://www.coin-or.org/.

22

[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 Quantiﬁcation 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 Conﬁguration

Problems. In Proceedings of the Workshop on Conﬁguration at ECAI 2010, Lisbon, Portu-

gal, 2010.

[9] M. R. Garey and D. S. Johnson. Computers and Intractability. W. H. Freeman, 1979. p.

226.

[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.

http://www.mathe2.uni-bayreuth.de/markus/reggraphs.html.

[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 Efﬁcient 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. Artiﬁcial 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.

23

- CitationsCitations15
- ReferencesReferences19

- "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.- "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.- "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.

Data provided are for informational purposes only. Although carefully collected, accuracy cannot be guaranteed. Publisher conditions are provided by RoMEO. Differing provisions from the publisher's actual policy or licence agreement may be applicable.

This publication is from a journal that may support self archiving.

Learn more