[Ipopt] Ipopt Digest, Vol 95, Issue 16

[Stefan Vigerske]

Hi,


On 11/27/2012 12:13 AM, Martijn Disse wrote:
> Dear Tony,
>
> Thank you for your extensive answer!
>
> In IPOPT it is possible to bound the solving time. In that case the exit-flag will then be -4 (at least for the C-interface).

Set the max_cpu_time option:
http://www.coin-or.org/Ipopt/documentation/node70.html

> Is there also a way of checking whether the final output variable are feasible? Obviously I could do it manually by writing a separate function, but it would be nice if IPOPT could provide this information.

I think this is not implemented.
You can get numbers like maximal constraint violation, from which you 
can then conclude whether the point is sufficiently feasible.

Best,
Stefan

>
> Best,
>
> -Martijn
>
>
>
> -----Oorspronkelijk bericht-----
> Van: Tony Kelman [mailto:kelman at berkeley.edu]
> Verzonden: vrijdag 23 november 2012 18:52
> Aan: Martijn Disse; ipopt at list.coin-or.org
> Onderwerp: Re: Ipopt Digest, Vol 95, Issue 16
>
> Martijn,
>
> Ipopt will maintain feasibility with respect to upper and lower bounds on variables, but general equality and inequality constraints are only guaranteed to be satisfied upon final convergence. If you can formulate your problem such that the feasible set is given by simple bounds, then Ipopt will be a feasible solver, otherwise it will not. Maintaining feasibility of general nonlinear equality constraints is rather difficult based on only local information, and to the best of my understanding Ipopt introduces slack variables (which are strictly positive at all times) to express all problems in terms of equality constraints and bounds. Ipopt does have a feasibility restoration feature where it does make an extra effort to initially find and finally return a feasible point, but I'm not sure whether that restoration phase gets invoked if you set a time limit and the algorithm has to terminate early.
>
> Ipopt is quite good at problems of any size in my opinion, but best when sparse Jacobian and Hessian expressions are available. Quasi-Newton Hessian approximations can be pretty good on some problems, yours is probably small enough that they're worth trying. Your problem is on the small side, but the fact that you have quite a few more inequality constraints than variables could influence your choice of solvers, depending on the structure of those inequalities. Looking into better ways of calculating gradient, Jacobian, and Hessian will help for basically any solver. Can you use a modeling language like AMPL (which would also allow you to switch between solvers and compare performance very easily) to express your problem, or are the objective and constraints coming from some black-box simulation you don't have access to the structure of?
>
> -Tony
>
> -----Original Message-----
> From: Martijn Disse <M.W.Disse at student.tudelft.nl>
> Date: Tue, 20 Nov 2012 17:31:07 +0000
> To: ipopt mailing list <ipopt at list.coin-or.org>
> Subject: [Ipopt] IPOPT versus other NLP solvers
>
> Hi Everyone
>
> In my research I am using IPOPT in a critical real-time model predictive control application. I have made a comparison, based on literature, between possible NLP solvers, but found it hard to find all the required information. It would be great if you could provide some quick feedback on the statements below.
>
>>From what I understand there is a distinction between feasible and
>> infeasible solvers. Infeasible solvers (e.g. NPSOL) do not necessarily
>> satisfy the nonlinear constraints until an optimal solution is reached.
>> This is not an ideal situation for critical real-time trajectory
>> generation problems in that a feasible solution is better than none at
>> all. Feasible solvers will stay within the feasible set for every
>> iteration, or at least will put more effort in doing so compared to
>> infeasible solvers. Is IPOPT a feasible solver?
>
>>From what I understand IPOPT is most suited for large NLP problems. My
>> problem consist of around 100 inequality constraint, 7-30 decision
>> variables and 3 equality constraints. Evaluation of the cost and
>> constraint functions and there derivatives is computationally extensive
>> due to finite-difference methods use (Jacobina and Hessian by IPOPT,
>> full-not sparse. Gradient by my own algoritm). Does this make the problem a "small"
>> problem and less suited for IPOPT?
>
> Could you provide me with some feedback on the statements above? I would really appreciate it.
>
> Best regards,
>
> -Martijn
>
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>