[Ipopt] Low # iters, ensuring that solution remains feasible
Tony Kelman
kelman at berkeley.edu
Thu Nov 13 19:08:03 EST 2014
I’m not used to seeing Ipopt’s timing statistics report larger wall time than CPU time, usually it’s the other way around when I’m using one of the openmp linear solvers. I have heard that Python forking can interact very poorly with multithreaded BLAS, so something odd might be happening.
Definitely profile your function evaluations. Depending on how complicated your nonlinearities are and how much code we’re talking about, you may want to pursue implementing your function evaluations in something faster than Python, particularly something that can give you efficient automatic differentiation. If you’re using AMPL, GAMS, JuMP, Pyomo (which outputs models to .nl files like AMPL), or OSiL, then generally function evaluations should only be taking around 5-20% of the wall time in Ipopt.
-Tony
From: Ipopt User
Sent: Thursday, November 13, 2014 10:25 AM
To: ipopt at list.coin-or.org
Subject: Re: [Ipopt] Low # iters, ensuring that solution remains feasible
To see where those 15 seconds are spent, look at the wall time in the advanced timing statistics: 14.946 out of 15.734 seconds are spent in function evaluations. This seems normal for the quasi newton method if you have only a few constraints.
Why does the optimization terminate early?
On Thu, Nov 13, 2014 at 1:24 PM, Ipopt User <ipoptuser at gmail.com> wrote:
To see where those 15 seconds are spent, look at the wall time in the advanced timing statistics: 14.946 out of 15.734 seconds are spent in function evaluations. This seems normal for the quasi newton method if you have only a few constraints.
Why does the optimization terminate early?
On Thu, Nov 13, 2014 at 12:45 PM, John Schulman <john.d.schulman at gmail.com> wrote:
I haven't had much luck yet setting the initial Lagrange multipliers.
One hack that helps a bit is to redefine the objective function so that it has value +inf when the constraint violation is greater than some threshold.
Of course, this severely impedes the progress of the optimizer and causes it to emit a lot of warnings.
But maybe rescaling or reshaping the objective function is the way to go here.
Yup, the problem 50000 dimensional, and there's no banded-diagonal structure or anything. I think the main bottleneck should be function and gradient evaluations, not the linear algebra. I looked at the timing stats and something is a bit off. The optimization takes about 15 seconds but the stats only account for about 1 second. Maybe because I'm using fork-based parallelism (via python multiprocessing) to compute the gradients? Anyway, if it's indeed true that linear algebra is taking .5 seconds or so, then that's insignificant.
Number of objective function evaluations = 70
Number of objective gradient evaluations = 51
Number of equality constraint evaluations = 0
Number of inequality constraint evaluations = 70
Number of equality constraint Jacobian evaluations = 0
Number of inequality constraint Jacobian evaluations = 51
Number of Lagrangian Hessian evaluations = 0
Total CPU secs in IPOPT (w/o function evaluations) = 0.591
Total CPU secs in NLP function evaluations = 0.439
Timing Statistics:
OverallAlgorithm....................: 1.030 (sys: 0.064 wall: 15.734)
PrintProblemStatistics.............: 0.000 (sys: 0.000 wall: 0.000)
InitializeIterates.................: 0.008 (sys: 0.001 wall: 0.222)
UpdateHessian......................: 0.051 (sys: 0.002 wall: 0.055)
OutputIteration....................: 0.001 (sys: 0.001 wall: 0.002)
UpdateBarrierParameter.............: 0.353 (sys: 0.022 wall: 0.378)
ComputeSearchDirection.............: 0.133 (sys: 0.005 wall: 0.137)
ComputeAcceptableTrialPoint........: 0.176 (sys: 0.017 wall: 7.201)
AcceptTrialPoint...................: 0.004 (sys: 0.000 wall: 0.004)
CheckConvergence...................: 0.304 (sys: 0.015 wall: 7.735)
PDSystemSolverTotal.................: 0.436 (sys: 0.020 wall: 0.458)
PDSystemSolverSolveOnce............: 0.403 (sys: 0.019 wall: 0.422)
ComputeResiduals...................: 0.026 (sys: 0.001 wall: 0.027)
StdAugSystemSolverMultiSolve.......: 0.187 (sys: 0.009 wall: 0.197)
LinearSystemScaling................: 0.000 (sys: 0.000 wall: 0.000)
LinearSystemSymbolicFactorization..: 0.000 (sys: 0.000 wall: 0.001)
LinearSystemFactorization..........: 0.030 (sys: 0.000 wall: 0.031)
LinearSystemBackSolve..............: 0.133 (sys: 0.000 wall: 0.133)
LinearSystemStructureConverter.....: 0.000 (sys: 0.000 wall: 0.000)
LinearSystemStructureConverterInit: 0.000 (sys: 0.000 wall: 0.000)
QualityFunctionSearch...............: 0.049 (sys: 0.005 wall: 0.054)
TryCorrector........................: 0.000 (sys: 0.000 wall: 0.000)
Task1...............................: 0.014 (sys: 0.002 wall: 0.017)
Task2...............................: 0.028 (sys: 0.000 wall: 0.028)
Task3...............................: 0.002 (sys: 0.000 wall: 0.003)
Task4...............................: 0.000 (sys: 0.000 wall: 0.000)
Task5...............................: 0.002 (sys: 0.000 wall: 0.003)
Function Evaluations................: 0.439 (sys: 0.031 wall: 14.946)
Objective function.................: 0.069 (sys: 0.007 wall: 3.589)
Objective function gradient........: 0.149 (sys: 0.008 wall: 3.946)
Equality constraints...............: 0.000 (sys: 0.000 wall: 0.000)
Inequality constraints.............: 0.077 (sys: 0.009 wall: 3.686)
Equality constraint Jacobian.......: 0.000 (sys: 0.000 wall: 0.000)
Inequality constraint Jacobian.....: 0.145 (sys: 0.007 wall: 3.725)
Lagrangian Hessian.................: 0.000 (sys: 0.000 wall: 0.000)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20141113/3c184fd0/attachment.html>
More information about the Ipopt
mailing list