[Coin-ipopt] wrong Lagrange-Multiplier
andreasw at watson.ibm.com
Thu Jun 30 17:14:30 EDT 2005
Since you are now the second one to complain about this, I fixed it.
The problem is that there is not a unique definition of the Lagrangian
function, and the sign of the constraint might be chosen differently.
Our sign was the opposite of what AMPL assumes, and therefore things were
incorretly returned to AMPL. Now Ipopt returns what AMPL expects, and -
voila - the multipliers seem correct. And since we didn't increase the
version number of Ipopt for a while, it is now upgraded to 2.2.1e. :)
The corrected code has is submitted to the CVS repository, so you can get
the new version from CVS, or you wait until tomorrow to have the new
version in the tarball.
The Ipopt solver available via NEOS is already corrected.
Comparing now the output of Ipopt and Loqo gives the same value of the
multiplier (at least via NEOS) for ug7. However, Ipopt correctly reports
that some other multipliers (particularly for ug9 and ug14) are not zero
as well (which makes sense since those are active), whereas Loqo claims
they are zero...
Thanks for making us aware of this...
On Thu, 30 Jun 2005, Karsten Theissen wrote:
> Dear Andreas and all Ipopt-users,
> checking a very simple NLOP, we found out that Ipopt calculate a wrong sign
> and wrong value of one Lagrange-Multiplier.
> In the following example (see attached aufg43a.mod) the value of ug7 should
> ug7 = 48.9
> This could be calculated by the Kuhn-Tucker-condition. Testing the problem
> with LOQO gives us the right value 48.9.
> Did you know what is happening here?? Our ipopt-output can be found in the
> attached file aufg43a.out.
> Karsten Theißen
More information about the Coin-ipopt