I am trying to model and solve a fairly complex constrained nonlinear optimization problem. The main issue is that to compute some equality constraints I need to solve an ODE numerically.

So far, I have been able to model a “minimal” version of the problem using Optimization and OrdinaryDiffEq, and solve it with the IPNewton() method implemented in Optim.

However, I want to swap this solver with a more performant one, i.e. Ipopt, which better handles large problems. So far I tried the followings solutions, but unsuccessfully:

Use Ipopt through OptimizationMOI and AmplNLWriter: issues with Jacobian/Hessian computation since Optimization.AutoForwardDiff(), which works with IPNewton(), does not provide the “expression graph” required by AmplNLWriter. Switching to Optimization.AutoModelingToolkit() does not work on my model. Providing explicit expressions for the Jacobian/Hessian, other than being excessively cumbersome, does not solve the “expression graph” problem either.

Switch to JuMP to model my problem: my variables and constraints are vector-valued, but JuMP lacks streamlined support for these. Plus, I tried to add the nonlinear constraint that solves the ODE in different ways, by registering an @operator and providing “explicit” Jacobian/Hessian obtained with ForwardDiff, but without success.

So my main questions are:

Which framework (Optimization, JuMP, ModelingToolkit, …) would you suggest to model my problem?

Would it be feasible to model my NLP with ModelingToolkit if also the ODE is modeled with the same toolkit? If yes, how?

Is there a way to interface Optimization to Ipopt directly, avoiding the AmplNLWriter that is causing issues?

Finally, my NLP is very large, and I have several constraints that solve the same ODE with different initial conditions. Thus, having a model that can automatically detect and take advantage of the sparsity structure of the derivatives will be highly beneficial.

I attach a small (working) example that should be representative of my problem. It is a Hohmann transfer which can be solved analytically, but it has the same kind of constraints I have in my full NLP.

I don’t have a full answer to your problem but here are some remarks.

You definitely don’t want to provide full Jacobians and Hessians, that’s what autodiff is here for.

That doesn’t seem true to me, JuMP lets you easily specify vector variables and constraints. What have you tried that failed.

Here too, it would be nice to have an idea of what you tried unsuccessfully, ideally an MWE.

You can check out SparseConnectivityTracer.jl and DifferentiationInterface.jl (especially the sparsity handling tutorial) to compute sparse exact Jacobians and Hessians with very little work on your end. Ping @hill, the co-developer of these packages.

You can run it by prepending the code attached to the original post. The ODE solution throws a lot of warnings about the step size being almost zero, and it finally fails.

For the explicit derivatives of operators, I tried this JuMP example.
I also checked out this trick, but adding scalar operators and constraints one by one is not an option for me. And I do not see any support for operators with vector outputs.

That’s not the way. You will miss a lot of SIMD optimizations which are also possible. Treating it purely as a sparse matrix misses the repeated structure optimizations. For a full treatment of that topic, especially in the context of GPU usage, see:

And yes if you have a lot of initial conditions I would suggest GPUing it, though even without the GPU codegening to the specific form could be like 5x even on CPU.

Definitely Optimization.jl. You’ll want the flexibility in AD choice here, since likely you want to not forward mode. Also, I’ve never been successful getting an ODE into JuMP’s nonlinear constraints, so it may just be a no-go.

Currently you won’t see an advantage in this if you’ve already written the ODE in a performant way.

So far, only ForwardDiff seems to work. The other choices listed in the docs fail with quite cryptic errors.
For example, AutoModelingToolkit throws a no method matching Float64(::Num) error during the initialization of the step size in the ODE solution, which I think is related to my previous question:

I can provide more detailed error stack traces if you want.

I didn’t have the time yet, but I’ll definitely look into this: