Why Are My Variables Changing Unexpectedly in My Freefall Program?

In summary: Since that name wasn't mentioned in an EXTERNAL statement, the compiler was treating it as an undefined variable, and was substituting its default type, which was logical, for the variable, which was supposed to be real. The code compiled without error, and ran without error messages. It just gave incorrect results.In summary, the conversation discusses a student having issues with variables in a freefall program. The variables 'y', 'v', and 'nshow' are problematic and change mysteriously. The issue is resolved by correctly ordering the variables in the call and definition, and ensuring all variables are declared. The conversation also mentions the importance of using IMPLICIT NONE to avoid similar errors.
  • #1
LucasCampos
17
0
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?

_________________________________________

Code:
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
______________________________________________________
 
Technology news on Phys.org
  • #2
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.
 
  • #3
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.
 
  • #4
LucasCampos said:
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.
 
  • #5


I would suggest checking your code carefully to make sure all of your variables are properly defined and initialized. It seems like there may be an issue with how some of your variables are being assigned or modified within the subroutine. I would also recommend running some test cases with known values to see if the issue persists and to help identify where the problem may be occurring. Additionally, it may be helpful to consult with a more experienced programmer or seek assistance from a professor or tutor to help troubleshoot and fix the issue.
 

FAQ: Why Are My Variables Changing Unexpectedly in My Freefall Program?

What are the variables that can be changed in an experiment?

The variables that can be changed in an experiment are known as independent variables. These are the factors that the scientist manipulates and controls in order to observe their effects on the outcome or dependent variable.

Why is it important to only change one variable at a time?

Changing only one variable at a time allows the scientist to accurately determine the cause and effect relationship between the independent and dependent variables. If multiple variables are changed at once, it becomes difficult to determine which variable is responsible for the observed outcome.

What are some common issues that can arise when changing variables in an experiment?

Some common issues that can arise when changing variables in an experiment include uncontrolled variables, which can impact the results and make them less reliable; confounding variables, which can skew the results and lead to incorrect conclusions; and inaccurate measurements or data collection methods.

How can scientists ensure that their experiments are valid when changing variables?

Scientists can ensure the validity of their experiments when changing variables by carefully designing their experiments and controlling for any potential confounding variables. They can also use multiple trials and replicate the experiment to ensure consistent results.

What are some strategies for effectively changing variables in an experiment?

Some strategies for effectively changing variables in an experiment include clearly defining the variables and their ranges, using randomization to eliminate bias, and carefully controlling and measuring all variables involved in the experiment.

Similar threads

Replies
1
Views
13K
Replies
8
Views
7K
Replies
4
Views
2K
Replies
8
Views
4K
Replies
8
Views
1K
Replies
8
Views
3K
Replies
4
Views
2K
Back
Top