[Ipopt] Restoration mode

[Seth Watts]

Hi Stefan -

Your suggestion of turning up IPOPT's output level was successful. I was
able to determine that I had a bug in the part of my code that pushed
derivatives computed in parallel (which were very close to the serial
derivatives) to the IPOPT variables. This bug caused the components of
IPOPT's grad_f variable to be significantly different than the same
variable in the serial version of my code (components differing by +/-
10%), which I assume is what triggered the recovery mode.

Using the increased output level (I used the maximum, 12) was a very
helpful debugging method that other users might find useful in diagnosing
similar problems.

Thanks again for your suggestion.

- Seth

On Fri, Sep 14, 2012 at 10:18 AM, Seth Watts <seth.e.watts at gmail.com> wrote:

> 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/20120918/59cfdae1/attachment.html>