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

[Frank J. Iannarilli]

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