CODEWITHSUNDEEP
optimizationgurobi
Tobias Triesch
Tobias Triesch

Reputation: 162

Gurobi: Apparently feasible model raises infeasible model error?

when debugging an implementation of a larger flow model on a digraph I found a strange error in one of the components that would yield an infeasible model error by gurobi. The change from feasibility to infeasibility seems to be due to a change in flow direction across the sole arc (1,0) that model consists of. I just cannot make any sense of that. See below the infeasible model .lp-file

\ Model Model1
\ LP format - for model browsing. Use MPS format to capture full model detail.
Minimize

Subject To
 p_lb[0]: pressure[0] >= 10
 p_lb[1]: pressure[1] >= 10
 p_ub[0]: pressure[0] <= 80
 p_ub[1]: pressure[1] <= 80
 q_lb[1,0]: q[1,0] >= -100
 q_ub[1,0]: q[1,0] <= 100
 Flow_Balance[0]: q[1,0] = -50
 Flow_Balance[1]: - q[1,0] = 50
 short_cut2[1,0]: - pressure[0] + pressure[1] = 0
Bounds
End

The whole problem is a feasibility problem for now, so my objective is zero. I have bounded pressure variables at nodes 0 and 1, a flow variable across the arc which occurs in the flow balances at each node. In addition I want the pressures at the nodes to match.

I have thrown the .lp-files and the .mps-files into my VSC text comparison but they don't seem to differ except for the flow direction. I have the strong feeling I might be overlooking something. Below also the .mps-files for both flow directions.

The feasible one:

NAME Model1
ROWS
 N  OBJ
 G  p_lb[0] 
 G  p_lb[1] 
 L  p_ub[0] 
 L  p_ub[1] 
 G  q_lb[1,0]
 L  q_ub[1,0]
 E  Flow_Balance[0]
 E  Flow_Balance[1]
 E  short_cut2[1,0]
COLUMNS
    pressure[0]  p_lb[0]   1
    pressure[0]  p_ub[0]   1
    pressure[0]  short_cut2[1,0]  -1
    pressure[1]  p_lb[1]   1
    pressure[1]  p_ub[1]   1
    pressure[1]  short_cut2[1,0]  1
    q[1,0]    q_lb[1,0]  1
    q[1,0]    q_ub[1,0]  1
    q[1,0]    Flow_Balance[0]  1
    q[1,0]    Flow_Balance[1]  -1
RHS
    RHS1      p_lb[0]   10
    RHS1      p_lb[1]   10
    RHS1      p_ub[0]   80
    RHS1      p_ub[1]   80
    RHS1      q_lb[1,0]  -100
    RHS1      q_ub[1,0]  100
    RHS1      Flow_Balance[0]  50
    RHS1      Flow_Balance[1]  -50
BOUNDS
ENDATA

The infeasible one:

NAME Model1
ROWS
 N  OBJ
 G  p_lb[0] 
 G  p_lb[1] 
 L  p_ub[0] 
 L  p_ub[1] 
 G  q_lb[1,0]
 L  q_ub[1,0]
 E  Flow_Balance[0]
 E  Flow_Balance[1]
 E  short_cut2[1,0]
COLUMNS
    pressure[0]  p_lb[0]   1
    pressure[0]  p_ub[0]   1
    pressure[0]  short_cut2[1,0]  -1
    pressure[1]  p_lb[1]   1
    pressure[1]  p_ub[1]   1
    pressure[1]  short_cut2[1,0]  1
    q[1,0]    q_lb[1,0]  1
    q[1,0]    q_ub[1,0]  1
    q[1,0]    Flow_Balance[0]  1
    q[1,0]    Flow_Balance[1]  -1
RHS
    RHS1      p_lb[0]   10
    RHS1      p_lb[1]   10
    RHS1      p_ub[0]   80
    RHS1      p_ub[1]   80
    RHS1      q_lb[1,0]  -100
    RHS1      q_ub[1,0]  100
    RHS1      Flow_Balance[0]  -50
    RHS1      Flow_Balance[1]  50
BOUNDS
ENDATA

I would be greatful if you could shed some light into the dark :)

Upvotes: 0

Views: 621

Answers (1)

Silke Horn
Silke Horn

Reputation: 460

By default, all variables have a lower bound of 0, but with your Flow_Balance constraints, you are setting q[1,0] = -50. To get an unbounded variable, you explicitly have to set its lower bound to minus infinity. (How you do this, depends on the API you are using.)

To debug such infeasibility issues, you can ask Gurobi to compute an Irreducible Inconsistent Subsystem (IIS). When you are running Gurobi from the command line (gurobi_cl), you can do this by specifying ResultFile=<filename>.ilp (the extension ilp tells Gurobi to compute and write an IIS); in Python you'd use the computeIIS method. E.g. computing an IIS for your infeasible model results in the single constraint q[1,0] = -50.

Upvotes: 1

Related Questions