- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 grid
and 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 Levelset
defined 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 ComputeLS
also 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page