Repository navigation
Layer instantiator #2986
Description
It would be useful to have some kind of layer API so that the user could just do:
model = Model(MOI.layers(POI.Optimizer, HiGHS.Optimizer)The challenge is the need to automatically add CachingOptimizer when needed. We could also automatically detected the needed coefficient type but I think for now, we can require the user to explicitly use {Float32} at each layer if he chooses to not use Float64.
It is challenging to find the right interface for this because it's quite complicated. But for the same reason, combining the layers is very difficult for our users and the errors are quite cryptic. So I think we should make the effort to find something that works and make the layers plug&play
Current issues
Bridge layers
Bridge layers don't create index maps for efficiency reason. What they do is use negative indices for the constraint that are bridged. This means that you cannot stack two bridge layers without a CachingOptimizer in between. I remember @chriscoey and @lkapelevich being hit by this bug when stacking SingleBridgeOptimizer layers on top of Hypatia. @GiovanniKarra was also hit by this issue with SingleBridgeOptimizer. I also got hit by this recently in jump-dev/MathOptComplements.jl#29 because ComplementOpt.Optimizer is a subtype of AbstractBridgeOptimizer and MOI.instantiate(() -> ComplementOpt.Optimizer(MOI.instantiate(Ipopt.Optimizer)) was creating a ComplementOpt.Optimizer layer with a LazyBridgeOptimizer layer directly following it so I had to explicitly create a cache in between like so: https://github.com/blegat/ComplementOpt.jl/blob/c852c0fd7016528e352a3a0b7158d611b51f0aad/test/runtests.jl#L322-L328
Need for incremental interface
POI needs an incremental interface and bridge layers do too. So a caching optimizer should automatically be added if needed.
Solution
The implementation would be something like
# This works for all layers of the table below
MOI.requires_incremental_interface(::Type{<:MOI.ModelLike}) = true
MOI.layers(optimizer_constructor; kws...) = MOI.instantiate(optimizer_constructor; kws...)
function MOI.layers(layer_type::Type{<:MOI.ModelLike}, args...; kws...)
model = MOI.layers(args...; kws...)
if (MOI.requires_incremental_interface(layer_type) && !MOI.supports_incremental_interface(model)) ||
(layer_type <: MOI.AbstractBridgeOptimizer && model isa MOI.AbstractBridgeOptimizer)
model = MOI.CachingOptimizer(# add a caching optimizer on top of `model`
end
return layer_type(model)
endThis does not completely resolves the issue with bridges. You could also have that model is not a bridge layer but its inner layer is a bridge optimizer and model does not map indices.
For a complete solution, we could have something like this that would be useful for jump-dev/JuMP.jl#4014
abstract type Layer <: MOI.AbstractOptimizer end # Make `CachingOptimizer` and `AbstractBridgeOptimizer` be subtype of that
MOI.inner_optimizer(model::MOI.Layer) = model.inner # Name inner by convention ?
MOI.inner_optimizer(model::MOI.Bridges.AbstractBridgeOptimizer) = model.model
MOI.inner_optimizer(model::MOI.Utilities.CachingOptimizer) = model.OptimizerThen, we add the following that should be implemented for any subtype of MOI.Layer (in addition to MOI.requires_incremental_interface)
MOI.share_indices_with_inner_optimizer(model::MOI.Layer) = MOI.supports_incremental_interface(model)
# Only exception to the above default implemention according to table below
MOI.share_indices_with_inner_optimizer(model::MOI.Utilities.CachingOptimizer) = falseand then the following one that shouldn't be implemented for layers, it correspond to the "index map" column in the above table
MOI.may_have_negative_indices(model::MOI.ModelLike) = false
MOI.may_have_negative_indices(model::MOI.AbstractBridgeOptimizer) = true
MOI.may_have_negative_indices(model::MOI.Layer) = MOI.share_indices_with_inner_optimizer(model) && MOI.may_have_negative_indices(MOI.inner_optimizer(model))Then, we can do
function MOI.layers(layer_type::Type{<:MOI.Layer}, args...; kws...)
model = MOI.layers(args...; kws...)
if (MOI.requires_incremental_interface(layer_type) && !MOI.supports_incremental_interface(model)) ||
(layer_type <: MOI.AbstractBridgeOptimizer && MOI.may_have_negative_indices(model))
model = MOI.CachingOptimizer(# add a caching optimizer on top of `model`
end
return layer_type(model)
endTable
Let's use this issue to collect the list of layers we want to support and their particularities before we commit with a specific design.
| Layer | supports_incremental_interface |
requires_incremental_interface |
share_indices_with_inner_optimizer |
|---|---|---|---|
CachingOptimizer |
✓ | ✓ | ✘ |
AbstractBridgeOptimizer |
✓ | ✓ | ✓ |
| Dualization | ✘ | ✓ | ✘ |
| ParametricOptInterface | ✓ | ✓ | ✓ |
| DiffOpt | ✓ | ✓ | ✓ |
| MultiObjectiveAlgorithms | ✓ | ✓ | ✓ |
Given that all layers require the incremental interface anyway, maybe we can remove requires_incremental_interface and only add it once we have a solver that needs it so the implementation is simply
function MOI.layers(layer_type::Type{<:MOI.Layer}, args...; kws...)
model = MOI.layers(args...; kws...)
if !MOI.supports_incremental_interface(model) ||
(layer_type <: MOI.AbstractBridgeOptimizer && MOI.may_have_negative_indices(model))
model = MOI.CachingOptimizer(# add a caching optimizer on top of `model`
end
return layer_type(model)
end
Activity
odow commentedon Apr 7, 2026
I don't necessarily disagree with this, but also. Instantiating is already so complicated. Do we need to add more stuff?
In the case of MultiObjectiveAlgorithms, the only safe thing to do is always add a cache:
https://github.com/jump-dev/MultiObjectiveAlgorithms.jl/blob/b5bd81f8c0fdcfb616acd7fc623d1152ab309a52/src/MultiObjectiveAlgorithms.jl#L208
Otherwise: do we know what all modifications are supported?
odow commentedon Apr 7, 2026
See also jump-dev/JuMP.jl#4014.
I think there are a few underlying issues to think about:
We're at a point where there may be many layers in the stack. Reasoning about what model is at each layer is hard. This is basically the point of Unsafe cached backend JuMP.jl#4014. But what is the "bottom-most" layer? Is MultiObjectiveAlgorithms the bottom-most layer? Or the one under that? What about POI?
Assume you get given an
optimizer_factorythat you want toMOI.instantiateand you have a set of requirements (copy_to?, incrementally build? modify?, delete?), should I add a cache and/or bridges to this layer?What guarantees does each layer provide about its
index_map? Is it the identity? Positive and monotonically increasing? Completely arbitrary? Does it have negative indices?Can we move layers around? If I get given an optimizer that has a bridge in it, it might be better to lift the bridges "closer" to the user so that we need to reformulate only once
blegat commentedon May 25, 2026
Thinking more about this, the fact that bridges use negative indices is complicating things quite a lot, I think I should first revisit why we need negative indices and see if that can be simplified. It may have been just me doing premature optimization.
That's the whole point of
MOI.Layer. If we have an interface for layers, we know when we are at a layer and we can ask the inner one and we know when when it's not a layer then it's the inner-most model.We could add something like that in a v2 but at the moment I'm not sure what's the use-case
No, we should do the order that the user chooses, at least for a first version