Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29271 Discussions

Error: The type of argument differs from the typeof dummy argument

boukes
Beginner
907 Views

Whencompiling the code below I get the error typed down in the subject box. Does anyone know how to resolve this problem?

c **********************************************************************

lmloc = ninfel(igrc)

nin = ninfe(igrc)

call sforcx ((kndid),(kcoord),(kid),(kxlod),dd,ielm,

1 nnods,ntnds,neqq,nedof(igrc),lmloc,nin)

c **********************************************************************

RETURN

END

c **********************************************************************

SUBROUTINE SFORCX (ndid,coord,id,xlod,dd,ielm,nnods,ntnds,

1 neqq,ndf,lmloc,nin)

0 Kudos
5 Replies
Steven_L_Intel1
Employee
907 Views
What's the complete text of the error? You don't show all the relevant code either, including declarations. Assuming Fortran implicit rules, kcoord and kxlod are integers but coord and xlod are reals. This mismatch would be an error.
0 Kudos
boukes
Beginner
907 Views

It is a code dated from 1994 and originally compiled with Powerstation 1. Because I want to execute on an xp pc, it is not possible to use powerstation anymore. After my last post I did the building again by placing the .for codes in a new project. Now I get the same error, but in another .for file. The complete code ca be found below and the errors are

Error: the type of the actual argument differs from the type of the dummy argument [ENER] and resp [ENED].[EEXT].[BETO],[RELAS].[RDAMP],[RINIT],[DDISE],[DISE],[VELE]

after these errors the following error is:

The type matching rules of actual arguments and dummy arguments have been violated.

I Think it is strange these errors are given at line 47 (at the rule call resp02)

c *********************************************************************

SUBROUTINE RESPXX (kel,kresis,ksave,kgem,kstep,ndf,kst,kenr,

1 ener,ened,eext,beto)

c *********************************************************************

c PURPOSE : To perform element response computations.

c----------------------------------------------------------------------

c DOUBLE PRECISION / LARGE

include 'double.h'

c----------------------------------------------------------------------

c CALLED FROM : respon

c SUBR. CALLS : resp**

c----------------------------------------------------------------------

c ARGUMENTS

C INPUT

c kel = element type.

c kresis = resisting force indicator.

c 1: static

c 2: static + damping

c kgem = > 0 if geometric stiffness included.

c kstep = segment step number (-1 resets envelop values).

c ndf = no. of element dofs.

c ksave = saving print indictor (1: print, 0: no print).

c kenr = energy calculation code.

c 1: perform calculation

c 0: omit

c beto = element stiffness proportional damping factor.

C OUTPUT

c ener = element elasto-plastic work.

c ened = element damping work.

c eext = second order external work done by element.

c relas(ndf) = element resisting force vector.

c rdamp(ndf) = element damping force vector.

c rinit(ndf) = element initial force vector.

C MODIFY

c kst = stiffness change indicator (set = 1 if change).

c ----------------------------------------------------------------------

c LABELLED COMMONS

include 'para.h'

include 'disvel.h'

c **********************************************************************

if (kel .eq. 1) then

call resp01 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 2) then

call resp02 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 3) then

call resp03 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 4) then

call resp04 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 5) then

call resp05 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 6) then

call resp06 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 7) then

call resp07 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 8) then

call resp08 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 9) then

call resp09 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 10) then

call resp10 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 11) then

call resp11 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 12) then

call resp12 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 13) then

call resp13 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 14) then

call resp14 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 15) then

call resp15 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 16) then

call resp16 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 17) then

call resp17 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 18) then

call resp18 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 19) then

call resp19 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

else if (kel .eq. 20) then

call resp20 (kresis,ksave,kgem,kstep,ndf,kst,kenr,ener,ened,

1 eext,beto,relas,rdamp,rinit,ddise,dise,vele)

end if

c **********************************************************************

RETURN

END



0 Kudos
Steven_L_Intel1
Employee
907 Views
Most old compilers would not detect this coding error. Please post the SUBROUTINE line of RESP02 and all of the argument declarations. We also need to see the declarations of the variables in RESPXX. If you want to create a ZIP file of the sources and include files and attach it to a reply (use the Options tab), that might make it easier to diagnose.
0 Kudos
Les_Neilson
Valued Contributor II
907 Views

Fortran has always had the rule that in the *absence* of an explicit type statement (integer, real, logical etc) then any variable name beginning with a letter "A" to "H" or "O" to "Z" was assumed to be of type REAL. Any variable name beginning with a letter "I" to "N" was assumed to be of type INTEGER.

In simple terms you have something like the following :

INTEGERIVALUE
... ...
CALLXXXX(IVALUE) ivalue here is called an Actual Argument
...
END

SUBROUTINEXXXX(ENER) ener here is called a dummy argument
......
END

In subroutineXXXX if there isNOT a statement
INTEGERENER
then because the dummy argumentname "ener" does not begin with a letter between "I" to "N" it is assumed to be of type REAL which does not match the type (INTEGER) of the actual argument "ivalue". Modern compilers are able to spot this error if the codes are in the same file (or in modules which is unlikely in your case)

HTH

Les

0 Kudos
jimdempseyatthecove
Honored Contributor III
907 Views

In addition to Les's comments if your subroutine happened to use a REAL for dummy argument passed as INTEGER .and. if that if that real dummy argument were not use or if the real dummy argument were tested against 0 (.eq., .lt, .ge, .ne.) then the subroutine would have run as intended (excepting if the REAL were REAL(8) and INTEGER were INTEGER(4)). The argument mis-match is an error in programming regardles if the subroutine happened to work as intended.

For the above to work, the variables would have to be internally passed by reference and not passed in a register. Therefore, the program that may have worked on IA32 might not work on EM64T (x64) depending on which argument was in error in the subroutine argument list.

Jim Dempsey

0 Kudos
Reply