[Ipopt] Warm start

[Tom Vacek]

Thanks to all who replied about this.  I have a little more of the 
story.  You can find a sparsity plot of the iteration matrix at 
http://www.cs.umn.edu/~vacek/sparsityPattern.png.  The problem has been 
formulated so that the iteration matrix has this special form, which 
should be easy to factorize.  Ma57 was taking about 50 seconds to 
factorize this matrix in Ipopt, versus about 7 seconds with Matlab ma57, 
so I'm trying to hunt down the cause of the difference.

My goal was to use warm start as a sort of debugger, so that I could 
examine the iteration matrix in Matlab at each step (or so), and try to 
understand how different orderings affect factorization time.

Perhaps I should just ask directly:  What might account for the 
difference in factorization time?  Perhaps there's an integer overflow 
in the 32-bit (Ipopt) ma57 which does not happen in Matlab's 64-bit.

Thanks,

Tom

On 04/21/2011 10:17 AM, Andreas Waechter wrote:
> Hi Tom,
>
> I'm a little surprised you need to manually reorder the matrix given 
> to the linear solver...  Usually, those codes try to find a suitable 
> ordering themselves, although this works differently well.  Have you 
> tried a different linear solver?  Also, I don't quite understand why 
> you need to change the ordering during the optimization - is the 
> nonzero structure changing between iterations?
>
> In any case, there are different levels of warm-starting Ipopt.  One 
> is to use the warm_start_init_point option and to supply values for 
> primal and dual variables.  However, since you are probably working 
> with the TNLP interface, this does not restore exactly how things 
> where in Ipopt internally at the end of the previous run (e.g., after 
> an eary stop after 10 iterations).   The thing is that Ipopt 
> internally works with an "NLP" and there is some translation done 
> between the TNLP and the NLP.  To really restore the iterate, you 
> could try to use a hidden and unsupported feature of Ipopt, using the 
> warm_start_entire_iterate option.  But this is somewhat complicated, 
> and you would have to dig through the code and see how it works.  We 
> implemented this in the context of the MINLP solver Bonmin, where it 
> had been used at some point, and you could look at that as an example, 
> but I'm not sure if the code in Bonmin is currently woring. If you 
> wanted to try that approach, look at the files
>
> Bonmin/src/Interfaces/BonTMINLP2TNLP.cpp
> Bonmin/src/Interfaces/Ipopt/*pp
>
> for a start, the code surrounding the get_warm_start_iterate method.
>
> In addition, you can use the mu_init option to set the initial value 
> of the barrier parameter in your restart to what you had when you 
> stopped Ipopt the last time.
>
> Hope this helps,
>
> Andreas
>
> On Tue, 19 Apr 2011, Tom Vacek wrote:
>
>> Hello all,
>>
>> I have a problem that has some symmetries that can be exploited in order
>> to reduce pivoting.  The problem has a diagonal Hessian, so my goal is
>> to reorder the variables in the problem so that the elements that need
>> pivoting are at the end of the diagonal, where they will cause the least
>> fill-in (using ma57).
>>
>> Optimally, the reordering would be done at each iteration.  I hacked
>> this out using warm start (reordering every 10 iterations).  It works
>> remarkably well given that most iterations are wasted rediscovering the
>> barrier parameter from before the reordering.  Clearly, I need a better
>> way to restart the solver.  Does anyone have any advice for me?
>>
>> Thanks,
>>
>> Tom
>>
>> _______________________________________________
>> Ipopt mailing list
>> Ipopt at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/ipopt
>>
>>