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

Linking problem

Elvis_T_
Beginner
724 Views

Hello, 

I am trying to solve a linear system of equations using LAPACK ROUTINES and I have tried to link but some of the codes seem to work whiles others do not. I get the error when  use the CALL GESV. 
design.f90(477): error #6285: There is no matching specific subroutine for this
generic subroutine call.   [GESV]
                CALL GESV(xtemp, ztemp)
---------------------^
compilation aborted for design.f90 (code 1)

This does not happen when i change CALL GESV to CALL GETRF but then CALL GETRS will also no work. xtemp is a 12 x 12 matrix whiles ztemp is a vector of 12 elements. 

This is the coding 

		PROGRAM DESIGN
		
		USE Prop_mod
		USE blas95
		USE f95_precision
		USE lapack95	

		IMPLICIT NONE	

		!DECLARATIONS OF VARIABLES

......

		DO i = 1, num 
			WRITE(30, '(*(G0.4, ",", :))') xtemp(i, :)
		ENDDO
		PAUSE
		
		ALLOCATE(ipiv(num))
		!CALL getrf(xtemp, ipiv)		
		!CALL getrs(xtemp, ipiv, ztemp)

		CALL gesv(xtemp, ztemp)
		
		WRITE(*, *)
		WRITE(*, *) xtemp
		WRITE(30, *)
		WRITE(30, *)
		DO i = 1, num 
			WRITE(31, '(*(G0.4, ",", :))') xtemp(i, :)
		ENDDO		
		PAUSE
		
		WRITE(*,*) ztemp
		PAUSE
		
		WRITE(*, *)

 

When i combine Call getrf and getrs, only getrf works and the solution subroutine "getrs" fails. 

Call gesv does not work at all. I really need someones help on this.

This is what i type to compile and link the codes

C:\Program Files (x86)\Intel\Composer XE 2013 SP1\Projects>ifort Props_mod.f90 d
esign.f90 /traceback mkl_rt.lib mkl_blas95_ilp64.lib mkl_lapack95_ilp64.lib libi
omp5md.lib /exe:ex1.exe

Am I not linking properly? I have tried all i know of but it is still not working. 

0 Kudos
13 Replies
mecej4
Honored Contributor III
724 Views

The error #6285 messages are usually caused by using variables of incorrect types or having incorrect declaration statements. You posted snippets of code without including the declarations, and the lines that you omitted may be exactly the lines that contain errors. Without those lines being available, it impossible for us to help you.

The xxyy_ilp64 libraries are for use with object files that call MKL routines with 8-byte integer arguments. If you use default (4-byte) integers, you must link against xxyy_lp64 libraries. Use the MKL Link Line Advisor and avoid such errors.

0 Kudos
TimP
Honored Contributor III
724 Views

You could look up examples of gesv usage.  Your error in declaration of xtemp or ztemp won't be fixed by suppressing compiler checking and fiddling with link options.

Type matching is rather picky; for example, it may not accept real and real(4) or real*4 as matching, so there are cases you could make up where suppressing the error could work, but it looks advisable for you to take advantage of the compile checking.

As you're using ifort and apparently not 64-bit integers, you could start out with the -mkl link options and focus on getting your source code right.

0 Kudos
Elvis_T_
Beginner
724 Views

Thank you for all your help. These are declarations i made.

		
		REAL, DIMENSION(:,:), ALLOCATABLE :: xtemp, nxtemp
		
		INTEGER, DIMENSION(:), ALLOCATABLE :: tubes, passes, coldside, insert, shells
		INTEGER, DIMENSION(:), ALLOCATABLE :: htp, ctp, ztemp, ipiv

I changed ztemp into nxtemp and the command run successfully but there was no solution to the Call statement. 

		ALLOCATE(ztemp(num))
		ALLOCATE(xtemp(num, num))
ALLOCATE(nxtemp(num, 1))
		PRINT *, ztemp
		WRITE(*, *)
		
		PRINT *, xtemp
		WRITE(*, *)
		
		DO i = 1, num 
			WRITE(30, '(*(G0.4, ",", :))') xtemp(i, :)
		ENDDO
		
		ALLOCATE(ipiv(num))
		nxtemp = RESHAPE(ztemp, (/num, 1/))

		CALL gesv(xtemp, nxtemp, ipiv, info)
		PRINT *, 'info = ', info, 'if = 0 then good  else problem'
		WRITE(*, *)

		!CALL getrf(xtemp, ipiv)	
		
		PRINT *, xtemp
		PAUSE
		
		!CALL getrs(xtemp, ipiv, nxtemp)
		!CALL sgetrs('N', num, 0, xtemp, num, ipiv, nxtemp, num, info)   

		DO i = 1, num 
			WRITE(31, '(*(G0.4, ",", :))') xtemp(i, :)
		ENDDO		
		
		WRITE(*, *)
		WRITE(*,*) ztemp
		WRITE(*, *)
	
		WRITE(*, *) nxtemp
		

I also included a /check in command prompt and made the other changes as suggested and this are the errors that came up. 

forrtl: warning (402): fort: (1): In call to I/O Write routine, an array temporary was created for argument #1
(this is repeated 12 times when /check is included but if not this does not show up)

 info = 12 (This is the data from the call statement)

But there was no solution to the Call statement. Is there something wrong with the arrays i am using in the call statement?

0 Kudos
Elvis_T_
Beginner
724 Views

In the command prompt - It compiled alright but errors came at run time

C:\Program Files (x86)\Intel\Composer XE 2013 SP1\Projects>ifort Props_mod.f90 d
esign.f90 /traceback /check mkl_rt.lib mkl_blas95_lp64.lib mkl_lapack95_lp64.lib
 libiomp5md.lib /exe:ex1.exe
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Inte
l(R) 64, Version 14.0.1.139 Build 20131008
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 11.00.61030.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:ex1.exe
-subsystem:console
-incremental:no
Props_mod.obj
design.obj
mkl_rt.lib
mkl_blas95_lp64.lib
mkl_lapack95_lp64.lib
libiomp5md.lib

0 Kudos
mecej4
Honored Contributor III
724 Views

Not much can be said about how a program should behave while running when (i) you have not presented the complete program and/or (ii) the program contains errors. Please present a complete example source file (plus include files and data files if needed) that can be compiled and run.

I changed ztemp into nxtemp and the command run successfully but there was no solution to the Call statement. 

I cannot make sense of that sentence. Which command ran successfully? What is a "solution to the Call statement"?

Helpful comments were made in response to your post. What is your response to those comments?

0 Kudos
Elvis_T_
Beginner
724 Views

Thanks for  your comments.

Sorry about that. The files are attached. I could not upload as a CSV file so i changed it to xls file before uploading. 

I changed ztemp into nxtemp and the command run successfully but there was no solution to the Call statement. 

Calling ifort in command prompt worked well after i reshaped ztemp into nxtemp, the Call statement could not solve the system of linear equations. 

0 Kudos
mecej4
Honored Contributor III
724 Views

Your program requires input data to be in text files. The Excel files that you provided cannot be read as text files. You can zip up the CSV files and attach the zip file, instead.

0 Kudos
Elvis_T_
Beginner
724 Views

data

0 Kudos
mecej4
Honored Contributor III
724 Views

In addition to the data in the two files provided, the program needs input data (to satisfy read(*,...) statements in the program) to run.

0 Kudos
Elvis_T_
Beginner
724 Views

These are the user input data. For example put in these data in the order in which they are asked:

C:\Program Files (x86)\Intel\Composer XE 2013 SP1\Projects>ex1

                 ENTER THE NUMBER OF HOT STREAMS  2

                ENTER THE NUMBER OF COLD STREAMS  1

 

         ENTER THE NUMBER OF MIXING POINTS FOR ...
                                  ... HOT STREAM  1

                                 ... COLD STREAM  2

             ENTER THE NUMBER OF HEAT EXCHANGERS  3


 ENTER THE INPUT DATA FOR THE HOT STREAMS

 HOT STREAM 1  - Kero
                         INLET FLOWRATE (kg/s) =  30
                         INLET TEMPERATURE (C) =  166
 HOT STREAM 2  - OverH
                         INLET FLOWRATE (kg/s) =  43
                         INLET TEMPERATURE (C) =  290

 ENTER THE INPUT DATA FOR THE COLD STREAMS

 COLD STREAM 1  - Crude1
                         INLET FLOWRATE (kg/s) =  193
                         INLET TEMPERATURE (C) =  27

 HEAT EXCHANGER INFORMATION FOR EACH STREAM


 CALCULATIONS FOR EACH HEAT EXCHANGER

 STARTING CALCULATION ...


 FOR HEAT EXCHANGER            1

                          ENTER THE HOT STREAM ID 1
                       IS THERE BRANCHING? Y or N n
                    BYPASS FRACTION (BTN 0 AND 1) 0

                         ENTER THE COLD STREAM ID 1
                       IS THERE BRANCHING? Y or N n
                    BYPASS FRACTION (BTN 0 AND 1) 0

 

 FOR HEAT EXCHANGER            2

                          ENTER THE HOT STREAM ID 2
                       IS THERE BRANCHING? Y or N y
            ENTER NUMBER OF BRANCHES FOR HOT ID  22
                       % OF MASS FLOW IN BRANCH  130
                    BYPASS FRACTION (BTN 0 AND 1) 0

                         ENTER THE COLD STREAM ID 1
                       IS THERE BRANCHING? Y or N y
       ENTER NUMBER OF BRANCHES FOR FOR COLD ID  12
                       % OF MASS FLOW IN BRANCH  138
                    BYPASS FRACTION (BTN 0 AND 1) 0

 

 FOR HEAT EXCHANGER            3

                          ENTER THE HOT STREAM ID 2
                    BYPASS FRACTION (BTN 0 AND 1) 0

                         ENTER THE COLD STREAM ID 1
                    BYPASS FRACTION (BTN 0 AND 1) 0

0 Kudos
mecej4
Honored Contributor III
724 Views

The 12 X 12 matrix that you pass to gesv is singular, which is why the value of info is not zero. You have to examine your problem and program logic to determine why the matrix is singular.

0 Kudos
Elvis_T_
Beginner
724 Views

Thank you mecej4 for all your help. 

I am re-examing the matrix but Is there another fortran routine to use in solving this singular matrix?

I am  totally stuck and need a way out

0 Kudos
mecej4
Honored Contributor III
724 Views

Elvis T. wrote:
I am re-examining the matrix but Is there another Fortran routine to use in solving this singular matrix?

Your 12th equation, for the input data set that you gave in #11, has all coefficients equal to zero. This indicates that, in effect, you have 11 equations for 12 unknowns. For most well-formulated engineering/physics problems, this should not happen. What did that 12th equation come from? Why are all the coefficients of that equation zero? Is that physically possible? Is there another physical law or constraint at play, which has not been represented with a corresponding equation?

Rather than look for magical solution methods, find the error in your problem formulation and fix it. Otherwise, you will be in the unpleasant situation of having to choose from an infinite set of "solutions", all of which are probably incorrect from a physical point of view.

0 Kudos
Reply