Choco-Graph : a module for graph variables in the Choco CP solver

Transcription

1 Choco-Graph : a module for graph variables in the Choco CP solver Jean-Guillaume Fages Charles Prud homme Xavier Lorca September 16, 2014 Contents 1 Overview 2 2 Defining a graph variable Graphs Backtrackable graphs Graph variable Constraining a graph variable Usual graph constraints Node and edge counts Loops Degrees Graph inclusion Symmetry Transitivity Cycles Connectivity Tree Cliques Diameter Some optimization constraints The TSP constraint Channeling constraints Set channeling Boolean channeling Integer channeling Implementing your own constraint A simple and non-incremental propagators Incremental propagators Search Variable selection Branching on a graph variable Large Neighborhood Search Practical examples Large scale Hamiltonian cycle : The Knight s Tour Problem Solving the Traveling Salesman Problem Finding a Directed Acyclic (sub)graph How to contribute? 27 ChocoTeam, choco3-support@mines-nantes.fr, TASC research team 1

2 1 Overview This Choco module allows you to search for a graph 1, which may be subject to constraints. The domain of a graph variable G is a graph interval [G, G]. G is the graph representing vertices and edges which must belong to any single solution whereas G is the graph representing vertices and edges which may belong to one solution. Therefore, any value G must satisfy the graph inclusion G G G. One may see a strong connection with set variables. A graph variable can be subject to graph constraints to ensure global graph properties (e.g. connectedness, acyclicity) and channeling constraints to link the graph variable with some other binary, integer or set variables. The solving process consists of removing nodes and edges from G and adding some others to G until having G = G, i.e. until G gets instantiated. These operations stem from both constraint propagation and search. You may wonder why using a graph variable. Here are the most important motivations to do so: Modeling convenience : When solving a graph problem, the model is close to the original problem. A graph variable is a consistent graph representation (e.g. a node which does not exist has no incident arcs), which simplifies the model. Stating constraints as graph properties in a declarative way is nice. Implementation convenience : Manipulating a domain which consists of two graphs (representing respectively mandatory and potential elements) makes easy the implementation of graph-based filtering algorithms. As the implementation becomes more natural, the risk of mistakes decreases. Performance gains : You can use optimized data structure for domains (e.g. bit sets, bipartite sets, linked lists...) which allow to reduce runtime of most algorithms and/or memory consumption. This brings significant improvement on large scale problems. Having such a global variable instead of many smaller ones makes the solver lighter, which brings performance improvement. This module can be seen as a CP framework for graph theory. In that sense, it is closer to Operations Research than Artificial Intelligence. With a minimum background in graph algorithms, this manual will help you to build your own models, constraints and search procedures so that you effectively solve your problems. This module has been introduced in 2011 but it has been deeply refactored in September In case some bugs have been introduced during that step, please inform us. 1 Either directed or undirected, with at most one arc/edge between any two vertices. 2

3 2 Defining a graph variable Prior to introduce how to build graph variables, it is necessary to describe graph structures of the core Choco solver. These graphs are often used as internal data structures for propagators. In our case, it will serve to define the domain of graph variables. 2.1 Graphs There are basically two kind of graphs in Choco : directed (DirectedGraph.java) and undirected (UndirectedGraph.java) graphs. Directed and undirected graphs have similar methods. The constructor of an undirected graph is the following: p u b l i c U n d i r e c t e d G r a p h ( i n t n, SetType type, b o o l e a n a l l N o d e s ) The integer n denotes the maximum number of nodes. This is necessary for memory allocation. The set of nodes is then a subset of {0, 1,..., n 1. Once the graph has been created, it is not possible to modify that value. SetType type indicates which kind of data structure to use. If the graph is very sparse, a linked list (SetType.LINKED_LIST) implementation would reduce the memory consumption. Otherwise, SetType.BIPARTITESET provides an optimal time complexity for every request, but has some hidden constants and a higher memory consumption. SetType.BITSET is a good default choice. The boolean allnodes indicates whether or not the node set is fixed. This parameter is very important. Whenever set to true, it means that the vertex set is [0, n 1] and will not change during search. It is not necessary to add vertices explicitly (all of them are present). If set to false, it means that the vertex set must be a subset of [0, n 1], and is initially EMPTY. Therefore, the user may have to add them explicitly by using the addnode(int i) method. Graph manipulations (iterations over nodes, edges, neighbors of a particular vertex...) rely on the choco ISet interface. I S e t nodes = graph. getnodes ( ) ; f o r ( i n t i = nodes. g e t F i r s t E l e m e n t ( ) ; i >=0; i = nodes. g e t N e x t E l e m e n t ( ) ) Note that for efficiency reason iteration of one ISet is not context safe, i.e. you cannot encapsulate two iteration loops of the same set (copy the set in an int[] for doing that). 2.2 Backtrackable graphs As we wish to use graphs to represent the domain of a variable, such graphs must be backtrackable, i.e. the graph must restore its previous value upon backtracking. To do so, one simply use a different constructor, having the solver in argument (to catch backtrack events): p u b l i c U n d i r e c t e d G r a p h ( S o l v e r s o l v e r, i n t n, SetType type, b o o l e a n a l l N o d e s ) 3

4 2.3 Graph variable Graph variables can be created through GraphVarFactory.java. The domain of such a variable is defined by two graphs : the lower bound graph gives nodes and arcs that belong to every solution, whereas the upper bound graph gives nodes and arcs that may belong to a solution. / * * * C r e a t e an u n d i r e c t e d graph v a r i a b l e named NAME * and whose domain i s t h e graph i n t e r v a l [LB,UB] * BEWARE: LB and UB g r a p h s must be b a c k t r a c k a b l e * ( use t h e s o l v e r as an argument i n t h e i r c o n s t r u c t o r )! * NAME Name of t h e v a r i a b l e LB U n d i r e c t e d graph r e p r e s e n t i n g mandatory nodes and edges UB U n d i r e c t e d graph r e p r e s e n t i n g p o s s i b l e nodes and edges SOLVER S o l v e r of t h e v a r i a b l e An u n d i r e c t e d graph v a r i a b l e * / p u b l i c s t a t i c I U n d i r e c t e d G r a p h V a r u n d i r e c t e d _ g r a p h _ v a r ( S t r i n g NAME, U n d i r e c t e d G r a p h LB, U n d i r e c t e d G r a p h UB, S o l v e r SOLVER) { return new UndirectedGraphVar (NAME, SOLVER, LB, UB ) ; / * * * C r e a t e a d i r e c t e d graph v a r i a b l e named NAME * and whose domain i s t h e graph i n t e r v a l [LB,UB] * BEWARE: LB and UB g r a p h s must be b a c k t r a c k a b l e * ( use t h e s o l v e r as an argument i n t h e i r c o n s t r u c t o r )! * NAME Name of t h e v a r i a b l e LB D i r e c t e d graph r e p r e s e n t i n g mandatory nodes and edges UB D i r e c t e d graph r e p r e s e n t i n g p o s s i b l e nodes and edges SOLVER S o l v e r of t h e v a r i a b l e An u n d i r e c t e d graph v a r i a b l e * / p u b l i c s t a t i c I D i r e c t e d G r a p h V a r d i r e c t e d _ g r a p h _ v a r ( S t r i n g NAME, D i r e c t e d G r a p h LB, D i r e c t e d G r a p h UB, S o l v e r SOLVER) { return new D i r e c t e d G r a p h V a r (NAME, SOLVER, LB, UB ) ; Note the the bound graphs must be able to restore their value upon backtracking. Therefore, you should use the following signatures: new UndirectedGraph ( Solver s o l v e r, i n t n, SetType type, boolean allnodes ) new DirectedGraph ( Solver s o l v e r, i n t n, SetType type, boolean allnodes ) The input maximum number of nodes should be the same for both the lower and the upper bound graphs. Here is an example involving an undirected graph variable: / / graph v a r i a b l e domain U n d i r e c t e d G r a p h GLB = new U n d i r e c t e d G r a p h ( s o l v e r, / / R e s t o r e v a l u e on b a c k t r a c k n, / / Maximal number of nodes SetType. BITSET, / / d a t a s t r u c t u r e t y p e f a l s e / / f i x e d node s e t? ) ; U n d i r e c t e d G r a p h GUB = new U n d i r e c t e d G r a p h ( s o l v e r, / / R e s t o r e v a l u e on b a c k t r a c k 4

5 n, / / Maximal number of nodes SetType. BITSET, / / d a t a s t r u c t u r e t y p e f a l s e / / f i x e d node s e t? ) ; f o r ( i n t i = 0 ; i < n ; i ++) { GUB. addnode ( i ) ; / / p o t e n t i a l node f o r ( i n t j = i ; j < n ; j ++) { i f ( l i n k [ i ] [ j ] ) { / / some i n p u t d a t a p r o v i d i n g p o t e n t i a l edges GUB. addedge ( i, j ) ; / / p o t e n t i a l edge GLB. addnode ( 1 ) ; / / 1 and 2 must b e l o n g t o t h e s o l u t i o n GLB. addnode ( 2 ) ; GLB. addedge ( 1, 2 ) ; / / 1 and 2 must b e l o n g t o t h e same c l i q u e / / graph v a r i a b l e g r a p h v a r = GraphVarFactory. u n d i r e c t e d _ g r a p h _ v a r ( "G", GLB, GUB, s o l v e r ) ; In this example, we see that vertices 1 and 2 must belong to every solution, as well as the edge (1, 2). Other potential vertices and edges are given by GUB. For simplicity reasons, one may prefer to use the following method, which creates an empty lower bound graph and a complete upper bound graph with 42 vertices: GraphVarFactory. u n d i r e c t e d _ g r a p h _ v a r ( "G", 4 2, s o l v e r ) ; 5

6 3 Constraining a graph variable A collection of constraints over a graph variable can be found in GraphConstraintFactory.java. The name is explicit but a bit long. You can either import it statically or use GCF.java as a shortcut. 3.1 Usual graph constraints Node and edge counts The factory contains several basic constraints, such as nb_nodes, which enables to constrain the number of nodes to be equal to a given integer variable. To make things simpler, you can call the GraphVarFactory.nb_nodes(g) function which will create and return an integer variable that is equal to the number of nodes (i.e. it posts the nb_nodes constraint). In the same way, one can count the number of edge (resp. arc) of an undirected (resp. directed) graph variable as follows: IntVar nbarcs = GraphVarFactory. nb_ arcs ( g ) ; Loops Graph variables may contain loops, i.e. arcs of the from (i, i). If you want the graph to contain no loops, then you should simply make sure the graph upper bound has initially no loop. Instead, if you wish some vertices to have a loop, then you can use the loop_set(g,l) constraint which ensures that the set variable l represents the nodes of g that have a loop. You can also directly create that set variable using: SetVar l o o p s = GraphVarFactory. l o o p _ s e t ( g r a p h v a r ) ; Finally, you can control the number of loops the graph variable has with an integer variable with the following : IntVar nbloops = GraphVarFactory. nb_ loops ( g ) ; Degrees It is possible to constrain the minimum and the maximum degree each node of an undirected graph variable, by using respectively min_degrees and max_degrees constraints. Such constraints only hold on vertices that belong to the solution. For instance, if vertex a is constrained to have a degree greater than 5 but has only 4 potential neighbors, then vertex a should be removed from the potential vertex set. Unless a was a mandatory vertex, this does not trigger any failure. Here is an example imposing every vertex to have at most 5 neighbors: s o l v e r. p o s t ( G r a p h C o n s t r a i n t F a c t o r y. max_degrees ( graph, 5 ) ) ; It is also possible to constrain the exact degree of every node with an integer variable, thanks to the degrees constraint. Instead of the above, this constraint holds on every vertex. Therefore, a vertex which does not belong to the potential vertex set 6

7 should have its degree variable equal to 0. You can create these degree variables simply as follows: I n t V a r [ ] d e g r e e s = GraphVarFactory. d e g r e e s ( g ) ; In the same way, one can restrict the in-degree (number of predecessors) and outdegree (number of successors) of each node of a directed graph variable Graph inclusion The subgraph(g1,g2) constraint enables to state that g1 is a subgraph of g2, i.e. every vertex and edge in g1 is also in g2. It follows that g1 cannot be larger than g Symmetry You can force a directed graph variable to be either symmetric or antisymmetric, by respectively using the GCF.symmetric(g) or the GCF.antisymmetric(g) constraints. For instance, by posting the following constraint you make sure that for any arc (i, j) g, then (j, i) / g. s o l v e r. p o s t (GCF. a n t i s y m m e t r i c ( g ) ) ; Transitivity Transitivity is a useful property which enables to compute transitive closures and cliques. s o l v e r. p o s t (GCF. t r a n s i t i v i t y ( g ) ) ; Cycles To constrain an undirected graph variable to form a (Hamiltonian) cycle, then you can simply use the cycle (hamiltonian_cycle) constraint: s o l v e r. p o s t ( G r a p h C o n s t r a i n t F a c t o r y. c y c l e ( g ) ) ; In the same way, a directed graph variable can be forced to form a circuit. s o l v e r. p o s t ( G r a p h C o n s t r a i n t F a c t o r y. h a m i l t o n i a n _ c i r c u i t ( g ) ) ; You can prevent a directed (resp. undirected) graph from containing any circuit (resp. cycle) by posting the no_circuit (resp. no_cycle) constraint, as follows: s o l v e r. p o s t ( G r a p h C o n s t r a i n t F a c t o r y. n o _ c i r c u i t ( g ) ) ; 7

8 3.1.8 Connectivity It is possible to force an undirected (resp. directed) graph variable to be connected (resp. strongly connected) or even to control its number of connected (resp. strongly connected) components with an integer variable. The filtering of such constraint is quite weak but fast. Here is an example : I n t V a r nbscc = V a r i a b l e F a c t o r y. f i x e d ( 2, s o l v e r ) ; s o l v e r. p o s t ( G r a p h C o n s t r a i n t F a c t o r y. n b _ s t r o n g l y _ c o n n e c t e d _ c o m p o n e n t s ( g, nbscc ) ) ; Tree You can force an undirected graph variable to form a tree (i.e. a connected acyclic graph) or a forest (i.e. an acyclic but potentially disconnected graph) by posting the respective constraints: s o l v e r. p o s t (GCF. t r e e ( g r a p h v a r ) ) ; s o l v e r. p o s t (GCF. f o r e s t ( g r a p h v a r ) ) ; In the case of directed graph variable, you can also have directed trees or directed forests (also called arborescences). I n t V a r r o o t = VF. enumerated ( " r o o t O f T r e e ", 0, n 1, s o l v e r ) ; s o l v e r. p o s t (GCF. d i r e c t e d _ t r e e ( graphvar, r o o t ) ) ; s o l v e r. p o s t (GCF. d i r e c t e d _ f o r e s t ( g r a p h v a r ) ) ; Note that the directed_tree constraint requires an integer variable denoting the root of the tree, i.e. the vertex which has no predecessor and from which all nodes can be reached Cliques It is possible to partition a graph into cliques by using the transitivity and connectivity constraints. Nevertheless, if the maximum number of cliques is small, a stronger filtering is provided by the nb_cliques(g,nb) constraint Diameter You can impose the diameter of a graph variable to be equal to a given integer variable with the diameter constraint. This constraint also forces the graph variable to be connected (or strongly connected in case of a directed graph variable). As a recall, the diameter is the length (in number of arcs) of the largest shortest path between any pair of nodes. 3.2 Some optimization constraints Solving hard optimization problems to optimality often requires to embed cost-based reasonings into global constraints. We have included two minimum spanning tree relaxations : the one-tree Lagrangian relaxation to solve the Traveling Salesman Problem and a minimum spanning tree subject to (dualized) degree constraints, to solve the 8

9 more general Degree Constrained Minimum Spanning Tree Problem. Such constraints introduce a significant overhead but they provide a very powerful filtering as well. Presumably, they should only be used once a good upper bound has been found (in case of a minimization problem), because the filtering depends on that value The TSP constraint The TSP constraint enables to find a Hamiltonian cycle of minimum cost. It is built as follows: / / c o n s t r a i n t s ( TSP b a s i c model + L a g r a n g i a n r e l a x a t i o n ) s o l v e r. p o s t ( G r a p h C o n s t r a i n t F a c t o r y. t s p ( graph, t o t a l C o s t, c o s t M a t r i x, 1 ) ) ; The arguments of this methods are respectively : the undirected graph variable representing the cycle, the integer variable representing the cost of the cycle, the integer (symmetric) cost matrix and the Lagrangian mode. Three values are possible for that parameter : 0 means the Lagrangian relaxation is not used; 1 means that the Lagrangian relaxation is turned on after a first solution has been found; 2 means the Lagrangian relaxation is used since root node. 3.3 Channeling constraints A wide range of channeling constraints are provided to allow links between boolean, integer or set variables and a graph variables. This enables to post some usual constraints over some vertex (sub)sets of some edge (sub)sets. Note that you do not have to create such channeling variables yourself : GraphVarFactory.java does it for you! See for instance the static method nodes_set which creates a set variables associates to the nodes of the graph variable given in parameter. Here is an example showing how to constrain the number of vertices of a graph variable g: SetVar v e r t i c e s = GraphVarFactory. n o d e s _ s e t ( g ) ; I n t V a r c a r d = VF. f i x e d ( 3, s o l v e r ) ; s o l v e r. p o s t ( SCF. c a r d i n a l i t y ( v e r t i c e s, c a r d ) ) ; In the same way, one can want to constraint outgoing (resp. ingoing) arcs of a vertex, by extracting such arcs in a set variable Set channeling A set variable can be associated with: Nodes of a graph variable Neighbors of one node of an undirected graph variable Successors of one node of a directed graph variable Predecessors of one node of a directed graph variable 9

10 An array of set variables can be associated with: Neighbors of every node of an undirected graph variable Successors of every node of a directed graph variable Predecessors of every node of a directed graph variable Boolean channeling A boolean variable can be associated with: a node of a graph variable An edge of an undirected graph variable An arc of one node of a directed graph variable An array of boolean variables can be associated with: Nodes of a graph variable Neighbors of a node of an undirected graph variable Successors of a node of a directed graph variable Predecessors of a node of a directed graph variable A matrix of boolean variables can be associated with: The adjacency matrix of a graph variables Integer channeling An array of integer variables can be associated with: Successors of a directed graph variable for which each node belongs to the solution and has exactly one successor 3.4 Implementing your own constraint In Choco-3, a constraint is nothing else but a String name and a set of propagators (filtering algorithm objects). Therefore, to implement your own constraint, you need to create your own propagators. Let see an example with a simple constraint enforcing that a given directed graph should be antisymmetric, i.e. if an arc (i, i) belong to the solution, then the arc (j, i) is forbiden. This constraint can be created with the following line of code, where PropAntiSymmetric is a propagator: return new C o n s t r a i n t ( " a n t i s y m m e t r i c ", new PropAntiSymmetric ( g ) ) ; Let us now investigate how to implement such a propagator. There are basically two ways : either use a non-incremental or an incremental propagator. 10

11 3.4.1 A simple and non-incremental propagators The simplest is the non-incremental approach, but it is also the slower. As we can see, every time the constraint is propagated, we perform an iteration over every mandatory arc (to remove its opposite if it has not been already done). public c l a s s PropAntiSymmetric_ coarse extends Propagator < IDirectedGraphVar > { / / VARIABLES IDirectedGraphVar g ; i n t n ; / / CONSTRUCTORS p u b l i c P r o p A n t i S y m m e t r i c _ c o a r s e ( I D i r e c t e d G r a p h V a r graph ) { super ( graph ) ; g = graph ; n = g. getnbmaxnodes ( ) ; / / METHODS p u b l i c void p r o p a g a t e ( i n t evtmask ) throws C o n t r a d i c t i o n E x c e p t i o n { I S e t k e r = g. getmandatorynodes ( ) ; I S e t succ ; / / i t e r a t e s over mandatory nodes f o r ( i n t i = k e r. g e t F i r s t E l e m e n t ( ) ; i >= 0 ; i = k e r. g e t N e x t E l e m e n t ( ) ) { succ = g. getmandsuccof ( i ) ; / / i t e r a t e s over mandatory a r c s f o r ( i n t j = succ. g e t F i r s t E l e m e n t ( ) ; j >= 0 ; j = s ucc. g e t N e x t E l e m e n t ( ) ) { g. removearc ( j, i, acause ) ; / / removes symmetric a r c s / / c h e c k e r of p a r t i a l i n s t a n t i a t i o n s, u s e f u l f o r r e i f i c a t i o n p u b l i c ESat i s E n t a i l e d ( ) { I S e t k e r = g. getmandatorynodes ( ) ; I S e t succ ; f o r ( i n t i = k e r. g e t F i r s t E l e m e n t ( ) ; i >= 0 ; i = k e r. g e t N e x t E l e m e n t ( ) ) { succ = g. getmandsuccof ( i ) ; f o r ( i n t j = succ. g e t F i r s t E l e m e n t ( ) ; j >= 0 ; j = s ucc. g e t N e x t E l e m e n t ( ) ) { i f ( g. getmandsuccof ( j ). c o n t a i n ( i ) ) { return ESat. FALSE ; / / t h e c o n s t r a i n t i s v i o l a t e d i f ( g. i s I n s t a n t i a t e d ( ) ) { return ESat. TRUE; / / t h e c o n s t r a i n t i s s a t i s f i e d f o r s u r e return ESat. UNDEFINED ; / / s a t i s f i a b i l i t y i s u n d e f i n e d In order to improve performances, you can inform the propagation engine that the propagator should be called only after one or many arc enforcing. It is useless to propagate it after a set of arc removals or node modifications. To do so, you can override 11

12 the getpropagationconditions method as follows: p u b l i c i n t g e t P r o p a g a t i o n C o n d i t i o n s ( i n t vidx ) { / / p r o p a g a t i o n c o n d i t i o n ( f a c u l t a t i v e ) : o nly p r o p a g a t e a r c e n f o r c i n g e v e n t s return GraphEventType.ADD_ARC. getmask ( ) ; Incremental propagators In an incremental approach, then we can run in constant time per newly enforce arc, with the following implementation: public c l a s s PropAntiSymmetric extends Propagator < IDirectedGraphVar > { / / VARIABLES IDirectedGraphVar g ; I G r a p h D e l t a M o n i t o r gdm ; / / o b j e c t e n a b l i n g t o i t e r a t e o v er e n f o r c e d / removed nodes / a r c s EnfProc e n f ; / / p r o c e d u r e t o a p p l y t o e v e r y e n f o r c e d a r c i n t n ; / / CONSTRUCTORS p u b l i c PropAntiSymmetric ( I D i r e c t e d G r a p h V a r graph ) { super ( new I D i r e c t e d G r a p h V a r [ ] { graph, P r o p a g a t o r P r i o r i t y.unary, t rue ) ; g = graph ; gdm = g. m o n i t o r D e l t a ( t h i s ) ; enf = new EnfProc ( ) ; n = g. getnbmaxnodes ( ) ; / / METHODS p u b l i c void p r o p a g a t e ( i n t evtmask ) throws C o n t r a d i c t i o n E x c e p t i o n { / / F i r s t p r o p a g a t i o n ( n o t i n c r e m e n t a l ) I S e t k e r = g. getmandatorynodes ( ) ; I S e t succ ; f o r ( i n t i = k e r. g e t F i r s t E l e m e n t ( ) ; i >= 0 ; i = k e r. g e t N e x t E l e m e n t ( ) ) { succ = g. getmandsuccof ( i ) ; f o r ( i n t j = succ. g e t F i r s t E l e m e n t ( ) ; j >= 0 ; j = s ucc. g e t N e x t E l e m e n t ( ) ) { g. removearc ( j, i, acause ) ; gdm. u n f r e e z e ( ) ; / / n e c e s s a r y c a l l t o s e t u p i n c r e m e n t a l data s t r u c t u r e s p u b l i c void p r o p a g a t e ( i n t idxvarinprop, i n t mask ) throws C o n t r a d i c t i o n E x c e p t i o n { / / i n c r e m e n t a l p r o p a g a t i o n o ver e v e r y e n f o r c e d a r c s i n c e t h e l a s t c a l l gdm. f r e e z e ( ) ; gdm. foreacharc ( enf, GraphEventType.ADD_ARC ) ; gdm. u n f r e e z e ( ) ; p u b l i c i n t g e t P r o p a g a t i o n C o n d i t i o n s ( i n t vidx ) { return GraphEventType.ADD_ARC. getmask ( ) ; 12

13 p u b l i c ESat i s E n t a i l e d ( ) { I S e t k e r = g. getmandatorynodes ( ) ; I S e t succ ; f o r ( i n t i = k e r. g e t F i r s t E l e m e n t ( ) ; i >= 0 ; i = k e r. g e t N e x t E l e m e n t ( ) ) { succ = g. getmandsuccof ( i ) ; f o r ( i n t j = succ. g e t F i r s t E l e m e n t ( ) ; j >= 0 ; j = s ucc. g e t N e x t E l e m e n t ( ) ) { i f ( g. getmandsuccof ( j ). c o n t a i n ( i ) ) { return ESat. FALSE ; i f ( g. i s I n s t a n t i a t e d ( ) ) { return ESat. TRUE; return ESat. UNDEFINED ; / / PROCEDURES / * * * Enable t o remove t h e o p p o s i t e a r c * / p r i v a t e c l a s s EnfProc implements P a i r P r o c e d u r e { p u b l i c void e x e c u t e ( i n t from, i n t t o ) throws C o n t r a d i c t i o n E x c e p t i o n { i f ( from!= t o ) { g. removearc ( to, from, acause ) ; / / whenever ( from, t o ) i s e n f o r c e d, ( to, from ) i s removed Note that the super constructor is no longer the same : super(new IDirectedGraphVar[]graph, PropagatorPriority.UNARY, true);. The first argument is the array of variables this propagator involves. The second one is an indicator of the runtime of the algorithm (here constant time). Finally, the last boolean argument states whether of not this propagator should be incremental or not. Therefore, it should be set to true. 13

14 4 Search 4.1 Variable selection Search procedures are necessary to explore a search space when (and it is usual case) propagation is not sufficient to find a solution. Therefore, at each node of a search tree, whenever propagation has terminated, a search procedure must compute a new decision (refutable hypothesis), which creates a new search node, in order to continue the solving process. A decision consists of selecting a variable and restricting its domain (e.g. X = 3 or X < 3). In case the model includes one or many graph variables, then a search process must select one variable and change its domain. For that, the user need to create a search procedure for each variable type and then create a composite search procedure which will decide, at each node, which one to apply (i.e. decide which variable type the solver should branch on). Note that in case your model has many graph variables, you should create one search strategy per such variable (or make your own search strategy), because built-in strategies only consider one graph variable. Here is a simple example which consists in applying successively intsearch, then setsearch and finally graphsearch: f i n a l A b s t r a c t S t r a t e g y < IntVar > i n t S e a r c h = I n t S t r a t e g y F a c t o r y. mindom_lb ( c a r d ) ; f i n a l A b s t r a c t S t r a t e g y <SetVar > s e t S e a r c h = S e t S t r a t e g y F a c t o r y. f o r c e _ f i r s t ( v e r t i c e s ) ; f i n a l A b s t r a c t S t r a t e g y < IUndirectedGraphVar > g r a p h S e a r c h = G r a p h S t r a t e g y F a c t o r y. g r a p h L e x i c o ( g r a p h v a r ) ; s o l v e r. s e t ( i n t S e a r c h, s e t S e a r c h, g r a p h S e a r c h ) ; / / t h i s i m p l i c i t l y use a s e q u e n c e r c o m p o s i t e s t r a t e g y If you want to decide yourself which strategy to apply, you can build your own composite strategy as in the following example which performs a random selection: A b s t r a c t S t r a t e g y < V a r i a b l e > r a n d o m S e l e c t o r = new A b s t r a c t S t r a t e g y ( new V a r i a b l e [ ] { v e r t i c e s, card, g r a p h v a r ) { Random rd ; A b s t r a c t S t r a t e g y [ ] s t r a t s ; A r r a y L i s t < Decision > c h o i c e s ; p u b l i c void i n i t ( ) throws C o n t r a d i c t i o n E x c e p t i o n { rd = new Random ( ) ; s t r a t s = new A b s t r a c t S t r a t e g y [ ] { i n t S e a r c h, s e t S e a r c h, g r a p h S e a r c h ; c h o i c e s = new A r r a y L i s t < > ( ) ; f o r ( A b s t r a c t S t r a t e g y s : s t r a t s ) { s. i n i t ( ) ; p u b l i c D e c i s i o n g e t D e c i s i o n ( ) { c h o i c e s. c l e a r ( ) ; f o r ( A b s t r a c t S t r a t e g y s : s t r a t s ) { D e c i s i o n d = s. g e t D e c i s i o n ( ) ; i f ( d!= n u l l ) { c h o i c e s. add ( d ) ; i f ( c h o i c e s. isempty ( ) ) { return n u l l ; / / a l l v a r i a b l e s a r e i n s t a n t i a t e d e l s e { return c h o i c e s. g e t ( rd. n e x t I n t ( c h o i c e s. s i z e ( ) ) ) ; ; s o l v e r. s e t ( r a n d o m S e l e c t o r ) ; 14

15 4.2 Branching on a graph variable Let us now investigate how to modify the domain of a graph variable in a search decision. The getdecision() method of AbstractStrategy<IGraphVar> should return a GraphDecision object. Let call dec this decision object. There are basically four options: Make a potential (but not mandatory) vertex node become mandatory (e.g. dec.setnode(g, node, GraphAssignment.graph_enforcer);) Remove a potential (but not mandatory) vertex node (e.g. dec.setnode(g, node, GraphAssignment.graph_remover);) Make a potential (but not mandatory) edge/arc (from, to) become mandatory (e.g. dec.setarc(g, from, to, GraphAssignment.graph_enforcer);) Remove a potential (but not mandatory) edge/arc (from, to) (e.g. dec.setarc(g, from, to, GraphAssignment.graph_remover);) You can implement your own AbstractStrategy<IGraphVar> or use buildin strategies that you can find in GraphStrategyFactory. Note that only GraphAssignment.graph_enforce is used by default. GraphStrategyFactory.lexico Selects nodes then edges according to their lexicographic ordering. GraphStrategyFactory.random Selects nodes randomly and then edges randomly. You can also use the generic method: / * * * D e d i c a t e d graph b r a n c h i n g s t r a t e g y. * GRAPHVAR a graph v a r i a b l e t o b r a n c h on NODE_STRAT s t r a t e g y o ver nodes ARC_STRAT s t r a t e g y o ver a r c s / edges PRIORITY e n a b l e s t o mention i f i t s h o u l d f i r s t b r a n ch on nodes <G> e i t h e r d i r e c t e d or u n d i r e c t e d graph v a r i a b l e a d e d i c a t e d s t r a t e g y t o i n s t a n t i a t e GRAPHVAR * / p u b l i c s t a t i c <G extends IGraphVar > A b s t r a c t S t r a t e g y g r a p h S t r a t e g y (G GRAPHVAR, N o d e S t r a t e g y NODE_STRAT, A r c S t r a t e g y ARC_STRAT, GraphStrategy. NodeArcPriority PRIORITY ) { return new GraphStrategy (GRAPHVAR, NODE_STRAT, ARC_STRAT, PRIORITY ) ; You can then implement your own NodeStrategy, which should select the next node to branch on, as the following which returns the first unfixed vertex or -1 if none exists: public c l a s s LexNode extends NodeStrategy <IGraphVar > { p u b l i c LexNode ( IGraphVar g ) { super ( g ) ; 15

16 p u b l i c i n t nextnode ( ) { f o r ( i n t i = envnodes. g e t F i r s t E l e m e n t ( ) ; i >= 0 ; i = envnodes. g e t N e x t E l e m e n t ( ) ) { i f (! kernodes. c o n t a i n ( i ) ) { return i ; return 1; You can also implement your own ArcStrategy, which should select the next arc to branch on, as the following which selects the first unfixed arc and returns true or false depending of whether such an arc exists or not. Note that this time the arc is defined through instance variables called from and to. public c l a s s LexArc extends ArcStrategy <IGraphVar > { p u b l i c LexArc ( IGraphVar g ) { super ( g ) ; p u b l i c boolean computenextarc ( ) { I S e t envsuc, kersuc ; f o r ( i n t i = envnodes. g e t F i r s t E l e m e n t ( ) ; i >= 0 ; i = envnodes. g e t N e x t E l e m e n t ( ) ) { envsuc = g. getpotsuccorneighof ( i ) ; kersuc = g. getmandsuccorneighof ( i ) ; i f ( envsuc. g e t S i z e ( )!= kersuc. g e t S i z e ( ) ) { f o r ( i n t j = envsuc. g e t F i r s t E l e m e n t ( ) ; j >= 0 ; j = envsuc. g e t N e x t E l e m e n t ( ) ) { i f (! kersuc. c o n t a i n ( j ) ) { t h i s. from = i ; t h i s. t o = j ; return true ; t h i s. from = t h i s. t o = 1; return f a l s e ; There are two options for NodeArcPriority: NodeArcPriority.NODES_THEN_ARCS: First fixes every node and then fixes every arc NodeArcPriority.ARCS: Fixes every arc (forcing an arc automatically forces its incident nodes). Note that potential nodes with no incident arcs may remain unfixed. 4.3 Large Neighborhood Search Large Neighborhood Search (LNS) is most powerful technique to solve large scale optimization problems. It may not be able to prove optimality but is designed to provide very good solutions in a reasonable runtime. Another interesting motivation for setting up an LNS is that the output solution may not be easy to improve by hand. 16

17 The sample TSP_lns.java provides an illustration of how to implement a large neighborhood search to solve a tsp. Setting up an LNS requires can be done as follows: / / o b j e c t d e s c r i b i n g which edges t o f r e e z e SubpathLNS LNS = new SubpathLNS ( graph. getnbmaxnodes ( ), s o l v e r ) ; / / r e s t a r t s e v e r y 30 f a i l s ( f a c u l t a t i v e ) LNS. f a s t R e s t a r t ( new F a i l C o u n t e r ( 3 0 ) ) ; / / s e t up t h e l n s ( t h e l a s t argument i n d i c a t e s whether t o r e s t a r t on e v e r y s o l u t i o n ) s o l v e r. p l u g M o n i t o r ( new LargeNeighborhoodSearch ( s o l v e r, LNS, f a l s e ) ) The only smart part relies in the implementation of INeighbor. We provide the following implementation / * * * O b j e c t d e s c r i b i n g which edges t o f r e e z e and which o t h e r s t o r e l a x i n t h e LNS * R e l a x e s a ( sub ) p a t h of t h e p r e v i o u s s o l u t i o n ( f r e e z e s t h e r e s t ) * / priva te c l a s s SubpathLNS extends ANeighbor { Random rd = new Random ( 0 ) ; i n t n, nbrl ; / / number of nodes, c o u n t e r U n d i r e c t e d G r a p h s o l u t i o n ; / / o b j e c t t o s t o r e t h e c u r r e n t b e s t s o l u t i o n i n t nbfreeedges = 15; / / number of edges which should not be f r o z e n protected SubpathLNS ( i n t n, Solver msolver ) { super ( msolver ) ; t h i s. n = n ; t h i s. s o l u t i o n = new U n d i r e c t e d G r a p h ( n, SetType. LINKED_LIST, t rue ) ; p u b l i c void r e c o r d S o l u t i o n ( ) { / / s t o r e s a s o l u t i o n i n a graph o b j e c t f o r ( i n t i =0; i <n ; i ++) s o l u t i o n. getneighof ( i ). c l e a r ( ) ; f o r ( i n t i =0; i <n ; i ++){ I S e t n e i = graph. getmandneighof ( i ) ; f o r ( i n t j = n e i. g e t F i r s t E l e m e n t ( ) ; j >=0; j = n e i. g e t N e x t E l e m e n t ( ) ) { s o l u t i o n. addedge ( i, j ) ; p u b l i c void f i x S o m e V a r i a b l e s ( ICause c a u s e ) throws C o n t r a d i c t i o n E x c e p t i o n { / / r e l a x e s a sub p a t h ( a s e t of c o n s e c u t i v e edges i n a s o l u t i o n ) i n t i 1 = rd. n e x t I n t ( n ) ; I S e t n e i = s o l u t i o n. getneighof ( i 1 ) ; i n t i 2 = n e i. g e t F i r s t E l e m e n t ( ) ; i f ( rd. n e x t B o o l e a n ( ) ) { i 2 = n e i. g e t N e x t E l e m e n t ( ) ; f o r ( i n t k =0; k<n nbfreeedges ; k ++){ graph. e n f o r c e A r c ( i1, i2, c a u s e ) ; i n t i 3 = s o l u t i o n. getneighof ( i 2 ). g e t F i r s t E l e m e n t ( ) ; i f ( i 3 == i 1 ) { i 3 = s o l u t i o n. getneighof ( i 2 ). g e t N e x t E l e m e n t ( ) ; i1 = i2 ; i2 = i3 ; p u b l i c void r e s t r i c t L e s s ( ) { nbrl++; / / E v e n t u a l l y i n c r e a s e s t h e s i z e of t h e r e l a x e s f r a g m e n t ( n o t n e c e s s a r y ) i f ( nbrl> nbfreeedges ) { 17

18 nbrl = 0 ; nbfreeedges += ( nbfreeedges * 3 ) / 2 ; p u b l i c boolean issearchcomplete ( ) { return nbfreeedges >=n ; The main methods to implement are recordsolution() which requires to copy some part of the current solution in internal data structure in order to be able to freeze some edges later. The method fixsomevariables is called after a restart in order to freeze some variables (here some edges). The method restrictless does not need to be implemented. It is called some times to suggest considering a larger neighborhood (variable neighborhood search). Finally, issearchcomplete asks whether the search is complete or not. The answer should be false in the general case, unless no variable has been frozen (which may occur in variable large neighborhood search). 18

19 5 Practical examples 5.1 Large scale Hamiltonian cycle : The Knight s Tour Problem The Knight s Tour Problem (KTP) is defined over a chessboard and consists of making a chess knight visit every cell exactly once and reach back its original position, where possible moves are given by classical chess rules for the knight. This problem can be seen as a graph problem. Let us introduce an undirected graph for which every vertex is associated with a cell of the chessboard and there is an edge between two vertices if and only if the chess rules allow to travel between the two cells associated with the edge endpoints. The problem then consists of finding a Hamiltonian cycle in this graph. This can be addressed using Choco-Graph. Here is the graph-based CP model of this KTP (with a board length of 200, which involves a 40, 000-vertex graph) : public c l a s s KnightTourProblem extends A b s t r a c t P r o b l e m { / / ( name = " t l ", usage = " time l i m i t. ", r e q u i r e d = f a l s e ) p r i v a t e long l i m i t = 20000; / / 20 s e c time l i m i ( name = " b l ", usage = " Board l e n g t h. ", r e q u i r e d = f a l s e ) p r i v a t e i n t boardlength = 2 00; / / l e n g t h = 200 => v e r t i c e s priv ate IUndirectedGraphVar graph ; / / METHODS p u b l i c s t a t i c void main ( S t r i n g [ ] a r g s ) { new KnightTourProblem ( ). e x e c u t e ( a r g s ) ; p u b l i c void c r e a t e S o l v e r ( ) { l e v e l = Level. SILENT ; / / do n o t p r i n t t h e s o l u t i o n v a l u e ( t o o b i g! ) s o l v e r = new S o l v e r ( " s o l v i n g t h e k n i g h t s t o u r problem with graph v a r i a b l e s " ) ; p u b l i c void buildmodel ( ) { / / This g e n e r a t e s t h e b o o l e a n i n c i d e n c e m a t r i x of t h e c h e s s b o a r d graph / / I t i s r e s p o n s i b l e of t h e high memory consumption of t h i s example / / and c o u l d be r e p l a c e d by l i g h t e r d a t a s t r u c t u r e ( b u t i t i s s i m p l e r as i t i s ) boolean [ ] [ ] m a t r i x = HCP_Utils. g e n e r a t e K i n g T o u r I n s t a n c e ( boardlength ) ; / / v a r i a b l e s S e t F a c t o r y. RECYCLE = f a l s e ; / / ( o p t i m i z a t i o n f o r l a r g e i n s t a n c e s i n v o l v i n g few b a c k t r a c k s, n o t very i m p o r t a i n t n = m a t r i x. l e n g t h ; / / graph r e p r e s e n t i n g mandatory nodes and edges / / ( l i n k e d l i s t d a t a s t r u c t u r e as t h e e x p e c t e d s o l u t i o n i s e x p e c t e d t o be s p a r s e, / / e v e r y v e r t e x i n [ 0, n 1] i s mandatory ) U n d i r e c t e d G r a p h GLB = new U n d i r e c t e d G r a p h ( s o l v e r, n, SetType. LINKED_LIST, t rue ) ; / / graph r e p r e s e n t i n g p o t e n t i a l nodes and edges / / ( l i n k e d l i s t d a t a s t r u c t u r e as i t s i n i t i a l v a l u e i s s p a r s e, / / e v e r y v e r t e x i n [ 0, n 1] b e l o n g s t o t h e p o t e n t i a l ) U n d i r e c t e d G r a p h GUB = new U n d i r e c t e d G r a p h ( s o l v e r, n, SetType. LINKED_LIST, t rue ) ; f o r ( i n t i = 0 ; i < n ; i ++) { f o r ( i n t j = i + 1 ; j < n ; j ++) { i f ( m a t r i x [ i ] [ j ] ) { GUB. addedge ( i, j ) ; / / add p o s s i b l e edges t o t h e domain 19

20 / / b u i l d t h e graph v a r i a b l e graph = GraphVarFactory. u n d i r e c t e d _ g r a p h _ v a r ( "G", GLB, GUB, s o l v e r ) ; / / c o n s t r a i n t s ( h a m i l t o n i a n c y c l e ) s o l v e r. p o s t ( G r a p h C o n s t r a i n t F a c t o r y. h a m i l t o n i a n C y c l e ( graph ) ) ; p u b l i c void c o n f i g u r e S e a r c h ( ) { / / b a s i c a l l y b ranch on s p a r s e a r e a s of t h e graph s o l v e r. s e t ( G r a p h S t r a t e g y F a c t o r y. g r a p h S t r a t e g y ( graph, / / v a r i a b l e t o b r a n c h on null, / / no need node s e l e c t i o n h e u r i s t i c ( a l l a r e mandatory ) new MinNeigh ( graph ), / / a r c s e l e c t i o n h e u r i s t i c GraphStrategy. NodeArcPriority. ARCS) / / branch on a r c s only ) ; S e a r c h M o n i t o r F a c t o r y. l i m i t T i m e ( s o l v e r, l i m i t ) ; S e a r c h M o n i t o r F a c t o r y. l o g ( s o l v e r, f a l s e, f a l s e ) ; p u b l i c void s o l v e ( ) { s o l v e r. f i n d S o l u t i o n ( ) ; p u b l i c void p r e t t y O u t ( ) { / / HEURISTICS priv ate s t a t i c c l a s s MinNeigh extends A r c S t r a t e g y < IUndirectedGraphVar > { i n t n ; p u b l i c MinNeigh ( IUndirectedGraphVar graphvar ) { super ( graphvar ) ; n = graphvar. getnbmaxnodes ( ) ; p u b l i c boolean computenextarc ( ) { I S e t suc ; i n t s i z e = n + 1 ; i n t s i z i ; from = 1; / / f i n d t h e l o w e s t r e m a i n i n g d e g r e e v e r t e x f o r ( i n t i = 0 ; i < n ; i ++) { s i z i = g. getpotneighof ( i ). g e t S i z e ( ) g. getmandneighof ( i ). g e t S i z e ( ) ; i f ( s i z i < s i z e && s i z i > 0) { from = i ; s i z e = s i z i ; i f ( from == 1) { return f a l s e ; / / f i n d i t s lowest remaining degree neighbor suc = g. getpotneighof ( from ) ; f o r ( i n t j = suc. g e t F i r s t E l e m e n t ( ) ; j >= 0 ; j = suc. g e t N e x t E l e m e n t ( ) ) { i f (! g. getmandneighof ( from ). c o n t a i n ( j ) ) { t o = j ; return true ; throw new UnsupportedOperationException ( " t h i s should not happen! " ) ; 20

21 The Hamiltonian cycle constraint involves basic filtering but which run incrementally in constant time for each edge removal/enforcing. Note that having a undirected model is a key (a directed representation would bring symmetries and increase the search space). This model provides the following output (obtained on a usual laptop): ** Choco SNAPSHOT ( ) : C o n s t r a i n t Programming Solver, C o p y l e f t ( c ) ** Solve : s o l v i n g t h e k n i g h t s t o u r problem w ith a graph v a r i a b l e S earch s t a t i s t i c s S o l u t i o n s : 1 B u i l d i n g time : 2,796 s / / t ime t o b u i l d t h e graph v a r i a b l e domain and p r o p a g a t o r s I n i t i a l i s a t i o n : 0,007 s I n i t i a l p r o p a g a t i o n : 0,039 s / / i n i t i a l p r o p a g a t i o n r u n t i m e R e s o l u t i o n : 7,918 s / / t o t a l s o l v i n g t ime Nodes : / / number of branching node i s almost t h e number of nodes in t h e graph ( 40, 000) B a c k t r a c k s : 1 / / good f i l t e r i n g and good s e a r c h! T his model i s good on t h e H a m i l t o n i a n c y c l e prob F a i l s : 1 R e s t a r t s : 0 Max depth : P r o p a g a t i o n s : / / number of i n c r e m e n t a l p r o p a g a t i o n s + number of non i n c r e m e n t a l p r o p a g a t i o n s Memory : 20mb / / memory usage of t h e model ( w h i l e t h e i n p u t m a t r i x t a k e s >1gb ) V a r i a b l e s : 3 / / graph + d e f a u l t s o l v e r c o n s t a n t s (ZERO and ONE) C o n s t r a i n t s : 1 / / H a m i l t o n i a n c y c l e c o n s t r a i n t ( which has 3 i n c r e m e n t a l p r o p a g a t o r s ) If we take a small instance, with a board length of 8, whence 64 vertices. Here is the print of the graph variable initial domain : g r a p h _ v a r G upper bound : / / ( p o t e n t i a l nodes and edges ) nodes : [ 0, 6 3 ] n e i g h b o r s : 0 > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > {

22 31 > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > {53 46 lower bound : / / ( mandatory nodes and edges ) nodes : [ 0, 6 3 ] / / a l l v e r t i c e s a r e mandatory n e i g h b o r s : / / no edge i s mandatory 0 > { 1 > { 2 > { 3 > { 4 > { 5 > { 6 > { 7 > { 8 > { 9 > { 10 > { 11 > { 12 > { 13 > { 14 > { 15 > { 16 > { 17 > { 18 > { 19 > { 20 > { 21 > { 22 > { 23 > { 24 > { 25 > { 26 > { 27 > { 28 > { 29 > { 22

23 30 > { 31 > { 32 > { 33 > { 34 > { 35 > { 36 > { 37 > { 38 > { 39 > { 40 > { 41 > { 42 > { 43 > { 44 > { 45 > { 46 > { 47 > { 48 > { 49 > { 50 > { 51 > { 52 > { 53 > { 54 > { 55 > { 56 > { 57 > { 58 > { 59 > { 60 > { 61 > { 62 > { 63 > { After solving the KTP, printing the (value of) the graph variable gives: g r a p h _ v a r G v a l u e : / / t h e v a r i a b l e i s i n s t a n t i a t e d nodes : [ 0, 6 3 ] / / A l l v e r t i c e s belong t o t h e s o l u t i o n graph n e i g h b o r s : 0 > {17 10 / / The n e i g h b o r s of node 0 a r e nodes 17 and 10 1 > {18 16 / /... edges ( 1, 1 8 ) and ( 1, 1 6 ) b e l o n g t o t h e s o l u t i o n graph 2 > {19 17 / /... 3 > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > {

24 26 > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { Solving the Traveling Salesman Problem The sample TSP_CP_Solver applies 30 seconds of LNS and 30 seconds of classical DFS of the CP model for solving the TSP. The CP model for the TSP is the following: / / v a r i a b l e s t o t a l C o s t = V a r i a b l e F a c t o r y. bounded ( " o b j ", 0, , s o l v e r ) ; / / c r e a t e s a graph c o n t a i n i n g n nodes UndirectedGraph GLB = new UndirectedGraph ( s o l v e r, n, SetType. LINKED_LIST, true ) ; UndirectedGraph GUB = new UndirectedGraph ( s o l v e r, n, SetType.SWAP_ARRAY, true ) ; / / adds p o t e n t i a l edges f o r ( i n t i = 0 ; i < n ; i ++) { f o r ( i n t j = i + 1 ; j < n ; j ++) { GUB. addedge ( i, j ) ; graph = GraphVarFactory. u n d i r e c t e d _ g r a p h _ v a r ( "G", GLB, GUB, s o l v e r ) ; / / c o n s t r a i n t s : TSP b a s i c model + l a g r a n g i a n r e l a x a t i o n ( a f t e r a f i r s t s o l u t i o n has been found ) s o l v e r. p o s t ( G r a p h C o n s t r a i n t F a c t o r y. t s p ( graph, t o t a l C o s t, c o s t M a t r i x, 2 ) ) ; Note that in the exact (DFS) model, the Lagrangian relaxation is triggered since root node (mode = 1). The search procedure varies from one model to the other (see 24