procedure of IMSL in doulbe precision

[Mike896]

Hi

I have an error message about the following program (I use IMSL):

module aa
contains
!
SUBROUTINE ROSBRK (N, X, F)
INTEGER N
REAL(8) X(N), F <==== change to real(8)
!
F = 1.0E2*(X(2)-X(1)*X(1))**2 + (1.0E0-X(1))**2
!
RETURN
END SUBROUTINE ROSBRK
end module aa

program main
include 'link_fnl_static.h'
!DEC$ OBJCOMMENT LIB:"libguide.lib"
use aa
USE BCONF_INT
USE UMACH_INT
IMPLICIT NONE
INTEGER N
PARAMETER (N=2)
!
INTEGER IPARAM(7), ITP, L, NOUT
REAL(8) F, FSCALE, RPARAM(7), X(N), XGUESS(N), & <==== change to real(8)
XLB(N), XSCALE(N), XUB(N)

!
DATA XGUESS/-1.2E0, 1.0E0/
DATA XLB/-2.0E0, -1.0E0/, XUB/0.5E0, 2.0E0/
! All the bounds are provided
ITP = 0
! Default parameters are used
IPARAM(1) = 0
! Minimize Rosenbrock function using
! initial guesses of -1.2 and 1.0
CALL D_BCONF (ROSBRK, ITP, XLB, XUB, X, XGUESS=XGUESS, & !<== change from BCONF (IMSL)
iparam=iparam, FVALUE=F)
! Print results
CALL UMACH (2, NOUT)
WRITE (NOUT,99999) X, F, (IPARAM(L),L=3,5)
!
99999 FORMAT (' The solution is ', 6X, 2F8.3, //, ' The function ', &
'value is ', F8.3, //, ' The number of iterations is ', &
10X, I3, /, ' The number of function evaluations is ', &
I3, /, ' The number of gradient evaluations is ', I3)
!
END

Error: The characteristics of dummy argument 2 of the associated actual procedure differ from the characteristics of dummy argument 2 of the dummy procedure. (12.2) [ROSBRK]

Isn't "dummy argument 2 of the associated actual procedure " ITP?

Isn't "dummy argument 2 of the dummy procedure" X?

Thank you very much.

Mike

[Steven_L_Intel1 · Accepted solution]

This is a compiler bug - it is not allowing a dimension of (N) to match a declaration of (*). A workaround is to call the generic BCONF rather than the specific, and this is a practice I would recommend anyway. That's what generics are for! This bug will be fixed in a future update.

[Mike896]

Thank you Steve. I thought I miss something.

Mike

[yuezhanwei]

Hi Steve,

I have a similar question. I set the data kind to 8 under the project proterties ->Fortran -> Data. I got the following error message when I use BCONF instead of D_BCONF.

error #6285: There is no matching specific subroutine for this generic subroutine call. [BCONF]

Can you help me with this problem? Thank you.

Best,
Vivian

[Steven_L_Intel1]

Vivian,

Welcome to the forum.

First suggestion? Don't use that option. Its effects are much broader than you might think. Instead, use explicit declarations of the variables you want to be REAL(8).

The problem is, I would guess (since I can't see your code), that not all the REAL arguments to BCONF are the correct real KIND. The option you set affects "default real", but not things declared as REAL*4, etc.

If you can show me the line of code with the call to BCONF and the declarations, if any, of all the variables in the argument list, I might be able to help more.

[yuezhanwei]

Steve,

Thank you very much for your suggestion. I just posted the code under the other thread where I asked the same question.

Are you suggesting that i should not change the default real kind under the project property? What's the use of that data property? I will try your suggestion now.

[Steven_L_Intel1]

I replied in the other thread.

The property does what it says, but I consider it poor practice to use it. I can understand that you might try that as a quick way to get additional precision, but sometimes the side-effects are more than you anticipate.

My general advice is to not use any compiler options that change the meaning of a program - at least when there is a way to express that same meaning in the source. For example, instead of setting the default real kind to 8, declare a PARAMETER constant to be the kind you want to use (using SELECTED_REAL_KIND or SELECTED_INT_KIND) and then use that constant when declaring variables. That way, everything is in the source. If you just showed the source, one might not know that a problem was caused by a compiler option that changed the meaning.

[yuezhanwei]

Steve,

Thank you very much for your help.

Best,
Vivian