topic There were dozens of in Intel® oneAPI Math Kernel Library

Why no simple linear equation solver?

WSinc — Mon, 24 Aug 2015 22:25:21 GMT

I looked in the INTEL MATH KERNEL library, and could not find a routine that just solves

A*X=B

where A is an N by N matrix, and X and B are vectors of length N.

They throw a lot of confusing **** at you, when you just want to solve a basic problem,

and dont have a system with special characteristics, like SPARSE, Band, Hermitian, etc.

So its impossible to just find a basic routine to give you a quick answer.

Or if its there, they sure don't bother to tell you where - - - -

They used to have one - what happened to it?

Had you spent a few seconds

mecej4 — Mon, 24 Aug 2015 22:34:00 GMT

Reading the contents list of the MKL manual, or reading the similar listing of the contents of Lapack on Netlib (http://www.netlib.org/lapack/lug/), shows one that the routines sGESV, dGESV, etc., will probably do what was wanted.

Well, I didnt know about the

WSinc — Tue, 25 Aug 2015 01:19:37 GMT

Well, I didnt know about the NET:LIB web site, otherwise I would have gone there first.

It appears that I should use the LAPACK routines, but apparently there has to be something special I put in the BUILD to access those.

They are not automatically included in the IMKL set ?

So, what is the build step I have to include?

I tried adding mkl_lapack95.lib to the list of "include libraries,"

but it still cannot find that routine.

That was the suggestion they made for IA-32 architecture, BTW.

Maybe Steve could answer this...

WSinc — Tue, 25 Aug 2015 01:21:45 GMT

Hi Billsincl,

Ying_H_Intel — Tue, 25 Aug 2015 08:15:51 GMT

Hi Billsincl,

Right, you may read netlib lapack function, which provide such solvers.

MKL also support the lapack ( almost de facto linear Algribra function standard), same interface.

?gesv
Computes the solution to the system of linear
equations with a square matrix A and multiple righthand sides.
Syntax
FORTRAN 77:
call sgesv( n, nrhs, a, lda, ipiv, b, ldb, info), s for single point floating,

call dgesv( n, nrhs, a, lda, ipiv, b, ldb, info), d for double floating.

Do you use Fortran or c to develop the solver? If you try to use MKL, then you can find the c or fortran example under MKL install directory:

for example;windows: Intel_sw_development_tools\compilers_and_libraries_2016.0.0xx\windows\mkl\examples

lapacke_dgesv_row.c

examples_f95\lapack95\source

Best Regards,

Ying

attach one fortran sample

Ying_H_Intel — Tue, 25 Aug 2015 08:21:08 GMT

attach one fortran sample code.

Regards,

Ying

This download example DOES

WSinc — Tue, 25 Aug 2015 18:07:46 GMT

This download example DOES NOT COMPILE.

It doesnt like the USE statements, says "check include paths."

So can we have an example that actually works ?

It also says:

WSinc — Tue, 25 Aug 2015 18:28:45 GMT

It also says:

d:\william data\Downloads\gesv.f90(44): error #6683: A kind type parameter must be a compile-time constant. [WP]

The other comments are just warnings.

But I dont see why these examples do us any good if they dont even compile - - -

The module names may be

mecej4 — Tue, 25 Aug 2015 19:24:39 GMT

The module names may be different in the version of MKL that you have and the ones that are used by the people replying to your post. It is usually necessary for you to check the names of modules in your installation before using them in code. Similarly, the MKL libraries to link against have to be tailored to your specific case. There are tools to facilitate these adjustments, but those tools will work only if you use them, to do which you need to learn about them first.

The module names in the current version of MKL are "F95_PRECISION" instead of "MKL95_PRECISION" and "LAPACK95" instead of "MKL95_LAPACK". As I suggested earlier, you need to find out the names of the modules in your installation and edit the source code to suit.

To run the program, you will also need the input data file gesv.d, which you will find in the MKL examples directory.

OK, so where do we find that

WSinc — Tue, 25 Aug 2015 19:36:00 GMT

Those USE statements don't work either. I get error #7002 for BOTH.

OK, so where do we find that out? Do the names of the modules have anything to do with the processor, or whether its 32 or 64 bits?

I dont see any articles that show us where - -

That Fortran file still doesnt compile, apparently having nothing to do with the USE statements

Why is this such a god-awful confused mess ??

Quote:billsincl wrote:

mecej4 — Tue, 25 Aug 2015 19:59:00 GMT

billsincl wrote:

OK, so where do we find that out? Do the names of the modules have anything to do with the processor, or whether its 32 or 64 bits?

No, the modules names are the same, but they are located in different directories depending on the architecture/memory model being used. For example, I have the 32-bit module files in ...\Composer XE\mkl\include\ia32.

That Fortran file still doesnt compile, apparently having nothing to do with the USE statements

No, all the compilation problems that you reported are related to USE statements. In fact, I am not sure why/if you chose to use the Fortran 95 interface to Lapack. Had you used the F77 interface (i.e., the implicit interface), you would not have needed to worry about USE statements.

Once I changed the module names as I indicated earlier in Ying H.'s example code, I could build and run the program with the data in the MKL examples directory. The program ran fine.

well, that's wonderful that

WSinc — Tue, 25 Aug 2015 20:59:28 GMT

well, that's wonderful that it runs on YOUR computer, but that does not solve MY problem - -

I thought we were supposed to use the most up to date compilers?

isn't F95 the default compiler nowadays?

Anyway, I checked the module names on my machine, and they agree with what you said, but the

compiler cant make any sense of the USE statements. Is there something I am also supposed to put in the build

that will POINT to those?

Can we have someone that will give us a definitive answer, rather than guessing and running around in circles?

------ Build started: Project

WSinc — Tue, 25 Aug 2015 21:08:14 GMT

------ Build started: Project: resist, Configuration: Debug|Win32 ------

Compiling with Intel(R) Visual Fortran Compiler XE 15.0.2.179 [IA-32]...
gesv (1).f90
d:\william data\Downloads\gesv (1).f90(39): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [LAPACK95]
d:\william data\Downloads\gesv (1).f90(38): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [F95_PRECISION]
d:\william data\Downloads\gesv (1).f90(46): error #6683: A kind type parameter must be a compile-time constant. [WP]
d:\william data\Downloads\gesv (1).f90(72): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.
d:\william data\Downloads\gesv (1).f90(72): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.
d:\william data\Downloads\gesv (1).f90(79): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.
d:\william data\Downloads\gesv (1).f90(79): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.
d:\william data\Downloads\gesv (1).f90(82): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.
d:\william data\Downloads\gesv (1).f90(82): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.
d:\william data\Downloads\gesv (1).f90(38): error #6581: Unresolved rename. [WP]
d:\william data\Downloads\gesv (1).f90(39): error #6580: Name in only-list does not exist. [GESV]
compilation aborted for d:\william data\Downloads\gesv (1).f90 (code 1)

OK, I converted it to use the

WSinc — Tue, 25 Aug 2015 21:43:58 GMT

OK, I converted it to use the explicit f77 interface, and it compiles.

But I also had to fix that REAL(WP) statement made it REAL(4) instead for single precision arrays.

Anyway, it still does not run, it can't find the SGESV entry point.

[quote=billsincl, #12]well,

mecej4 — Tue, 25 Aug 2015 22:21:00 GMT

well, that's wonderful that it runs on YOUR computer, but that does not solve MY problem.

You are missing the point: since the program builds and runs on a different computer, the conclusion to be drawn is that any remaining problems are attributable to your compiler/MKL installation or your build procedure, and definitely do not lie in the source code. This observation narrows down the scope where problems exist.

So far, you have not told us which compiler and MKL versions you use, nor how you do the build. Without giving that information, it is unreasonable of you to demand a definitive answer.

The Fortran file that you attached to #14 runs fine (after correcting it to set lda and ldb both = n before calling sgesv) with the current release of IFort (15.0.4) and the accompanying version of MKL (11.2.3). If you are building at the command line, you need to use the /Qmkl option. If you are using Visual Studio, you have to specify that the MKL libraries are to be used at link time (in the project properties->Fortran->Libraries->Use Intel Math Kernel Library).

OK, I have both of those, and

WSinc — Wed, 26 Aug 2015 00:40:20 GMT

OK, I have both of those, and I did get it to run with the F77 interface. So I know it can find the entry point.

However, the F95 interface fails. No one seems to be able to tell me why.

I did use the MAth Kernel library in the build step.

Apparently there is something else that has to be added to this process.

Quote:billsincl wrote:

mecej4 — Wed, 26 Aug 2015 01:15:00 GMT

billsincl wrote:

However, the F95 interface fails. No one seems to be able to tell me why.

I did use the MAth Kernel library in the build step.

Apparently there is something else that has to be added to this process.

The F95 interface works fine, as you should see from #11. If you invest the time to learn how Fortran include files, module files and libraries relate to one another and how you should go about using them in the build process, you will perceive that it is all very logical and reasonable. In fact, many of the issues occur even when building a simple Fortran program. However, the compiler driver manages all the necessary ingredients behind the scenes, so you may be unaware of what is needed and being taken care of.

There is a tool called the MKL Link Line Advisor, see https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor , which can help you with using MKL in any but the simplest projects.

If it is logical and

WSinc — Wed, 26 Aug 2015 03:10:48 GMT

If it is logical and reasonable, why is the behavior not consistent on different machines?

We should not have to take a three month course in this stuff, just to solve a simple problem.

I have filed a complaint about this - - -

Hi billsincl,

Ying_H_Intel — Wed, 26 Aug 2015 08:53:16 GMT

Hi billsincl,

Maybe screencast will help. I attache the build processing in word file for your reference.

i suppose you have installed parallel studio XE 2015 update 2. (ifort and MKL are installed). and please let us know if any issues.

Regards,
Ying

This mecej4 tells me there

WSinc — Wed, 26 Aug 2015 15:41:06 GMT

This mecej4 tells me there there is something wrong with the installation on my machine.

Well since that was done by INTEL as part of my subscription, why dont they look at it, and correct the problem?

As I said earlier, my computer is a typical INTEL desktop, with a 32 bit INTEL processor, so the installation

coming from you should be pretty routine, right ?