Gfortran and Lapack 3e

[jkb]

Hello,

I'm trying to build lapack 3e with gfortran (4.0.1) without any success. I use a Sparc32 workstation (sun4m) running Linux Debian Testing and I have modified config.inc file:

FORTRAN = gfortran-4.0
F90 = gfortran-4.0
F90OPTS = -O3
CC = gcc
OPTS = -O3
COPTS = -O3
DRVOPTS = $(OPTS)
NOOPT =
REAL32 = -DLA_REALSIZE=4
LOADER = gfortran-4.0
LOADOPTS =

Make returns:
...
gfortran-4.0 -O3 -c -o la_dormr3.o la_sormr3.F
gfortran-4.0 -O3 -c -o la_dsygs2.o la_ssygs2.F
gfortran-4.0 -O3 -c -o la_dsytd2.o la_ssytd2.F
m4 -DLA_SC -DLA_DZ la_auxiliary.m4 > la_auxiliary.f
gfortran-4.0 -O3 -c la_auxiliary.f
In file la_auxiliary.f:4

USE LA_DZAUXILIARY
1
Error: Name 'la_larfb' at (1) is an ambiguous reference to 'la_larfb' from module 'la_scauxiliary'

If I only write in make.inc:
M4FLAGS = -DLA_DZ
gfortran-4.0 -O3 -c la_auxiliary.f works but when the process try to build library, it hangs because simple precision subroutines are not available.

Any idea ? Thanks in advance,

JKB

[Julie]

Hello,

I managed to reproduce your error using gfortran when compiling LAPACK3E.

With g95 ( http://g95.sourceforge.net/) LAPACK3E is compiling and works fine. Could you try that to see if it runs fine on your machine?

We need to investigate what the problem is with gfortran and LAPACK3E. Thank you for pointing out that problem.

Julie Langou

[Ed Anderson]

The common source features of LAPACK3E depend on the Fortran 90 compiler's support for overloading a generic interface. This is a standard language feature. Through the use of compiler options, a single source module is compiled into at least two and as many as four different modules for the four different data types, 32-bit REAL, 64-bit REAL, 32-bit COMPLEX, and 64-bit COMPLEX, all of which define the same generic interface for a subroutine.

The last gnu compiler I tried did not allow the same generic module name to be defined in more than one module. Without this feature, you can't compile LAPACK3E. The commercially available compilers from IBM, Cray, Sun, SGI, and Intel all support modern Fortran language features.

Ed Anderson

[jkb]

[quote]Hello,

I managed to reproduce your error using gfortran when compiling LAPACK3E.

With g95 ( http://g95.sourceforge.net/) LAPACK3E is compiling and works fine. Could you try that to see if it runs fine on your machine?

We need to investigate what the problem is with gfortran and LAPACK3E. Thank you for pointing out that problem.

Julie Langou[/quote]

Thanks for your answer, Julie. I cannot directly use g95 because I use Lapack in a big program (RPL/2 : http://www.systella.fr/~bertrand/rpl2) and I have to use a portable and stable compiler. I have some trouble with eigenvalues and Lapack and I would try if the trouble is the same with lapack3e.

Example : computation of det(matrix)
2: [[ 4 31 18 27 2 29 ]
[ 22 13 36 9 20 11 ]
[ 3 30 14 23 7 34 ]
[ 21 12 5 32 25 16 ]
[ 35 8 10 19 33 6 ]
[ 26 17 28 1 24 15 ]]
1: 0
Result is good.

If I try to compute the determinant of the mat*mat, I obtain :
2: [[ 2143 1900 2407 1732 2191 1948 ]
[ 1657 2386 1921 2218 1705 2434 ]
[ 2326 1813 2467 1576 2326 1813 ]
[ 2326 1813 1738 2305 2326 1813 ]
[ 2056 2083 1651 2488 2008 2035 ]
[ 1813 2326 2137 2002 1765 2278 ]]
1: 7

The result should be null ! The eigenvalues of this matrix are :
1: [ (12321,0) (729,0) (-95.9999999999998,0) (0.000000000000115,0) (729,0) (-96.0000000000002,0) ]

How can I increase the precision of this result ?

Regards,

JKB

[sven]

LAPACK does numerical computation and so you can rarely expect exact results. The eigenvalues of A computed by LAPACK will be the exact eigenvalues of a matrix (A+E) where norm(E) is small relative to norm(A). That is, the eigenvalues are exact for a slightly perturbed matrix. Eigenvalues that would be zero in exact arithmetic will usually be computed of the order of machine precision relative to norm(A).

Even for your first matrix, MATLAB (which uses LAPACK) does not compute a zero eigenvalue, the product of the eigenvalues is computed as 4.835085966367428e-008.

If you need exact results you need to use a symbolic algebra package such as Maple or Mathematica.

Do you really need to compute determinants? They are very sensitive to scaling since, for an n by n matrix A, det(kA) = k^n det(A). I know of very few applications that actually require determinants.