[Coin-ipopt] "strange" behavior with Ipopt

[Andreas Waechter]

Hi,

Just a belated addition to Stefan's explanation:

Due to rounding error, it often matters in which order floating point 
operations are done.  Usually, the difference might only be on the order 
of machine precision, over several iterations they might accumulate.  And 
then a test like "<=" might be true in one case but not the other, and 
from then on the algorithm might take truely different paths.

I even observed strongly different behavior between the code when it was 
compiled in debug or optimized mode, or when I run it on a different 
operation system.  This is an annoying feature that can make debugging to 
a nightmare...

Andreas

On Fri, 18 Jan 2008, Stefan Vigerske wrote:

> Hi,
>
> Edson Cordeiro do Valle wrote:
>>           Hello
>>   I have been with a "strange" behavior with Ipopt. I have 3 groups of
>> inequality constraints, they are grouped because they have similar
>> equations. When I change the order which they are added to the
>> optimization problem, the solver converges to different optima (I have
>> found 2 of them). In one of the permutations, the problem reaches the
>> maximum number of iterations and does not converge.
>> My question is: Is this behavior normal or, based on the algorithm, it
>> is possible to happen?
>
> I think this is normal, esp. if the problem is not convex.
> E.g., if the solver at some point picks a dual variable that is maximum
> among all others, and the maximum is not unique, then it can depend on
> the ordering of the constraints what happens next.
> Or factorizations change when the ordering of the constraints is
> different, and thus yield to different iterates.
>
> Stefan
>
> -- 
> Stefan Vigerske
> Humboldt University Berlin, Numerical Mathematics
> http://www.math.hu-berlin.de/~stefan
> _______________________________________________
> Coin-ipopt mailing list
> Coin-ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-ipopt
>