[Ipopt] unknown sparsity pattern; #non-zeros in constr. Jac. not allowed to change; objective and infeasibility grow despite filter

[Martin Neuenhofen]

Hi all,

I have three questions [1,2,3].

For my application I don't know the sparsitiy pattern of my Jacobian in
advance. [1] Why does Ipopt want to know it in advance at all? Is a
graph-based fill-in reducing reordering only computed once in the beginning
or for what benefit?
Calling my model with NaNs gives me by far more nonzeros than would
practically occur in that Jacobian for any call with real values.

Further, I have the bad feeling that when in Matlab my matrix has by
properties of my current iterate another number of non-zeros then Ipopt
will rearrange them falsely (by using the same index arrays for the sparse
storage), will thus use a wrong Jacobian and consequently fail to converge
towards feasibility. [2] Is this true?

Why is it possible at all that Ipopt performs iterations where both
objective and primal infeasibility grow? [3] Shouldn't the filter enforce
that never one grows and always one strictly decreases (or in case any of
these seems impossible that the solver exists)?

Thanks for your answers.

Kind regards,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20170120/1f158d93/attachment.html>