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

error #6633: The type of the actual argument differs from the type of the dummy argument.

Matin_E_
Beginner
9,519 Views

I am new to programming with Intel Fortran so I think there is something missing or wrongly organized that I am not aware of in this case. I would be grateful if someone can help me in this regard.

The problem is that I see the following errors when compiling my code, while I believe that I have declared the derived type variables cr and me correctly.

error #6633: The type of the actual argument differs from the type of the dummy argument.   [CR]

error #6633: The type of the actual argument differs from the type of the dummy argument.   [ME]

My code contains a Module named InputData which contains the definition of the derived type gridand declaration of the derived type variables cr and me of type grid. I make use of these definitions in the main program using a USE statement. The error refers to a line in the main program which CALLs an internal subroutine that uses cr and “me” as input argument (INTENT(IN)). Surprisingly, I use exactly the same way for declaring the derived type variable ls of type Levelsetdefined in Module OutputData using a USE statement in the Main program and get no error on that variable in the same subroutine. Adding a USE InputData statement to the subroutine ComputeLSalso did not address the issue.

I tried to remove all modules and include all type definitions and variable declarations in the Main program instead of in separate modules. But unfortunately the errors still exist.

@SteveLionel

 

 

0 Kudos
1 Solution
mecej4
Honored Contributor III
9,519 Views

You have two types of mistakes in the source files. 

  • You have more than one place where a derived type is defined. For instance, you have a subroutine that contains a definition for the type of one or more of its arguments, and a definition of the type of the actual argument elsewhere.
  • You have variables of derived type declared in a module, and the same variable appears as a dummy argument in a subroutine that USEs that module.

I have attached corrected source files that can be compiled, but there are two problems that you still need to address: subroutine CENTERPOINTS is not yet provided, (ii) you will have to make sure that the code actually does the calculations that you intended.

The following code is not valid because a variable with USE association is also used as a dummy argument.

module mymod
integer mvar
end module mymod

subroutine mysub(mvar,nvar)
use mymod
integer, intent(in) :: mvar
integer, intent(out) :: nvar
nvar=2*mvar-1
end subroutine mysub

However, a contained routine may declare a variable with the same name as a variable available by host association, and the following code is valid.

module mymod
integer m,p

contains
   subroutine mysub(m,n)
      integer, intent(in) :: m
      integer, intent(out) :: n
      n=2*m-1+p
   end subroutine mysub

end module mymod

 

View solution in original post

0 Kudos
5 Replies
mecej4
Honored Contributor III
9,519 Views

Two separate type declarations are not considered to matching types even when the declarations match perfectly, except when certain strong rules are obeyed. For details, read carefully through 4.5.1.3 of the F2003 standard, in particular this part: "Data entities in different scoping units also have the same type if they are declared with reference to different derived-type definitions that specify the same type name, all have the SEQUENCE property or all have the BIND attribute, have no components with PRIVATE accessibility, and have type parameters and components that agree in order, name, and attributes. Otherwise, they are of different derived types."

Run the compiler on the test program below

program tst
implicit none
type A
  integer :: ai
end type A

type B
  integer :: bi
end type B

type(A) :: ta
type(B) :: tb

ta%ai = 15
tb = ta

write(*,*)tb%bi

end program tst

as an illustration of this point.

The solution is to give a single declaration in a module, and USE that module in place of the separate type declarations that you have now. 

In two places, you use MINLOC in such a way that the return value is an array, but assign it to a scalar. 

 

0 Kudos
Matin_E_
Beginner
9,519 Views

Thanks for your answer. The problem related to MINLOC might be because I had not distinguished between a 1x1 array and a scalar. I fixed it then.

As per the main problem, error # 6633, I am trying to pass variables of type "grid" to a subroutine with dummy arguments of the same type, "grid", and not to a different type name with the same field types as you have defined types A and B above. Is it not allowed in a subroutine to declare a variable of a derived-type which is defined in another module? For example, can we not declare a variable of type "grid" which is defined in module "InputData" in another subroutine using  "USE InputData" or USE InputData, ONLY: grid"? Should all variables of type "grid" be declared in the same module, "InputData", and then be used in any other subroutine containing "USE InputData" statement without being declared as a dummy argument?

Can you tell me why "error #6633: The type of the actual argument differs from the type of the dummy argument." refers only to "cr" and "me" but not to the variable "ls" of derived type "levelset" which is also defined in another module?

By the way, I have deleted the declarations inside the internal subroutines and instead, included USE statement for the module containing type definitions and variable declarations. (I have attached the revised code). Now, error # 6633 has gone, however I receive error #6405: The same named entity from different modules and/or program units cannot be referenced.   [CR], referring to a line I have declared a local variables using the size of one of the fields of the derived type variable "cr" declared in a module (line below).

REAL, DIMENSION( SIZE(cr%conn, DIM=1), 3 ) :: centers, normals

This is apparently due to the USE statement I have added to the subroutine. Could you let me know why I am not allowed to use such a declaration? Is there any way to define the size of these variables in the declaration statement or should I use "allocatable" or "pointer" attribute?

 

 

 

0 Kudos
mecej4
Honored Contributor III
9,520 Views

You have two types of mistakes in the source files. 

  • You have more than one place where a derived type is defined. For instance, you have a subroutine that contains a definition for the type of one or more of its arguments, and a definition of the type of the actual argument elsewhere.
  • You have variables of derived type declared in a module, and the same variable appears as a dummy argument in a subroutine that USEs that module.

I have attached corrected source files that can be compiled, but there are two problems that you still need to address: subroutine CENTERPOINTS is not yet provided, (ii) you will have to make sure that the code actually does the calculations that you intended.

The following code is not valid because a variable with USE association is also used as a dummy argument.

module mymod
integer mvar
end module mymod

subroutine mysub(mvar,nvar)
use mymod
integer, intent(in) :: mvar
integer, intent(out) :: nvar
nvar=2*mvar-1
end subroutine mysub

However, a contained routine may declare a variable with the same name as a variable available by host association, and the following code is valid.

module mymod
integer m,p

contains
   subroutine mysub(m,n)
      integer, intent(in) :: m
      integer, intent(out) :: n
      n=2*m-1+p
   end subroutine mysub

end module mymod

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
9,518 Views

In C++ you can define a type (struct or class) multiple times using the same name, same everything else, same compiler options, and git away with it because C++ will verify the signatures and the Linker will reject differences in object code.

In Fortran this is not the case. You only get to have one place within a Link output where you can define the type.

Note "within a Link output". A DLL and an application will have it defined in different places (but most likely within the same module). Some distros may have different declarations (but functionally useful to the application) to hide proprietary data.

Jim Dempsey

0 Kudos
Matin_E_
Beginner
9,518 Views

Thank you so much for your clarifying examples. I read the corrected file line by line, and realized my mistake. I really appreciate your help.

0 Kudos
Reply