Silverfrost Forums

Welcome to our forums

Error Real(kind=2) when real(kind=1) is required

28 Nov 2011 3:26 #9309

Hello, I think I spent a long time in front of the computer that I can´t see anymore. May be someone can help me find the mistake. here is the summarized code:

module common_var
  implicit none
  save
  integer			:: L,IMAX,K,KP
  double precision	:: Pe
  double precision	:: EW(200),EWP(200),R(1000),E(1000),VZ(1000)
end module common_var

Program Temperature
use common_var
implicit none
double precision                :: C_coef,D_coef,WHF,WT
integer                             :: I,L1,L2
!!!!!!!!!!!!!!Load Data!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
open(20, FILE = 'Velocity.asc', STATUS = 'UNKNOWN')
read(20,*)IMAX
read(20,*)(R(I),VZ(I),E(I),I=1,IMAX)
close(20)
write(*,*)'Data loaded'
do I=1,200
EW(I)=0.0
EWP(I)=0.0
end do

call SDEW(E,R,VZ,EW,EWP,K,KP)

End Program Temperature
!-----------------------------
subroutine SDEW(E,R,VZ,EW,EWP,K,KP)
use common_var
write(*,*)  'Unterprogramm: '
end subroutine SDEW

The error is like following: attempt to call routine with argument number one as a real(kind=2) when real(kind=1) was required.

I dont see my mistake , can anyone help please!! Miriam

28 Nov 2011 5:30 #9310

If you use a module to pass your variables, you cannot pass them a second time in a parameter list. Therefore, simply write

call sdew()

and

subroutine sdew()

... and it works.

Regards - Wilfried

28 Nov 2011 8:37 #9311

Wilfried,

I learnt something here! Miriam is treating these declarations as you would an 'INCLUDE' file in Fortran-77. In fact, the declarations are more like a COMMON block.

Eddie

29 Nov 2011 7:48 #9317

Thanx!!! It is working. It worked also with the 'traditional' call of the subroutine, but with the variable declaration as real instead of double precision in the module common_var.

Miriam

29 Nov 2011 8:45 #9319

Hi Eddie and Miriam,

I found a lot of good information about modules in the FTN95 user's guide, chapter 10, 'Using modules'. For instance, they write 'Modules provide an alternative method to using COMMON blocks for sharing data between different program units without passing such data as arguments.'

These PDF documentation dates from the Salford era but is very useful until today. I don't know whether it is available here for download.

To be true, usually I still prefer the traditional common blocks 😉

Regards - Wilfried

29 Nov 2011 1:54 #9325

I really dont get the meaning of the whole thing. With the 'real'- declaration, it works, with 'double precision' it is not. If I use with double precision this way to call the subroutine sdew() it works. I don´t get the logic behind all of this. Moreover my program is expanding (will be approximately by 5000 lines with a lot of functions and subroutines). And now with the next implemented function I have again the same error. I really don´t see how to solve the problem for once, so that I dont have to find tricks for every function and by the end the program won´t run.

29 Nov 2011 3:20 #9326
  1. This works because X is available in the main program and in the subroutine via the Common block

      Program Eddie
      Double Precision X(50)
      Common / A /  X
      Call B
      END
      Subroutine B
      Double Precision X(50)
      Common / A /  X
      Return
      END 
    
  2. This works because X is available in the main program and then in the subroutine via the subprogram argument list

     Program Eddie
     Double Precision X(50)
     Common / A /  X
     Call B (X)
     END
     Subroutine B (X)
     Double Precision X(50)
     Return
     END  
    
  3. This doesn't work because you aren't allowed to make X available in 2 completely different ways: through the Common block and via the subprogram argument list

     Program Eddie
     Double Precision X(50)
     Common / A /  X
     Call B (X)
     END
     Subroutine B (X)
     Double Precision X(50)
     Common / A /  X
     Return
     END 
    
  4. This works because X is made available to routine B through the subprogram argument list

     Module C
     Double Precision X(50)
     End Module
     Program Eddie
     Uses C
     Call B (X)
     END
     Subroutine B (X)
     Double Precision X(50)
     Return
     END 
    
  5. This works because the scope of X covers the program and the subroutine because they both Use C

     Module C
     Double Precision X(50)
     End Module
     Program Eddie
     Uses C
     Call B
     END
     Subroutine B
     Uses C
     Return
     END
    
  6. This doesn't work because you aren't allowed to make X available to subroutine B in 2 different ways: via the subprogram argument list AND because the scope of X covers the program and the subroutine as they both Use C

    Module C
    Double Precision X(50)
    End Module
    Program Eddie
    Uses C
    Call B (X)
    END
    Subroutine B (X)
    Uses C
    Return
    END 
    

Somewhere in every routine you need to declare that X is Double Precision.

Eddie

29 Nov 2011 4:25 #9327

Just an additonal remark:

You should never use declarations like 'real x' but specify all times what kind of real you mean. In most cases, a declaration like 'double precision x' or 'real8 x' or 'real(kind=2) x' will be useful, meaning 8 bits of memory for x. Sometimes, 'real4 x' or 'real(kind=1) x' may be used (4 bits). This in conjunction with 'implicite none' in all main programmes, subroutines and functions will help to minimise problems resulting from inconsistant variable declarations. It is also a good idea to note the warning messages from compiler + linker 😉

In the same way write 'integer4 j' instead of 'integer j', 'logical2 t' instead of 'logical t' and so on. It is my experience that exact declarations are better than the use of respective compiler options (like /intl).

Regards - Wilfried

29 Nov 2011 11:45 #9330

Your problem is that the arrays used in subroutine SDEW are transferred both via the argument list and the module. This should not be done. Where you transfer array E by both argument list and module, the compiler considers them as different, and so the E in the argument list is implied to be a real4 variable, not a real8 array. compiling with /xref should show this. (not sure why the compiler allows this ?) ( My recommendation is that you replace 'double precision' by 'real*8' as it more clearly defines the precision being used ) The use of double precision is not the source of your problem.

Try this change, where the module use is removed from subroutine SDEW

module common_var 
  implicit none 
  save 
  integer         :: L,IMAX,K,KP 
  double precision   :: Pe 
  double precision   :: EW(200),EWP(200),R(1000),E(1000),VZ(1000) 
end module common_var 

Program Temperature 
use common_var 
implicit none 
double precision                :: C_coef,D_coef,WHF,WT 
integer                             :: I,L1,L2 
!!!!!!!!!!!!!!Load Data!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
open(20, FILE = 'Velocity.asc', STATUS = 'UNKNOWN') 
read(20,*)IMAX 
read(20,*)(R(I),VZ(I),E(I),I=1,IMAX) 
close(20) 
write(*,*)'Data loaded' 
do I=1,200 
 EW(I)=0.0 
 EWP(I)=0.0 
end do 

call SDEW(E,R,VZ,EW,EWP,K,KP) 

End Program Temperature 
!----------------------------- 
subroutine SDEW(E,R,VZ,EW,EWP,K,KP) 
!
  double precision :: E(1000), R(1000), VZ(1000), EW(200), EWP(200)
  integer :: K, KP 
!
write(*,*)  'Unterprogramm: ' 
end subroutine SDEW 

or as Wilfred recomended :

module common_var 
  implicit none 
  save 
  integer         :: L,IMAX,K,KP 
  double precision   :: Pe 
  double precision   :: EW(200),EWP(200),R(1000),E(1000),VZ(1000) 
end module common_var 

Program Temperature 
use common_var 
double precision                :: C_coef,D_coef,WHF,WT 
integer                             :: I,L1,L2 
!!!!!!!!!!!!!!Load Data!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
open(20, FILE = 'Velocity.asc', STATUS = 'UNKNOWN') 
read(20,*)IMAX 
read(20,*)(R(I),VZ(I),E(I),I=1,IMAX) 
close(20) 
write(*,*)'Data loaded' 
do I=1,200 
 EW(I)=0.0 
 EWP(I)=0.0 
end do 

call SDEW

End Program Temperature 
!----------------------------- 
subroutine SDEW
use common_var 
!
write(*,*)  'Unterprogramm: ' 
end subroutine SDEW 
Please login to reply.