AMPL loops tests fail with Ipopt (??? Lagrange multipliers instead of "dual/marginal_value")

Reported by: Owned by: VladimirVV ipopt-team normal Ipopt 3.10 normal AMPL loops sign dual values gabehack@…

Description

Ipopt returns (back to AMPL) dual variables with opposite sign as other AMPL-compatible solvers do.
Take for example simplest problem:

|x| -> min

formulated as LP-problem

#===== TestDualLP.mod ======
var x;
var z;
minimize MOD: z;
s.t. upZ: x - z <= 0;
s.t. loZ: -z - x <= 0;

Run the following AMPL-script (TestDualLP.amp, TestDualLP.mod in attach) with different value of
option solver lpsolve | snopt | knitro

#===== TestDualLP.amp ======[[BR]]
model TestDualLP.mod;
option solver lpsolve; #and with other: snopt, knitro, ipopt
solve LPp;
display x;
display upZ;
display loZ;

For lpsolve, snopt and knitro you'll get the following result, i.e. marginal value of right side of "<= p" constraint (diff(min)/diff(p)), NOT the Lagrange multiplier which is positive here !!

x = 0
upZ = -0.5
loZ = -0.5

But for
option solver ipopt
signs of duals is opposite (i.e. Ipopt returns Lagrange multiplier instead of marginal value).

x = 5.19833e-23
upZ = 0.5
loZ = 0.5

The same effect may be reproduced for simplest NLP problem with equation constraint also (TestDualQP.amp, TestDualQP.mod in attach).

#===== TestDualEq.mod ======
var x;
var y;
minimize SQ: x^2 + y^2;
s.t. eq: x + y = 2;

I have found the problem on running AMPL loops demo-scripts (http://www.ampl.com/NEW/loop2.html) with different AMPL-solvers (on Linux):
lpsolve, snopt, knitro and ipopt (Ipopt 3.10.0 (Linux 2.6.32-71.29.1.el6.x86_64), ASL(20110308)).
and found that all solvers work properly except Ipopt.

Take multi2 for instance with "option solver ipopt;" in multi2.run.

\$ampl multi2.run
fails with the following dump (final part of output and whole calculations scenario is wrong)

PHASE I -- ITERATION 3

PRODUCT bands

Error at _cmdno 104 executing "solve" command
(file multi2.run, line 39, offset 1034):
error processing param price['CLEV','STL']:
failed check: param price['CLEV','STL'] = 0.6209092318224038
is not <= 1e-06;

comment:1 Changed 16 months ago by stefan

• Resolution set to fixed
• Status changed from new to closed

We do the same in the GAMS interface.

Fixed with r2123, will be merged to to stable/3.10 and be in next release.

comment:2 Changed 16 months ago by guest

• Resolution fixed deleted
• Status changed from closed to reopened

I don't think this ticket is completely resolved. If you pose the AMPL examples in terms of maximization problems you now get the "flipped" dual values (whereas before r2123,r2131 the maximization form of the AMPL models received the correct dual values). So perhaps checking the sense of the objective is in order?

I also believe this issue involves whatever code actually copies dual values from ASL to initialize (warm-start) Ipopt. This is just a hunch, however my evidence comes from examining the behavior of Ipopt in the warm-starting example found at https://projects.coin-or.org/Ipopt/wiki/IpoptAddFeatures. When one compares the performance of Ipopt in this example before and after r2123/r2131, it suggests that the original "flipped" dual values where correct for what Ipopt collects from ASL (at least in the minimization problem form). In other words, the warm-started solve in this example requires only 3 iterations before r2123,r2131, whereas after these commits it requires 7 or 8 (basically the same amount it required in the non-warm-started solve). So again, perhaps the duals values obtained from AMPL (ASL) need to be "flipped" (possibly depending on the objective sense).

I don't have a trac account here, so my credentials are shown below:

email: gabehack@…

name: Gabe

comment:3 Changed 16 months ago by stefan

• Cc stefan@… removed
• Priority changed from high to normal
• Severity changed from major to normal

Since I do not have AMPL, I cannot test changes.

So best would be if you could send me a patch that you tested and confirmed that it works.

comment:4 Changed 11 months ago by stefan

• Resolution set to fixed
• Status changed from reopened to closed

Regarding the first point (passing the dual values back to AMPL), change r2169 introduces multiplication by -obj_sign.

Regarding the second point (retrieving dual values from AMPL), I can imagine that the same change in sign should be made from the values given by AMPL and those passed on to Ipopt. This now happens with r2170.

comment:5 Changed 11 months ago by guest

• Resolution fixed deleted
• Status changed from closed to reopened

Thank you for addressing this issue. Forgive me for re-opining once more, but I think one last patch is required for the bound multipliers returned through the zU and zL suffixes (i.e., the reduced costs). Please consider the following patch which corrects the sign for zU in the case of a min problem and corrects the sign for zL in the case of a max problem:

• Ipopt/src/Apps/AmplSolver/AmplTNLP.cpp

 const double* zU_init = suffix_handler_->GetNumberSuffixValues("ipopt_zU_in", AmplSuffixHandler::Variable_Source); for (Index i=0; i

comment:6 Changed 11 months ago by stefan

• Resolution set to fixed
• Status changed from reopened to closed

Thanks, this is now done in r2184.

Note: See TracTickets for help on using tickets.