Linking problem

Elvis_T_ · ‎06-16-2014

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.

mecej4 · ‎06-17-2014

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.

TimP · ‎06-17-2014

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.

Elvis_T_ · ‎06-17-2014

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?

Elvis_T_ · ‎06-17-2014

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.

-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

mecej4 · ‎06-17-2014

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?

Elvis_T_ · ‎06-17-2014

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.

mecej4 · ‎06-17-2014

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.

Elvis_T_ · ‎06-17-2014

data

mecej4 · ‎06-17-2014

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

Elvis_T_ · ‎06-17-2014

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

mecej4 · ‎06-17-2014

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.

Elvis_T_ · ‎06-18-2014

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

mecej4 · ‎06-18-2014

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.