PC-DPOP - UTIL Phase

This phase is an adaptation of the UTIL phase from DPOP. It proceeds as in DPOP for normal nodes, and reverts to partial centralization for cluster nodes (i.e. nodes whose separator size exceedsk):

1. theUTILpropagation starts bottom-up and proceeds exactly like in DPOP for normal nodes.

2. cluster nodes perform centralization (see Section8.1.1.1): a cluster node does not compute its

UTILmessage like in DPOP, but sends to its parent aRelationmessage that contains the set of relations (arity at mostk) that the node would have used as an input for computing theUTIL message.

3. Upon receiving such aRelationmessage, a nodeXidoes:

• IfXiis a cluster root, it reconstructs the subproblem from the incomingRelationmessages and then solves it (see Section8.1.1.3). Then it continues theUTILpropagation as in DPOP.

Later on, during the VALUE phase, whenXireceives theVALUEmessage from its parent, it retrieves the solution from its local cache and informs nodes in the cluster of their optimal values via VALUE messages.

• IfXiis a cluster node, it passes on to its parent all the relevant relations (the ones received from its children and its own), that it would otherwise use to compute itsUTILmessage.

For details, see Section8.1.1.1.

8.1.1.1 PC-DPOP - Centralization

Centralization occurs in high-width clusters such asC1, C2, C3in Figure8.1. It is initiated by clus-ter nodes, since they cannot compute and send theirUTILmessages because that would exceed the dimensionality limit imposed byk. Every cluster node packages together into aRelationmessage the union of the relations and UTIL messages received from children, and its own relations with its parent/pseudoparents. The resultingRelationmessage is sent to the parent, as in normal DPOP.

On one hand, this ensures the dimensionality limitkis observed, as no relation with arity larger than kis produced or sent over the network. On the other hand, this allows the cluster root to reconstruct the subproblem that has to be centralized, and enable the use of structure sensitive algorithms like DPOP, AOBB, etc.

Alternatively, to save bandwidth, avoid overload on cluster root nodes, and also improve privacy (see Section8.4), a node can selectively join subsets of its outgoingRelationmessage, s.t. the dimen-sionality of each of the resulting relations is less thank. The resulting set of relations is then packaged as aRelationmessage, and sent to the parent. This happens as follows:

1. nodeXireceives allUTIL/Relationmessages from its children, if any

2. Xiforms the unionUiof all relations in theUTIL/Relationmessages and the relations it has with its parent and pseudoparents

3. Ximatches pairs of relations inUis.t. by joining them the resulting relation will havek dimen-sions or less (the dimensionality of the resulting relation is the union of the dimendimen-sions of the inputs). If the join was successful, remove both inputs fromUi, and add the result instead. Try until no more joins are possible between relations inUi. This process is linear in the size ofUi.

4. The resultingUiset is sent toXi’s parent in aRelationmessage

This process proceeds bottom-up until a cluster root nodeXris reached.Xrthen reconstructs the subproblem from itsRelationmessages, and solves it (see next Section).

The result is that in high-width clusters, the algorithm reverts to partial centralization, by having nodes send to their parents not high dimensionalUTILmessages, but lower arity (aggregated)inputs that could be used to generate thoseUTILmessages.

8.1.1.2 Subproblem reconstruction

Let us assume a cluster root nodeXihas received a set of relationsRCifrom its children. Each relation ri∈RC_iis defined over a set of variables:scope(ri).Xireconstructs the subproblem it has received as follows:

1. Xicreates an internal copy of all the nodes found in the scopes of the relations received.

2. Xicreates a hyper edge for each relationri∈RCi, which connects all variables inscope(ri).

It is interesting to note that this makes it possible for a cluster root to reconstruct the subprob-lemwhile preserving structural information. This is important because it enables the cluster root to use high-performance optimization algorithms that take advantage of problem structure, like for exam-ple [42,8,132,131].

8.1.1.3 Solving centralized subproblems

The centralized solving occurs in the cluster root nodes. In the example of Figure8.1, such a cluster is the shaded area containingX₉, X₁₀, X₁₁, X₁₂, X₁₃.

The root of the cluster (e.g. X9) maintains acache tablethat has as many locations as there are possible assignments for its separator (in this cased^k=d²locations). As a normal node inDPOP, the root also creates a table for the outgoingUTILmessage, with as many dimensions as the size of the separator. Each location in the cache table directly corresponds to a location in theUTILmessage that is associated with a certain instantiation of the separator. The cache table stores the best assignments of the variables in the centralized subproblem that correspond to each instantiation of the separator.

Then the process proceeds as follows:

• for each instantiation ofSepi, the cluster root solves the corresponding centralized subproblem.

The resulting utility and optimal solution are stored in the location of theUTILmessage (cache table location, respectively) that correspond to this instantiation.

Algorithm 16PC-DPOP - partial centralization DPOP.

PC-DPOP(X,D,R, k): each agentXidoes:

runLABEL-DFSprotocol as in Algorithm8→ Xiknows its label UTILpropagation protocol

1 wait forU T IL/Relationmessages from all children

2 iflabel(Xi) = normal nodethen computeU T IL^P_iⁱas in DPOP and send it toPi 3 iflabel(Xi) = cluster nodethen

4 Join subsets of incoming UTIL/Relation and relations with (p)parent with same dimension s.t.

for each join,dim(join)≤k

5 package joins asRelationiand send toPi 6iflabel(Xi) = cluster root nodethen

7 reconstruct subproblem from received relations

8 solve subproblem for eachs∈ Sepiand store utility inU T IL^P_iⁱand solution in local cache

9 sendU T IL^P_iⁱtoPi

VALUEpropagation(XigetsSepi←Sep^∗_i fromPi)

10ifXiis cluster rootthen

11 find in cacheSol^∗that corresponds toSep^∗_i

12 assign self according toSol^∗

13 sendSol^∗to nodes in my cluster via VALUE msgs

14elsecontinue VALUE phase as in DPOP

• when allSepiinstantiations have been tried, theUTILmessage for the parent contains the optimal utilities for each instantiation of the separator (exactly as in DPOP), and the cache table contains the corresponding solutions of the centralized subproblem that yield these optimal utilities.

• the cluster root sends its UTIL message to its parent, and the process continues just like in normal DPOP.