[Coin-ipopt] (no subject)
Andreas Waechter
andreasw at watson.ibm.com
Wed Nov 9 14:27:04 EST 2005
Hi Danh,
>From the output we can see that the linear solver used in Ipopt (MA27 in
your case) keeps running out of memory, so that Ipopt allocates more and
more for it, until it finally exceeds what the system can give it.
This usually happens when the linear solver creates a lot of fill-in
during the factorization, and this can be a consequence of an either very
degenrate problem, but since in your case this happens already in the
first iteration and repeatedly later, it is more likely that your problem
is very badly scaled.
You might want to revisit your problem formulation, in particular the
constraints. Ideally, the "typical" values in the Jabocian should be on
the order of 1 to 10. Ipopt has an automatic scaling heuristic that
scales down constraints when values on the Jacobian are more than 100, but
the output shows us that this is not the case in your problem. Instead,
maybe a large number of values in the Jacobian are actually tiny?
Sometimes, it can also happen that the starting point is chosen badly, so
that the Jacobian at that point leads to very small values in the
Jacobian, even though typically they are not small (e.g., if you have
terms like x1*x2, and choose x1=x2=0 as the initial point). Looking at
the Ipopt output, we can see that the initial constraint violation is on
the order of 5 million, so maybe you can come up with a better starting
point that is less infeasible. (That might be a good idea anyway).
If you want to improve the scaling of your problem formulation, you can
change the entries in the Jacobian by either multiplying constraints with
a constant. E.g., if a constraint looks like
1e-5*x1 + 4e-5*x2 = 0
you should multiply it by 1e5. On the other hand, if your variables
correspond to different (physical) quantities in different unit, changing
the scale of variables may help. E.g., if you have the two constraints
3*x1 + 1e-5*x3 = 0
4*x2 - 4e-6*x3 = 0
then replace x3 by 1e6*y3 (in the constraints and of course in the
objective function, and adapt the bounds accordingly).
A third possibility why MA27 creates to much fill-in could be that the
sparsity structure of your problem just leads to many nonzeros in the
factors (this could be if your problem is not structured). In that case
there is not much you can do (but I doubt that this is the case), and
maybe only using a different linear solver might be the solution (remember
that MA27 is rather old...). We are currently working on the integration
of the linear solver Pardiso into the C++ version of Ipopt, but that is
not ready yet.
I hope this helps,
Andreas
On Wed, 9 Nov 2005, Nguyen An Danh wrote:
> Hi,
> Could you show me how to overcome this difficulty. I performed the following
> problem on Linux system of 4Gb.
> Thank you in advance.
> Danh.
>
> Parameter IMAXITER has multiple assignments - using 0.10000D+05 .
> ******************************************************************************
> This program contains IPOPT, a program for large-scale nonlinear optimization.
> IPOPT is released as open source under the Common Public License (CPL).
> For more information visit www.coin-or.org/Ipopt
> ******************************************************************************
>
> Going to allocate double precision work space of size 13343572
> integer work space of size 19017588
>
>
> Number of variables : 112001
> of which are fixed : 0
> Number of constraints : 26955
> Number of lower bounds : 1
> Number of upper bounds : 16000
> Number of nonzeros in Jacobian: 1880872
> Number of nonzeros in Hessian : 432001
> get_scale: |g|_inf = 1.00000000000000
> get_scale: QFSCALE = 1.00000000000000
> get_scale: smallest CSCALE = 1.00000000000000
> get_scale: No scaling of constraints necessary
>
> ITER ERR MU ||C|| ||YPY|| ||PZ|| ||D|| ALFA(V)
> ALFA(X) NU #LS F #cor Regu CPU(s)
> 0 .605D+05p .100D+00 .506D+07 .000D+00 .000D+00 .000D+00 .000D+00 .000D
> +00 .000D+00 0 -.67500332D+01 0 .000D+00 .496D+01
> ma27_call: LIWMA increased from 6129572 to 24785287
> ma27_call: LA increased from 8522302 to 24785287
> ma27_call: LIWMA increased from 24785287 to 68396777
> ma27_call: LA increased from 24785287 to 68396777
> Constraints not dependent.
> Hessian not dependent.
> 1 .594D+05p .100D+00 .496D+07 .000D+00 .000D+00 .506D
> +07 .164D-06d .187D-01f .000D+00 1 -.67500341D+01 1 .100D-03 .361D+03
> 2 .594D+05p .100D+00 .496D+07 .000D+00 .000D+00 .496D
> +07 .186D-01p .191D-03h .000D+00 1 -.67500340D+01 14 .699D+14 .677D+03
> 3 .594D+05p .119D+05 .496D+07 .000D+00 .000D+00 .496D
> +07 .188D-01r .184D-05- .000D+00 2 -.67500340D+01 10 .489D+24 .987D+03
> filter: Request reinitialization of LAMBDA.
> 4 .939D+05p .100D+00 .495D+07 .000D+00 .000D+00 .709D
> +09 .778D-03r .582D-02f .000D+00 1 -.10783351D+02 0 .000D+00 .990D+03
> 5 .939D+05p .188D+05 .495D+07 .000D+00 .000D+00 .495D+07 .981D
> +00r .629D-05- .000D+00 4 -.10783351D+02 1 .163D+24 .129D+04
> 6 .176D+06c .188D+05 .511D+07 .000D+00 .000D+00 .151D+10 .100D
> +01r .146D-03f .000D+00 1 -.10966326D+02 0 .000D+00 .129D+04
> 7 .111D+06c .188D+05 .495D+07 .000D+00 .000D+00 .248D+07 .930D+00r .111D
> +00f .000D+00 1 -.10966558D+02 0 .000D+00 .129D+04
> 8 .992D+05p .188D+05 .486D+07 .000D+00 .000D+00 .162D+07 .926D+00r .161D
> +00f .000D+00 1 -.10966580D+02 0 .000D+00 .130D+04
> 9 .992D+05p .188D+05 .481D+07 .000D+00 .000D+00 .111D+07 .925D+00r .167D
> +00f .000D+00 1 -.10966531D+02 0 .000D+00 .130D+04
> filter: Request reinitialization of LAMBDA.
>
> ITER ERR MU ||C|| ||YPY|| ||PZ|| ||D|| ALFA(V)
> ALFA(X) NU #LS F #cor Regu CPU(s)
> 10 .992D+05p .100D+00 .479D+07 .000D+00 .000D+00 .806D+06 .923D+00r .184D
> +00f .000D+00 1 -.10966668D+02 0 .000D+00 .130D+04
> Largest entry in LAMBDA is too large: 164122.020999873
> Setting LAMBDA to zero.
> ma27_call: LIWMA increased from 68396777 to 173579105
> ma27_call: LA increased from 68396777 to 173579105
> ma27_call: LIWMA increased from 173579105 to 563262077
> ma27_call: LA increased from 173579105 to 563262077
> ma27_call: LIWMA increased from 563262077 to 2079614087
> ma27_call: LA increased from 563262077 to 2079614087
> get_step_full: IP_MALLOC returned -1 for KKT (realloc)
> solve_barrier: get_step_full returns IERR = 96
> mainloop: Error: solve_barrier ends with IERR = 96
>
> Number of iterations taken ............. 10
> Final value of objective function is....-0.1096666791164388D+02
>
> Errors at final point (scaled) (unscaled)
> Final maximal constraint violation is... 0.992242D+05 0.992242D+05
> Final value for dual infeasibility is... 0.332702D+04 0.164129D+06
> Final value of complementarity error is. 0.323538D+05 0.428481D+07
>
> The objective function was evaluated 17 times.
> The constraints were evaluated 17 times.
>
> EXIT: Error during dynamic memory allocation
>
> CPU seconds spent in IPOPT and function evaluations = 3303.3800
>
>
> An error occoured after 10 Iterations.
> The error code is 96
>
> _______________________________________________
> Coin-ipopt mailing list
> Coin-ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-ipopt
>
More information about the Coin-ipopt
mailing list