Review of the MA27 interface

[cvanaret]

Fixed following bugs:

• ikeep has size 3n, not 3nnz;
• the member factor that initially contains the matrix entries, then the factors after a call to MA27BD, must be initialized in do_numerical_factorization(). This solves the issue with the byrdpreset on hs015 mentioned in MA27 interface #115.

Cleaned up the factorization function (replaced recursive calls with while loop).

cc @worc4021

[worc4021]

Oh dear! Amateur issues! Good spot! Very strange that valgrind didn't notice the size issue.

I noticed that we're now copying the entries of the matrix into the factor array twice. We call save_matrix_to_local_format from do_symbolic_factorization but then somehow left it being overridden with the copy from the matrix. Potentially wasteful to be doing both..?!

[cvanaret]

I noticed that we're now copying the entries of the matrix into the factor array twice. We call save_matrix_to_local_format from do_symbolic_factorization but then somehow left it being overridden with the copy from the matrix. Potentially wasteful to be doing both..?!

Absolutely! It turns out we actually get the sparsity pattern from the ASL function sphsetup (called once at the beginning). I'll refactor so that we can query it, store it in the appropriate sparse format once and for all, then we'll work only with the matrix entries from then on.

[worc4021]

The while loop is a good idea! However, I would introduce an upper limit on how often it can reallocate memory. When Hessians have illegal values in them e.g. a nan in ipopt you can get the linear solvers run off with your memory - the solvers don't check for this. They hopelessly keep trying to reallocate and refactor and eventually your whole process dies, but the longer the work vectors get the slower each round becomes.

[cvanaret]

Good idea. I would set an upper bound of (say) 5 factorization attempts, and I would check the Hessian values beforehand ;)