[Coin-ipopt] Limit on MU

[Andreas Waechter]

Hi again,

Reading Carl's reply I realized that the fix I described probably doesn't
do what you want anyway.  That version of Ipopt works by solving a
sequence of barrier problems to relaxed tolerances, and the barrier
parameter for each barrier problem is proportinal to the relaxed error
tolerance.  The proportionality factor is determined by the option
"DMUERRFAC", which by default is 10.  If you choose a larger value, then
the barrier parameters for a given tolerance will be smaller, and in
particular, for the final relaxed error tolerance (which is on the order
of DTOL) the algorithm will use a smaller MU - just as you want it.
However, you will still have to modify the code at that point that I
mentioned because the factor 10 is hardcoded there (and the alg might just
cycle for a larger value of DMUERRFAC - something that Dominique Orban
recently made me aware of...)

Regards,

Andreas

On Wed, 3 Aug 2005, Carl Damon Laird wrote:

> Hi Ivan,
>
> I assume that the reason you want a smaller mu is to produce a solution
> that is tighter to the bound for the active variables.
>
> It has been my experience that reducing dinfmaxtol (to something like
> 1e-10) pulls things in tighter, although I have never done this with a
> large overall tolerance. Furthermore, I assume that you use a large
> tolerance because of noise in the problem (derivatives?) and this is not
> the case with my problems.
>
> Anyway, it is something to try before modifying the code.
>
> Cheers,
>
> Carl.
>
>
>
> On Wed, 3 Aug 2005, Andreas Waechter wrote:
>
> > Hi Ivan,
> >
> >> We've been exploring IPOPT (Fortran version) for some time in solving
> >> our nonlinear programming problem and ran into a curious behavior.
> >
> > Out of curiosity:  What kind of problems are you solving?
> >
> >> We're in the unfortunate position of having to set DTOL rather large and
> >> we've noticed that the barrier parameter is hard-bounded by DTOL/10.  In
> >> your paper, you explain: "the update (7) does not allow the rule to
> >> become smaller than necessary given the desired tolerance
> >> \epsilon_{tol}, thus avoiding numerical difficulties at the end of the
> >> optimization procedure."  We are unclear on what the specific numerical
> >> difficulties would be for this primal-dual formulation of the problem.
> >> Are there any results that have shown what the 'necessary' value of MU
> >> should be in relation to the overall tolerance?
> >
> > If you would choose MU to be on the order of, say, 1e-16, you might run
> > into problems because your slacks and bound multiplier values become very
> > small (on the order of machine precision).  Therefore, the idea was that
> > the mimimal value of the barrier parameter should be tied to the specified
> > error tolerance.
> >
> > If you specify that you only want to solve the problem to a tolerance of,
> > say, 1e-3, the lower bound on MU will be small enough so that your desired
> > tolerance can be met, but not much smaller.  If you want to have the
> > algorithm use a smaller value of MU (and therefore solve the
> > complementarity condition more tightly than the other optimality
> > conditions), you can change line 96 of update_mu.f accordingly.
> >
> >> Since I have you attention I can't resist asking if there are any
> >> updates on when the C++ alpha version will be released?
> >
> > We hope to be ready to release the C++ version in about three weeks.
> > Therefore, we are not making any more changes to the Fortran version
> > (except for bug fixes).  The new version will not have all the "features"
> > of the Fortran version (e.g., there will be no reduced-space option - and
> > the limitied-memory quasi-Newton options for the full space will be added
> > a little bit later).
> >
> > Hope this helps,
> >
> > Andreas
> >
> > _______________________________________________
> > 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
>