subroutine arguments are not realizing.

[anishtain4]

This is an external subroutine, but when I want to run my code and it reaches the line after Minit=0.... it stops working and gives the access vilation error. when I looked at in in debug mode all of the input arguments have the value "Undefined pointer/array" what is wrong? I'm using this variables in other subroutines and they are fine! P0R and T0R are defined in util as parameter. What I'm doing wrong?

this is the code:

[bash]SUBROUTINE INITIAL(Q,GRD,FLD)
  USE UTIL
  !IMPLICIT NONE
  REAL::Q(:,:),GRD(:,:),FLD(:)
  REAL              ::Minit,T,P,ro,U
  Minit = 0.5**2.
  T   = T0R/(1+(FLD(4)-1)/2*Minit)
  P   = P0R/(1+(FLD(4)-1)/2*Minit)**(FLD(4)/(FLD(4)-1))
  ro  = P/FLD(1)/T
  U   = SQRT(Minit*FLD(4)*FLD(1)*T)
  Q(1,:)= ro*GRD(3,:)
  Q(2,:)= ro*U*GRD(3,:)
  Q(3,:)= ro*(FLD(2)*T+U**2/2)*GRD(3,:)
END SUBROUTINE[/bash]

[netphilou31]

Hi,

I think that the problem comes with the arguments declaration statement. You should use * instead of : for the sizes and you need to declare correctly the number of rows for the Q() and GRD() arrays.

I think that with this declaration the compiler assumes that these variables are not allocated. It is also strange that the compiler does not give you any error while compiling this subroutine !

Best regards,

[Arjen_Markus]

The use of ":" indeed forces the compiler to use a different calling convention than if you use "*".
With colons the program must pass the shape of the arrays too.

It is not the compiler's fault: you might have an explicit interface block in the calling program.

That asided, the best solution is to put the routine in a module and then use that module in the
program/routines that call this particular routine. Then the compiler knows the precise interface and it can generate the correct code.

Regards,

Arjen

[anishtain4]

I'm afraid that's not the case since I'm using this method ever since I'm writing codes, * is for the old fortrans and you may have trouble with that when u are using multidimensional arrays.
I have another code that works properly and the following subroutine exist in it:

[bash]FUNCTION RK4(X,h,EOK,DX,nu)
  USE INTERF,ONLY:FNC
	IMPLICIT NONE
	REAL,INTENT(IN)     ::EOK,h,DX,nu
	REAL,INTENT(IN)	    ::X(:)
...[/bash]

As you see I used the same method for X but I have no problem with that.

I didn't use any interface for this piece of code, yet it worked fine.
actually I was running this code but I had some numerical mistakes, to correct them I made a huge change and now I don't know what is wrong? I didn't made any change to this subroutine at all!

[Arjen_Markus]

You may not have seen any problem, but that is just a coincidence!

: and * are fundamentally different ways of passing array arguments. In the absence of an explicit interface, the compiler has to assume that the _called_ routine uses a FORTRAN 77 style. That means: an array is passed via the starting address - no size or shape information is passed.

It may be that you do not need that information in RK4 and then the mismatch in interface might just not become problematic.

Regards,

Arjen

[jimdempseyatthecove]

In the caller's subroutine/function(/program) variable declaration section try adding
INTERFACE
SUBROUTINE INITIAL(Q,GRD,FLD)
USE UTIL
REAL::Q(:,:),GRD(:,:),FLD(:)
END SUBROUTINE
END INTERFACE

[fortran]If this corrects the problem for the subroutine INITIAL
(when called from the subroutine including the INTERFACE)
then consider creating similar INTERFACE blocks for
other such routines. Place the interface blocks into
a module file, eg MOD_INTERFACES, add to project
and add USE MOD_INTERFACES to routines that call these subroutines/functions


[/fortran]

[mecej4]

Please pay attention to the good advice that others have given you. If a dummy argument is an assumed shape array (one declared with ':' for the extents rather than '*'), the language requires that an explicit interface be available at the calling location. Here is the relevant excerpt from F2003:

Section 12.3.1.1:
23 A procedure other than a statement function shall have an explicit interface if it is referenced and
.............
30 (2) The procedure has a dummy argument that
.............
33 (b) is an assumed-shape array,

That you got away with violating this requirement in the past gives you no guarantee that you will have similar luck in the future. Whether a problem occurs or not depends what attributes of the array, which should have been passed as hidden arguments or inside descriptors, are used in the subroutine/function of which it is a dummy argument. If you ever modify your code, thinking that it is fine, and add statements in the subroutine/function that use this expected but missing information, garbage values can be used or access violations can occur.