[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:
Precise:
75 iterations, 390sec CPU
-----
Inprecise:
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"?
Regards,
Frank J. Iannarilli, franki at aerodyne.com
Aerodyne Research, Inc., 45 Manning Rd., Billerica, MA 01821 USA
www.aerodyne.com/cosr/cosr.html
More information about the Coin-ipopt
mailing list