COBYLA hangs

[bluescarni]

COBYLA seems to hang on the following code:

https://gist.github.com/bluescarni/bdb1981c80966ebae5d92551b605347d

Compilation command line, on 64bit linux GCC 6.3 and NLopt 2.4.2:

g++ -std=c++11 -O2 -DNDEBUG file.cpp -lnlopt -march=native

If the dimension of the problem is changed, from 150, to 149 or 151, the optimisation does not hang. If the dimension is 150, the optimisation seems to hang after ~170 objfun/constraint evaluations (strangely enough, the exact number is 171 on my Gentoo linux installation, and 175 on my Arch linux installation).

The optimisation problem is No. 5.1. from Luksan, L., and Jan Vlcek. “Sparse and partially separable test problems for unconstrained and equality constrained optimization”. It has only equality constraints.

http://folk.uib.no/ssu029/Pdf_file/Luksan99.ps

[ericjster]

For what it is worth, using NLOPT_AUGLAG with the local solver NLOPT_LN_NEWUOA or NLOPT_LN_BOBYQA, can solve this problem in about 28000 evaluations, in about 90 seconds on my machine, with ftol_rel = ftol_abs = 1e-6. I only mention this as a fellow user, if it might help to work around the infinite loop in COBYLA.

[bluescarni]

@ericjster Thanks for the pointer! I thought it might be somehow related to the equality constraints as, as far as I understand, those are not handled by the original COBYLA algorithm...

[bluescarni]

@ericjster btw, shameless plug, but if you might find our project pagmo interesting:

https://github.com/esa/pagmo2

I was writing the NLopt wrappers for pagmo when I ran into this issue.

[ericjster]

Thanks Francesco, I will check it out.

…

On Sun, Apr 9, 2017 at 5:14 PM Francesco Biscani ***@***.***> wrote: @ericjster <https://github.com/ericjster> btw, shameless plug, but if you might find our project pagmo interesting: https://github.com/esa/pagmo2 I was writing the NLopt wrappers for pagmo when I ran into this issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#118 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFXAt3c-Nov6be0gR1sxmvBQG48Iv74Pks5ruWZFgaJpZM4M3hm5> .

[virtmax]

Are there any plans to eliminate this bug?

[jschueller]

Not that I know.
There are some nans at some point propagating, for example in the z__ variable.

[jschueller]

Found it at line 1428 of cobyla.cn both sp and temp are 0.

1428          alpha = sp / temp;

Add this in your main and run gdb:

#include <fenv.h>

int main ()
feenableexcept(FE_INVALID | FE_OVERFLOW);

[aphirst]

Out of curiosity, is this division by zero also expected to cause issues if solving the same system reimplemented in a different language? (If I have time this evening, I'll attempt a rewrite in Fortran.)