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

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.

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.

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.