Document how to not support constraints depending on the actual data (not type)

[rschwarz]

If a solver does not support a specific function-set pair, this is readily communicated via the MOI.supports method.

However, the documentation also mentions another case that is not covered by this method:

With this in mind, developers should support all the constraint types that they want to be usable from JuMP. That said, from the perspective of JuMP, solvers can safely choose to not support the following constraints:

ScalarAffineFunction in GreaterThan, LessThan, or EqualTo with a nonzero constant in the function. Constants in the affine function should instead be moved into the parameters of the corresponding sets.

How should this be implemented?

[rschwarz]

Throwing AddConstraintNotAllowed seems to work:

function MOI.add_constraint(o::Optimizer, func::MOI.ScalarAffineFunction{Float64},
                            set::S) where {S <: SS}
    if func.constant != 0.0
        msg = "SCIP does not support linear constraints with a constant offset."
        throw(MOI.AddConstraintNotAllowed{MOI.ScalarAffineFunction{Float64}, S}(msg))
    end
    [...]

but according to gitter discussion that error should only be used for whole constraint classes.

I guess that UnsupportedConstraint is no better, then.

[joaquimg]

In this part of LQOI we simply move the constant to the set and send a warning, no errors...

[rschwarz]

Right, this is what I did initially.
But then how do you implement

function MOI.set(o::SCIP.Optimizer, ::MOI.ConstraintSet, ci::CI{MOI.ScalarAffineFunction{Float64},S}, set::S)

if you did not store the constant somewhere in the Optimizer?

[joaquimg]

I think I understand what you mean, in LQOI we decided to save the constraint constant.

I am in favor of the warning making it clear that the original constraint was modified and the the modification you are asking about would replace the modifies set and not the originally user defined set.

[joaquimg]

But we need a decision here and it should be made clear in the manual.

[rschwarz]

Yes, my preference for SCIP.jl is to not store any model data in the wrapper (beyond some index mapping) and not support any constraints that would require it.

[joaquimg]

I agree its a reasonable implementation choice. Lets see what the others think about this, for now I would use the warning and modify the user input.

[odow]

Per the documentation:

MathOptInterface.jl/src/constraints.jl

Lines 116 to 129 in 6c5fd6b

	* An [`UnsupportedConstraint`](@ref) error is thrown if `model` does not support
	`F`-in-`S` constraints,
	* a [`AddConstraintNotAllowed`](@ref) error is thrown if it supports `F`-in-`S`
	constraints but it cannot add the constraint(s) in its current state and
	* a [`ScalarFunctionConstantNotZero`](@ref) error may be thrown if
	`func` is an `AbstractScalarFunction` with nonzero constant and `set`
	is [`EqualTo`](@ref), [`GreaterThan`](@ref), [`LessThan`](@ref) or
	[`Interval`](@ref).
	* a [`LowerBoundAlreadySet`](@ref) error is thrown if `F` is a
	[`SingleVariable`](@ref) and a constraint was already added to this variable
	that sets a lower bound.
	* a [`UpperBoundAlreadySet`](@ref) error is thrown if `F` is a
	[`SingleVariable`](@ref) and a constraint was already added to this variable
	that sets an upper bound.

You should throw AddConstraintNotAllowed. If it's just the non-zero constant term, throw ScalarFunctionConstantNotZero.

This issue is pretty old, so I'm tempted to close it; it obviously hasn't been an issue in the last two years.

[odow]

Closed by #1300