EXPO C test is flaky

[jfowkes]

I've noticed that the EXPO C test is flaky and will sometimes fail on Ubuntu with 32bit Integers:

537/799 expo+double+C - GALAHAD:expotf_c_double        FAIL       44.29s   killed by signal 11 SIGSEGV

LD_LIBRARY_PATH=/home/runner/work/GALAHAD/GALAHAD/builddir/:/opt/hostedtoolcache/Python/3.12.14/x64/lib:/home/runner/work/GALAHAD/GALAHAD/galahad/lib:/home/runner/work/GALAHAD/GALAHAD/../deps/lib:/home/runner/work/GALAHAD/GALAHAD/../CUTEst/lib
MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MESON_TEST_ITERATION=1 
ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MALLOC_PERTURB_=226 
UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 
/home/runner/work/GALAHAD/GALAHAD/builddir/expotf_c_double

We should rewrite the test so that it doesn't cause intermittent failures.

[nimgould]

Agreed. Not high priority as this code is only alpha at the moment, it is only out there so that the UNOers can play

[jfowkes]

This is most likely due to the fact that the C test is using SBLT as the linear solver rather than say SYTR and so should be an easy fix.

[nimgould]

Yes, the logs showed that the factorization used failed (status = - 10). Of course, this is an issue for slblt, but the standalone slblt tests seem to be ok

[jfowkes]

Possibly some underflow/overflow going on as expo does make use of exponential penalty functions?

[nimgould]

Locally, all seems fine:

C sparse matrix indexing

tests options for all-in-one storage format

C: 11 iterations. Optimal objective value = 2.00 status = 0
R: 11 iterations. Optimal objective value = 2.00 status = 0
D: 11 iterations. Optimal objective value = 2.00 status = 0
I: 11 iterations. Optimal objective value = 2.00 status = 0

but that is with ssids (on my branch)