Why Are My Variables Changing Unexpectedly in My Freefall Program?

[LucasCampos]

I'm a student, and I had to do a freefall program. But I'm having some issues with variables. As soon as a subroutine ends, they go bananas! The problematic trio is 'y','v' and 'nshow'. When the subroutine Euler ends, 'v' gets the module of y, y go to zero and nshow to 32767!

How can I fix that?

_________________________________________

PROGRAM free_fall
IMPLICIT NONE
DOUBLE PRECISION y,a,g,t,dt,v
INTEGER nshow, counter
t = 0.0d0
OPEN(UNIT=1, FILE="TEST.dat")
OPEN(UNIT=2, FILE="TESTEULER.dat")
CALL initial (y,v,a,g,t,dt)
WRITE (1,*) v,y,nshow
!^Here my variables change misteriously
counter=0
CALL Euler (y,v,a,t,dt,nshow,counter)
CALL print_table(y,v,a,dt,t,nshow)
END

SUBROUTINE initial(a,y,v,g,t,dt)
DOUBLE PRECISION y,a,g,t,dt,v
WRITE(*,*) 'time step ='
READ(*,*) dt
WRITE(*,*) 'height ='
READ(*,*) y
WRITE(*,*) 'initial velocity ='
READ(*,*) v
WRITE(*,*) 'number of times steps between output ='
READ(*,*) nshow
WRITE (1,*) v,y,nshow
!^Until this point, variables are OK
END

SUBROUTINE Euler(y,v,a,t,dt,nshow,counter)
DOUBLE PRECISION y,a,t,dt,v
INTEGER nshow,counter
OPEN(UNIT=4, FILE="vt.dat")
OPEN(UNIT=3, FILE="yt.dat")
a = -9.8
100 v = v+a*dt;
y = y+v*dt
t = t+dt
counter = counter + 1
IF (mod(counter,nshow) .EQ. 0.0D0) CALL print_table(y,v,a,dt,t,nshow)
WRITE (2,*) t,y,v,dt,a,counter,nshow
WRITE (*,*) t,y,v,dt,a
IF (y .LE. 0.0D0) go to 200
go to 100
200 STOP
END

SUBROUTINE print_table(y,v,a,dt,t)
DOUBLE PRECISION y,t,v
WRITE (4,*) t,v
WRITE (3,*) t,y
!Each table will be made in a file. TEST and TESTEULER are, obviously, tests
END

______________________________________________________

 

[Mark44]

When you call initial, the actual parameters are CALL initial (y,v,a,g,t,dt).
The formal parameters in your initial subroutine definition are SUBROUTINE initial(a,y,v,g,t,dt).

Since you are using variables with the same names in the call and the definition, you should keep them in the same order in both places. I think that's what your problem is.

 

[LucasCampos]

OMG! Thanks! I've been wrestling against tis problem for a full day already! It was exatly as you said. Just the order. The nshow problem is that it was not being declared.

 

[jtbell]

The nshow problem is that it was not being declared.

That sort of thing is why, when I still used Fortran, I always put IMPLICIT NONE at the beginning of each program and subroutine, to force me to declare all my variables.

I remember once spending an hour helping a student find a bug in her program, and it turned out she had mis-spelled a variable in one occurrence, substituting the letter O for the digit 0, or the letter I for the digit 1, or something like that.