Community
cancel
Showing results for 
Search instead for 
Did you mean: 
WSinc
New Contributor I
32 Views

Why no simple linear equation solver?

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
Black Belt
28 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.

WSinc
New Contributor I
28 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...

WSinc
New Contributor I
28 Views

 

 

 

Ying_H_Intel
Employee
28 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 

Ying_H_Intel
Employee
28 Views

attach one fortran sample code. 

Regards,

Ying

WSinc
New Contributor I
28 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 ?

WSinc
New Contributor I
28 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 - - -

mecej4
Black Belt
28 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.

WSinc
New Contributor I
28 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 ??

mecej4
Black Belt
28 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.

WSinc
New Contributor I
28 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?

WSinc
New Contributor I
28 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)

WSinc
New Contributor I
28 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.

mecej4
Black Belt
28 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). 

WSinc
New Contributor I
28 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.

mecej4
Black Belt
28 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.

WSinc
New Contributor I
28 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 - - -

Ying_H_Intel
Employee
28 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 

WSinc
New Contributor I
28 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 ?