how to test installed lapack library, quickly

[x_minus_one]

Hi,

Is there a convenient way to test a pre-packaged lapack library?

For example, if I want to test the accuracy of the lapack library included in SUSE Linux distribution, do I have to use Fortran driver routines and input data files in the test directory of original lapack source?

I am wondering if there exists some kind of Tcl/Perl/Python scripts to test installed lapack library, and quickly?

By the way, the lapack package in Debian seems to come with testing routines.

Thank you,

[Julie]

Hello,

Is there a convenient way to test a pre-packaged lapack library?
For example, if I want to test the accuracy of the lapack library included in SUSE Linux distribution, do I have to use Fortran driver routines and input data files in the test directory of original lapack source?

yes that's it,
basically you can do sthg like:

1. download lapack.tgz from netlib ( http://www.netlib.org/lapack/lapack.tgz )
2. dezippe and untar
3. > cd LAPACK
4. > cp INSTALL/make.inc.LINUX make.inc
5. edit the make.inc file so that LAPACKLIB points on the LAPACK library you want to test and BLASLIB points on the BLAS library you want to test
6. > cd TESTING
7. > make
8. then you have a look to the *.out files, they give you whether the tests succeeds or not. Some tests will fail and this is normal. A good idea is to compare with the normal lapack library from netlib. For more information on the tests that report failures see http://www.netlib.org/lapack/faq.html#1.23

I am wondering if there exists some kind of Tcl/Perl/Python scripts to test installed lapack library, and quickly?

Not that I am aware of.

Julie

[x_minus_one]

This is what I found when I followed the above instruction.

Variables BLASLIB and LAPACKLIB in `make.inc' cannot take absolute path because these variables are expanded to create relative path in makefiles in subdirectories.

So I created symlinks to `liblapack.a' and `libblas.a' in the root directory of the lapack source tree, without modifying BLASLIB and LAPACKLIB variables.

I also created a similar symlink to `libtmglib.a', which SUSE installs along with `liblapack.a' and `libblas.a'.

Test results are totally unexpected. Testing doesn't even finish in most cases.

Testing of `double' ran until end on both 32-bit and 64-bit platform; results seem to be OK. By the way, this is Pentium-4 with 64-bit extension.

Testing of `complex' and `complex16' terminated with segmentation fault on both 32-bit and 64-bit platform.

Testing of `single' ran until end on 32-bit platform, but it hang on 64-bit platform.

Now, I will have to examine what went wrong...

[x_minus_one]

Hi,

I have done more testing, and I found the followings:

SuSE 9.3 uses Lapack 3.0 source, dated May 31, 2000, without applying any patch to Fortran code files; only Make files are modified. For x86 and x86_64 platform, gcc 3.3.5 is used.

As I have mentioned in my previous post, testing script fails prematurely except for the case `double' and `single' (32-bit). The same results are reproduced when I compiled the same source of Lapack manually on Gentoo x86 (gcc 3.3.5) and x86_64 (gcc 3.4.3) platform.

I have applied the patches dated Oct 4, 2002, to the above Lapack source, and compiled it on Gentoo platform. Now, testing scripts run without error in all cases, both on 32-bit and 64-bit platform.

Hence, it is a bug (or bugs) in May 31, 2000 release of Lapack 3.0 that is causing failure during testing procedure.

Note that a compiler flag `-fno-f2c' in `make.inc.LINUX' does not seem to be the cause of the problem since SuSE rpm script overrides this flag except for building of `libtmglib.a'.

I hope this information may be useful.

Regards,

[Julien Langou]

Hello,

From g77 (v3.4.3):

The f2c calling conventions require functions that return type
"REAL(KIND=1)" to actually return the C type "double", and func-
tions that return type "COMPLEX" to return the values via an extra
argument in the calling sequence that points to where to store the
return value.

However, because the "libg2c" library uses f2c calling conventions,
g77 rejects attempts to pass intrinsics implemented by routines in
this library as actual arguments when -fno-f2c is used, ....

Yes clearly if you use 'g77 -fno-f2c' with LAPACK you will be in troubles. Your bugs are clearly reproductible (in particular in your case: 64-bit x86 with a recent version of g77).

LAPACK uses some intrinsic functions. They are provided from libg2c. If you use the option -fno-f2c, it is normal that you observe failure for the single precision arithmetic (since libg2c returns double without f2c) in 32-bit or 64-bit mode. However it is also normal that everything runs fine in double (with -fno-f2c ) in 32-bit or 64-bit mode. All this makes sense according to the documentation of g77.

Best to keep in mind:
Do not use 'g77 -fno-f2c' with LAPACK

Note that a compiler flag `-fno-f2c' in `make.inc.LINUX' does not seem to be the cause of the problem since SuSE rpm script overrides this flag except for building of `libtmglib.a'.

you sure?

just try to recompile all those libraries (even tmglib.a) without -fno-f2c (i.e. you explicitly do not write -fno-f2c in the Makefile). Then your library should pass all the testings. The Netlib archive as well. (Although having the latest patch is recommended).

Julien (Thanks George for the decryption of the g77 manual )

[x_minus_one]

Yes, you are right.

The only change I made this time is the removal of `-fno-f2c' flag from compilation of `libtmglib.a'; so, everything is compiled without this flag.

Now, all test scripts run without error, although I have tested this specification only on 64-bit platform.

It looks like SuSE 9.3 is distributing a correctly-built `liblapack.a' and an incorrectly-built `libtmglib.a'.

Thank you very much, I appreciate.