<div dir="ltr">Interesting. I have modified and attached Ipopt/examples/Cpp_example/ to demonstrate the issue.<div><br></div><div>Not sure why, but app->Options()->SetNumericValue("print_level", 8); does not generate extra output, so I cannot directly compare our log files. THe output below is for Ipopt 3.12.3, but I was able to reproduce this issue with Ipopt 3.11.<br><div><br></div><div><div>~/IPOPT/build/Ipopt/examples/Cpp_example$ ./cpp_example | head -n 100</div><div><br></div><div>******************************************************************************</div><div>This program contains Ipopt, a library for large-scale nonlinear optimization.</div><div> Ipopt is released as open source code under the Eclipse Public License (EPL).</div><div> For more information visit <a href="http://projects.coin-or.org/Ipopt" target="_blank">http://projects.coin-or.org/Ipopt</a></div><div>******************************************************************************</div><div><br></div><div>This is Ipopt version 3.12.3, running with linear solver ma27.</div><div><br></div><div>Number of nonzeros in equality constraint Jacobian...: 0</div><div>Number of nonzeros in inequality constraint Jacobian.: 0</div><div>Number of nonzeros in Lagrangian Hessian.............: 0</div><div><br></div><div>Total number of variables............................: 1</div><div> variables with only lower bounds: 1</div><div> variables with lower and upper bounds: 0</div><div> variables with only upper bounds: 0</div><div>Total number of equality constraints.................: 0</div><div>Total number of inequality constraints...............: 0</div><div> inequality constraints with only lower bounds: 0</div><div> inequality constraints with lower and upper bounds: 0</div><div> inequality constraints with only upper bounds: 0</div><div><br></div><div>iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls</div><div> 0 -1.0000000e+00 0.00e+00 2.00e+00 0.0 0.00e+00 - 0.00e+00 0.00e+00 0</div><div> 1 -1.0933387e+01 0.00e+00 1.01e+00 1.0 9.93e+00 - 9.84e-01 1.00e+00f 1</div><div> 2 -2.0934581e+01 0.00e+00 1.00e+00 -1.0 1.00e+01 - 1.00e+00 1.00e+00f 1</div><div> 3 -3.0934593e+01 0.00e+00 1.00e+00 -2.9 1.00e+01 - 1.00e+00 1.00e+00f 1</div><div> 4 -4.0934594e+01 0.00e+00 1.00e+00 -4.9 1.00e+01 - 1.00e+00 1.00e+00f 1</div></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 20, 2015 at 6:53 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
I cannot reproduce this behavior (and I assume you mean that x is increasing only slowly, not decreasing).<br>
Even when putting x>=0 as a constraint instead of just a variable bound, Ipopt reports unboundedness after 35 iterations.<br>
<br>
The values for x in all iterations are<br>
curr_x[ 1]{x}= 0.0000000000000000e+00<br>
curr_x[ 1]{x}= 1.0000000000000000e+04<br>
curr_x[ 1]{x}= 4.0000000000000000e+04<br>
curr_x[ 1]{x}= 1.3000000000000000e+05<br>
curr_x[ 1]{x}= 4.0000000000000000e+05<br>
curr_x[ 1]{x}= 1.2100000000000000e+06<br>
curr_x[ 1]{x}= 3.6400000000000005e+06<br>
curr_x[ 1]{x}= 1.0930000000000002e+07<br>
curr_x[ 1]{x}= 3.2800000000000007e+07<br>
curr_x[ 1]{x}= 9.8410000000000030e+07<br>
curr_x[ 1]{x}= 2.9524000000000012e+08<br>
curr_x[ 1]{x}= 8.8573000000000036e+08<br>
curr_x[ 1]{x}= 2.6572000000000010e+09<br>
curr_x[ 1]{x}= 7.9716100000000029e+09<br>
curr_x[ 1]{x}= 2.3914840000000011e+10<br>
curr_x[ 1]{x}= 7.1744530000000046e+10<br>
curr_x[ 1]{x}= 2.1523360000000012e+11<br>
curr_x[ 1]{x}= 6.4570081000000037e+11<br>
curr_x[ 1]{x}= 1.9371024400000010e+12<br>
curr_x[ 1]{x}= 5.8113073300000039e+12<br>
curr_x[ 1]{x}= 1.7433922000000012e+13<br>
curr_x[ 1]{x}= 5.2301766010000031e+13<br>
curr_x[ 1]{x}= 1.5690529804000012e+14<br>
curr_x[ 1]{x}= 4.7071589413000044e+14<br>
curr_x[ 1]{x}= 1.4121476824000012e+15<br>
curr_x[ 1]{x}= 4.2364430472100040e+15<br>
curr_x[ 1]{x}= 1.2709329141640014e+16<br>
curr_x[ 1]{x}= 3.8127987424930048e+16<br>
curr_x[ 1]{x}= 1.1438396227480014e+17<br>
curr_x[ 1]{x}= 3.4315188682441050e+17<br>
curr_x[ 1]{x}= 1.0294556604732416e+18<br>
curr_x[ 1]{x}= 3.0883669814197350e+18<br>
curr_x[ 1]{x}= 9.2651009442592154e+18<br>
curr_x[ 1]{x}= 2.7795302832777658e+19<br>
curr_x[ 1]{x}= 8.3385908498332975e+19<br>
curr_x[ 1]{x}= 1.8338590849833298e+20<br>
<br>
I attach the full log.<br>
<br>
If I define x>=0 as variable bound, then Ipopt needs only 6 iterations.<br>
<br>
Stefan<div><div><br>
<br>
<br>
On 06/18/2015 05:49 PM, Ipopt User wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
When I try to solve the simple scalar problem min{-x : x >= 0} with IPOPT<br>
and use hessian_approximation = limited-memory, the progress is very slow.<br>
Essentially, x is reduced by 1 in each iteration.<br>
<br>
From what I understand, this is due to the Hessian approximation, which in<br>
this case is just the identity matrix (plus 1/x due to the log barrier<br>
term, which is significant only in the first few iterations). Solving Hs =<br>
-g, with H the Hessian, s the step and g the gradient, it finds s = 1.<br>
Indeed when I set limited_memory_init_val = 0.1, x is reduced by 10 in each<br>
iteration.<br>
<br>
This seems undesirable to me. Other L-BFGS based solvers like SNOPT and<br>
L-BFGS-B figure out that the problem is unbounded in a few iterations.<br>
<br>
<br>
<br></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" rel="noreferrer" target="_blank">http://list.coin-or.org/mailman/listinfo/ipopt</a><br>
<br>
</blockquote>
<br>
</blockquote></div><br></div></div></div>