supports vs canset

[mlubin]

Why do we have both

MOI.canset(model, MOI.NLPBlock())

and

MOI.supports(model, MOI.NLPBlock())

?

@blegat

[blegat]

MOI.canset says whether the attribute can be set right now with the state of the optimizer while MOI.supports says that it is possible to set this attribute even if it is not settable right now or it should be set using copy! or allocate-load.

[mlubin]

This is potentially more confusing than helpful for users and implementers of solver interfaces. If the optimizer supports an attribute but canset would be false, why not just throw an error explaining why the attribute is not settable right now?

@odow @joaquimg

[blegat]

supports is the replacement of cancopy. It is useful for copy-only solvers as we can check programatically if a copy might fail. For solvers that support addconstraint! and set!, it might seem cumbersome to also implement supports and supportsconstraint. We might change the fallback to

supports(m::ModelLike, attr...) = canset(m, attr)

so that solvers for which canset is equivalent to supports only need to implement canset.

[mlubin]

Could you provide an example where we need to distinguish between supports and canset programmatically? Default fallbacks help but don't really remove the additional complexity of having these two concepts.

[blegat]

If a user adds a rotated second order cone constraints, we need to know whether the optimizer supports it to know whether we need to transform it into a second order cone constraint (e.g. using a bridge) or to leave the constraint as it is.

[mlubin]

Why not use supportsconstraint instead of canaddconstraint in that context?

[blegat]

That's exactly my point, we need supportsconstraint in this situation

[mlubin]

Right, so I'd propose to remove canaddconstraint.

[blegat]

We need canaddconstraint for the CachingOptimizer to see whether the optimizer supports adding a constraint or it needs to go in EmptyOptimizer state
https://github.com/JuliaOpt/MathOptInterface.jl/blob/7164fdc573f3f92acb93de1bf18a3d3bd5e315c7/src/Utilities/cachingoptimizer.jl#L213-L215

[mlubin]

I'm also proposing to replace that usage of canaddconstraint with supportsconstraint.

[blegat]

But supportsconstraint does not help distinguishing whether the solver supports adding constraints or needs to be emptied and needs to be passed the whole problem using copy!.

[mlubin]

What about MOI.canaddconstraint(m.optimizer) && MOI.supportsconstraint(m.optimizer, typeof(func), typeof(set)) in this case?

Why does "whether the solver supports adding constraints" need to depend on the type of constraint, beyond what's already encoded in MOI.supportsconstraint?

[blegat]

Some solvers might, after optimize! is called, support adding some kind of constraints but not other kind of constraints, even if they support these constraints.

[mlubin]

Ok, good point. I would question if the extra complexity in MOI is worth it to handle that case. Users will be able to work around an error message by manually detaching the optimizer.