[Help-gsl] nmsimplex2 gets stuck when nmsimplex doesn't

[Neil Stewart]

I'm having trouble with the new Nelder Mead simplex algorithm and I think I
may have found a bug. The algorithm initially crawls down hill successfully
for several hundred iterations, but them seems to collapse and get stuck.

Below are the vertices for one iteration of the stuck simplex. The problem
has 14 parameters (the first 14 columns; the final column is the function
value being minimised). The 16 rows are the 16 times the to-be-minimised
function was called during a single gsl_multimin_fminimizer_iterate().
Notice how, after the first two rows, all of the remaining rows are
identical. The simplex has collapsed to a single point.

The algorithm will run indefinitely, repeating these vertices over and over.
Different random starting points nearly all end up here, or in another
similar pattern. Restarting the algorithm from here with a bigger simplex
size kicks it on, but it collapses again at a different point.

0.03242 0.30522 0.63573 0.90886 0.00071 0.00181 0.00612 0.03337 0.12715 0.00038 
0.04802 0.16050 0.41929 0.62331 5.34309
0.03269 0.29779 0.62830 0.90143 0.00077 0.00194 0.00626 0.03461 0.12125 0.00039 
0.04927 0.15408 0.41190 0.61599 5.31868
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702
0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929 0.00040 
0.04969 0.15194 0.40944 0.61355 5.31702

(I've omitted some decimal places, but the last 14 rows are identical to at
least 18 decimal places.)

I'm using the new gsl_multimin_fminimizer_nmsimplex2 algorithm. Switching
back to the original gsl_multimin_fminimizer_nmsimplex algorithm (notice the
missing 2 at the end) fixes the problem. The original algorithm always
converges on the same minimum, even when started from many different
starting points, which is nice.

The collapse of the simplex into a single point seems like a bug in
gsl_multimin_fminimizer_nmsimplex2. Any comments most welcome.