Community
cancel
Showing results for 
Search instead for 
Did you mean: 
OP1
New Contributor I
129 Views

Strangeness with DZGEMV

The following code produces different outputs for DZGEMV and GEMV. The code is built with default 64-bit integer and real numbers; The parallel version of the MKL library is used (using ILP64 interfaces).

The path to the module files is: C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2019.3.203\windows\mkl\include\intel64\ilp64

Using the link advisor, the libraries used are: mkl_blas95_ilp64.lib mkl_lapack95_ilp64.lib mkl_intel_ilp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib libiomp5md.lib (library directory: C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2019.3.203\windows\mkl\lib\intel64_win).

GEMV and MATMUL produce the expected result. I can't explain what DZGEMV does here.

This is on a WIN 10 machine, with Intel Parallel Studio XE 2019 Update 3 Cluster Edition.

PROGRAM P
USE BLAS95
IMPLICIT NONE

COMPLEX :: PHI(2,1),V(2),W(1),ALPHA,BETA
INTEGER :: M,N,ONE

PHI = CMPLX(1.0)
V   = CMPLX(2.0)
ALPHA = CMPLX(1.0)
BETA = CMPLX(0.0)
W = CMPLX(0.0)

M   = 2
N   = 1
ONE = 1

CALL DZGEMV('C',M,N,ALPHA,PHI,M,V,ONE,BETA,W,ONE)
WRITE(*,*) W

CALL GEMV(PHI,V,W,ALPHA=ALPHA,BETA=BETA,TRANS='C')
WRITE(*,*) W

W = MATMUL(CONJG(TRANSPOSE(PHI)),V)
WRITE(*,*) W

END PROGRAM P

Output:

 (2.00000000000000,0.000000000000000E+000)
 (4.00000000000000,0.000000000000000E+000)
 (4.00000000000000,0.000000000000000E+000)
Press any key to continue . . .

 

0 Kudos
7 Replies
Gennady_F_Intel
Moderator
129 Views

it looks like an issue. we will check the problem on our side.

Gennady_F_Intel
Moderator
129 Views

yes, I see the wrong output either but not exactly what you obtained.
 (0.0000000E+00,0.0000000E+00)
 (4.000000,0.0000000E+00)
 (4.000000,0.0000000E+00)

Gennady_F_Intel
Moderator
129 Views

the verbose mode shows that different precisions have been called. dzgemm -- double complex, CSGEMV - single complex

MKL_VERBOSE Intel(R) MKL 2020.0 Update 1 Product build 20200208 for Intel(R) 64 architecture Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2) enabled processors, Win 2.60GHz cdecl intel_thread
MKL_VERBOSE DZGEMV(C,2,1,00000075776FFE10,00007FF7679CEB00,2,00007FF7679CEB10,1,00000075776FFE18,00007FF7679CEB20,1) 66.86us CNR:OFF Dyn:1 FastMM:1 TID:0  NThr:2
 (0.0000000E+00,0.0000000E+00)
MKL_VERBOSE CGEMV(C,2,1,00000075776FFBD8,00007FF7679CEB00,2,00007FF7679CEB10,1,00000075776FFBE0,00007FF7679CEB20,1) 9.17us CNR:OFF Dyn:1 FastMM:1 TID:0  NThr:2
 (4.000000,0.0000000E+00)
 (4.000000,0.0000000E+00)

mecej4
Black Belt
129 Views

If I am not mistaken, OP is passing an incorrect type argument to DZGEMV. The fifth argument, PHI, must be of type double precision real, not default complex or complex(8).

OP1
New Contributor I
129 Views

Thanks mecej4 - but shouldn't an interface argument inconsistency be detected by the compiler?

mecej4
Black Belt
129 Views

OP wrote:
Thanks mecej4 - but shouldn't an interface argument inconsistency be detected by the compiler?

You have enabled the compiler to see an explicit interface to GEMV, which is a generic subprogram name, through the USE BLAS95 statement. The compiler will have checked the arguments in that call.

For the other BLAS routine that you call, DZGEMV, only an implicit interface is available to the compiler, and that one is incorrect. The compiler can detect such errors only if you provide an explicit and correct interface, or if there is more than one call from the same program unit to the same BLAS routine and the calls are mutually inconsistent.

OP1
New Contributor I
129 Views

Yes, I see. I just did a rookie mistake here, ha ha. Thanks for the clarification!

Reply