[Ipopt] Restoration mode

[Seth Watts]

Hi Stefan -

Thank you for your suggestions. I have completed a series of verification
tests for my derivatives using finite differences, and I am sure they are
correct in the serial version. The parallel version's derivatives are very
similar (relative differences of components on the order of 1e-6) if not
exact to output precision.

I have run valgrind on a previous version the parallel version of the code
as part of its debugging, and it had no memory leaks, bad pointers, etc. I
haven't run Valgrind on the new version, but I will do so to ensure I don't
have any bad pointers hanging around.

I will also try turning up the output level on Ipopt to see if the
additional detail gives a hint as to the discrepancy, which will hopefully
clear up the mystery.

Thanks again.

- Seth


On Fri, Sep 14, 2012 at 10:01 AM, Stefan Vigerske
<stefan at math.hu-berlin.de>wrote:

> Hi,
>
> there is a derivative checker in Ipopt that you might want to try out as
> well.
> Of course it is possible that small differences lead to forcing Ipopt
> into restoration mode, but I think it's unlikely.
> You may want to try to run the parallel code also under a tool like
> valgrind.
> Finally, if you set the print level of Ipopt to a high value, you may be
> possible to see from which point on Ipopt is doing different thing and
> why it does that.
>
> Stefan
>
> On 09/12/2012 12:45 AM, Seth Watts wrote:
> > I do not understand based on the documentation exactly what the
> restoration
> > mode is, when Ipopt enters it, and how it exits it.
> >
> > Based on what I have read, Ipopt enters restoration mode when it
> determines
> > it is in a non-feasible region, and uses a modified algorithm to attempt
> to
> > return to a feasible region. Can anyone clarify matters further?
> >
> > I have two versions of my program, one which evaluates NLP functions in
> > serial, and one which evaluates them in parallel. Since modifying my
> > parallel version, now Ipopt enters restoration mode every time, while the
> > serial version never does. Both are started with random initial
> parameters
> > which in general do not result in a feasible starting point, but the
> serial
> > version is always able to drive the system to a feasible state while
> > reducing the cost function, all without  entering restoration mode (at
> > least, no "r" is printed in the standard output).
> >
> > Even when fixing the seed of the random number generator to compare
> serial
> > and parallel versions directly, the serial does not enter restoration
> mode
> > while the parallel version does. Based on some some of the restoration
> mode
> > options in the documentation, I think it is possible this may occur when
> > the derivatives of the constraints are not correct. Comparing my serial
> and
> > parallel results, I do have some small discrepancies, which I believe are
> > due to parallel evaluation of the derivatives and the non-commutativity
> of
> > floating point operations.
> >
> > Is it possible that small changes in the derivatives could force Ipopt
> into
> > restoration mode? If so, what options would you recommend to reduce this
> > behavior?
> >
> > Thank you,
> > Seth Watts
> >
> >
> >
> > _______________________________________________
> > Ipopt mailing list
> > Ipopt at list.coin-or.org
> > http://list.coin-or.org/mailman/listinfo/ipopt
> >
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20120914/86c5f80f/attachment.html>