[Coin-ipopt] filter: current iterate feasible; can't do restoration. Abort

[Andreas Waechter]

Hi Matthew,

Ipopt (the optimization code) requires a user to provide at least first
derivatives.  However, the NLPAPI seems to allow a user to only provide
function values, and if no C-functions for the computation of derivatives
are provided, they are computed by finite differences.  I had a quick
glance into the NLPAPI code, and it seems that the hard-coded
finite-difference tolerance is .5e-5.

If you want to know more about this, please contact the developer of the
NLPAPI (Michael Henderson, mhender at watson.ibm.com).

If you want, you can still send me the IPOPT.OUT file for your run
(directly to me, not the mailing list), but I suspect that all I can say
is that the first derivatives don't seem good enough.

Regards,

Andreas


On Fri, 22 Apr 2005, Matthew Guthaus wrote:

> Hi Andreas,
>
> Thanks for the quick response. I should have given some more details,
> but your reply helps.
>
> My function doesn't have an easy closed form, so I am not supplying any
> derivatives (first or second). I assumed that it was using a finite
> difference approach, but I now realize that I have not given any
> tolerance for the finite differencing. Is there such an option?
>
> Matt
>
>
> On Apr 22, 2005, at 4:40 PM, Andreas Waechter wrote:
>
> > Hi Matthew,
> >
> > Given that your problem has only bound constraints, I suspect that
> > there
> > is something wrong with the derivatives that Ipopt sees.  You might
> > want
> > to check if the derivatives that you provide to the NLPAPI are correct.
> > Are you providing only first or also second derivatives?  Or are you
> > using
> > some quasi-Newton option (either in Ipopt or in thew NLPAPI?).
> >
> > When you write that your function is "fairly smooth", does it mean that
> > there are points where the first or second derivatives do not exist or
> > are
> > not continuous?  In that case, you might just be stuck at a point where
> > your functions are not smooth, and then there is not much we can do
> > about
> > it; Ipopt is written to solve problems where the functions are a least
> > twice differentiable.
> >
> > I suggest you check the C code for the computation of the derivatives
> > (unless you are using the option to write the functions are strings in
> > the
> > NLPAPI, in which case there might be a bug in the NLPAPI...).  If you
> > can't find anything wrong, you could send me the IPOPT.OUT file for a
> > print level iprint=3 (please to me directly to avoid spamming the
> > mailing
> > list).  Maybe I can say more then.
> >
> > Andreas
> >
> >
> > On Fri, 22 Apr 2005, Matthew Guthaus wrote:
> >
> >> I am using IPopt through the C NLPAPI. I set up a problem successfully
> >> and get this output after a few iterations:
> >>
> >> ITER     ERR       MU      ||C||   ||YPY||  ||PZ||     ||D||   ALFA(V)
> >>   ALFA(X)     NU   #LS       F      #cor   Regu    CPU(s)
> >> ...
> >>    14 .104E+05d .100E+00 .000E+00 .000E+00 .000E+00  .342E-02
> >> .447E+00d
> >> .100E+01f .000E+00  1 0.12190353E+02  0 .000E+00 .280E+00
> >> filter: current iterate feasible; can't do restoration. Abort
> >>   solve_barrier: filter returns IERR =  16
> >>   mainloop: Error: solve_barrier ends with IERR =  16
> >>
> >> I'm not quite sure what this means... I have tried playing with my
> >> tolerance and scaling factors, but this doesn't change much.
> >> The problem only has simple upper/lower bound constraints and is
> >> fairly
> >> smooth. It should have a minimum near 0. I have used the Matlab fmin
> >> function previously with good results, but with poor performance.
> >>
> >> Any insight from the IPOpt experts?
> >>
> >> Thanks,
> >>
> >> Matt
> >>
> >>
> >> _______________________________________________
> >> Coin-ipopt mailing list
> >> Coin-ipopt at list.coin-or.org
> >> http://list.coin-or.org/mailman/listinfo/coin-ipopt
> >>
>
> _______________________________________________
> Coin-ipopt mailing list
> Coin-ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-ipopt
>