# Solving takes ages when a var opt int is used to output #132

Closed
opened this Issue Jan 23, 2017 · 2 comments

Projects
None yet
2 participants

### oboudry commented Jan 23, 2017

 When running this simple solver on MiniZinc 2.1.2 (in the IDE), with the default Geocode solver, it gets me a very quick optimal solution as long as I don't try to output the obj variable (a var opt int). When I add it either through the output statement or by annotating it with ::add_to_output, the solver runs forever without finding a single solution. The code below runs without problem if I remove var from the obj declaration, and adds a "deopt" to the expression to make it a non-var. This is from Workshop 2 "Surrender" of the Coursera "Basic Modeling for Discrete Optimization" course. `% workshop 2 % select a set of trade negotiation party enum NEGOTIATOR; NEGOTIATOR: dummy; int: l; % minimum party size int: u; % maximum party size int: m; % minimum joint ability array[NEGOTIATOR] of int: honor; array[NEGOTIATOR,NEGOTIATOR] of int: joint; var set of NEGOTIATOR: party::add_to_output; % cardinality of the party is between l and u constraint card(party) >= l /\ card(party) <= u; % sum of pairs joint must be greather than m constraint sum(i in party, j in party, where i < j)(joint[i,j]) >= m; % maximize the honor of the party (the min of all members) var opt int: obj::add_to_output = (min([honor[i] | i in party])); solve maximize obj; %solve maximize min(i in party)(honor[i]); output ["party = (party)\nobj = (obj)"];`
Member

### guidotack commented Jan 31, 2017

 This is not a bug. As long as you don't specify a search strategy, the solver needs to guess which variables to search over, and it uses the fact whether variables are output or not to guess. Sometimes that guess can be quite bad. Just adding ::set_search([party],input_order,indomain_min,complete) will fix it.

Member

### guidotack commented Feb 3, 2017

 Right, actually there was a problem here with aliased optional variables! Thanks for clarifying again.