mechmotum/cyipopt

Can I define the hessian and jacobian structures if JAX is used with minimize_ipopt?

hssharadga opened this issue · 3 comments

hssharadga commented

Hi!

We can use Jax to calculate the hessian matrix and jacobian instead of providing it ourselves. IPOPT with Jax is very slow for large problems.

If we calculate the hessian matrix and jacobian ourselves and use the Problem interface*, we can define their structures. Defining the hessian matrix and jacobian structures will make the solver faster, especially if sparse.

Can we use the Jax library to calculate the hessian matrix and jacobian and still be able to define the structures? I want to take the power of both.

Please let me know. Otherwise, using the Problem interface and not Jax will be better.

Problem interface: https://cyipopt.readthedocs.io/en/stable/tutorial.html (Example 71)

moorepants commented

Given that no one has replied, I'm not sure you will get an answer. I recommend just trying it out. Most of us here are not JAX experts.

nrontsis commented

There are two aspects to this:

  1. Can jax infer the sparsity pattern of a function? As far as I understand there is not standard functionality in jax for this. For reference, here is a package that does it in Julia. In the python ecosystem, casadi supports this so you might want to check this as an alternative to the jax + cyipopt combo.
  2. Assuming we knew the sparsity pattern of the callbacks, can we pass this to minimize_ipopt? The answer to this is, currently, no. Instead minimize_ipopt does some pretty unsafe guessing of the sparsity pattern of the jacobians (but not for the hessians?) using the initial point passed to minimize_ipopt. This is unsafe because it is not guaranteed (nor documented to the user as far as I know) that the sparsity of the callables will be the same for every x, and can practically result into passing incorrect jacobians/hessians to ipopt.

Overall, I think that minimize_ipopt can easily lead to inefficient or unsafe use of Ipopt (e.g. Ipopt is not really designed for dense matrices), so I think that loud(er) warnings about this should be placed in its documentation.

moorepants commented

Given @nrontsis's tips, I will close this. Reopen if this isn't suitable.