lapack95 errors

[Vishnu]

I am trying to use an eigenvalue routine through the lapack95 interface of the mkl. But I end up with this:

$ ifort Eigen.f90 -mkl

/opt/intel/compilers_and_libraries_2016.3.210/linux/mkl/include/lapack.f90(28): error #6218: This statement is positioned incorrectly and/or has syntax errors.
MODULE F95_PRECISION
^
/opt/intel/compilers_and_libraries_2016.3.210/linux/mkl/include/lapack.f90(31): error #6790: This is an invalid statement; an END [PROGRAM]  statement is required.
END MODULE F95_PRECISION
^
/opt/intel/compilers_and_libraries_2016.3.210/linux/mkl/include/lapack.f90(31): error #6785: This name does not match the unit name.   [F95_PRECISION]
END MODULE F95_PRECISION
-----------^
Eigen.f90(86): error #6785: This name does not match the unit name.   [EIGEN]
END PROGRAM Eigen
------------^
Eigen.f90(23): warning #5427: Program may contain only one main entry routine
IMPLICIT NONE
^
compilation aborted for Eigen.f90 (code 1)

Also, in the program, I have:

PROGRAM Eigen

INCLUDE 'mkl.fi'
INCLUDE 'lapack.f90'

IMPLICIT NONE
.
.
.

Any idea what the trouble might be?
 

[Dmitry_B_Intel · Accepted solution]

Hi Vishnu,

The lapack.f90 file is not supposed to be included inside a program/subroutine/function. Either compile it separately, and then 'use lapack95' inside your program, or put the include statement outside of the program, at file level (possibly replacing include with #include and preprocessing the file).

Dima

[Vishnu]

Dmitry Baksheev (Intel) wrote:

Hi Vishnu,

The lapack.f90 file is not supposed to be included inside a program/subroutine/function. Either compile it separately, and then 'use lapack95' inside your program, or put the include statement outside of the program, at file level (possibly replacing include with #include and preprocessing the file).

Dima

I don't understand what you mean by compile it separately. Is this what you mean: ?

$ ifort lapack.f90 -mkl
/opt/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64_lin/for_main.o: In function `main':
for_main.c:(.text+0x2a): undefined reference to `MAIN__'

Also, where should I put the 'USE lapack95' statement? Before 'IMPLICIT', or after?

[mecej4]

The purpose of compiling lapack.f90 is to generate a module. You left out the -c option in the command line of #3, so after compiling the compiler driver attempted to link and produce an executable. Nevertheless, the desired .mod file will have been generated, as you can see by asking for a directory listing. Therefore, you can  proceed to add the USE  statement to those programs that you wish to have that feature.

USE statements must come before any declarations, and you would fare better by consulting your Fortran language documentation or text books to resolve such questions.

[Vishnu]

mecej4 wrote:

The purpose of compiling lapack.f90 is to generate a module. You left out the -c option in the command line of #3, so after compiling the compiler driver attempted to link and produce an executable. Nevertheless, the desired .mod file will have been generated, as you can see by asking for a directory listing. Therefore, you can  proceed to add the USE  statement to those programs that you wish to have that feature.

USE statements must come before any declarations, and you would fare better by consulting your Fortran language documentation or text books to resolve such questions.

Oh! I see. I did it with the '-c' and it gives no errors.

Now, when I compile my program, I get these errors:

$ ifort Eigen.f90 -mkl
Eigen.f90(24): error #6222: This IMPLICIT statement is not positioned correctly within the scoping unit.
IMPLICIT NONE
^
Eigen.f90(60): error #6236: A specification statement cannot appear in the executable section.
USE lapack95
^
compilation aborted for Eigen.f90 (code 1)

The program is structures as follows:

PROGRAM Eigen

INCLUDE 'mkl.fi'

IMPLICIT NONE
.
.
.
USE lapack95
CALL syevd(M,E)
.
.

Problem is, I can't seem to find good enough documentation for the lapack95 interface.

Thanks a lot!

[mecej4]

I gave you the answer in the second paragraph of #4.

Documentation is sometimes "good enough", but only after it gets read!

[Vishnu]

mecej4 wrote:

I gave you the answer in the second paragraph of #4.

Documentation is sometimes "good enough", but only after it gets read!

Oh! sorry. I thought you meant that I should put the 'USE' statement just before the 'CALL' declaration. Now, I get this:

$ ifort Eigen.f90 -mkl
Eigen.f90(22): error #6278: This USE statement is not positioned correctly within the scoping unit.
USE lapack95
^
Eigen.f90(24): error #6222: This IMPLICIT statement is not positioned correctly within the scoping unit.
IMPLICIT NONE
^
compilation aborted for Eigen.f90 (code 1)

when I have the following structure:

PROGRAM Eigen

INCLUDE 'mkl.fi'
USE lapack95

IMPLICIT NONE
.
.
CALL syevd(M,E)
.
.

The two pieces of documentation I found (that were relavant to lapack95) were: F95 Interface and ?syevd . Neither talk about how to use USE statements.

Thanks!

[mecej4]

Remove the "Include" line, which is now redundant (and, considering its contents, out of order as well).

The relevant documentation is a Fortran manual/book.

[Vishnu]

I'm really sorry that I keep asking. I tried it without including the 'mkl.fi' then:

$ ifort Eigen.f90 
/tmp/ifortAD9igx.o: In function `MAIN__':
Eigen.f90:(.text+0xb46): undefined reference to `ssyevd_f95_'

$ ifort Eigen.f90 -mkl
/tmp/ifortSIN02R.o: In function `MAIN__':
Eigen.f90:(.text+0xb46): undefined reference to `ssyevd_f95_'

Why is the reference to 'ssyevd_f95_' undefined? The files that are present in the working directory right now (after I compiling the lapack.f90 from the mkl folder) are: f95_precision.mod  and  lapack95.mod

[mecej4]

The errors in #9 are linker errors, rather than the compiler errors that you encountered earlier. Lapack-95 routines are not contained in the default MKL libraries that the -mkl flag causes to be searched. Please consult the MKL line-line advisor, https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/ .

The name of the Lapack-95 library depends on the target architecture, and I do not know which one you are using. The link-line advisor will take care of the combinations for you.

[JohnNichols]

If you have a look at the BORR.ZIP files included in a post on this site - somewhere -- you will see the method to solve for EIGENVALUES using FEAST -- it is really straight forward --

[Vishnu]

mecej4 wrote:

The errors in #9 are linker errors, rather than the compiler errors that you encountered earlier. Lapack-95 routines are not contained in the default MKL libraries that the -mkl flag causes to be searched. Please consult the MKL line-line advisor,

Thanks a lot! That was the problem. It works now!!

[Vishnu]

John Nichols wrote:

If you have a look at the BORR.ZIP files included in a post on this site - somewhere -- you will see the method to solve for EIGENVALUES using FEAST -- it is really straight forward --

Oh! didn't know about this. Thanks for telling me about it. The FEAST page says that it is included in MKL. So then wouldn't that be simpler?

[Vishnu]

The link line advisor suggests the following:

ifort Eigen.f90 -lmkl_intel_ilp64 -lmkl_core -lmkl_sequential -lpthread -lm -ldl

But using that doesn't help. It gives me lots of errors. I can't even find what some of the options mean in the Intel Fortran Compiler User & Reference Guide. for eg. why load `-lm` when intel has math libs? etc.

What worked was the following (ref: Example 6 in: http://sc.tamu.edu/help/eos/mathlib.php )

$ ifort Eigen.f90 -mkl -lmkl_lapack95_lp64

But if you will notice, it uses single precision (since I use default REALs in my code). To use double, I tried:

$ ifort Eigen.f90 -real-size 64 -mkl -lmkl_lapack95_ilp64

But executing it resulted in the following error:

$ ./a.out 

Intel MKL INTERNAL ERROR: Insufficient workspace available in function SYEVD.

Why is that so? Am I missing some allocation procedure? Should I write my code with explicit KIND_8 values instead of asking the compiler to set: `-real-size 64` ? If so why doesn't it work?

Thanks a lot!

[Vishnu]

I thought that maybe I had to instruct lapack to use double precision. so I put this in my code:

PROGRAM Eigen

USE F95_PRECISION, ONLY: WP => DP
USE lapack95

IMPLICIT NONE
.
.

But the output is still the same:

$ ifort Eigen.f90 -real-size 64 -mkl -lmkl_lapack95_ilp64
$ ./a.out 

Intel MKL INTERNAL ERROR: Insufficient workspace available in function SYEVD.

I don't understand what I'm doing wrong.

[Vishnu]

I am very sorry. I missed something from the linking advisor. It works now with:

ifort Eigen.f90 -real-size 64 -lmkl_lapack95_ilp64 -lmkl_intel_ilp64 -lmkl_core -lmkl_sequential -lpthread -lm -ldl

Do you know where I can look up these options: -lpthread -lm -ldl , and why they're required when using intel fortran?

[mecej4]

Vishnu wrote:

What worked was the following (ref: Example 6 in: http://sc.tamu.edu/help/eos/mathlib.php )

$ ifort Eigen.f90 -mkl -lmkl_lapack95_lp64

But if you will notice, it uses single precision (since I use default REALs in my code). To use double, I tried:

That is wrong, and based on a misunderstanding. The LP64 libraries are suitable for use from Fortran and C code in which integer-type arguments to MKL routines are 32-bit integers. On the other hand, the ILP64 libraries are meant for use when integer-type arguments are 64-bit integers.

Both sets of libraries contain all the relevant siblings in a family of routines: for example, GEMV in Lapack95 resolves to one of the Lapack routines SGEMV, DGEMV, CGEMV, ZGEMV, SCGEMV or DZGEMV, depending on whether the non-integer, non-character subroutine arguments are REAL, DOUBLE PRECISION, COMPLEX, DOUBLE COMPLEX, etc. 

It is completely wrong to think that you should choose LP64 or ILP64 depending on whether you wish to use 32-bit reals or 64-bit reals. So far, you have said nothing to indicate that you need to use ILP64. Avoid making a mess by not using ILP64 until you truly need it. In fact, you may do well to use the 32-bit compiler and use 32-bit IA32 libraries until you get over your teething troubles.

[TimP]

Did you test to see whether they are actually required? mkl_parallel would require -lpthread (since linux OpenMP is built upon that facility), but -qopenmp would supply that implicitly. -lm -ldl should be included implicitly in any link script generated by ifort, and it's been many years since I've seen that to fail. libm refers to the glibc math library in case you call any math functions not in the ifort libraries, and libdl is required since you use shared object versions of MKL libraries.

[Vishnu]

mecej4 wrote:

That is wrong, and based on a misunderstanding. The LP64 libraries are suitable for use from Fortran and C code in which integer-type arguments to MKL routines are 32-bit integers. On the other hand, the ILP64 libraries are meant for use when integer-type arguments are 64-bit integers.

.

.

It is completely wrong to think that you should choose LP64 or ILP64 depending on whether you wish to use 32-bit reals or 64-bit reals. So far, you have said nothing to indicate that you need to use ILP64. Avoid making a mess by not using ILP64 until you truly need it. In fact, you may do well to use the 32-bit compiler and use 32-bit IA32 libraries until you get over your teething troubles.

Oh! I hadn't understood that. The mkl linker does not make that evident. Thank you. So you're saying that I should stick to  the LP64 even while I require 64bit reals, as long as I do not require 64bit integers. Is that right? Thanks a lot for clarifying that.

[Vishnu]

Tim P. wrote:

Did you test to see whether they are actually required? mkl_parallel would require -lpthread (since linux OpenMP is built upon that facility), but -qopenmp would supply that implicitly.

I don't understand. I have not used the openmp version of the linking anywhere. The mkl linker (that mecej4 suggested above) gives the -lpthread option even when I choose 'Sequential'. What are you referring to when you ask me if I've tested to see if they're working?

Tim P. wrote:

-lm -ldl should be included implicitly in any link script generated by ifort, and it's been many years since I've seen that to fail. libm refers to the glibc math library in case you call any math functions not in the ifort libraries, and libdl is required since you use shared object versions of MKL libraries.

I see, thanks for that. It makes sense now. Check this out: https://docs.oracle.com/cd/E53394_01/html/E54772/libdl-3lib.html .  It says that linking to ldl is no longer necessary. Do you know if that applies here too?

[TimP]

You refer to Solaris man pages about libdl.  Why not look up "linux libdl" ?

If you add -# to your ifort link command, you can check whether -ldl is being added implicitly.