Automatic fallback in CachingOptimizer

[blegat]

We have fallbacks for a few attributes such as ConstraintPrimal but currently, they are only used by MockOptimizer.
When you have a CachingOptimizer{Solver.Optimizer}, a common use case is to do

try
    MOI.get(model, MOI.ConstraintPrimal(), ...)
catch
    MOI.get_fallback(model, MOI.ConstraintPrimal(), ...)
end

However, as mentioned in #1249, relying on try-catch for such normal behavior is not ideal. Moreover, we might catch other errors that shouldn't be ignored.
We decided against having a supports for getters and Solver.Optimizer cannot call get_fallback because it does not implement MOI.ConstraintFunction. Maybe we could have a function use_fallback and in the caching optimizer, we call use_fallback first and if it returns true then we call get_fallback instead of get.

Then if a solver does not natively support giving the ConstraintPrimal nor the ConstraintFunction, it can implement use_fallback(::Solver.Optimizer, ::MOI.ConstraintPrimal) = true. It would then be able to pass the MOI tests needed ConstraintPrimal.

[odow]

#1249 was more that the try-catch was in every usage path. I don't think it's a problem for things like getting the constraint primal.

[blegat]

If you query the ConstraintPrimal for many constraints in different calls then you will hit the catch many times. As getting the ConstraintPrimal can be quite fast, all the time will be in the caching.
Solvers that don't need it don't need to do anything. Only solvers that don't support ConstraintPrimal should implement it. We could have unit tests that check that either the getter is defined or this function returns true.

[odow]

ConstraintPrimal from a CachingOptimizer is the main problem here:

• The inner optimizer might support ConstraintPrimal
• The inner optimization might support ConstraintFunction and VariablePrimal, so get_fallback(model.optimizer, will work
• The cache supports ConstraintFunction and the optimizer supports VariablePrimal, so we could use get_fallback(model,

Are there any other attributes? DualObjectiveValue might be one. Is it that bad if the CachingOptimizer has a try-catch? We can always do that as a first-pass. No one has complained so far...

[odow]

Using JuliaHub, here is every instance of get_fallback:

Good use for ConstraintPrimal

• BARON
  • https://github.com/joehuchette/BARON.jl/blob/5635ba7eb2d9700d9ab6976f5ae879c07f625bd7/src/moi/results.jl#L83
• CDDLib
  • https://github.com/JuliaPolyhedra/CDDLib.jl/blob/7530963dbb7bf137f1ea4cab81ef81180a2658a1/src/MOI_wrapper.jl#L144
• Polyhedra
  • https://github.com/JuliaPolyhedra/Polyhedra.jl/blob/0288f2758e1e84f2896122b08a010febd0b6a2a2/test/lp_to_polyhedra.jl#L67
  • https://github.com/JuliaPolyhedra/Polyhedra.jl/blob/0288f2758e1e84f2896122b08a010febd0b6a2a2/src/vrep_optimizer.jl#L132

Good use for DualObjectiveValue

• GLPK
  • https://github.com/jump-dev/GLPK.jl/blob/5cee5af5cbd78ba074fa391f04f99ac8daafda92/src/MOI_wrapper/MOI_wrapper.jl#L1935
• HiGHS
  • https://github.com/jump-dev/HiGHS.jl/blob/0f4edbbe85946b845071a69392e6e769009d26e8/src/MOI_wrapper.jl#L1707

SumOfSquares

Oof. Implemented for a new attribute: SOSDecompositionAttribute.
https://github.com/jump-dev/SumOfSquares.jl/blob/c1350a7e7c910f542d4442c0869df502a555cfda/src/attributes.jl#L42-L49

There's a TODO here that I don't understand
https://github.com/jump-dev/SumOfSquares.jl/blob/c1350a7e7c910f542d4442c0869df502a555cfda/src/Bridges/Constraint/Constraint.jl#L35-L36

🏴‍☠️ 🏴‍☠️ 🏴‍☠️ 🏴‍☠️ OSQP 🏴‍☠️ 🏴‍☠️ 🏴‍☠️ 🏴‍☠️

Uh oh! They re-define MOI.get(optimizer::MOIU.CachingOptimizer, attr::MOI.ConstraintPrimal, ci::MOI.ConstraintIndex) to the get fallback!!!
https://github.com/osqp/OSQP.jl/blob/763ad7f56bee6bbc542bff1b4a201bc69f10aafb/test/MOI_wrapper.jl#L56-L61

[odow]

If we had #1628, then solvers could just say that they support the attribute.

The downside is that changing the behavior of this is massively breaking (solvers would need to declare that they do support ConstraintPrimal).

Opt-out is also not great, because you can't know all the attributes you need to opt-out of.

[odow]

@blegat are you okay with closing this? DualObjectiveValue is another potential candidate, but ConstraintPrimal was really the main problem.