SOS1 variables are not supported

Specific Domains Optimization (Mathematical)
1

I’m trying to build a SOS1 constraint using JuMP MOI (with Gurobi, CPLEX, Mosek).

m = Model(with_optimizer(Mosek.Optimizer))
@variable(m, x[1:3])
@constraint(m, x in MOI.SOS1([1, 2, 3]))

But it gives me an error saying:

ERROR: LoadError: Constraints of type MathOptInterface.VectorOfVariables-in-MathOptInterface.SOS1{Int64} are not supported by the solver and there are no bridges that can reformulate it into supported constraints.
Stacktrace:
 [1] moi_add_constraint(::MathOptInterface.Utilities.CachingOptimizer{MathOptInterface.AbstractOptimizer,MathOptInterface.Utilities.UniversalFallback{JuMP._MOIModel{Float64}}}, ::MathOptInterface.VectorOfVariables, ::MathOptInterface.SOS1{Int64}) at /Users/jipkim/.julia/packages/JuMP/jnmGG/src/constraints.jl:371
 [2] add_constraint(::Model, ::VectorConstraint{VariableRef,MathOptInterface.SOS1{Int64},VectorShape}, ::String) at /Users/jipkim/.julia/packages/JuMP/jnmGG/src/constraints.jl:385
 [3] top-level scope at /Users/jipkim/.julia/packages/JuMP/jnmGG/src/macros.jl:621
in expression starting at /Users/jipkim/Dropbox/Julia/Bilevel/SOStest.jl:7

Can anybody point me out how to handle this?

2

It doesn’t look like Mosek.jl supports SOS1 constraints. However Gurobi and CPLEX should. The issue is probably the SOS1{Int64}. Does x in MOI.SOS1([1.0, 2.0, 3.0]) work?

If so, JuMP should probably promote SOS sets to Float64.

1 Like
3

Agree. I’ve run into this as well with MOI.SOS1(1 : 3), which additionally has the issue that 1 : 3 is a UnitRange instead of a Vector. Probably better to handle it centrally than to require all of the solver interfaces to widen their type signatures.

1 Like
4

I’ve opened an issue: Promote eltype of MOI sets like SOS to Float64 · Issue #1911 · jump-dev/JuMP.jl · GitHub

2 Likes
5

Hi Oscar,

Thank you for the response and opening an issue for this.
Can it be allowed to define SOS variables without a weight (ordering) vector? So that below two constraints (con1 & con2) represent the same thing?

@variable(m, x[1:3])
@constraint(m, con1, x in MOI.SOS1([1.0, 2.0, 3.0]))
@constraint(m, con2, x in MOI.SOS1())

In the case of SOS1 variables, ordering is less critical than SOS2 and an automatic ordering would be more convenient.

6

This seems like a reasonable thing to open a feature request for: Sign in to GitHub · GitHub

1 Like