Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
12 Views

use lapack

 

The documentation refers to  use lapack and use lapack95.   Do I have to add a "use lapack" to access getrf & getrs?   It seems if I put in "use lapack" I get:  This name has already been used as an external module name. [LAPACK]

 

If I add "use lapack95", then I get:

Error in opening the compiled module file. Check INCLUDE paths. [LAPACK95]

 

But if I have neither, I don't get the calls resolved:

Error 2  error LNK2019: unresolved external symbol GETRF referenced in function SMIKE smike.obj 

same for getrs.

 

I am compiling in x64, release, with default real set to kind=8 in compiler options.

! use lapack from intel library PURE SUBROUTINE DGETRF_F95(A,

call getrf(anewt, ipvt, info)

if ( info.ne.0 ) asing = .true.

job = 0

! PURE SUBROUTINE DGETRS1_F95(A,IPIV,B,TRANS,INFO)

! call getrs('N',nnewt,1,anewt,bnewt,mxq,mxq,ipvt,solutn,job)

call getrs(anewt,ipvt,bnewt,'N',job)

 

 

Thanks...

 

 

 

0 Kudos
5 Replies
Highlighted
Black Belt
12 Views

Your code shows calls to the Lapack95 generic routine names getrf and getrs. To get these calls to work correctly, you must provide an explicit interface since these routines take optional arguments. The module to use has a name that is either 'lapack95' or 'mkl95_lapack'.

At link time, you need to include mkl_lapack95_lp64.lib, if you are using 32-bit integer arguments, in addition to the standard MKL libraries. 

To find the correct module and library names, look in c:\Program Files (x86)\Intel\Composer XE 2015\mkl\include\intel64\lp64 and c:\Program Files (x86)\Intel\Composer XE 2015\mkl\lib\intel64 (you may need to modify these paths if you installed the compiler in a non-default location).

For your convenience, here is a working example. The data file for the example is dgetrsx.d in the .../MKL/examples/lapack/data directory.

      PROGRAM MAIN
!-----------------------------------------------
!   I n t e r f a c e   B l o c k s
!-----------------------------------------------
      USE lapack95
      IMPLICIT NONE
!-----------------------------------------------
!   L o c a l   V a r i a b l e s
!-----------------------------------------------
      INTEGER :: I, INFO, J, N, NRHS
      INTEGER, ALLOCATABLE :: IPIV(:)
      DOUBLE PRECISION, ALLOCATABLE :: A(:,:),B(:,:)
!-----------------------------------------------
      WRITE (*, *) 'GETRS Example Program Results'
!     Skip heading in data file
      READ (*, *)
      READ (*, *) N, NRHS
      ALLOCATE(A(N,N),B(N,NRHS),IPIV(N))
!
!        Read A and B from data file
!
         READ (*, *) ((A(I,J),J=1,N),I=1,N)
         READ (*, *) ((B(I,J),J=1,NRHS),I=1,N)
!
!        Factorize A
!
         CALL GETRF (A, IPIV, INFO)
!
         WRITE (*, *)
         IF (INFO == 0) THEN
!
!           Compute solution
!
            CALL GETRS (A, IPIV, B)
!
!           Print solution
!
            WRITE(*,10)(i,B(i,1),B(i,2),i=1,N)
   10 format(' Solution:',/,(i4,1p2E12.3))
         ELSE
            WRITE (*, *) 'The matrix is singular'
         ENDIF
      STOP
!
      END PROGRAM MAIN

 

0 Kudos
Highlighted
New Contributor I
12 Views

 

I am trying to link with mkl.  I found the sequentila mkl option /Qmkjl:sequential option.  I took out any specific module/library paths and libraries.

I get unresolved references for:

 

 

Error 2  error LNK2019: unresolved external symbol DGETRF_F95 referenced in function SMIKE smike.obj 
Error 3  error LNK2019: unresolved external symbol DGETRS1_F95 referenced in function SMIKE smike.obj 
 

ANy idea what I need to add to resolve these?

Using MS vS 2012, ifort 15.0 on windows 7,  multithreaded run time library, x64/Release.  I have the option to use default real as 64 bits.

thanks...

0 Kudos
Highlighted
Black Belt
12 Views

You probably forgot to add mkl_lapack95_lp64.lib as an additional dependency or as an addition to the linker command line. Simply choosing to link with MKL is not sufficient.

0 Kudos
Highlighted
New Contributor I
12 Views

 

Thanks, that looks like its working.  One question is there are 15 .lib files in that directory.  I am not sure how I would know which to add.  Especially the mkl_lapack95_   with either ilp64 or lp64. 

We link some of our codes with dlls, and we need to distribute exe's with the right dlls in order for them to run on computers without compilers installed.  It usually is a guessing game which are the right dlls to distribute with the exes to get them to run on other computers.

Anyway,  Thanks!!

0 Kudos
Highlighted
Black Belt
12 Views

'LP64' means that Longs and Pointers are 64-bits in size, whereas 'ILP64' means that Integers, Longs and Pointers are 64-bits (the terms are somewhat C-centric). If you call MKL routines with any integer arguments, and those integer arguments are 8-byte integers, you need ILP64. If not, you need LP64. Note that the size of real/double arguments is not at issue here.

There is a handy Link Line Advisor (https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/) to help you with selecting the libraries to specify to the linker. With more recent versions of Intel Fortran/C++, a local copy is also installed on your hard drive.

Intel provides installable redistribution packages for your users/customers at https://software.intel.com/en-us/articles/intelr-composer-redistributable-libraries-by-version at https://software.intel.com/en-us/articles/intelr-composer-redistributable-libraries-by-version . You can simply ask them to download the relevant version, instead of packaging the DLLs yourself.

0 Kudos