Hi Stefan -<br><br>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.<br>
<br>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.<br><br>Thanks again for your suggestion.<br><br>- Seth<br>
<br><div class="gmail_quote">On Fri, Sep 14, 2012 at 10:18 AM, Seth Watts <span dir="ltr"><<a href="mailto:seth.e.watts@gmail.com" target="_blank">seth.e.watts@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Stefan -<br><br>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.<br>
<br>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.<br>
<br>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.<br><br>Thanks again.<span class="HOEnZb"><font color="#888888"><br>
<br>- Seth</font></span><div class="HOEnZb"><div class="h5"><br><br><br><div class="gmail_quote">
On Fri, Sep 14, 2012 at 10:01 AM, Stefan Vigerske <span dir="ltr"><<a href="mailto:stefan@math.hu-berlin.de" target="_blank">stefan@math.hu-berlin.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Hi,<br>
<br>
there is a derivative checker in Ipopt that you might want to try out as<br>
well.<br>
Of course it is possible that small differences lead to forcing Ipopt<br>
into restoration mode, but I think it's unlikely.<br>
You may want to try to run the parallel code also under a tool like<br>
valgrind.<br>
Finally, if you set the print level of Ipopt to a high value, you may be<br>
possible to see from which point on Ipopt is doing different thing and<br>
why it does that.<br>
<br>
Stefan<br>
<br>
On 09/12/2012 12:45 AM, Seth Watts wrote:<br>
</div><div><div>> I do not understand based on the documentation exactly what the restoration<br>
> mode is, when Ipopt enters it, and how it exits it.<br>
><br>
> Based on what I have read, Ipopt enters restoration mode when it determines<br>
> it is in a non-feasible region, and uses a modified algorithm to attempt to<br>
> return to a feasible region. Can anyone clarify matters further?<br>
><br>
> I have two versions of my program, one which evaluates NLP functions in<br>
> serial, and one which evaluates them in parallel. Since modifying my<br>
> parallel version, now Ipopt enters restoration mode every time, while the<br>
> serial version never does. Both are started with random initial parameters<br>
> which in general do not result in a feasible starting point, but the serial<br>
> version is always able to drive the system to a feasible state while<br>
> reducing the cost function, all without entering restoration mode (at<br>
> least, no "r" is printed in the standard output).<br>
><br>
> Even when fixing the seed of the random number generator to compare serial<br>
> and parallel versions directly, the serial does not enter restoration mode<br>
> while the parallel version does. Based on some some of the restoration mode<br>
> options in the documentation, I think it is possible this may occur when<br>
> the derivatives of the constraints are not correct. Comparing my serial and<br>
> parallel results, I do have some small discrepancies, which I believe are<br>
> due to parallel evaluation of the derivatives and the non-commutativity of<br>
> floating point operations.<br>
><br>
> Is it possible that small changes in the derivatives could force Ipopt into<br>
> restoration mode? If so, what options would you recommend to reduce this<br>
> behavior?<br>
><br>
> Thank you,<br>
> Seth Watts<br>
><br>
><br>
><br>
</div></div><div><div>> _______________________________________________<br>
> Ipopt mailing list<br>
> <a href="mailto:Ipopt@list.coin-or.org" target="_blank">Ipopt@list.coin-or.org</a><br>
> <a href="http://list.coin-or.org/mailman/listinfo/ipopt" target="_blank">http://list.coin-or.org/mailman/listinfo/ipopt</a><br>
><br>
<br>
_______________________________________________<br>
Ipopt mailing list<br>
<a href="mailto:Ipopt@list.coin-or.org" target="_blank">Ipopt@list.coin-or.org</a><br>
<a href="http://list.coin-or.org/mailman/listinfo/ipopt" target="_blank">http://list.coin-or.org/mailman/listinfo/ipopt</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>