Gurobi added indicator constraints since version 7.0. CPLEX already had them a few versions ago. What would it take to get indicator constraints in JuMP. I know that Gurobi.jl should wrap the function but I don’t what else should happen in JuMP or the intermediate layers (MathProgBase maybe?). The goal would be to have a syntax like

@indicatorconstraint(m, ind[i in 1:3], x[i] = 1 => sum(y[i,j] for j in J) <= b[j])

Which would translate to a call to GRBaddgenconstrIndicator (or the corresponding CPLEX function). This would also enable an easy extension for disjunctions.

The most natural place for this is in an extension of JuMP. I’ve been toying around with implementing a modeling tool for logical constraints like this, but I can’t say if/when it’ll materialize.
Joey

If a family of useful indicator constraints can be abstracted across Gurobi and CPLEX, then it can be treated similarly to SOS constraints and go into MathProgBase. If it requires any automatic transformations (like disjunctions), on the other hand, then it falls more in the scope of a JuMP extension.

From what I’ve seen in the documentation of CPLEX and gurobi, the function that generates the indicator constraint takes 3 arguments: binary variable, value (0 or 1), and a constraint). I still quite don’t understand how could that be implemented as SOS. Are you suggesting to store the indicator constraint in the array m.soscontr?

From what I read understood… reading the code to implement it I think the following steps would be required, correct me if I’m wrong.

Gurobi.jl/CPLEX.jl → implement the ccall to the low level function… may be add_indicator!
→ Map MathProgBase add_indicator! to that function

MathProgBase → Add add_indicator! interface

JuMP → Add m.indcontr array to the model object
→ Add indicator.jl (similar to the definitions made for sos.jl)
→ function JuMP.add_indicator!( ), similar to addSOS1
→ add macro @indicatorconstraint(m, binvar, value, constraint)

If that seems right, I believe I can give it a shot.

No, I was suggesting that indicator constraints could follow the model of SOS constraints, as you propose below.

This looks reasonable in principle, as long as the MathProgBase add_indicator! can map to the low-level Gurobi/CPLEX functions. The JuMP syntax might take a bit of bikeshedding to get right, but go and take a stab at it.