Gurobi's computeIIS() method identifies an Irreducible Inconsistent Subsystem (IIS) of an infeasible model. An IIS is a subset of the model's constraints and variable bounds that is still infeasible, but that becomes feasible if any single member of the subsystem is removed.
For large models, especially mixed-integer programming models, computing an IIS can be time-consuming. Even when the IIS is computed successfully, it may be large and difficult to interpret.
In both cases, it can help to distinguish between model elements the user can act on and model elements that are fixed in the relevant planning context. This distinction can be used either as an interpretation aid after computing an IIS, or as a way to focus the IIS computation itself.
What does "actionable" mean?
In many optimization models, some constraints and variable bounds represent parts of the system that the user cannot realistically change in the time frame being analyzed. We call these non-actionable model elements.
For example, in a short-term supply chain model, constraints and bounds may represent physical supply limits, warehouse inventory already available, transportation capacity, production that has already occurred, or fixed network structure.
A user managing day-to-day operations may not be able to change these parts of the model. However, that user may be able to relax certain demand requirements, delay an order, buy additional supply from an external supplier, allow unmet demand, or change service-level targets. These are the actionable model elements: the levers the user can realistically pull to address the infeasibility.
In this situation, the most useful question is often not:
Which constraints and bounds make the full model infeasible?
Instead, the useful question is:
Given the non-actionable parts of the model, which actionable constraints or bounds are involved in the infeasibility?
This distinction is useful even if you compute the IIS in the usual way. After computing an IIS, you can focus first on the actionable constraints and bounds that appear in the IIS. If IIS computation itself is taking too long, you can also use the IIS force attributes to guide computeIIS() toward the actionable part of the model.
Optional: force non-actionable model elements into the IIS
If the IIS is large but computes quickly, you may not need to use the force attributes. You can compute an IIS as usual, then filter or label the IIS members according to whether they are actionable.
The force attributes are most useful when IIS computation is slow, or when you deliberately want the IIS algorithm to focus on the remaining actionable model elements.
For each non-actionable model element, set the corresponding IIS force (IISConstrForce, IISLBForce, IISUBForce) attribute to 1 before calling computeIIS():
constr.IISConstrForce = 1 # Force a linear constraint into the IIS
var.IISLBForce = 1 # Force a variable lower bound into the IIS
var.IISUBForce = 1 # Force a variable upper bound into the IISThe default value of these attributes is -1, which lets Gurobi decide whether to include the model element in the IIS. A force value of 1 forces the corresponding model element into the computed infeasible subsystem. A value of 0 forces it out of the IIS.
Note: Similar force attributes are available for other model element types, includin IISSOSForce, IISQConstrForce, IISGenConstrForce. The same idea applies: force the non-actionable model elements into the IIS, and leave the actionable elements at their default value.
At first, forcing non-actionable elements into the IIS may seem counterintuitive. If these elements cannot be changed, why include them? The reason is that forcing an element out of the IIS allows the IIS algorithm to ignore, remove, or violate that element when constructing the subsystem. For a non-actionable element, that is usually not useful: violating it may make the subsystem feasible, but it does not describe a practical fix. By forcing non-actionable elements into the subsystem, you tell Gurobi: these model elements define the fixed context, and the useful diagnostic information is in the remaining actionable elements.
This can speed up IIS computation because Gurobi does not need to determine whether the forced model elements are required for irreducibility. Such information would often be useless in this context, because a non-actionable element cannot be modified or disregarded for the practical use case. Thus, setting the IIS force attributes for non-actionable model elements allows the IIS algorithm to focus on the remaining actionable constraints and bounds.
This approach is particularly useful when a large part of the model represents fixed system behavior, and only a smaller part of the model represents decisions, requirements, or assumptions the user can change.
Important: forcing elements changes the meaning of the IIS
This caveat applies when you use the IIS force attributes. When you force constraints or bounds into the IIS, the subsystem returned by computeIIS() may no longer be irreducible with respect to those forced elements. In other words, some forced constraints or bounds may not actually be necessary to prove infeasibility.
This is expected. The forced elements describe the fixed context for the diagnosis. The main diagnostic value is usually in the actionable constraints and bounds that Gurobi still selected for the IIS.
The computed subsystem is only irreducible with respect to model elements that Gurobi was allowed to consider for inclusion or exclusion. If an element was forced into the subsystem with a force value of 1, Gurobi does not try to remove it to prove irreducibility.
Example
In the following example, a planner makes two products: p1 and p2.
The model contains physical flow constraints and production limits. In the short-term planning context, these are non-actionable: the planner cannot change today's production capacity or the fact that shipments must be backed by production.
The demand requirements are actionable. The planner may be able to buy additional product from an external supplier, pay a penalty for unmet demand, delay a shipment, or renegotiate a service target.
The goal is therefore not simply to find any IIS in the full model. The goal is to answer the more practical question:
Given the fixed production limits and flow relationships, which actionable demand requirements are involved in the infeasibility?
import gurobipy as gp
from gurobipy import GRB
m = gp.Model("focused_iis")
# Production variables.
# Upper bounds represent today's fixed production limits.
make_p1 = m.addVar(lb=0, ub=10, name="make_p1")
make_p2 = m.addVar(lb=0, ub=20, name="make_p2")
# Shipment variables.
ship_p1_A = m.addVar(lb=0, name="ship_p1_A")
ship_p1_B = m.addVar(lb=0, name="ship_p1_B")
ship_p2_A = m.addVar(lb=0, name="ship_p2_A")
ship_p2_B = m.addVar(lb=0, name="ship_p2_B")
# Non-actionable physical relationships:
# shipments cannot exceed production.
balance_p1 = m.addConstr(ship_p1_A + ship_p1_B <= make_p1, name="balance_p1")
balance_p2 = m.addConstr(ship_p2_A + ship_p2_B <= make_p2, name="balance_p2")
# Additional non-actionable operational limits for product p2.
p2_A_capacity = m.addConstr(ship_p2_A <= 7, name="p2_A_capacity")
p2_B_capacity = m.addConstr(ship_p2_B <= 9, name="p2_B_capacity")
# Actionable demand requirements:
# the planner may decide that one or more customer demands cannot be fully met today.
demand_p1_A = m.addConstr(ship_p1_A >= 8, name="demand_p1_A")
demand_p1_B = m.addConstr(ship_p1_B >= 5, name="demand_p1_B")
demand_p2_A = m.addConstr(ship_p2_A >= 3, name="demand_p2_A")
demand_p2_B = m.addConstr(ship_p2_B >= 4, name="demand_p2_B")
m.optimize()
if m.Status == GRB.INFEASIBLE:
# Force non-actionable constraints into the infeasible subsystem.
for c in [balance_p1, balance_p2, p2_A_capacity, p2_B_capacity]:
c.IISConstrForce = 1
# Force non-actionable production bounds into the infeasible subsystem.
make_p1.IISUBForce = 1
make_p2.IISUBForce = 1
m.computeIIS()How do I inspect the actionable IIS members?
After computeIIS() finishes, you can filter or label the IIS members according to whether they are actionable. If you used force attributes, filter out the model elements that were forced into the subsystem:
print("Actionable linear constraints in the IIS:")
for c in m.getConstrs():
if c.IISConstr and c.IISConstrForce != 1:
print(f" {c.ConstrName}")
print("Actionable variable bounds in the IIS:")
for v in m.getVars():
if v.IISLB and v.IISLBForce != 1:
print(f" Lower bound: {v.VarName} >= {v.LB}")
if v.IISUB and v.IISUBForce != 1:
print(f" Upper bound: {v.VarName} <= {v.UB}")For this example, the output is:
Actionable linear constraints in the IIS: demand_p1_A demand_p1_B Actionable variable bounds in the IIS:
This tells the planner where to look first. Given the fixed production limit and flow-balance relationship for p1, the two actionable demand requirements for p1 are involved in the infeasibility.
The useful interpretation is:
Given the fixed production limits, flow-balance relationships, and operational limits, the demand requirements
demand_p1_Aanddemand_p1_Bare involved in the infeasibility.
With this information, the planner can decide which practical lever to pull: buy additional p1 from an external supplier, relax one or both demand requirements, delay an order, or pay a penalty for unmet demand.
The forced non-actionable constraints and bounds may also appear in the returned subsystem. They should not be interpreted as actionable causes of infeasibility. They appear because they define the fixed context in which the actionable constraints are being diagnosed.
The result should not be interpreted as saying that every forced constraint or bound is part of a globally irreducible IIS.
What if computeIIS() still takes too long?
You can use parameters such as TimeLimit or WorkLimit to limit how long Gurobi spends computing an IIS.
m.Params.TimeLimit = 300 m.computeIIS()
If IIS computation stops early, Gurobi returns the smallest infeasible subsystem found so far. You can check the IISMinimal model attribute to determine whether the returned subsystem is minimal.
if not m.IISMinimal:
print("The returned infeasible subsystem is not minimal.")When using the force-attribute strategy described above, a non-minimal result has an important practical interpretation: even after treating the non-actionable model elements as fixed, Gurobi may not have proven that infeasibility can be resolved by changing only one actionable constraint or bound.
In practice, this often means that you may need to relax or modify more than one actionable constraint or variable bound to recover feasibility.
This is still useful diagnostic information. The returned subsystem gives you a smaller set of actionable model elements to investigate, even if it is not minimal.
Summary
If computeIIS() is taking too long, or if the IIS is too large to interpret easily, classify model elements as actionable or non-actionable.
If the IIS computes successfully, this classification can be used as an interpretation aid: focus first on the actionable constraints and bounds in the IIS. These are usually the model elements the user can relax, change, or question.
If IIS computation is slow, consider setting the appropriate IIS force attributes to 1 for non-actionable model elements. This can make IIS computation faster and focus the result on the constraints and bounds the user can actually change.
When force attributes are used, interpret the result carefully. Forced elements are included by design, and the returned subsystem may not be irreducible with respect to them.