Why doesn't this run?

[WSinc]

This simple test program crashes.

I got it to link, .

but apparently the documentation is not consistent with the

way it is actually used.

According to what it says,, I can get by with only two input arguments, and it

is supposed to select the routine based upon what input type is being used (REAl or DOUBLE)

It doesn't do what it says.

I am assumng a FORTRAN 95 interface, since I now have Build 2013.1

See uploaded test file.

[WSinc]

By the way, putting in random numbers always works.

At least on other machines.

[TimP]

If you want random number generators for which you don't supply source code to work with some consistency across various platforms, you should be using Fortran standard intrinsics.

You should be able to guess better than the rest of us what you intend to do and what your compile line and error messages might be,

Evidently, dgels ought to fail when you don't use the required group of arguments.  ifort does have a -check-interfaces option.

[Zhang_Z_Intel]

What Fortran compiler do you use? If you use a non-Intel compiler and want to use the LAPACK95 interface of Intel MKL, you have to have the LAPACK95 interface .mod files built first.

Please show your command line options for compiling and linking. You can also use this tool http://software.intel.com/sites/products/mkl/ to make sure you used the correct command line options.

I also think matrix b in your code is not big enough. It has only m rows (m=5) but the solution vector has n rows (n=10). You need to make the leading dimension of b at least n otherwise there isn't enough space to store the solution.

[mecej4]

In effect, you demonstrated that one may shoot onself in the foot by using the overloaded names of Lapack-95 routines without linking to the Lapack95 libraries. Here is an explanation of what happened:

1. You used the USE LAPACK95 statement and called the generic name GELS in your code. The compiler found the interface for GELS, recognized that the two arguments were of type REAL(8), and issued a call to the correct specific name, _DGELS_MKL95.

2. However, you probably did not specify that the library mkl_lapack95.lib for the link step, so you received an "unsatisfied external" error.

3. The plot thickens: To fix the error listed in 2., you replaced the generic name, GELS, by the specific name DGELS. This is a Fortran 77 entry point, and it is found in the MKL libraries, so the compile/link "worked". Unfortunately, you now had a program that called the Fortran 77 entry point, which requires 11 arguments, with only two arguments. That leads to an unsurprising crash, when the F77 routine DGELS attempted to access argument arrays that were not passed to it. Since you did not provide an interface to DGELS (as you could have, for example, by saying INCLUDE 'mkl.fi'), the compiler would be unable to catch the error.

MORAL: 1a. Do not call Fortran 95+ generic names without specifying the MKL_LAPACK95 library.

              1b.  Do not call Fortran 77 routines without providing ALL the arguments, unless you have explicit clearance to do so in the documentation.

[WSinc]

I thought I WAS using the LAPACK Fortran 95 routines.

And the latest build of the INTEL compiler. 2013.1

That's why I said USE LAPACK95 and set the Fortran libraries option to USE MKL.

That's what I was told to do, anyway..

When I said GELS and not DGELS it could NOT find an external. Only after

 I changed it to DGELS did it find the external. So apparently it CANNOT determine which routine from the input argument types.

Other people made remarks that suggested they they didn't understand over or under determined

least squres problems.

If there is some magic trick that will actually allow me to use

these routines, where do I find it?

Don't they have a sample ten-line program that shows HOW to use it?

See trivial example I uploaded below. It crashes when it calls the routine.

God - what a confused mess ! ! !

[mecej4]

No magic needed; it is quite simple. As I explained earlier, link to the Lapack-95 library (first change CALL DGELS(..) to CALL GELS(..))

[bash]ifort /Qmkl test-14-1.f90 mkl_lapack95.lib[/bash]

The program may not run correctly if the problem is not well-posed from the linear algebra point-of-view. For instance, the matrix B in your example does not have the correct size, and may elements of A are left undefined.

There is a GELS example in the MKL distribution.

[WSinc]

BTW, if you run this, you will see that it is getting the right routine

(MKL_DGLES) and crashes about 10 lines into the machine code.

So it has to do with the argument setup. Apparently the linker does not properly

connect the default arguments that are supposed to be implictly passed from

the way the arrays are dimensioned. Does this mean I have to specify all the dimensions

AS IF the routine DGLES is a F77 routine?

The documenatation say otherwise.

I get the impression this was never tested with real*8 inputs.

[mecej4]

You are not using the Lapack-95 library properly. As a consequence, something will break, and you can be quite imaginative in placing blame on the compiler, the linker, etc.That will not, however, rectify the situation.

To break out of this bind you need to read the documentation and follow the instructions. After all, polymorphism, while it may be a thing of beauty, comes with a price.

[Zhang_Z_Intel]

billsincl wrote:

 The documenatation say otherwise.

Can you kindly specify which part of the documentation you think is not right? You can copy/paste the sentences/paragraphs that led to your confusion.

I've tried both of your test programs. They both crash because you used DGELS instead of GELS. DGELS is not an LAPACK95 routine. So why don't you change it to GELS? After this change, both programs compile and link fine and they run without crash. The next problem, however, is that although they run without crash, they return INFO=-8. This is because your matrix b has the wrong size, as other people have already pointed out.

[Zhang_Z_Intel]

billsincl wrote:

When I said GELS and not DGELS it could NOT find an external.

This inidcates that you didn't have your link line options set up correctly. Please configure your IDE (I'm supposing you are on Windows platform) to pass these options to the compiler:  /module:%MKLROOT%/include/ia32 -I%MKLROOT%/include. And, pass these options to the linker:  %MKLROOT%/lib/ia32/mkl_lapack95.lib  mkl_intel_c_dll.lib mkl_sequential_dll.lib  mkl_core_dll.lib

Again, this information is easily found here: http://software.intel.com/sites/products/mkl/

[WSinc]

Well, I was working from within the VS environment, so I don't have the luxury of setting up

the ifort commands like you suggested. Does this mean I have to compile everything manually, rathe than uisng VS 2010?

The documentation says that Matrix B can have a different number of columns, and the same number of rows.

This depends upon whether you have an overdetermnied problem, or underdetermined.

Like I said before, if I say GELS, it can't find ANY routines matching that. Maybe the problem is related to USING VS 2010.

The documentation does not address these issues,just manual builds, etc.

But isn't VS2010 supposed to set everthing up FOR US properly?

apparently the prople using this don't believe in using VS in that situation?

[mecej4]

Well, I was working from within the VS environment, so I don't have the luxury of setting up the ifort commands like you suggested.

Interesting, when frugal/Spartan living gets one accused of indulging in decadent luxury!

In VS, if you want to use Lapack 95 in your project, you have to specify (i) that the project uses MKL and (ii) mkl_lapack95.lib as an additional library to link against, and (iii) the Lapack95 module directory is to be searched for header files/modules.

As to the issue of array sizes: when you solve an undetermined m X n system A x = b, with m < n, and (for simplicity, consider) a single right-hand-side of size m X 1, the minimum norm solution x is going to be of size n X 1, which is too large to overwrite the corresponding column b, which is only m X 1.

[WSinc]

I did have USE MKL LIBRARY turned on in the Project properties.

This was under "Fortran" and subheading "libraries."

And in the actual code I had USE LAPACK95.

Is there something else I have to insert into the Project setup?

The confusion came about when I sent you folks the source code, and you compiled and linked it

outside the VS environment. So naturally you thought everything worked, wheras it

did NOT work within the VS environment.

For example, within VS, this crashes:

USE LAPACK95

real*8 a(5,5), B(5,5)    ! exactly determined system

call  GELS(A,B)

---------------------------------------------------------------------

In this case, it can't find the LAPACK routine. So the issue of array sizes

is not germaine here.....

I'm wondering if perhaps I should call the LAPACK routine as an F77 routine and

put all the arguments in, in other words bypass the F95 stuff entriely.

Maybe it would work then ?

We need a good article about this, don't you think?

Yours; Bill (living in confused decadent luxury)

Either that, or have to abandon VS and use manual builds and compiles,

which is rather awkward.

[mecej4]

And in the actual code I had USE LAPACK95. Is there something else I have to insert into the Project setup?

This is what was probably missing (quoting from above in this thread): "you have to specify (ii) mkl_lapack95.lib as an additional library to link against."

There seems to be a common misconception that inserting USE LIBXXX in the source code will tell the linker to use that named library. In reality, the USE statement is there only to provide a convenient interface to the Lapack-95 libraries, so the compiler can check arguments.To tell the linker to search the Lapack-95 library, you have to do one of several things:

     (i) specify it as an additional linker argument

     (ii) specify it in an "Additional Libraries" tab in VS, or

     (iii) use an OBJCOMMENT directive in your source code in which you name the concerned library.

The USE LAPACK95 statement does not provide interfaces for Lapack-3 or MKL routines. If you want those checked, additional USE and/or INCLUDE statements are needed.