MathOptInterface.ScalarNonlinearFunction not supported by the solver

[LebedevRI]

This happens with the new non-linear JuMP modelling, seems to work with the old one
(but the docs say the two can not be combined, and other stuff does not work with the old one)

I'm not sure if this is a JuMP's or SCIP's issue...

using JuMP, SCIP

a = 3
b = 1

model = Model(SCIP.Optimizer)

@variable(model, c[1:b], Int)

@expression(model, d[i=1:b,j=1:a], j <= c[i])

@variable(model, e[i=1:b,j=1:a], Bin)

@constraint(model, [i=1:b,j=1:a], e[i,j] == d[i,j])

print(model)

Constraints of type MathOptInterface.ScalarNonlinearFunction-in-MathOptInterface.EqualTo{Float64} are not supported by the solver.

If you expected the solver to support your problem, you may have an error in your formulation. Otherwise, consider using a different solver.

The list of available solvers, along with the problem types they support, is available at https://jump.dev/JuMP.jl/stable/installation/#Supported-solvers.

Stacktrace:
  [1] error(s::String)
    @ Base ./error.jl:35
  [2] _moi_add_constraint(model::MathOptInterface.Utilities.CachingOptimizer{MathOptInterface.Bridges.LazyBridgeOptimizer{SCIP.Optimizer}, MathOptInterface.Utilities.UniversalFallback{MathOptInterface.Utilities.Model{Float64}}}, f::MathOptInterface.ScalarNonlinearFunction, s::MathOptInterface.EqualTo{Float64})
    @ JuMP ~/.julia/packages/JuMP/D44Aq/src/constraints.jl:679
  [3] add_constraint(model::Model, con::ScalarConstraint{NonlinearExpr, MathOptInterface.EqualTo{Float64}}, name::String)
    @ JuMP ~/.julia/packages/JuMP/D44Aq/src/constraints.jl:706
  [4] macro expansion
    @ ~/.julia/packages/JuMP/D44Aq/src/macros.jl:1345 [inlined]
  [5] (::var"#25#26"{Model})(i::Int64, j::Int64)
    @ Main ~/.julia/packages/JuMP/D44Aq/src/Containers/macro.jl:301
  [6] #84
    @ ~/.julia/packages/JuMP/D44Aq/src/Containers/container.jl:85 [inlined]
  [7] iterate
    @ ./generator.jl:47 [inlined]
  [8] collect(itr::Base.Generator{JuMP.Containers.VectorizedProductIterator{Tuple{Base.OneTo{Int64}, Base.OneTo{Int64}}}, JuMP.Containers.var"#84#85"{var"#25#26"{Model}}})
    @ Base ./array.jl:782
  [9] map(f::Function, A::JuMP.Containers.VectorizedProductIterator{Tuple{Base.OneTo{Int64}, Base.OneTo{Int64}}})
    @ Base ./abstractarray.jl:3291
 [10] container
    @ ~/.julia/packages/JuMP/D44Aq/src/Containers/container.jl:85 [inlined]
 [11] container
    @ ~/.julia/packages/JuMP/D44Aq/src/Containers/container.jl:71 [inlined]
 [12] container(f::Function, indices::JuMP.Containers.VectorizedProductIterator{Tuple{Base.OneTo{Int64}, Base.OneTo{Int64}}}, #unused#::Type{JuMP.Containers.AutoContainerType}, names::Vector{Any})
    @ JuMP.Containers ~/.julia/packages/JuMP/D44Aq/src/Containers/container.jl:75
 [13] macro expansion
    @ ~/.julia/packages/JuMP/D44Aq/src/macros.jl:1213 [inlined]
 [14] top-level scope
    @ In[3]:14

[LebedevRI]

Notably, this works in Ipopt (modulo the mixed-integer part).

[matbesancon]

thanks for letting us know! @odow do you know what could be the culprit here? Is a bridge f(x) == b to b <= f(x) <= b potentially missing?

[odow]

Isn't this just that SCIP does not support MOI.ScalarNonlinearFunction yet?

But also, @LebedevRI is using the wrong syntax for indicator constraints. It must be:

model = Model()
@variable(model, e[i=1:b,j=1:a], Bin)
@constraint(model, [i=1:b,j=1:a], e[i,j] --> {j <= c[i]})

[LebedevRI]

Isn't this just that SCIP does not support MOI.ScalarNonlinearFunction yet?

FWIW i did indeed have another "snippet" where MOI.ScalarNonlinearFunction support
was the culprit as per stacktrace, but did not manage to reproduce that yet so that i could file an issue.

But also, @LebedevRI is using the wrong syntax for indicator constraints. It must be:

I'm using what is said in the docs:
https://jump.dev/JuMP.jl/stable/manual/constraints/#Indicator-constraints
https://jump.dev/JuMP.jl/stable/tutorials/linear/tips_and_tricks/#Indicator-constraints
... nowhere did i see the --> syntax, although i very much agree that it looks better than =>.

[odow]

I'm using what is said in the docs:

Suggestions for how to make it clearer then? It says:

Indicator constraints consist of a binary variable and a linear constraint.
The constraint holds when the binary variable takes | the value 1. The
constraint may or may not hold when the binary variable takes the
value 0.

I guess we need to add "You cannot use an expression for the left-hand side.

nowhere did i see the --> syntax, although i very much agree that it looks better than =>.

--> and => are the same thing. No difference. I thought I updated the documentation, but perhaps I didn't.

[matbesancon]

Isn't this just that SCIP does not support MOI.ScalarNonlinearFunction yet?

Ah my bad I should add this, I wasn't sure if an additional step was needed to make solvers work with the new JuMP nonlinear

[LebedevRI]

I'm using what is said in the docs:

Suggestions for how to make it clearer then? It says:

Indicator constraints consist of a binary variable and a linear constraint.
The constraint holds when the binary variable takes | the value 1. The
constraint may or may not hold when the binary variable takes the
value 0.

I guess we need to add "You cannot use an expression for the left-hand side.

nowhere did i see the --> syntax, although i very much agree that it looks better than =>.

--> and => are the same thing. No difference. I thought I updated the documentation, but perhaps I didn't.

Right. I was more talking about the syntax side of question, but clarifying that
the LHS really must be a variable and not an expression could be clarified a bit.
Though, would an automatic rewrite (to introduce the variable) be a bad thing there?

Thank you for looking into this! I think MOI.ScalarNonlinearFunction support would be awesome.

[LebedevRI]

Just to calibrate expectations, is there any kind of an aspirational timeframe
as to when this kind of functionality might be implemented in this solver?

[LebedevRI]

So i've tried to take a stab at this, but it is not yet apparent to me how this would look like in SCIP.j
(as compared to the Ipopt.jl implementation). If there are any suggestions on how to approach this,
i could try again, but this really could use someone already familiar with the codebase...