[Ipopt] UMFPACK & IPOPT

[Andreas Waechter]

Indeed, it doesn't look like UMFPACK, as non-symmetric solver, would 
have any way to compute the inertia.

There is one variant implemented in Ipopt ("inexact-solver" - it is not 
documented, since not as stable and robust as we would like) that can 
work with an iterative linear solver, which would also not return the 
inertia.  To make this work, there is another mechanism to trigger a 
modification of the Hessian matrix to handle nonconvexities.  In 
principle, one could use this variant with an direct linear solver as 
well, which would then not need to return the inertia.  However, it 
would require quite a bit of knowledge of and digging into the Ipopt 
code to make that happen.

In any case, as Jonathan suggested, before spending a lot of time 
writing any code, it would make sense to do some experiments and test 
the general performance.  On additional issue might be that the linear 
systems in Ipopt are getting extremely ill-conditioned towards the end 
of the optimization, due to the barrier approach.  If one uses a 
symmetric indefinite direct linear solver, this doesn't hurt the quality 
of the solutions.  However, I suspect that a non-symmetric solver might 
have difficulties obtaining sufficiently accurate solutions of the 
linear system at the end of the optimization (in case there are active 
inequality constraints).  I have no data or experiments to back this up, 
but I believe to remember form tests that I did long time ago, that 
non-symmetric solvers didn't work in this context.

Regards,

Andreas


Andreas Waechter

Associate Professor
Department of Industrial Engineering and Management Sciences
McCormick School of Engineering
Northwestern University
Evanston, IL 60208
USA


On 02/17/2012 09:58 AM, Jonathan Hogg wrote:
> It is not obvious to me that using UMFPACK as the solver in Ipopt 
> would be easy or desirable.
>
> Not Easy: having a quick scan of the documentation, it doesn't look 
> like it would easily offer up the inertia (unless I've missed something).
>
> Not Desirable: You take a hit of doing twice as much work and using 
> twice as much memory as you are no longer exploiting symmetry (UMFPACK 
> produces an LU factorization, while other solvers used by Ipopt 
> produce LDL^T). You may also find that the fill-in is worse, slowing 
> you down even further - I'd advise some quick experiments to determine 
> if this is a killer before you start implementing a proper Ipopt 
> interface.
>
> Jonathan.
>
> On 17/02/12 15:38, Sylvain Auliac wrote:
>> Hello again,
>> I know this question as already been discussed, but as the last mail 
>> about that I have seen searching in google was written in 2009 there 
>> maybe has been some new things... So, does someone was able to write 
>> an interface to link IPOPT with the UMFPACK solver ?
>> I am actually trying to do that (because the software in which I am 
>> linking IPOPT use UMFPACK), but if I could spare some time it would 
>> be nice...
>>
>>
>> Sylvain Auliac
>> Laboratoire Jacques-Louis Lions
>> Université Pierre et Marie Curie
>> mail: auliac at ann.jussieu.fr
>> tel : 01 44 27 71 70
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ipopt mailing list
>> Ipopt at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/ipopt
>