<div dir="ltr">Hi Tony,<div><br></div><div>thanks that's very informative. I didn't know that this is how the two types of solvers differ. I am aware about the licensing issues, and that's one of the reasons I pushed for ipopt, but what you are saying wrt evaluation time is quite important for our problem.</div><div><br></div><div>Best,</div><div>Florian</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 June 2015 at 16:27, Tony Kelman <span dir="ltr"><<a href="mailto:kelman@berkeley.edu" target="_blank">kelman@berkeley.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If during the optimisation in a given iteration only a subset of constraints needs to be evaluated<br>
</blockquote>
<br></span>
I don't think this ever happens in an interior-point algorithm.<br>
<br>
If your function evaluations are very expensive, that is probably a good enough reason to prefer an SQP solver like NAG or SNOPT over an interior point solver like Ipopt, since generally you'll have fewer outer iterations with SQP but fewer total iterations with interior-point. When the function evaluations are cheap you care more about the linear algebra cost of the total number of iterations, but when they are expensive you care more about the number of function evaluations.<br>
<br>
There are other considerations like the fact that Ipopt is open-source but NAG and SNOPT are not, though none of the sparse linear algebra libraries for use with Ipopt are redistributable other from Mumps.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Tony<br>
<br>
</font></span></blockquote></div><br></div>