Bridges in Manual mode with solver not supporting default_copy_to

[blegat]

In this case there are two caches. Because of the second cache, in view of the first cache, all operations will work and it is in the second cache that some operation will fail and that the inner optimizer will be emptied. Therefore it seems that the second cache should be in manual mode and that the reset, attach, ... operation have to be applied downstream to the second cache.
We could also say that the Manual mode does not really make sense when the optimizer does not support default_copy_to and error in that case (this is what is currently done in #1626).

[mlubin]

I feel like I need a diagram to understand this. We weren't thinking about bridges when we designed Manual mode. Manual mode hasn't received much attention for 0.19. Maybe we should say that it's experimental and we'll get back to it after 0.19.

[odow]

Closing as stale. This is more for MOI, but there are plenty of issues in MOI to track this.

[blegat]

Which MOI issues? This is referring to the JuMP's manual mode.

[odow]

How is JuMP's manual mode different to MOIU.MANUAL?

MANUAL mode in JuMP doesn't introduce two caches.

julia> model = Model(caching_mode = MOIU.MANUAL)
A JuMP Model
Feasibility problem with:
Variables: 0
Model mode: MANUAL
CachingOptimizer state: NO_OPTIMIZER
Solver name: No optimizer attached.

julia> set_optimizer(model, GLPK.Optimizer)

julia> backend(model)
MOIU.CachingOptimizer{MOI.AbstractOptimizer,MOIU.UniversalFallback{MOIU.Model{Float64}}}
in state EMPTY_OPTIMIZER
in mode MANUAL
with model cache MOIU.UniversalFallback{MOIU.Model{Float64}}
  fallback for MOIU.Model{Float64}
with optimizer MOIB.LazyBridgeOptimizer{GLPK.Optimizer}
  with 0 variable bridges
  with 0 constraint bridges
  with 0 objective bridges
  with inner model A GLPK model

If the user provides a solver that doesn't support default_copy_to, then we add a cache as appropriate

julia> backend(model)
MOIU.CachingOptimizer{MOI.AbstractOptimizer,MOIU.UniversalFallback{MOIU.Model{Float64}}}
in state EMPTY_OPTIMIZER
in mode MANUAL
with model cache MOIU.UniversalFallback{MOIU.Model{Float64}}
  fallback for MOIU.Model{Float64}
with optimizer MOIB.LazyBridgeOptimizer{MOIU.CachingOptimizer{Clp.Optimizer,MOIU.UniversalFallback{MOIU.Model{Float64}}}}
  with 0 variable bridges
  with 0 constraint bridges
  with 0 objective bridges
  with inner model MOIU.CachingOptimizer{Clp.Optimizer,MOIU.UniversalFallback{MOIU.Model{Float64}}}
    in state ATTACHED_OPTIMIZER
    in mode AUTOMATIC
    with model cache MOIU.UniversalFallback{MOIU.Model{Float64}}
      fallback for MOIU.Model{Float64}
    with optimizer Clp.Optimizer

What is the problem?

Which MOI issues

Oh. I thought we had a "document or remove MANUAL mode" issue, but I guess we don't.

[blegat]

In the case of Clp, the inner CachingOptimizer is in automatic mode so it will never throw any error. In case Clp does not support add_constraint, the user won't see any error as it will be caught by the inner cache. The purpose of manual mode is for the user to see when the optimizer is detached, etc... but here, it is still hidden from him.
So the question here is: should the inner CachingOptimizer be in manual mode instead ?

[odow]

How would the user interact with the inner CachingOptimizer then? I don't think JuMP should have a MANUAL mode. If you really want that, you could achieve it by using direct_model(cache) where cache is in MANUAL.