[Ipopt] Unexplained IpOpt behavior

[Kulkarni, Kedar (GE Global Research)]

Dear all,

 

I am using IpOpt in MATLAB (through a mex file) to solve a large-scale
optimization problem where we estimate the gradient and jacobian with
finite differences.

The problem is that there are times when IpOpt worsens the obj function
value than the earlier iterates and sometimes, it even makes the
iterates infeasible (although the earlier iterates were feasible).
Beyond that point it goes into a restoration mode: it tries remove the
constraint violation first and then tries to improve the objective
function. The net result is that it starts at some obj function value
and reaches the same value again after some time - the time seems to be
spent on correcting the constraint violation that wasn't there earlier. 

 

I am not able to explain this behavior. Any suggestions/thoughts on why
this is happening  will be really helpful.

 

Here are some of my thoughts which may be helpful to reach a reasonable
conclusion:

 

1) Could it be because we are using finite differences to estimate the
gradients? Especially because we are using a straightforward expression
based on the forward difference method with a small constant
perturbation to evaluate the gradient. While one would expect
sensitivity to gradient accuracy, I'm not sure if it should affect to
this extent.

 

2) Let us just say the current IpOpt iterate is somehow worse than the
earlier iterate. Why doesn't IpOpt have an internal mechanism by which
it goes back to the earlier iterate and tries again; or some variant
thereof? If it does that already, then why does that not seem to be the
case - it seems to be printing out the iterates irrespective of whether
they are better/worse than the earlier ones.

 

Thank you so much for your time and help. Any
thoughts/insights/suggestions will be highly appreciated.

 

Regards,

-kedar.

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20120120/776bbe1c/attachment.html>