[Coin-ipopt] Influencing the dual variable

Oliveira, Ivan B ivan.b.oliveira at intel.com
Fri Nov 11 15:43:52 EST 2005


Thanks, Andreas.

I think the warm_start_init_point will be all we need for now.  If we
find that we'd like to influence the algorithm's estimation of the dual
variables I think we have a plan to do so.

Thanks again,

--Ivan.
 
----------------------------
Ivan B. Oliveira
SC12-205
(408)765-0584
 

-----Original Message-----
From: Andreas Waechter [mailto:andreasw at watson.ibm.com] 
Sent: Wednesday, November 09, 2005 2:33 PM
To: Oliveira, Ivan B
Cc: Carl Damon Laird; coin-ipopt at list.coin-or.org
Subject: RE: [Coin-ipopt] Influencing the dual variable

Hi Ivan,

I finally had a look at your exchange with Carl more closely...

The current official release already has an option called
"warm_start_init_point" that you can set to "yes", if you want to
provide
to Ipopt not only the primal variables, but also the multipliers at the
starting point.  The code is in IpWarmStartIterateInitialize.cpp.  There
are some more options related to this, so far undocumented.

At the time when we released the official version, we didn't set this
very
well and didn't document it, but it might work.  You can give it a
try...
The next release will still have that option, but a number of underlying
things might have changed.

This allows you to change the initial variables for the algorithm.
There
is no intention to offer the possibility to change the variables at
later
points, since it would intefere with the algorithm (Newton's method) and
not make much sense, unless you know exactly what to do.  But if that is
the case, it has to be embedded carefully into the algorithm, and the
callback functions for evaluating NLP functions or derivatives are not
the
right place.

I hope this helps,

Andreas

On Wed, 2 Nov 2005, Oliveira, Ivan B wrote:

> Hi Carl,
>
> 	right now it always sets the
> 	init_lambda flag to false
>
> Quite right - I noticed this in the code but did know if I had
> misinterpreted the meaning of the init_lambda flag.  I think we're on
> the same wavelength.
>
> As long as I understand that this is the case I feel comfortable
> temporarily changing my version to allow me to do this.  But it would
be
> a nice feature to be implemented in the release once you have the
time.
>
> As for influencing (note I prefer this weaker statement than
'changing'
> :) the dual variables *during* iterations - I take it from you answer
> there is no plan to support such a thing?
>
> Thanks,  (You guys are doing a great job!)
>
> --Ivan.
>
> ----------------------------
> Ivan B. Oliveira
> SC12-205
> (408)765-0584
>
> -----Original Message-----
> From: Carl Damon Laird [mailto:claird at andrew.cmu.edu]
> Sent: Tuesday, November 01, 2005 9:16 PM
> To: Oliveira, Ivan B
> Cc: coin-ipopt at list.coin-or.org
> Subject: Re: [Coin-ipopt] Influencing the dual variable
>
> Hi Ivan,
>
> First, I will assume that you are using the TNLP interface class
(there
> are others, but this is the "standard" one). The interface does allow
> you
> to set initial values for the multipliers (but never to "change" them
> during the iterations).
>
> You will notice that the get_starting_point method:
>
>      virtual bool get_starting_point(Index n, bool init_x, Number* x,
>                                      bool init_z, Number* z_L, Number*
> z_U,
>                                      Index m, bool init_lambda,
>                                      Number* lambda)=0;
>
> If the options are such that your NLP needs to provide initial values
> for
> the equality multipliers (lambda), then init_lambda will be true and
you
>
> can put the values into the lambda vector (likewise for the bound
> multipliers z_L and z_U).
>
> That was the intent of the design. Now, having said that, I looked
> through
> the code and I do not see any option that you can set that will
actually
>
> cause IPOPT to ask for the multipliers, right now it always sets the
> init_lambda flag to false (other than a bleeding edge warm start
> feature).
> I apologize for this oversight.
>
> I don't see any reason why it would not be easy for us to add the
> option(s) to allow user initialized lambda, and z_L and z_U values. I
> will
> be out of town until early next week, but I can implement these
options
> then. Again, sorry for the oversight, we should have had this in
place.
>
> Any additional comments Andreas?
>
> Thanks for the post,
>
> Carl Laird.
>
> On Tue, 1 Nov 2005, Oliveira, Ivan B wrote:
>
> > Hi guys,
> >
> >
> >
> > It doesn't seem possible to either initialize or change the value of
> > dual variables during the optimization in the C++ implementation of
> > IPOPT.  Seems all the callbacks have a const in the signature, and
the
> > code does not seem to provide hooks to influence the iterations
> between
> > evaluations.  Is this correct?  Are there any workarounds you can
> > suggest?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > --Ivan.
> >
> >
> >
> > ----------------------------
> >
> > Ivan B. Oliveira
> >
> > SC12-205
> >
> > (408)765-0584
> >
> >
> >
> >
>
> _______________________________________________
> Coin-ipopt mailing list
> Coin-ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-ipopt
>






More information about the Coin-ipopt mailing list