Cart-pole trajectory optimization with ModelingToolkit, Multibody and JuliaSimCompiler model, how to improve performance? Constraints jacobian sparsity pattern issue?

Specific Domains Optimization (Mathematical)
, , ,
1

Hi!

I’m trying to do a trajectory optimization problem with a direct collocation method on my own model. To begin with, I decided to reproduce a documented problem : the cart-pole.

I used ModelingToolkit and Multibody to create the system and then I want to run the trajectory optimization with it. Here are a few steps I took and problems I faced, but more details can be found here (feel free to use the source code!): GitHub - ElMapacheDelOeste/CartPoleMTKTrajectoryOptim.jl: Example of 1D and 2D cart-pole trajectory optimization problem using ModelingToolkit.jl for the physics.

  • I first tried to use InfiniteOpt.jl but I couldn’t find a way to set up my problem with my model.
  • After implementing the transcription for direct collocation manually, I wanted to improve the solver performance by working with the sparsity of the constraints jacobian but didn’t manage to have it work consistently.

Any ideas on how to improve these exemples would be much appreciated. Especially if there are packages working directly with models built with the JuliaSimCompiler.

I am stuck with the use of the argument “cons_jac_prototype” in “OptimizationFunction”. After a couple of calls to the “eval_constraint_jacobian” function of nlp.jl, the jacobian computed by cons_j changes the sparsity pattern while the values added in the new matrix are exactly 0.0. Is there a known solution to this?

Thanks so much for any ideas and piece of advice.

2

Yeah… we’ve been thinking about the same thing :wink:

We’re in the process of extending ODESystem to allow for cost functions and modeling optimal control problems:

If you want to join the fun there’s of course still lots to do. But yes the plan is to make this kind of thing just a standard part of the library, where an ODESystem can take a cost function and then are planning to have codgen to:

  • InfiniteOpt (use their collocation)
  • JuMP (manual collocation with SciML ODE tableaus)
  • Codgen to Pyomo / CASADI collocations
  • BoundaryValueDiffEq.jl (this is effectively a general adaptive collocation solver, also gives shooting methods)

The current PR is trying to do the first two this week.

I didn’t have a direct Optimization.jl one in mind but that is a reasonable one to add at least for benchmarking and because we can have a lot of flexability in the codegen there (though I would expect JuMP would currently do better on this).

But, it seems like we’re directly in the process of adding exactly the same thing to the library itself, so you might want to coordinate with Vincent (I don’t know if he’s on the Discourse?). Indeed I was trying to think this morning about what test case we should use, and Cartpole seems like a reasonble choice.

1 Like
3

I’m sure you are aware of Johan Åkesson’s PhD thesis from Lund University, and his proposed extension Optimica for Modelica, partially implemented in JModelica. See https://lup.lub.lu.se/search/files/4533240/599262.pdf

4

Definitely! I’ve spoken with him in person about Optimica. I think it’s great work but I also think that it needs a new foundation to carry the torch. In particular, I think it (like most Modelica tools) needed to separate the concerns of modeling and solvers, and then with solvers it needed to go down the path of adaptive collocation methods (based off of DAE BVP solver methods), and then add mixed-mode (mixed reverse+forward) automatic differentiation / adjoints. That is kind of what leads to this.

1 Like
5

Thanks for the reply, we will follow this closely even though for now, as we model the cartpole with Multibody, waiting for the release of the new JuliaSimCompiler, it seems that we will not be able to update our ModelingToolkit to a later version than 9.59.

Concerning the issue with providing the sparsity pattern of the constraint jacobian, am I doing something wrong or did I misunderstand the usage of the “cons_jac_prototype” argument?

6

@jClugstor @ChrisRackauckas could this be linked to our dirty fix in Fix sparsity pattern mismatch and test by jClugstor · Pull Request #2662 · SciML/OrdinaryDiffEq.jl · GitHub? Apparently the error encountered by @Odie is in this function at line 291:

7

The collocation method won’t touch the ODE solver, so the codes are unrelated. But if you’re saying the bug could be due to some implicit sparse matrix form change somewhat in the code, yeah that’s entirely possible but a cursory look at our code doesn’t look like it would broadcast in a way that would do that so we would have to look at the MOI code to see if it does

8

A side note: the cartpole system is planar, and could be made to use the Multibody.PlanarMechanics submodule. Models using this module do typically not require JuliaSimCompiler and thus generally give you slightly less headaches when trying to use the generated code with automatic differentiation. The generated code will also be faster when using planar mechanics since the need to multiply by rotation matrices and invert non-scalar mass matrices tends to go away.