What does "failed the tests for error exits" mean?

[c++matrixmadness]

I am new to LAPACK and ran the test programs to make sure the system was working correctly. In the output files I frequently got the message "failed the tests for error exits". Is this a serious problem? I searched in lawn 41 but didn't see anything on this and googled key words having to do with this message but couldn't find out what it tells me. I thought it mean that the functions tested failed to recognize that they were given illegal values, but it doesn't appear that this is the case because not all routines that didn't recognize illegal values left the message 'failed the tests for error exits".
An example of this is in the file dsep.out below:

** On entry to DSPEVDSafe minimumPrecisionMI parameter number 11 had an illegal value
** On entry to DSPEVDSafe minimumPrecisionMI parameter number 11 had an illegal value
** On entry to DSPEV Safe minimumPrecisionM^A parameter number 1 had an illegal value
** On entry to DSPEV Safe minimumPrecisionM^A parameter number 2 had an illegal value
** On entry to DSPEV Safe minimumPrecisionM^A parameter number 3 had an illegal value
** On entry to DSPEV Safe minimumPrecisionM^A parameter number 7 had an illegal value
** On entry to DSPEVXSafe minimumPrecisionM parameter number 1 had an illegal value
** On entry to DSPEVXSafe minimumPrecisionM parameter number 2 had an illegal value
** On entry to DSPEVXSafe minimumPrecisionM parameter number 3 had an illegal value
** On entry to DSPEVXSafe minimumPrecisionM parameter number 4 had an illegal value
** On entry to DSPEVXSafe minimumPrecisionM parameter number 7 had an illegal value
** On entry to DSPEVXSafe minimumPrecisionM parameter number 8 had an illegal value
** On entry to DSPEVXSafe minimumPrecisionM parameter number 8 had an illegal value
** On entry to DSPEVXSafe minimumPrecisionM parameter number 9 had an illegal value
** On entry to DSPEVXSafe minimumPrecisionM parameter number 9 had an illegal value
** On entry to DSPEVXSafe minimumPrecisionM parameter number 14 had an illegal value
*** Illegal value of parameter number 1 not detected by DSYEVX ***
*** Illegal value of parameter number 2 not detected by DSYEVX ***
*** Illegal value of parameter number 4 not detected by DSYEVX ***
*** Illegal value of parameter number 6 not detected by DSYEVX ***
*** Illegal value of parameter number 8 not detected by DSYEVX ***
*** Illegal value of parameter number 9 not detected by DSYEVX ***
*** Illegal value of parameter number 9 not detected by DSYEVX ***
*** Illegal value of parameter number 10 not detected by DSYEVX ***
*** Illegal value of parameter number 10 not detected by DSYEVX ***
*** Illegal value of parameter number 15 not detected by DSYEVX ***
*** Illegal value of parameter number 17 not detected by DSYEVX ***
*** Illegal value of parameter number 1 not detected by DSPEVD ***
*** Illegal value of parameter number 2 not detected by DSPEVD ***
*** Illegal value of parameter number 3 not detected by DSPEVD ***
*** Illegal value of parameter number 7 not detected by DSPEVD ***
*** Illegal value of parameter number 9 not detected by DSPEVD ***
*** Illegal value of parameter number 9 not detected by DSPEVD ***
*** Illegal value of parameter number 9 not detected by DSPEVD ***
*** Illegal value of parameter number 11 not detected by DSPEVD ***
*** Illegal value of parameter number 11 not detected by DSPEVD ***
*** Illegal value of parameter number 11 not detected by DSPEVD ***
*** Illegal value of parameter number 1 not detected by DSPEV ***
*** Illegal value of parameter number 2 not detected by DSPEV ***
*** Illegal value of parameter number 3 not detected by DSPEV ***
*** Illegal value of parameter number 7 not detected by DSPEV ***
*** Illegal value of parameter number 1 not detected by DSPEVX ***
*** Illegal value of parameter number 2 not detected by DSPEVX ***
*** Illegal value of parameter number 4 not detected by DSPEVX ***
*** Illegal value of parameter number 7 not detected by DSPEVX ***
*** Illegal value of parameter number 8 not detected by DSPEVX ***
*** Illegal value of parameter number 8 not detected by DSPEVX ***
*** Illegal value of parameter number 9 not detected by DSPEVX ***
*** Illegal value of parameter number 9 not detected by DSPEVX ***
*** Illegal value of parameter number 14 not detected by DSPEVX ***
*** DST routines failed the tests of the error exits ***


SEP: NB = 1, NBMIN = 2, NX = 1

All tests for DST passed the threshold ( 4440 tests run)

All tests for DST drivers passed the threshold ( 13464 tests run)


Thank you for reading this,
Harry

[Julien Langou]

Hi Harry,
Which version of LAPACK are you using? If not 3.6.1, can you use 3.6.1?
I do not have these errors in my .out files using 3.6.1. It is not great to see these errors.
Cheers,
Julien.

[c++matrixmadness]

Julien,
I am using LAPACK version 3.0 but the LAPACK test files are from version 3.6.0 and were downloaded separately. This is because LAPACK came as part of a larger software package called libMesh. I am updating to LAPACK 3.6.1 now. I will test it when it is fully updated to see if the problem went away.

For the interpretation of the test I will run I have the following questions:
I was wondering if it's a bad thing if the tests pass the threshold? I would think it's a bad thing because the tests are passing an error bound but I just wanted to make sure.
Would it be better for me to set the test ratio requirement to just above 1? According to http://www.netlib.org/xblas/ the test ratio should be below one, but I found this information on xblas, which is supposed to be extra precise, so maybe this doesn't apply directly to the LAPACK tests.

Thankfully,
Harry

[Julien Langou]

I am using LAPACK version 3.0 but the LAPACK test files are from version 3.6.0 and were downloaded separately.

Oh, I see. Well, what you are doing is not really supported. I can see many reasons why there are problems. I do not think it is worth spending time on understanding why 3.0 does not pass the 3.6.1 testing. So do not be too worried about this.

This is because LAPACK came as part of a larger software package called libMesh. I am updating to LAPACK 3.6.1 now. I will test it when it is fully updated to see if the problem went away.

Yes. Good idea.

I was wondering if it's a bad thing if the tests pass the threshold? I would think it's a bad thing because the tests are passing an error bound but I just wanted to make sure.

Yes, if you are over the threshold, this is bad. I think the threshold is 30 for now. If you see 50, this is not too bad. When you see 1e+6, there is a problem.

Would it be better for me to set the test ratio requirement to just above 1?

We have it set at 30.0 or 20.0. 1.0 is likely to be way too small and trigger a lots of errors. (Which are not really numerical failure.)

According to http://www.netlib.org/xblas/ the test ratio should be below one, but I found this information on xblas, which is supposed to be extra precise, so maybe this doesn't apply directly to the LAPACK tests.

Correct. And moreover I am not even sure what XBLAS is doing as far as check goes. So when they say "below 1", they might be speaking about something else.

Cheers,
Julien.

[c++matrixmadness]

I tested the program after updating to LAPACK 3.6.0 (My professor had difficulty upgrading to 3.6.1) and the results were exactly the same. Do I need to change the testing program in any way to get it to test the new LAPACK 3.6.0 or does this mean that there is a different problem?

Hermitian,
H a r r y
a a i -i -i
r -i r i -i
r i -i r i
y i i -i y (Harry)

[Julien Langou]

Hi Harry, sorry but it is really hard for me to help. I am not sure how to help. Julien.

[c++matrixmadness]

I am not sure how to help.

After reading some of lawn (LAPACK working note) 41 I think I know what the problems may be, and what questions to ask.

Since I obtained LAPACK through a larger program called libMesh, the libmesh creators probably did not think it was necessary to include the testing and timing routines for LAPACK. Instead they just supplied .so files and .a files (the source and object files for lapack and blas). Since these are source and object files in machine code I cannot see what is inside them or tune parameters according to the architecture of the computer. All the files I have associated with lapack and blas are as follows:
/usr/lib/libblas includes libblas.so, libblas.so.3.o, libblas.so.3.6.0, and libblas.a
/usr/lib/lapack contains lapack.so, lapack.so.3.0, lapack.so.3.6.0, and lapack.a
/usr/share/doc/liblapack-test/examples/run_lapack_tests.sh is the only testing program I have.

What I noticed is that the structure of the folders is completely different compared to that described on page 9 section 4 of lawn 41. I thought that this may be the reason for the errors. Additionally the blas may not be optimized to the machine. So my questions are as follows:
If I move my files into the same configuration as in lawn 41 section 4 page 9 could this help?
Is there a way to link .so files with the other testing functions so I can use the old source files but add testing routines?
Is there a way to make sure I am testing the new lapack 3.6.0 instead of just testing lapack 3.0 again?
Is there any documentation on testing LAPACK if it came from a third party software rather than being downloaded directly?

My proposed lapack file setup is attached as a word document.

Harry