Summary
Feature request / discussion: Pyomo currently has no pathway to hand a disjunction to a MIP solver as solver-native indicator constraints, even though every major MIP solver (Gurobi addGenConstrIndicator, CPLEX, SCIP, Xpress) supports them and they are a natural, big-M-free target for Pyomo.GDP linear disjunctions.
Today the only mention of indicator constraints in the code base is a guard asserting they are absent (pyomo/solvers/plugins/solvers/cplex_direct.py:775). For comparison, DisjunctiveProgramming.jl ships an Indicator reformulation alongside big-M and hull (Perez, Joshi & Grossmann, JuliaCon Proc. 2023), so JuMP users can already choose it; Pyomo.GDP users cannot.
Why it matters
- Indicator constraints avoid choosing M values entirely (no big-M weakening, no numerical trouble from huge coefficients), at the cost of relying on solver-internal branching/presolve handling — a well-studied trade-off (Bonami et al., Math. Prog. 151, 2015; Belotti et al., COAP 65, 2016).
- For GDP models with hard-to-bound expressions,
gdp.bigm/gdp.mbigm either fail or produce weak relaxations; an indicator route would be the robust fallback.
Scope sketch (why this is more than a transformation)
- A representation for
y = 1 → (a'x ≤ b) that writers/interfaces can recognize (new component, or a recognized structure on transformed constraints).
- Interface support: gurobipy and cplex direct/persistent (and the
contrib.solver generation) emitting native indicator constraints; LP-file writers could emit the LP-format -> syntax where supported.
- A
gdp.* transformation mapping each (linear) disjunct constraint to indicator form off its binary_indicator_var, with the same XOR handling as the existing transformations.
Interested in maintainer thoughts on where the representation should live (this is the main design question); implementation help available from our side.
Context: found during a GDP/MINLP roadmap audit (tracked at bernalde#2) comparing Pyomo.GDP against the current GDP software ecosystem.
Summary
Feature request / discussion: Pyomo currently has no pathway to hand a disjunction to a MIP solver as solver-native indicator constraints, even though every major MIP solver (Gurobi
addGenConstrIndicator, CPLEX, SCIP, Xpress) supports them and they are a natural, big-M-free target forPyomo.GDPlinear disjunctions.Today the only mention of indicator constraints in the code base is a guard asserting they are absent (
pyomo/solvers/plugins/solvers/cplex_direct.py:775). For comparison, DisjunctiveProgramming.jl ships anIndicatorreformulation alongside big-M and hull (Perez, Joshi & Grossmann, JuliaCon Proc. 2023), so JuMP users can already choose it; Pyomo.GDP users cannot.Why it matters
gdp.bigm/gdp.mbigmeither fail or produce weak relaxations; an indicator route would be the robust fallback.Scope sketch (why this is more than a transformation)
y = 1 → (a'x ≤ b)that writers/interfaces can recognize (new component, or a recognized structure on transformed constraints).contrib.solvergeneration) emitting native indicator constraints; LP-file writers could emit the LP-format->syntax where supported.gdp.*transformation mapping each (linear) disjunct constraint to indicator form off itsbinary_indicator_var, with the same XOR handling as the existing transformations.Interested in maintainer thoughts on where the representation should live (this is the main design question); implementation help available from our side.
Context: found during a GDP/MINLP roadmap audit (tracked at bernalde#2) comparing Pyomo.GDP against the current GDP software ecosystem.