added: migration to MOI.VectorNonlinearOracle

[franckgaga]

All references to experimental Ipopt._VectorNonlinearOracle are replaced by the new MOI.VectorNonlinearOracle.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.44%. Comparing base (d2f05ba) to head (3010000).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #269      +/-   ##
==========================================
+ Coverage   92.43%   98.44%   +6.01%     
==========================================
  Files          26       26              
  Lines        4612     4314     -298     
==========================================
- Hits         4263     4247      -16     
+ Misses        349       67     -282     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[franckgaga]

@odow So its seems that MOI.VectorNonlinearOracle is not supported by MadNLP.jl. I get the error:

ERROR: Constraints of type MathOptInterface.VectorOfVariables-in-MathOptInterface.VectorNonlinearOracle{Float64} are not supported by the solver.

If you expected the solver to support your problem, you may have an error in your formulation. Otherwise, consider using a different solver.

The list of available solvers, along with the problem types they support, is available at https://jump.dev/JuMP.jl/stable/installation/#Supported-solvers.
Stacktrace:
  [1] error(s::String)
    @ Base ./error.jl:44
  [2] _moi_add_constraint(model::MathOptInterface.Utilities.CachingOptimizer{…}, f::MathOptInterface.VectorOfVariables, s::MathOptInterface.VectorNonlinearOracle{…})
    @ JuMP ~/.julia/packages/JuMP/vfM5V/src/constraints.jl:1007
  [3] add_constraint(model::Model, con::VectorConstraint{…}, name::String)
    @ JuMP ~/.julia/packages/JuMP/vfM5V/src/constraints.jl:1039
  [4] macro expansion
    @ ~/.julia/packages/JuMP/vfM5V/src/macros/@constraint.jl:173 [inlined]
  [5] macro expansion
    @ ~/.julia/packages/JuMP/vfM5V/src/macros.jl:402 [inlined]
  [6] set_nonlincon!(mpc::NonLinMPC{…}, optim::Model, g_oracle::MathOptInterface.VectorNonlinearOracle{…}, geq_oracle::MathOptInterface.VectorNonlinearOracle{…})
    @ ModelPredictiveControl ~/.julia/dev/ModelPredictiveControl/src/controller/nonlinmpc.jl:752
  [7] init_optimization!(mpc::NonLinMPC{…}, model::NonLinModel{…}, optim::Model)
    @ ModelPredictiveControl ~/.julia/dev/ModelPredictiveControl/src/controller/nonlinmpc.jl:547
...

I understand that you need to "manually" add the support in the MOI interface of each solver's package (e.g. MadNLP.jl, KNITRO.jl, etc.). Am I right ? It will be obviously a farily long job.

@baggepinnen I would consider this as a breaking change for MPC.jl, since code based on MadNLP or any other custom solver won't run anymore until the support for VectorNonlinearOracle is added in its respective MOI interface. Do you agree ? And I don't think we should wait much longer to release a new version of MPC.jl, since this is significantly more performant, around 2.5 times faster when nonlinear constraints are present. The MultipleShooting transcription is even faster than the SingleShooting transcription on the pendulum now 😳 !!!

[odow]

So its seems that MOI.VectorNonlinearOracle is not supported by MadNLP.jl

Correct

I understand that you need to "manually" add the support in the MOI interface of each solver's package (e.g. MadNLP.jl, KNITRO.jl, etc.). Am I right ? It will be obviously a farily long job.

Correct

I would consider this as a breaking change for MPC.jl

Can't you keep the old code and make this new code opt-in somehow?

[franckgaga]

Can't you keep the old code and make this new code opt-in somehow

Theoretically yes, but the very next step is to support exact Hessians, which is "not supported" by the splatting syntax (strictly speaking it is supported, but as you probably know it would be extremely inneficient and intricate for the NL constraints). So it would be kind of a spaghetti to introduce new features that only work with the opt-in option. Still doable, but I'm not sure it is worth the effort.

The users could stick to 1.11 to support all solvers, or upgrade to 2.0 for a speed boost, and soon-to-be release 2.1, to support exact Hessians.

[odow]

cc @sshin and @frapac: I added a new set to MOI that Francis is interested in using with MadNLP: jump-dev/MathOptInterface.jl#2860

[odow]

I can work on KNITRO today

[franckgaga]

Okay, I will try to implement the solution of @odow to maintain compatibility. The default will opt-in for Ipopt and opt-out otherwise.