`MOI.AddVariableNotAllowed` error when using JuMP extension

[timholy]

julia> using Manopt, JuMP, OptimizationProblems

julia> model = OptimizationProblems.PureJuMP.bt1()
A JuMP Model
├ solver: none
├ objective_sense: MIN_SENSE
│ └ objective_function_type: QuadExpr
├ num_variables: 2
├ num_constraints: 1
│ └ QuadExpr in MOI.EqualTo{Float64}: 1
└ Names registered in the model
  └ :constr1, :x

julia> set_optimizer(model, Manopt.JuMP_Optimizer)

julia> optimize!(model)
ERROR: MathOptInterface.AddVariableNotAllowed:

## Cause

Adding variables cannot be performed

## Fixing this error

An `MOI.NotAllowedError` error occurs when you have tried to do something that
is not implemented by the solver.

The most common way to fix this error is to wrap the optimizer in a
`MOI.Utilities.CachingOptimizer`.

For example, if you are using `JuMP.Model` or `JuMP.set_optimizer`, do:

model = JuMP.Model(optimizer; with_cache_type = Float64)
model = JuMP.GenericModel{T}(optimizer; with_cache_type = T)
JuMP.set_optimizer(model, optimizer; with_cache_type = Float64)

Similarly, if you are using `MOI.instantiate`, do:

model = MOI.instantiate(optimizer; with_cache_type = Float64)


Stacktrace:
  [1] add_variable(model::ManoptJuMPExt.ManoptOptimizer)
    @ MathOptInterface ~/.julia/packages/MathOptInterface/03Qtw/src/variables.jl:64
  [2] add_variables
    @ ~/.julia/packages/MathOptInterface/03Qtw/src/variables.jl:44 [inlined]
  [3] add_variables
    @ ~/.julia/packages/MathOptInterface/03Qtw/src/Bridges/bridge_optimizer.jl:2255 [inlined]
  [4] _copy_variables_with_set(dest::MathOptInterface.Bridges.LazyBridgeOptimizer{ManoptJuMPExt.ManoptOptimizer}, src::MathOptInterface.Utilities.UniversalFallback{MathOptInterface.Utilities.Model{Float64}})
    @ MathOptInterface.Utilities ~/.julia/packages/MathOptInterface/03Qtw/src/Utilities/copy.jl:553
  [5] default_copy_to(dest::MathOptInterface.Bridges.LazyBridgeOptimizer{ManoptJuMPExt.ManoptOptimizer}, src::MathOptInterface.Utilities.UniversalFallback{MathOptInterface.Utilities.Model{Float64}})
    @ MathOptInterface.Utilities ~/.julia/packages/MathOptInterface/03Qtw/src/Utilities/copy.jl:386
  [6] copy_to
    @ ~/.julia/packages/MathOptInterface/03Qtw/src/Bridges/bridge_optimizer.jl:448 [inlined]
  [7] optimize!
    @ ~/.julia/packages/MathOptInterface/03Qtw/src/MathOptInterface.jl:121 [inlined]
  [8] optimize!(m::MathOptInterface.Utilities.CachingOptimizer{MathOptInterface.Bridges.LazyBridgeOptimizer{ManoptJuMPExt.ManoptOptimizer}, MathOptInterface.Utilities.UniversalFallback{MathOptInterface.Utilities.Model{Float64}}})
    @ MathOptInterface.Utilities ~/.julia/packages/MathOptInterface/03Qtw/src/Utilities/cachingoptimizer.jl:370
  [9] optimize!(model::Model; ignore_optimize_hook::Bool, _differentiation_backend::MathOptInterface.Nonlinear.SparseReverseMode, kwargs::@Kwargs{})
    @ JuMP ~/.julia/packages/JuMP/e83v9/src/optimizer_interface.jl:609
 [10] optimize!(model::Model)
    @ JuMP ~/.julia/packages/JuMP/e83v9/src/optimizer_interface.jl:560
 [11] top-level scope
    @ REPL[4]:1

It seems likely that I may have to set some attributes, but the demo does not quite give me enough info to know what the options are and how they apply to different types of problems.

[kellertuer]

Hi Tim,

thanks for your interest. I have been fighting with the extension a lot and currently it is not fully clear how Manifolds should even be modelled within JuMP. For that reason, there is #532
and the support for that extension will be dropped soon-ish.

One reason is, that while JuMP has very good tutorials how to use JuMP, how to write an extension is to nearly no extend documented. There might be plans to do a separate package combining both, but I personally will no longer try to combine both these packages. For example, I am not able to do much more than the demo does myself, and it might be one of thinly things that actually can be done.

If you have a problem that involves manifolds, then I would recommend to use just Manopt for now; for your concrete case I am not sure on which manifold the problem would be even defined? If it is (just) a Euclidean problem, then maybe also other packages (and their inclusion into JuMP) might suite well.

[timholy]

Understood. Maintenance is hard and one has to be realistic. Thanks for your quick response!

[kellertuer]

Thanks for your understanding. It is even a bit more than that. JuMP already struggles with matrices as variables, even more when they are typed (like for https://juliamanifolds.github.io/Manifolds.jl/stable/manifolds/fixedrankmatrices/ with a strut of 2 matrices and a vector).

So while this extension was (in hindsight) created in a bit of a rush, only maybe just a few manifolds would be easily supported – for example the sphere and hyperbolic space, but from that also only one of the three representations. While trying to maintain the extension, I noticed that anything beyond that is probably simply not possible.
Maybe Benôit has a goal to bring these into MOI some time, but at this time, the extension causes more things to not (and never) work than it enables. For you specific case, I am not sure which case that is, since I do not yet see which manifold you were going for.

[timholy]

I was just giving it a whirl in a benchmarking project, going through all the open-source NLP solvers supported by JuMP, and Manopt was listed.

[kellertuer]

Ah, ok.

Ion principle, sure, Manopt.jl does support (classical, flat space) Euclidean optimization, and hopefully all solvers should work reasonably performant there as well – just that they are not really easy to access from JuMP due to the problems mentioned above. So if you want to benchmark that, you would have to do that without JuMP.
And sure, if it is about comparing “things available from JuMP” the answer is – then Manopt is not part of that, since it does not fit the paradigm JuMP follows.