Some of the interfaces brought in by mkl.fi are missing some argument definitions. While not an problem, since the implicit typing takes over, it does generate compiler warnings:

C:\PROGRA~2\INTELS~1\COMPIL~1\windows\mkl\include\mkl_spblas.fi(414): warning #6717: This name has not been given an explicit type.   [N]
C:\PROGRA~2\INTELS~1\COMPIL~1\windows\mkl\include\mkl_spblas.fi(427): warning #6717: This name has not been given an explicit type.   [N]
C:\PROGRA~2\INTELS~1\COMPIL~1\windows\mkl\include\mkl_spblas.fi(1019): warning #6717: This name has not been given an explicit type.   [N]
C:\PROGRA~2\INTELS~1\COMPIL~1\windows\mkl\include\mkl_spblas.fi(1032): warning #6717: This name has not been given an explicit type.   [N]
C:\PROGRA~2\INTELS~1\COMPIL~1\windows\mkl\include\mkl_spblas.fi(1623): warning #6717: This name has not been given an explicit type.   [N]
C:\PROGRA~2\INTELS~1\COMPIL~1\windows\mkl\include\mkl_spblas.fi(1636): warning #6717: This name has not been given an explicit type.   [N]
C:\PROGRA~2\INTELS~1\COMPIL~1\windows\mkl\include\mkl_spblas.fi(2228): warning #6717: This name has not been given an explicit type.   [N]
C:\PROGRA~2\INTELS~1\COMPIL~1\windows\mkl\include\mkl_spblas.fi(2241): warning #6717: This name has not been given an explicit type.   [N]
C:\PROGRA~2\INTELS~1\COMPIL~1\windows\mkl\include\mkl_service.fi(251): warning #6717: This name has not been given an explicit type.   [MEM_TYPE]

This is from the 20160121 release. I haven't noticed it before because I don't usually build with /warn:all. Trying to supress them with

!DIR$ NODECLARE
include 'mkl.fi'
!DIR$ DECLARE

doesn't help in this case - I'm guessing the command-line takes precendence.

Cheers,
Ben

I have a very large program which does numerical modeling. Up until recently I've been debugging and everything has been fine.  I'm now switching over to optimize areas that need improvements.  In my code I need to solve many linear algebra problems (50k+ cases) each take about a tenth of a second in sequential mode.  Each case is completely variable independent.  So it seemed to make sense to me to put the entire thing in a openmp for loop to run my 50k+cases and keep the cores fed that way.  That's when I started noticing small errors in the data.  Such as 4.600009 vs 4.600011.  Then I started seeing cases where the solver didn't converge at all (all of my cases converge without openmp).

What clued me in to it might be DSS is I ran a very large set of cases (~1M) while running a profiler.  After about 100k or so the concurrency drops to 1 core (of 16) and shows that all of the cores are waiting on dss_reorder to complete.

I cannot post all of the code(proprietary and legal reasons), but here's the bulk of the function that runs the DSS code.  Its fairly straight forward DSS code.  Each openmp loop gets its own dss handle.

            SOLVER_SETUP
                MKL_INT Error;
                _MKL_DSS_HANDLE_t Handle;
                MKL_INT opt = MKL_DSS_DEFAULTS | MKL_DSS_MSG_LVL_WARNING | MKL_DSS_TERM_LVL_ERROR | MKL_DSS_ZERO_BASED_INDEXING;
                MKL_INT Sym = MKL_DSS_NON_SYMMETRIC;
                MKL_INT Typ = MKL_DSS_INDEFINITE;
                const MKL_INT RowCount = NodeCount;
                const MKL_INT ColCount = NodeCount;
                const MKL_INT NonZeros = mMatrixA.NonZeros.size();
                const MKL_INT One = 1;

                Error = dss_create(Handle, opt);
                CME_Assert(ERROR != MKL_DSS_SUCCESS);
                Error = dss_define_structure(Handle, Sym, mMatrixA.RowStart, RowCount, ColCount, mMatrixA.Columns, NonZeros);
                CME_Assert(ERROR != MKL_DSS_SUCCESS);
                Error = dss_reorder(Handle, opt, 0);
                CME_Assert(ERROR != MKL_DSS_SUCCESS);
            SOLVER_LOOP_INIT
                Error = dss_factor_real(Handle, Typ, mMatrixA.Values);
                CME_Assert(ERROR != MKL_DSS_SUCCESS);
                Error = dss_solve_real(Handle, opt, mVectorB, One, mCurrentValue);
                CME_Assert(ERROR != MKL_DSS_SUCCESS);
            SOLVER_LOOP_END    
                Error = dss_delete(Handle, opt);

SOLVER_*****  are macros 

The solver loop shown here is not the open mp loop discussed.  It is there because the equations are highly non-linear and the matrix mMatrixA depends upon mCurrentValue.  

None of the asserts indicate there are any issues with the solver at anytime.

I'm currently running MKL 11.3 update 2.  Visual Studio 2013.  I've tried this on 3 different machines all with the same result.

From what I've seen it seems like dss_reorder has concurrency issues, but the documentation says otherwise.  I have tried both the sequential and parallel version of the mkl with the same results.

I am hoping someone has seen this before and knows of a work around (Although, I did not see this issue on any forums)

Thanks for any help

I have been running and debugging a code with the Intel visual fortran composer that uses the MKL poisson solver. It runs without issues in Windows. But when I run it in a UNIX system I get a SIGSEGV error. I am compiling it in 64 bits and I have checked that that is happening. I  have tried: -heap-arrays, ulimit -s unlimited and none of them have fixed the problem. I used -traceback and it points  to the line where I do 

call D_COMMIT_HELMHOLTZ_3D (f, bd_ax, bd_bx, bd_ay, bd_by, bd_az , bd_bz, xhandle, yhandle, ipar, dpar, stat)

The subroutine where this call is:

    subroutine solvePoisson3DVorticityPerMKL(f, bd_ax, bd_bx , bd_ay, bd_by, bd_az, bd_bz, nx, ny, nz, ax, bx, ay, by, az, bz, i)
    double precision dpar(5*(nx+ny)/2+9)
    integer ipar(128), i, stat, nx, ny, nz
    double precision :: bd_ax(:,:), bd_bx(:,:) , bd_ay(:,:), bd_by(:,:), bd_az(:,:), bd_bz(:,:)
    double precision :: f(:,:,:), finish, start
    character(6) BCtype
    double precision q, ax, bx, ay, by, az, bz
    type(DFTI_DESCRIPTOR), pointer :: xhandle, yhandle

    SELECT CASE (i) ! select component
    CASE (1)
        BCtype = 'PPDDPP'
#ifndef SHEAR_FLOW
        bd_ay  =0
        bd_by  =0
#endif
    case (2)
        BCtype = 'PPNNPP'

    case (3)
        BCtype = 'PPDDPP'
#ifndef SHEAR_FLOW
        print *,"Unidirectional flow"
        bd_ay  =- 0.1*(bx-ax)/2 ! for unidirectional flow
        bd_by  =0.1*(bx-ax)/2
#endif
    end select
    q=0.0
    ipar =0


    call D_INIT_HELMHOLTZ_3D(ax, bx, ay, by, az, bz, nx, ny, nz, BCtype , q, ipar, dpar, stat)
    ipar(3)=0 ! dissable warnings
    call D_COMMIT_HELMHOLTZ_3D (f, bd_ax, bd_bx, bd_ay, bd_by, bd_az , bd_bz, xhandle, yhandle, ipar, dpar, stat)
    call D_HELMHOLTZ_3D(f, bd_ax, bd_bx, bd_ay, bd_by, bd_az , bd_bz, xhandle, yhandle, ipar, dpar, stat)
    call free_Helmholtz_3D(xhandle, yhandle, ipar, stat)

    end subroutine solvePoisson3DVorticityPerMKL

The error :

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
CoupledSystem      0000000000519B15  Unknown               Unknown  Unknown
CoupledSystem      00000000005178D7  Unknown               Unknown  Unknown
CoupledSystem      00000000004CBB94  Unknown               Unknown  Unknown
CoupledSystem      00000000004CB9A6  Unknown               Unknown  Unknown
CoupledSystem      000000000047F4B6  Unknown               Unknown  Unknown
CoupledSystem      0000000000482AD0  Unknown               Unknown  Unknown
libpthread.so.0    00002B3F0728F130  Unknown               Unknown  Unknown
libmkl_def.so      00002B3F095743E4  Unknown               Unknown  Unknown
libmkl_core.so     00002B3F05D48E59  Unknown               Unknown  Unknown
libmkl_intel_ilp6  00002B3F0475F7CF  Unknown               Unknown  Unknown
CoupledSystem      0000000000447A77  vorticitysolverut         380  FluidUtilities.f90
CoupledSystem      00000000004579CC  vorticitysolverut        2596  FluidUtilities.f90
CoupledSystem      000000000045648F  vorticitysolverut        2567  FluidUtilities.f90
CoupledSystem      0000000000403865  MAIN__                    135  main.f90
CoupledSystem      00000000004030DE  Unknown               Unknown  Unknown
libc.so.6          00002B3F079D1AF5  Unknown               Unknown  Unknown
CoupledSystem      0000000000402FE9  Unknown               Unknown  Unknown

I have allocated the vectors previously. Again the code works without an issue on windows. Thanks. 

Hello everyone, I used VS 2013 + IVF 2013 + MSMPI + PetSC + microsoft HPC those environment to build a fortran multithreaded console app.

The OpenMP conditional compilation = yes, use intel math kernel = No, Process OpenMP Directives = Generate Parallel code.

The source code builded successfully and works fine in developer machine .

But when I attemped execute builded .exe on client machine it come to runtime error like this :

The procedure entry point could not be located: mkl_serv_print_verbose_info in the dynamic link libraryOn the EXE.

On client machine I do not install any develop environment, only copied libiomp5md.dll , mkl_core.dll, mkl_intel_thread.dll these 3 files to the execute directory, I had adjust compile conditions and makes lots of changes in vs-project property, it coundn't work .

So question is, how should I do to make sure the builded exes runs correct with no errors on client machine with no develop environment.

The following code generates an exception, although I set the error mode to VML_ERRMODE_IGNORE. Is there a way to use high accuracy (VML_HA) computations without raising underflow exceptions when computing exp (-88.) ?

float testData[1] = {-88.77909088};
vmsExp (1, testData, testData, VML_HA | VML_FTZDAZ_ON | VML_ERRMODE_IGNORE);

I am using the Intel MKL version 11.3.2 with Visual Studio 2013, statically linking mkl_intel_c.lib, mkl_core.lib and mkl_sequential.lib into my project.

I consistently have Pardiso crash when running on Linux. I've trimmed it down to a relatively simple test case of building a Poisson matrix and solving it with Pardiso.  The same program runs fine on Windows 8 and 10. It segfaults on both Centos 6.7 and Ubuntu 14.04. I assume I'm doing something wrong, but I can't tell what.

I'm building and testing on Centos 6.7 (upgraded from 6.5, not originally installed as 6.7).  I'm using g++ 4.8.2.  I put a fresh install of MKL from "parallel_studio_xe_2016_composer_edition_for_cpp_update2.tgz" into my home directory. I'm intentionally using the TBB version of MKL, and not using OpenMP at all. When I started working on this, I was using OpenMP and Pardiso was still crashing in OpenMP instead of TBB.

GDB shows the segfault is during Pardiso phase 11, inside some tbbmalloc stuff.

Full Source file: https://drive.google.com/open?id=0B1-EScYNsy0uTDZNX2Etck9NM1U

Makefile: https://drive.google.com/file/d/0B1-EScYNsy0uNEZLQmx5dl80ZUk/view?usp=sh...

Lots of console output, versions, make, gdb, ldd: https://drive.google.com/file/d/0B1-EScYNsy0uTjFqU2lyQTVjdUU/view?usp=sh...

Any suggestions on what I should look at?

-Essex

Hi,

I'm having a problem using pardiso solver in MKL library in direct or iterative mode. The manual says to choose between direct or iterative mode simply set the variable SOLVER (0=direct, 1=iterative) in :

call pardisoinit(PT, MTYPE, SOLVER, IPARM, DPARM, ERROR)

However, when i call the above routine the code crashes. It works only if i remove the variable SOLVER from the call. So it only works if i call the following:

call pardisoinit(PT, MTYPE, IPARM, DPARM, ERROR)

I attached the code so you can check it (it's a very small code with simple matrix inversion).

Thanks for your help !

Martin Gardner  provided this rather interesting genetic program in his writing in Sci Amer in the mid 80's. 

I copied his program in basic and ran it on GWBASIC and it ran nicely without a problem

At the time I coded it in Fortran and tried to get a random number generator to work to no success.

So I am trying to get accustomed to linking my f90 code to the MKL library and I decided to start with the $dot function.  I have included my compile command and my code below; please note that I set and environment variable for MKLROOT to save space and time.

My problem is that when I try to compile this, I keep getting the following error: /tmp/ifortdoYMJ3.o: In function `MAIN__':
DotProd.f90:(.text+0x4b7): undefined reference to `sdot_f95_'

I have been trying to figure out where this problem is coming from, without any luck. I was wondering if someone could provide some insight into this problem? I am working on ubuntu, on a 64 bit system.

Any help is appreciated!

----------------------------------Compile Command

ifort DotProd.f90 -L$MKLROOT/lib/intel64/libmkl_blas95_ilp64.a -i8 -I$MKLROOT/include/intel64/ilp64 -I$MKLROOT/include -Wl,--start-group $MKLROOT/lib/intel64/libmkl_intel_ilp64.a $MKLROOT/lib/intel64/libmkl_core.a $MKLROOT/lib/intel64/libmkl_sequential.a -Wl,--end-group -lpthread -lm -ldl

--------------------------------- Code

program DotProd

use f95_precision
use blas95

implicit none
! This program was constructed to learn how to use the BLAS library of the MKL
! The BLAS routine used will be the ?dot routine.

real, dimension(:), allocatable :: a,b ! Define two vectors
real res
integer :: size_of_vectors, ent

! Prompt the user for input
print *, 'Please input the size of the vectors in question'
read *, size_of_vectors

! Define size of vectors
allocate (a(1:size_of_vectors))
allocate (b(1:size_of_vectors))

! Prompt user for vector entries
print *, 'Please input the entries for vector a'
    do ent = 1, size_of_vectors
        read *, a(ent)
    end do

print *, 'Please input the entries for vector b'
    do ent = 1, size_of_vectors
        read *, b(ent)
    end do

! Output vectors
print *, 'Vector a ='
    do ent = 1, size_of_vectors
        print *, a(ent)
    end do
print *, 'Vector b ='
    do ent = 1, size_of_vectors
        print *, b(ent)
    end do
    
res = dot(a,b)
print* , 'a dot b =', res

end program DotProd

Hello,

I am trying to run examples in $(MKLROOT)/examples directory (specifically examples_f95.tgz). I have problem with lapack.

As the user guide suggest if I want to use gfortran compiler I should build lapack and blas libraries located in $(MKLROOT)/interfaces. This is what I did:

1) In $(MKLROOT)/interfaces/blas95

sudo make libintel64 FC=gfrotran interface=lp64 INSTALL_DIR=/opt/intel/mkl/gfortran

2) In $(MKLROOT)/interfaces/lapack95

sudo make libintel64 FC=gfrotran interface=lp64 INSTALL_DIR=/opt/intel/mkl/gfortran

Everything compiled without errors. However, after this procedure only blas95.mod and f95_precision.mod were located in /opt/intel/mkl/gfortran/include/intel64/lp64. Examples from blas95 directory are working, but those from lapack95 don't beacuse there is no lapack95.mod file. Somewhere in this forum I found that .mod files can be included manually just by running:

sudo gfortran -J/opt/intel/mkl/include/intel64/lp64 -c lapack.f90 blas.f90 

from $(MKLROOT)/include directory. After this procedure .mod files were present, but compilation of lapack example produces error:

Fatal Error: Reading module lapack95 at line 2 column 1: Unexpected EOF

I don't have this problem with blas although I have the same options in make. 

Dear Mr. / Mrs. ,

I'm having difficulty compiling code that uses the DGETRF and DGETRI Fortran functions.
Below I placed a very small test example "test.f03", that illustrates my problem:

program main
use lapack95, only: DGETRF_F95

implicit none

integer :: i,j,info
integer, dimension(20) :: ipiv
real(8), dimension(20,20) :: test1,inverse1

do i=1,20
  test1(i,:) = (/ (j,j=i,19+i) /)
end do
inverse1 = test1
call DGETRF_F95(inverse1,ipiv,info)

if (info /= 0) then
  stop 'Matrix is numerically singular'
end if

end program main

When I attempt to compile this code I get the following errors:

bash-4.3$ gfortran test.f03 -I./include -L/opt/sw/intel/mkl/lib/intel64 -lmkl_lapack95_lp64 -lmkl_rt
/opt/sw/intel/mkl/lib/intel64/libmkl_lapack95_lp64.a(dgetrf.o): In function `dgetrf_f95_':
../../../../interfaces/lapack95/source/dgetrf.f90:(.text+0xa76): undefined reference to `for_dealloc_allocatable'
../../../../interfaces/lapack95/source/dgetrf.f90:(.text+0xb46): undefined reference to `for_check_mult_overflow64'
../../../../interfaces/lapack95/source/dgetrf.f90:(.text+0xb63): undefined reference to `for_allocate'
../../../../interfaces/lapack95/source/dgetrf.f90:(.text+0xbc8): undefined reference to `for_check_mult_overflow64'
collect2: error: ld returned 1 exit status

Which is completely unknown to me. Could somebody tell me what I'm missing here?

Thank you for your time!

I'd like to set the MKL_DIRECT_CALL flag for the custom MKL dll that we are using from a C application and hopefully speed up the matrix operations. Will it be enough to set the flag for the C application alone? What about the makefile for the custom MKL dll? 

Hi,

I'm having a problem using pardiso solver in MKL library in direct or iterative mode. The manual says to choose between direct or iterative mode simply set the variable SOLVER (0=direct, 1=iterative) in :

call pardisoinit(PT, MTYPE, SOLVER, IPARM, DPARM, ERROR)

However, when i call the above routine the code crashes. It works only if i remove the variable SOLVER from the call. So it only works if i call the following:

call pardisoinit(PT, MTYPE, IPARM, DPARM, ERROR)

I'm using intel visual fortran composer xe on windows 8.1.

Hello,

I need sparse matrix-vector multiplication in my code and want to use the MKL, as I want to also use the Xeon Phi cards in my system. However, the 64-bit version (the one activated by the -DMKL_ILP64 flag for the Intel compiler) seems to be broken

#include <iostream>
#include <mkl.h>

int main() {
  MKL_INT           rows = 2;
  MKL_INT           cols = 2;
  double const     alpha = 1.0;
  double const     val[] = {1.0, 1.0, 1.0};
  MKL_INT         indx[] = {0, 1, 1};
  MKL_INT        outer[] = {0, 2, 3};
  MKL_INT const*   pntrb = outer;
  MKL_INT const*   pntre = outer + 1;
  double const       x[] = {0.0, 1.0};
  double const      beta = 0.0;
  double             y[] = {0.0, 0.0};

  mkl_dcsrmv("N", &rows, &cols, &alpha, "G**C", val, indx, pntrb, pntre, x, &beta, y);
  std::cout << "y = {"<< y[0] << ", "<< y[1] << "}"<< std::endl;
}

When I compile the above code with: icpc -mkl, I get the output: "y = {1, 1}", which should be expected. When I do so with the -DMKL_ILP64 switch I get: "y = {0, 0}".

I need this fixed rather quickly, as our client really needs his Xeon Phi cards running this code. Can you please confirm this bug? I am using Intel Compiler version 16.0.3 20160415 as well as Intel MKL 11.3 Update 3.

Best regards,

Lars

I'm trying to test the cluster pardiso to solver complex linear equations with Hermitian matrix. When I ran the parallel program using -np 2 option, everything looks fine. However, when I used more MPIs like -np 4, it reported errors and gave wrong results. Please see the attached code, output with np 2 and np 4 as well as error message with np 4.

Please have the attached FORTRAN code. Any suggestions are greatly appreciated. Thanks.

********************************************************************************

program cluster_sparse_solver_complex_unsym
implicit none
include 'mkl_cluster_sparse_solver.fi'
include 'mpif.h'
C.. Internal solver memory pointer for 64-bit architectures
TYPE(MKL_CLUSTER_SPARSE_SOLVER_HANDLE) pt(64)
C.. All other variables
INTEGER maxfct, mnum, mtype, phase, n, nrhs, error, msglvl
INTEGER*4 rank, mpi_stat
INTEGER iparm(64)
INTEGER ia(9)
INTEGER ja(13)
COMPLEX*16 a(13)
COMPLEX*16 b(8)
COMPLEX*16 bs(8)
COMPLEX*16 x(8)
INTEGER i, idum(1)
COMPLEX*16 ddum(1)
COMPLEX*16 res, res0

complex*16 c_temp,alpha,beta
character*1 matdescra(6)

C.. Fill all arrays containing matrix data.
DATA n /8/, nrhs /1/, maxfct /1/, mnum /1/

data ia/1,3,5,7,8,9,11,13,14/
data ja/1,2,2,3,3,4,4,5,6,7,7,8,8/
data b/3,4,5,6,7,8,1,2/
a(1)=15d0
a(2)=(3d0,1d0)
a(3)=14d0
a(4)=(2d0,1.1d0)
a(5)=20d0
a(6)=(1d0,0.5d0)
a(7)=25d0
a(8)=20d0
a(9)=15d0
a(10)=(1d0,0.2d0)
a(11)=17d0
a(12)=(2d0,0.5d0)
a(13)=25d0

C.. variables for matrix multiplication
matdescra(1)='H' ! Hermitian for cyclic complex matrix
matdescra(2)='U' ! upper matrix
matdescra(3)='N' ! non unit diagonal
matdescra(4)='F' ! one based indexing
alpha=1.0
beta=0.0

C..
C.. Initialize MPI.
call MPI_INIT(mpi_stat)

call MPI_COMM_RANK(MPI_COMM_WORLD, rank, mpi_stat)
C..
C.. Set up Cluster Sparse Solver control parameter
C..
do i = 1, 64
iparm(i) = 0
enddo
iparm(1) = 1 ! no solver default
iparm(2) = 2 ! fill-in reordering from METIS
iparm(6) = 0 ! =0 solution on the first n compoments of x
iparm(8) = 2 ! numbers of iterative refinement steps
iparm(10) = 13 ! perturbe the pivot elements with 1E-13
iparm(11) = 1 ! use nonsymmetric permutation and scaling MPS
iparm(13) = 1 ! maximum weighted matching algorithm is switched-off
iparm(40) = 0 ! Input: matrix/rhs/solution stored on master
error = 0 ! initialize error flag
msglvl = 1 ! print statistical information
mtype = 4 ! symmetric, indefinite
C.. Initiliaze the internal solver memory pointer. This is only
C necessary for the FIRST call of the Cluster Sparse Solver.
do i = 1, 64
pt(i)%DUMMY = 0
enddo
C.. Reordering and Symbolic Factorization, This step also allocates
C all memory that is necessary for the factorization
phase = 11 ! only reordering and symbolic factorization
call cluster_sparse_solver (pt, maxfct, mnum, mtype, phase, n, a, ia, ja,
1 idum, nrhs, iparm, msglvl, ddum, ddum, MPI_COMM_WORLD, error)
if (RANK.EQ.0) write(*,*) 'Reordering completed ... '
if (error .NE. 0) then
if (RANK.EQ.0) write(*,*) 'The following ERROR was detected: ', error
call MPI_FINALIZE(mpi_stat)
stop 1
endif

C.. Factorization.
phase = 22 ! only factorization
call cluster_sparse_solver (pt, maxfct, mnum, mtype, phase, n, a, ia, ja,
1 idum, nrhs, iparm, msglvl, ddum, ddum, MPI_COMM_WORLD, error)
if (RANK.EQ.0) write(*,*) 'Factorization completed ... '
if (error .NE. 0) then
if (RANK.EQ.0) write(*,*) 'The following ERROR was detected: ', error
call MPI_FINALIZE(mpi_stat)
stop 1
endif
C.. Back substitution and iterative refinement
phase = 33 ! only solution
if (RANK.EQ.0) then
do i = 1, n
b(i) = (1.d0,1.d0)
enddo
endif
call cluster_sparse_solver (pt, maxfct, mnum, mtype, phase, n, a, ia, ja,
1 idum, nrhs, iparm, msglvl, b, x, MPI_COMM_WORLD, error)
if (error .NE. 0) then
if (RANK.EQ.0) write(*,*) 'The following ERROR was detected: ', error
call MPI_FINALIZE(mpi_stat)
stop 1
endif

if (RANK.eq.0) then
write(*,*) 'Solve completed ... '
write(*,*) 'The solution of the system is '
do i = 1, n
write(*,*) ' x(',i,') = ', x(i)
enddo
call mkl_zcsrmv('N',n,n,alpha,matdescra,a,ja,ia(1),ia(2),x,beta,bs)
res = (0.d0,0.d0)
res0 = (0.d0,0.d0)
do i=1,n
res = res + (bs(i)-b(i))*conjg((bs(i)-b(i)))
res0 = res0 + b(i)*conjg(b(i))
enddo
print *, 'Relative residual = ', sqrt(abs(res))/sqrt(abs(res0))
endif

C.. Termination and release of memory
phase = -1 ! release internal memory
call cluster_sparse_solver (pt, maxfct, mnum, mtype, phase, n, ddum, idum, idum,
1 idum, nrhs, iparm, msglvl, ddum, ddum, MPI_COMM_WORLD, error)
if (error .NE. 0) then
if (RANK.EQ.0) write(*,*) 'The following ERROR was detected: ', error
call MPI_FINALIZE(mpi_stat)
stop 1
endif

if(rank .eq. 0) then
if ( sqrt(abs(res))/sqrt(abs(res0)) .gt. 1.d-10 ) then
write(*,*) 'Error: residual is too high!'
stop 1
endif
endif
call MPI_FINALIZE(mpi_stat)
end

I was looking through the LAPACK documentation and came across various instances where there are different routines recommended for large and small matrices. For eg., SYEVD vs SYEVR ( https://software.intel.com/en-us/node/469180 ) - { last paragraph of the description section } .

But nowhere that I could find, is there any mention of how large, large exactly is. Does someone here know?

Thanks!

The code attached below will either crash (access violation error) or produce the right result, or an approximate result depending on the number of MPI processes it runs on. This code is run on a Win 7 64-bit machine with dual six-core processor.

The 8-by-8 matrix used in this example is Hermitian, positive definite.

One should probably note that the MKL documentation page for 'cluster_sparse_solver' (the definition of the argument "a", for instance) does not mention MTYPE=4; this omission is found in multiple other places as well (description of ipar(10) in the page 'cluster_sparse_solver iparm Parameter', for instance).

PROGRAM MAIN
USE MPI
USE MKL_CLUSTER_SPARSE_SOLVER
IMPLICIT NONE


INTEGER(KIND=4)  :: MAXFCT,MNUM,MTYPE,PHASE,N,IA(9),JA(13),PERM(1),NRHS,IPARM(64),MSGLVL,ERROR,RANK,I
COMPLEX(KIND=8)  :: A(13),B(8),X(8),RES,RES0,ALPHA,BETA,BS(8)
CHARACTER(LEN=1) :: MATDESCRA(6)
TYPE(MKL_CLUSTER_SPARSE_SOLVER_HANDLE) :: PT(64)

CALL MPI_INIT(ERROR)
CALL MPI_COMM_RANK(MPI_COMM_WORLD,RANK,ERROR)

MAXFCT = 1
MNUM   = 1
MTYPE  = 4

N      = 8
A(1)  = 15
A(2)  = (3,1)
A(3)  = 14
A(4)  = (2.0,1.1)
A(5)  = 2
A(6)  = (1.0,0.5)
A(7)  = 25
A(8)  = 20
A(9)  = 15
A(10) = (1.0,0.2)
A(11) = 17
A(12) = (2.0,0.5)
A(13) = 25
IA     = [1,3,5,7,8,9,11,13,14]
JA     = [1,2,2,3,3,4,4,5,6,7,7,8,8]

PERM   = 0
NRHS   = 1

MSGLVL = 1
DO I=1,64
    PT(I)%DUMMY = 0
ENDDO

IPARM     = 0
IPARM(1)  = 1   ! NO SOLVER DEFAULT
IPARM(2)  = 2   ! FILL-IN REORDERING FROM METIS
IPARM(6)  = 0   ! =0 SOLUTION ON THE FIRST N COMPOMENTS OF X
IPARM(8)  = 2   ! NUMBERS OF ITERATIVE REFINEMENT STEPS
IPARM(10) = 13  ! PERTURBE THE PIVOT ELEMENTS WITH 1E-13
IPARM(11) = 1   ! USE NONSYMMETRIC PERMUTATION AND SCALING MPS
IPARM(13) = 1   ! MAXIMUM WEIGHTED MATCHING ALGORITHM IS SWITCHED-OFF
IPARM(40) = 0   ! INPUT: MATRIX/RHS/SOLUTION STORED ON MASTER

PHASE  = 11
CALL CLUSTER_SPARSE_SOLVER(PT,MAXFCT,MNUM,MTYPE,PHASE,N,A,IA,JA,PERM,NRHS,IPARM,MSGLVL,B,X,MPI_COMM_WORLD,ERROR)
IF (RANK==0) WRITE(*,*) 'REORDERING COMPLETED ... '
IF (ERROR/=0) THEN
    IF (RANK==0) WRITE(*,*) 'THE FOLLOWING ERROR WAS DETECTED: ', ERROR
    CALL MPI_FINALIZE(ERROR)
    STOP 1
ENDIF

PHASE = 22
CALL CLUSTER_SPARSE_SOLVER(PT,MAXFCT,MNUM,MTYPE,PHASE,N,A,IA,JA,PERM,NRHS,IPARM,MSGLVL,B,X,MPI_COMM_WORLD,ERROR)
IF (RANK==0) WRITE(*,*) 'FACTORIZATION COMPLETED ... '
IF (ERROR/=0) THEN
    IF (RANK==0) WRITE(*,*) 'THE FOLLOWING ERROR WAS DETECTED: ',ERROR
    CALL MPI_FINALIZE(ERROR)
    STOP 1
ENDIF

PHASE = 33
IF (RANK==0) THEN
    DO I=1,N
        B(I) = (1,1)
    ENDDO
ENDIF
CALL CLUSTER_SPARSE_SOLVER(PT,MAXFCT,MNUM,MTYPE,PHASE,N,A,IA,JA,PERM,NRHS,IPARM,MSGLVL,B,X,MPI_COMM_WORLD,ERROR)
IF (ERROR/=0) THEN
    IF (RANK==0) WRITE(*,*) 'THE FOLLOWING ERROR WAS DETECTED: ',ERROR
    CALL MPI_FINALIZE(ERROR)
    STOP 1
ENDIF

MATDESCRA(1) ='H'
MATDESCRA(2) ='U'
MATDESCRA(3) ='N'
MATDESCRA(4) ='F'
ALPHA = 1.0
BETA  = 0.0

IF (RANK==0) THEN
    WRITE(*,*) 'SOLVE COMPLETED ... '
    WRITE(*,*) 'THE SOLUTION OF THE SYSTEM IS '
    DO I = 1, N
        WRITE(*,*) ' X(',I,') = ', X(I)
    ENDDO
    CALL MKL_ZCSRMV('N',N,N,ALPHA,MATDESCRA,A,JA,IA(1),IA(2),X,BETA,BS)
    RES  = (0.D0,0.D0)
    RES0 = (0.D0,0.D0)
    DO I=1,N
        RES = RES + (BS(I)-B(I))*CONJG((BS(I)-B(I)))
        RES0 = RES0 + B(I)*CONJG(B(I))
    ENDDO
    PRINT *, 'RELATIVE RESIDUAL = ', SQRT(ABS(RES))/SQRT(ABS(RES0))
ENDIF


END PROGRAM MAIN

The compile and link command is shown here:

Compiling with Intel(R) Visual Fortran Compiler 17.0 [Intel(R) 64]...
ifort /nologo /O2 /I"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.0.048\windows\mkl\include" /I"C:\Program Files (x86)\IntelSWTools\mpi\2017.0.048\intel64\include" /module:"x64\Release\\" /object:"x64\Release\\" /Fd"x64\Release\vc120.pdb" /libs:dll /threads /c /Qlocation,link,"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\\bin\amd64" /Qm64 "D:\TEMP\CLUSTER_SPARSE_SOLVER\MAIN.F90"
Linking...
Link /OUT:"x64\Release\CLUSTER_SPARSE_SOLVER.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.0.048\windows\mkl\lib\intel64_win" /LIBPATH:"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.0.048\windows\mpi\intel64\lib" /MANIFEST /MANIFESTFILE:"x64\Release\CLUSTER_SPARSE_SOLVER.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:CONSOLE /IMPLIB:"D:\TEMP\CLUSTER_SPARSE_SOLVER\x64\Release\CLUSTER_SPARSE_SOLVER.lib" mkl_intel_lp64.lib mkl_core_dll.lib mkl_intel_thread_dll.lib mkl_blacs_lp64_dll.lib impi.lib -qm64 "x64\Release\mkl_cluster_sparse_solver.obj""x64\Release\MAIN.obj"
Embedding manifest...
mt.exe /nologo /outputresource:"D:\TEMP\Sandbox\CLUSTER_SPARSE_SOLVER\x64\Release\CLUSTER_SPARSE_SOLVER.exe;#1" /manifest "x64\Release\CLUSTER_SPARSE_SOLVER.exe.intermediate.manifest"

CLUSTER_SPARSE_SOLVER - 0 error(s), 0 warning(s)

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?
 

Hi,

I'm new to MKL so please bare with me. We're moving a project from 32 to 64 bit and we've encountered some inconsistencies between 32 & 64 bit vdExp.

I have the following code

double value = 0.027771918023383080;

double result;

vdExp( 1, &value, &result );

In 32 bit mode, the value in result is 1.0281611526482297 whilst when I run it in 64 bit mode I get 1.0281611526482299.

Any ideas why this is? I've double checked and I'm definitely compiling with the correct libraries. I used the Intel MKL link advisor.

Regards

Mark.

Hi, I am using MKL 11.1 to find eigen vectors with and am having issues with the results changing sign depending on which machine I run this. This gives completely different results in the end for an ellipse fitting algorithm and, thus, failures in automated tests.

Given the following matrix in row major order:

-8747596.5053710938      -316030.00427246094       1615084.5202636719
-5749756.8850097656      -667037.37084960938       632059.98022460938
 52358865.204467773       2874878.4188232422      -8747596.5129394531

The following call is made:

auto squareSize = 3;
auto info = LAPACKE_dgeev( LAPACK_ROW_MAJOR, 'N', 'V', squareSize,
  inputArrayOutput.Data(), squareSize,
  realEigenValues.Data(), imaginaryEigenValues.Data(),
  nullptr, squareSize, rightEigenVectors.Data(), squareSize );

Running this on machines that give the "correct" or expected result will give.

inputAndOutput
-18162659.389763702       -4492507.6042798907      -5290349.3859531470
 0.00000000000000000       214.50030177488844       915701.07938791020
 0.00000000000000000      -0.0070577840503023292    214.50030177488844
real eigenvalues
-18162659.389763702        214.50030177488844       214.50030177488844
imag eigenvalues
0.00000000000000000        80.391669176281070      -80.391669176281070
right eigenvectors
 0.17135077952698607       0.15755967091010539     -6.3641462760426620e-06
 0.091750438224901587     -0.67430368000587571      0.00013608158502213653
-0.98092852310503897       0.72144956765842805      0.00000000000000000

But on a "failing" machine this will give something like:

inputAndOutput
-18162659.389763702        4492507.6042798860      -5290349.3859531470
 0.00000000000000000       214.50030177486741      -915701.07938790950
 0.00000000000000000       0.0070577836735623567    214.50030177486741
real eigenvalues
-18162659.389763702        214.50030177486741       214.50030177486741
imag eigenvalues
 0.00000000000000000       80.391667030653210      -80.391667030653210
right eigenvectors
 0.17135077952698605      -0.15755967091010534      6.3641461061856458e-06
 0.091750438224901559      0.67430368000587682     -0.00013608158139016290
-0.98092852310503875      -0.72144956765842760      0.00000000000000000

As can be seen the sign of the last two right eigen vectors changes. The question then is why? And how can one correct this sign change so the result will always have the same sign? It seems to be correlated to the output in "inputAndOutput" but how?

Or is this in fact a bug and would a later MKL version fix this?