Why no simple linear equation solver?

[WSinc]

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?

[WSinc]

It looks like you are inserting the INTERFACE block for GESV, is that right?

Well, I will try that -

I did the most recent install of the FORTRAN and the MKL stuff, as per my current license.

One interesting thinh I noticed - when they give an example, they do NOT use the F95 interface,

they use the F77 one that requires all the input arguments.

Maybe they had the same problem?

[mecej4]

billsincl wrote:

One interesting thing I noticed - when they give an example, they do NOT use the F95 interface,

they use the F77 one that requires all the input arguments.

Maybe they had the same problem?

The example files cover both interfaces, but the extent of coverage is less for the F95 examples.

The example files that use the F95 interface are free-format *.f90 files, to be found in "...\Composer XE\mkl\examples\lapack95\source" and other such directories. The example file gesv.f90 for Lapack95-GESV() is within that directory.

[Steven_L_Intel1]

Bill,

The problem is most likely that the example Ying gave you uses old names for the LAPACK95 modules. MKL changes its module names (and library names) every few releases, so you need to read the MKL documentation and release notes to see what is needed.

When I was trying this out, I also discovered that the MKL Link Line Advisor gave bad advice for how to build the program.

So...  Use the version of Ying's example I have attached here. If you are building from the command line, do it like this:

For Win32:

ifort /Qmkl gesv.f90 mkl_lapack95.lib

For x64:

ifort /Qmkl gesv.f90 mkl_lapack95_ilp64.lib

If you are building in Visual Studio, set the following project properties:

Fortran > Libraries > Use Intel Math Kernel Library > Parallel
Linker > Input > Additional Dependencies > lapack95.lib (if x64, mkl_lapack95_ilp64.lib)

See if this works for you.

[WSinc]

Hi steve -

I get error #11018, says the linker cannot attach lapack95.lib

I just did an install from INTEL,  using my subscription package -

Did they change the library name recently ?

I can go look - - -

I dont care at this point about actually running it,

I think if I can just link to the routine I will be in good shape.

as I said earlier, it CAN find it if I use the OLDER F77 interface.

[Steven_L_Intel1]

Please attach a zip of your buildlog.htm.  Is the "Solution Platform" Win32 or x64? I tested this using the 2016 install. 

[WSinc]

Now I dont get the problem with the LIB, but it still cant find the entry point.

[WSinc]

There were dozens of complaints about the new fortran 16/MKL install, and I had the same problem here as well.

[WSinc]

Hi again -

I think I have found the problem -

The newest installation put a BRAND NEW DIRECTORY in the c folder, called 

"intel software tools"

All the NEW stuff went there. Did it delete the old routines ?

This is nowhere close to where the other stuff was, BTW.

so I am wondering perhaps the VS2010 does not know about the new directory to look for everything ?

It should if it was updated as well, right ?

[WSinc]

 I copied the INTERFACE SOURCE code into the project and compiled that.

Apparently it accepted that, but as far as the actual entry point, it cant find that (DGESV1_95)

so  am wondering if there is still a mixup about the library routine locations.

Why would there be a DGESV  and a DGESV1 both in the interface ?

Is there a way to scan the LAPACK95.lib, and see what entry points are actually present ?

[Steven_L_Intel1]

Bill, the 2016 products do indeed install into a different top-level directory. Visual Studio knows where to find the files if you have version 16 selected as the version to use (Tools > Options > Intel Compilers and Tools > Visual Fortran > Compilers.

You have incorrectly set the linker options. You have the library name lapack95.lib under General > Additional Library Directories, where it will be ignored. You want to add that under Input > Additional Dependencies.

[WSinc]

I did try that "additional dependencies" thing earlier, got no results.

But I will try it again with the new installation.

Is there anything in the build that tells us what library routines were used, and where they came from?

[Steven_L_Intel1]

You can enable a link map (Linker > Debugging > Generate Map File), or specify Linker > General > Show Progress > Show All Progress Messages (this produces a LOT of output - best to review it in the build log). Both will indicate which library an external procedure was found in. In addition to the calls from your program there will be all the other external references from the compiled code and library routines in there.

In the LAPACK95 module, the GESV generic interface has several specific procedures for different combinations of arguments. The difference between DGESV_95 and DGESV1_95 is that in DGESV_95 the B argument is rank 2, while in DGESV1_95 it is rank 1. The compiler sorts this out when you call GESV depending on the types, kinds and ranks of the actual arguments.  All of these routines are resolved from mkl_lapack95.lib (IA-32) or mkl_lapack95_ilp64 (x64). You should always reference the generic, not the specific, and let the compiler determine which specific is appropriate.

[WSinc]

YES, I finally got it to work ! !

I had to link to MKL_LAPACK95.lib to get the entry points.

Thanks for your help ! !

[Steven_L_Intel1]

Glad to hear that the instructions I provided in post 24 worked for you.

[WSinc]

In days of yore I would have simply used the F77 interface, but as you know,

the interface is much more complicated, and I had other LAPACK routines

I wanted to interface with. So it was better to consistently use the F95 interface with ALL of them.

I figured that if I could get just ONE to work, then that would solve the problem with all the LAPACK routines.

Besides I am not sure I can use a "mixed" set of interfaces, i.e.F77 and F95 in the same build.

[Steven_L_Intel1]

There's no problem mixing explicit (what you call "F95") and implicit (what you call "F77") interfaces as long as there are no name collisions. I don't think MKL has this problem - I know that IMSL does. The explicit interfaces generally don't require you to pass array dimensions separately.