getrf and access violation

[g_f_thomas]

Whatever the configuration the following raises an access violation on the call to getrf in a win32 console app with default accepted properties:

program test

use

mkl95_lapack use mkl95_precision

implicit none

real(8)

c(2,2), x(2), y(2), a_0, orgS_2, S_0, orgS_0 integer(4) ipiv(2)

c = 0.d0; ipiv = 0

c(1,1) = 1.d0; c(1,2) = 2.d0; c(2,1) = 2.d0; c(2,2)=4.d0

call dgetrf(c, ipiv)

x = 0.d0; y = 0.d0

info = 0

a_0 = 5.d0; orgS_2 = 4.7d0

S_0 = 10.d0; orgS_0 = 10.46d0

y(1) = 2 * (a_0 - orgS_2); y(2) = 2 * (S_0 - orgS_0)

call dgetrs(c, ipiv, y, x, 'N', info) pause

end test

MKL 10.0.1.015 and IVF 10.1.013. IVF links to the runtime multithreaded library

The linker additional dependencies are (Debug): mkl_solver.lib mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib libguide.lib

Where am I going wrong? Any suggestions will be much appreciated.

Thanks,

Gerry

ps It makes no difference whether I use libguide from MKL or IVF

[Michael_C_Intel4]

Dear Gerry,

names like 'dgetrf' are resereved for Fortran77 entry points, they have different interface from Fortran95 entry points, which should be called as 'getrf' or 'getrs'. Using Fortran77-style names with Fortran95-style arguments will cause a failure. Just call getrf instead of dgetrf and getrs instead of dgetrs.

Best regards,

Michael.

[g_f_thomas]

Michael,

Yes I'm aware of this notational difference. Whether I use the f77 or f95 interface the end result is the same in calling ?getrf: Access Violation. When I switch from lapack to the linear interval solvers (earmarked for removal in a future release of MKL) the problem executes correctly and without crashing. I notice that the MKL examples don't demonstrate use of ?getrf which I'd wager isthe most highly used routine in lapack.

Thanks,

Gerry

[Vladimir_Koldakov__I]

Gerry,

In addition to the "getrf" you should use f95"getrs" call instead of f77 "dgetrs" call.

Moreover,as described in the mklman.pdf the interface "getrs"is:

call getrs( a, ipiv, b [, trans] [,info] ), where "b" is the matrix.

So you should replace you call:

call dgetrs(c, ipiv, y, x, 'N', info)

with the

call getrs(c, ipiv,b, 'N', info)

where b isthe matrix.

Regards,

Vladimir

[g_f_thomas]

Thanks Vladimir. I made the change and now I have a:

Error1 error LNK2019: unresolved external symbol _DGETRS1_MKL95 referenced in function _MAIN__test.obj

Now what?

Gerry

[Vladimir_Koldakov__I]

Gerry,

Could you please give me your command line?

Its really available to use 1 dimensional matrix b in getrs() interface instead of two dimensional. In this case one more (additional) interface is used.

There are no problems if you link the mkl_lapack95.lib library what is built when you execute lapack95 examples.

But manually you should compile one more file: interfaces/lapack95/source/dgetrs1.f90 and linkobtained object file.

I suggest the simplest way to run your test: replace one of the examples with your code, say, source/gbsv.f90 and re-run examples.

The next code pass:

program test

use mkl95_lapack

use mkl95_precision

implicit none

real(8) c(2,2), x(2), y(2), a_0, orgS_2, S_0, orgS_0

integer(4) ipiv(2)

integer info ! added

c = 0.d0; ipiv = 0

c(1,1) = 1.d0; c(1,2) = 2.d0; c(2,1) = 2.d0; c(2,2)=4.d0

call getrf(c, ipiv)

x = 0.d0; y = 0.d0

info = 0

a_0 = 5.d0; orgS_2 = 4.7d0

S_0 = 10.d0; orgS_0 = 10.46d0

y(1) = 2 * (a_0 - orgS_2); y(2) = 2 * (S_0 - orgS_0)

call getrs(c, ipiv, y, 'N', info)

pause

end !test

Regards,

Vladimir

[g_f_thomas]

Thanks again Vladimir, running nmake for the lapack95 examples revealed my failure to link against mkl_lapack95.lib. Perhaps a demonstration ofgetrs usage ought to be included in the examples.

Gerry

[Vladimir_Koldakov__I]

Gerry,

Your input is very usefulfor improvingLAPACK95 documentation and examples.

Thanks,

Vladimir