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

Mon Apr 25 14:07:07 EDT 2005

Hi Matthew,

Having looked that the IPOPT.OUT file that you sent me, it seems that
there is quite some "numerical noise" in the values of the objective
function.

Ipopt usually assume that the functions are really smooth, i.e. if the
changes in the variables are small, then the values should not change
much.  However, often when there is numerical algorithms involved in
computing function values (such as integrating differential equations),
this is not true, particularly if the tolerances for the integrator are
not very tight.

There are two things you could try:

1. Tighten the tolerance in your integrator (or whatever numerical method
you use) if you can do that.

2. Tell Ipopt to be less picky when comparing numbers, using the DPRECFACT
option.  Roughly speaking, this parameter tells Ipopt so think that a
comparison

 a <= b

is true, even if a = b + DPRECFACT*MACHPES*max(abs(a),abs(b)), i.e. even
if a is a little bit larger than b.

Here, MACHEPS is the machine precision (around 1e-16), and the default
value of DPRECFACT is 1e2.

This is in the code usually to handle round-off error and make sure that
Ipopt accepts trial points that are essentially Ok.  But if you choose a
much larger value for DPRECFACT, such as 1e8 or so, it might simply Ipopt
accept many more trial points, and continue despite that strictly speaking
no progress has been made.

You could also try to set IMERIT to 0, which disables the line search and
makes Ipopt simply accept every trial point.  The danger of this as well
as using a larger value of DPRECFACT is that the algorithm might not
converge, cycle or so.  But since the model functions are not given to
Ipopt very precisely, I there is not so much else you can do.

I hope this helps,

Andreas

On Mon, 25 Apr 2005, Andreas Waechter wrote:

> 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
> >
>
> _______________________________________________
> Coin-ipopt mailing list
> Coin-ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-ipopt
>