Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Intel Community
- Software
- Software Development SDKs and Libraries
- Intel® oneAPI Math Kernel Library
- difficulties in a program in which some blas work but ddot.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Achille_B_

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-15-2013
11:35 AM

163 Views

difficulties in a program in which some blas work but ddot.

Hi guys

I found a problem and maybe some of you could help-me.

In order to solve problems with a blas function in a bigger program, I've tried to make a shorter program to test linking options. So I can easily compile and run this short program with blas calls:

"

...

real(8):: a(6000,6000), b(6000,4000), c(6000,4000), d(6000), e(6000), alpha, betainteger(8)::m, n, lda, ldb, ldc, i, juplo = 'u'

side = 'l'

m = 6000

n = 4000

lda = m

ldb = m

ldc = m

alpha = 0.5

beta = 2.0...

call dsymv('u', 3000, alpha, a, 6000, d, 1, beta, e, 1)

call dsymm (side, uplo, m, n, alpha,a, lda, b, ldb, beta, c, ldc)..."

With this simple command: **ifort teste_mkl.f90 -mkl**

And no "**use"** statement in the source code. However, if i try uncomment:

"

...

i=1

alpha=

ddot(m, d, i, e, i)...."

or

"

....

alpha=

ddot(6000, d, 1, e, 1)..."

I get the message

"teste_mkl.f90(51): error #6404: This name does not have a type, and must have an explicit type. [DDOT]alpha= ddot(m, d, i, e, i)-------^compilation aborted for teste_mkl.f90 (code 1)"

When I replace **ddot** f77 call by **dot(d,e)** f95 call, add **"use mkl_blas95"** and "**use mkl_lapack95"** in the source code and compile with "**ifort -mkl teste_mkl.f90 -lmkl_blas95_ilp64 -lmkl_lapack95_ilp64**" every thingworks fine.

But I don't want to use blas95 (portability issues). What I'm doing wrong with **ddot** f77 call? I can compile and use other blas routines through f77 call without problems in the same program.

Thanks for your attention.

Link Copied

4 Replies

TimP

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-15-2013
04:46 PM

163 Views

You must have included IMPLICIT NONE or equivalent (which is good practice). Then you need a declaration of ddot, such as you might find by

include 'mkl_blas.fi'

If your program has portability problem with blas95, it might be good to correct it.

Achille_B_

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-16-2013
05:30 AM

163 Views

Hi TimP

I used "**use** mkl_blas" instead of using "**include** 'mkl_blas.fi'". I always include "**implicit none** below the last **use** statement".

I don't know the effective difference between **use** and **include** statements, I always write **use** statements in my source codes.

Including your suggestion and using " **ifort -mkl** teste_mkl.f90" to compile I got the following error message:

"

teste_mkl.f90(3): error #5102: Cannot open include file 'mlk_blas.fi'

include 'mlk_blas.fi'

--------^

teste_mkl.f90(51): error #6404: This name does not have a type, and must have an explicit type. [DDOT]

alpha= ddot(m, d, i, e, i)

-------^

compilation aborted for teste_mkl.f90 (code 1)

"

with **include** statement and

"

teste_mkl.f90(4): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [MKL_BLAS]

use mkl_blas

----^

teste_mkl.f90(5): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [MKL_LAPACK]

use mkl_lapack

----^

teste_mkl.f90(52): error #6404: This name does not have a type, and must have an explicit type. [DDOT]

alpha= ddot(m, d, i, e, i)

-------^

compilation aborted for teste_mkl.f90 (code 1)

"

with **use** statement.

It's important to emphatize that when I remove the **use** or **include** statement and comment the line with **ddot** calling, I can compile ( **ifort -mkl** teste_mkl.f90) and execute (./a.out) **dsymm** and **dsymv** callings without problems or warnings.

As the new versions of ifort/mkl don't complain about lack of **"use** mkl_blas" and **"use** mkl_lapack", I stopped putting them within my source codes, i just add **-mkl** option in the compile command, which is sufficient to build programs with shared parallel version of mkl. So I write **use** statements and compile with the full link advisor prescription just when something goes bad. Do you think I should change my behavior?

Thanks.

Vamsi_S_Intel

Employee

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-16-2013
07:29 PM

163 Views

You have a typo in your* include 'mkl_blas.fi' * statement,

teste_mkl.f90(3): error #5102: Cannot open include file** 'mlk_blas.fi'**

include 'mlk_blas.fi'

DDOT is a Fortran function that returns a double precision value, whereas DSYMM, DSYMV are Fortran Subroutines and so you need to include the appropriate interface file that contains the type information of the function.

Could you try it again after fixing the typo?

Achille_B_

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-17-2013
04:47 AM

163 Views

Thanks TimP and Vansi

Fixing the typo solved the problem.

But I still can't understand:

- why

DSYMMandDSYMVthat are blas levels 3 and 2 subroutines don't requireincludestatement to work properly butDDOT(blas level 1) requires;- And why

include 'mkl_blas.fi'works anduse mkl_blasdoesn't. If I write the f95 interfacedot(d,e), ause mkl59_blasbeforeimplict noneworks fine.

Best Regards

Arantes

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

For more complete information about compiler optimizations, see our Optimization Notice.