[Coin-ipopt] Precision Init of Vars in Equality Constraints is Key!?

Frank J. Iannarilli franki at aerodyne.com
Thu Mar 24 00:09:25 EST 2005

Hi All,

I've noticed that if I submit problems to IPOPT with imprecisely set 
initialization values, for variables appearing in equality constraints, 
that IPOPT can run very much longer, and perhaps more poorly!

Of course, all constraints get slacks to convert to equality constraints, 
but I'm referring to user-defined equality constraints.  For example:

  s.t. Sum{j=1..N} w[j] = 1

  N=9, e.g., initialize w[j] = 1/N = 1/9 ~ 0.1111...

1/9 cannot be exactly represented in floating point, so the constraint is 
not initially satisfied.

For a given problem I'm playing with, I tried running per above, then 
initializing w[j] with exactly representable floating point values such 
that they summed precisely to 1.  The differences in execution:

75 iterations, 390sec CPU


135 iterations, 560sec CPU,
at iteration 48: filter: Setting LAMBDA to zero after restoration phase
after final iteration 135:
 Restoration started with CNRM =   1.96217842E-09
 filter: Error: resto_filter returns IERR =  18
 solve_barrier: filter returns IERR =  18
 mainloop: Error: solve_barrier ends with IERR =  18

and non-negligible dual infeasibility.

Is this to be expected, and do I have the proper casual "explanation"?


Frank J. Iannarilli, franki at aerodyne.com
Aerodyne Research, Inc., 45 Manning Rd., Billerica, MA 01821 USA

More information about the Coin-ipopt mailing list