Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.

Why no simple linear equation solver?

WSinc
New Contributor I
973 Views

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?

 

0 Kudos
36 Replies
mecej4
Honored Contributor III
712 Views

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.

0 Kudos
WSinc
New Contributor I
712 Views

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...

0 Kudos
WSinc
New Contributor I
712 Views

 

 

 

0 Kudos
Ying_H_Intel
Employee
712 Views

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 

0 Kudos
Ying_H_Intel
Employee
712 Views

attach one fortran sample code. 

Regards,

Ying

0 Kudos
WSinc
New Contributor I
712 Views

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 ?

0 Kudos
WSinc
New Contributor I
712 Views

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 - - -

0 Kudos
mecej4
Honored Contributor III
712 Views

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.

0 Kudos
WSinc
New Contributor I
712 Views

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 ??

0 Kudos
mecej4
Honored Contributor III
712 Views

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.

0 Kudos
WSinc
New Contributor I
712 Views

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?

0 Kudos
WSinc
New Contributor I
712 Views

------ 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)

0 Kudos
WSinc
New Contributor I
712 Views

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.

0 Kudos
mecej4
Honored Contributor III
712 Views

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). 

0 Kudos
WSinc
New Contributor I
712 Views

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.

0 Kudos
mecej4
Honored Contributor III
712 Views

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.

0 Kudos
WSinc
New Contributor I
712 Views

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 - - -

0 Kudos
Ying_H_Intel
Employee
712 Views

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 

0 Kudos
WSinc
New Contributor I
712 Views

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 ?

0 Kudos
Ying_H_Intel
Employee
681 Views

Hi billsincl

No sure if you test under command line as i show in the docx.  

Regarding the installation, i guess it is not problem.  Anyway,  please check if you have the mkl_lapack95.lib in the MKL install folder. 

mkl_lapack95.png

Then if it is there, please add it into your project link line.   ( if it is not there, you need reinstall the product . when install, please use custom install with fortran 95 support. ) 

Here is the step for add mkl_lapack95.lib. 

if in command line,  it is ifort  gesv.f90 mkl_lapack95.lib mkl_intel_c.lib mkl_core.lib libiomp5md.lib 

2)  if you are working in Visual Studio Environment, please add mkl_lapack95.lib  in Project's property page => Linker =>Input => Additional Dependencies. 

mkl_lapack95_link.png

Then if  you copy the input data  and add it into project, you should be able to run. 

run.png

If there is still trouble, could you please attach your screencopy, so we can diagnose what is your develop environment and the problem. 

Regards,
Ying

0 Kudos
Reply