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

[Dominique Orban]

Hi Adela and Andreas,

Andreas Waechter wrote:
> 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?

Here's my own 10 cents: you can specify initial values for the Lagrange 
multipliers in AMPL by saying something like this in your model file:

	subject to my_constraint default 12.3: x^2 + y^2 <= 1;

This assigns the value 12.3 to the multipliers. Solvers have access to this 
value through the "pi0" component of the ASL structure.

Cheers,
Dominique