[Coin-ipopt] Re: IPOPT + warm-start

[Andreas Waechter]

Hi Adela,

Please send messages regarding Ipopt to the Ipopt mailing list 
(http://list.coin-or.org/mailman/listinfo/coin-ipopt).  I'm copying my 
answer to it now.   (Note, if you haven't signed up yet, you need to 
subscribe first before you can post messages.)

> I'm Adela Pagès from the Universitat Politècnica de Catalunya (Barcelona, 
> Spain). Currently our research group is trying to solve a quadratic binary 
> mixed problem by relaxing the integrality constraints and adding some 
> quadratic constraints. The model comes from the merging of a power generation 
> planning problem (which is quadratic and continuous) and a maintenance 
> scheduling problem (which is linear and binary).
>
> We implemented our strategy in AMPL and we use IPOPT as a solver. Given that 
> the initial point is very important for achieving good solutions, I wish to 
> try some warm-start techniques.
>
> I don't know which is the better way to do the variable initialization and I 
> wonder if you would give me some advice on the following questions:
> * I can see different results if the 'warm_start_init_point' option is 'yes' 
> or 'no'. However, if I print the _var.init0 and _con.dinit0 the result is 
> always 0. I understand that IPOPT is using always the primal variable 
> initialization and dual information only if  'warm_start_init_point' option 
> is 'yes'. Am I right?
> * Is it possible to initialize the reduced costs of the variable bounds 
> component-wise?
> * Is there any document/examples/guidelines in which I could learn how to 
> implement my own warm-start? Or how to retrieve information of an iterate 
> that satisfies some conditions? I have to admit that my knowledge on C++ 
> programming is very basic.

You bring up a good point.

Carl Laird was the one who initially wrote that AMPL interface, and I'm 
not completely familiar with everything he did there (so it might be good 
if he could chip in).  However, here my 10 cents:

It seems to me that the following is currently happening:

When you solve a problem for the first time, AMPL is giving only the value 
for the primal variables to Ipopt.  If you then rerun the problem (or a 
related problem), Ipopt gets the values of what is currently in _var.val 
as initial values for the primal x variables.  Ipopt also receives the 
content of _con.dual as possible initial values for the constraint 
multipliers.  Those values are only used by Ipopt, if you choose 
"warm_start_init_point yes".  (I have no idea what the meanings of init0 
and dinit0 are... they seem to be always zero...?)

At this point, I don't see how one could possibly assign different initial 
values for the contraint multipliers, and I also don't see how initial 
dual values could be given to Ipopt for the bound constraint multipliers.

Maybe there are standard ways to do this, and I just don't know them, 
since I'm not so familiar with AMPL.  However, if there is no standard way 
how other solvers receive this information, we could find a workaround 
using "suffixes".  Here, you would define a new suffix in your AMPL model, 
and after some changes in the Ipopt AMPL interface code (AmplTNLP.cpp), 
Ipopt could check of you have set values for those suffixes, and then use 
that information for a warm start.

Does anyone else reading this mailing list have an idea what might be the 
easiest and most elegant way to do this?

Thanks,

Andreas