Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.

lapack95 errors

Vishnu
Novice
2,102 Views

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?
 

0 Kudos
1 Solution
Dmitry_B_Intel
Employee
2,091 Views

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

View solution in original post

0 Kudos
22 Replies
Dmitry_B_Intel
Employee
2,092 Views

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

0 Kudos
Vishnu
Novice
1,936 Views

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?

0 Kudos
mecej4
Honored Contributor III
1,936 Views

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.

0 Kudos
Vishnu
Novice
1,936 Views

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!

0 Kudos
mecej4
Honored Contributor III
1,936 Views

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

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

0 Kudos
Vishnu
Novice
1,936 Views

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!

0 Kudos
mecej4
Honored Contributor III
1,936 Views

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.

0 Kudos
Vishnu
Novice
1,936 Views

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

0 Kudos
mecej4
Honored Contributor III
1,936 Views

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.

0 Kudos
JohnNichols
Valued Contributor III
1,934 Views

 

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 --

 

0 Kudos
Vishnu
Novice
1,936 Views

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!!

0 Kudos
Vishnu
Novice
1,936 Views

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?

0 Kudos
Vishnu
Novice
1,936 Views

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!

0 Kudos
Vishnu
Novice
1,936 Views

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.

0 Kudos
Vishnu
Novice
1,936 Views

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?

0 Kudos
mecej4
Honored Contributor III
1,936 Views

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.

0 Kudos
TimP
Honored Contributor III
1,936 Views

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.

0 Kudos
Vishnu
Novice
1,936 Views

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.

0 Kudos
Vishnu
Novice
1,936 Views

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?

0 Kudos
TimP
Honored Contributor III
1,674 Views

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.

0 Kudos
Reply