<div dir="ltr"><div>Hi,</div><div><br></div><div>Thanks for your answer, Stefen.</div><div><br></div><div>I have two questions on your help to my questions 2 and 4.</div><div><br></div><div>2) Unfortunately, it is far away from the bounds. I modified them s.t. the initial point would be perfectly feasible if the NLP discretization's mesh was finer. Could you think of other possible causes for this phenomenon?</div><div><br></div><div>4) When I change the type of the constraints, doesn't that result in a more difficult optimisation problem? (because the number of multipliers for these constraints would double and they would be more affected from a change of the barrier parameter)</div><div><br></div><div>Kind regards,</div><div>Martin</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-19 8:33 GMT+00:00 Stefan Vigerske <span dir="ltr"><<a href="mailto:stefan@math.hu-berlin.de" target="_blank">stefan@math.hu-berlin.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<span><br>
<br>
On 01/18/2017 09:19 PM, Martin Neuenhofen wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><span>
Dear all,<br>
<br>
we would like to use Ipopt in the following settings:<br>
<br></span>
   1. How is the Hesse update of the Lagrangian computed in particular? The<span><br>
   Hesse is HL, then it is HL= sigma * f + sum_i{ lambda_i * Hc_i } . Are the<br>
   updates performed for each summand Hc_I and Hf separately or for their sum<br>
   w.r.t. the difference from one iteration to the next. I am wondering<br>
   because in the first case there would be no assurance of conservation of<br>
   positive definiteness and in the second case there would be issues with<br>
   regards to that the lambdas change. So do they then freeze the lambdas once<br>
   for the update?<br>
</span></blockquote>
<br>
The L-BFGS approximation is done for HL.<br>
I would think that the Hessian to be approximated is considered as a function of x and lambda.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
   2. For our particular application I can easily find feasible starting<span><br>
   points. However, if I pass a slightly infeasible initial guess to Ipopt<br>
   then the inf_pr simply does not converge to 10^-6 . It starts from 0.5,<br>
   goes to 0.1, and then both the feasibility and the cost-function value grow<br>
   with each further iteration above 10^5. I already ensured that inf_pr has<br>
   "original" scaling. I have no idea why Ipopt fails on this one and why in<br>
   that way (I mean I had at least expected that it would terminate and say "I<br>
   am unable to find you a feasible point" instead of just messing everything<br>
   up).<br>
</span></blockquote>
<br>
If your point is close to the variable bounds, then it is moved away from the bounds before starting. You might want to play with the bound_push and bound_frac options to reduce the amount that it is moved.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
   3. How can I make a custom solver? I want something like an iterfunc. I<span><br>
   use Matlab so I want to write my own preconditioned iterative saddle solver<br>
   in Matlab and apply it during each iteration on the KKT system and shift it<br>
   on my own.<br>
</span></blockquote>
<br>
I don't know if that's possible with the C++ interface. Some people have implemented customizations of Ipopt that go deep into the algorithm.<br>
However, Ipopt's Matlab interface hasn't been maintained for a while, so I doubt that anyone would even add additional functionality in it.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
   4. Can one disable the intrinsic check of Ipopt whether the system is<span><br>
   overdetermined (in terms of more equality constraints than degrees of<br>
   freedom). I want to solve such problems since the equations arise from<br>
   discretizations so they and their solution have to be interpreted only in a<br>
   rough manner of being satisfied. In general, does Ipopt hold any features<br>
   for these kinds of systems (e.g. adaptive stopping criteria s.t. I do not<br>
   run back into a point of local intersection of two (nearly) collinear<br>
   equality constraints).<br>
</span></blockquote>
<br>
No. If you think that equality constraints don't need to be satisfied, then you should relax them to inequalities.<br>
<br>
Stefan<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><span>
We are happy for any information on either of these bullets, please as<br>
exhaustive as possible.<br>
<br>
Kind regards,<br>
Martin<br>
<br>
<br>
<br></span><span>
______________________________<wbr>_________________<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" rel="noreferrer">http://list.coin-or.org/mailma<wbr>n/listinfo/ipopt</a><br>
<br>
</span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
<a href="http://www.gams.com/~stefan" target="_blank" rel="noreferrer">http://www.gams.com/~stefan</a><br>
</font></span></blockquote></div><br></div>