Undefined Variable Error

I recently changed a few equations in a subroutine of my program and now it's giving me the Error 112 when I try to run it. I also get a couple of Error 58's but I edited the project properties to ignore those which seems to be working.

This is what it says in the Error info:

INTEGRATESPEED - in file main.f95 at line 848 [+022b] main - in file main.f95 at line 452 [+2f0e]

These are the lines it is referring to:

This is in the main part of the program (line 452) CALL IntegrateSpeed(Thrust,Mass,MassflowHelp,Alpha,g,Gamma,Density,DrefHelp,CD,Timestep,v0,Drag,v1)

This is part of the subroutine IntegrateSpeed (line 848) vA=v0+(Timestep/2)*dv0

I did not change either of those two lines, neither did I add new variables. I just changed the equation a bit.

I'd very much appreciate any help you can give!

error 112 is : Reference to undefined variable or array element (/UNDEF)

This indicates that at line 848, one of the variables v0, Timestep or dv0 are not recognised as defined.

You could use SDBG to test these values or write them out imediately before line 848. Have you selected /UNDEF in your compile options ? (It appears a good thing if you have) When /DCLVAR is used variables are initialised with a value to indicate that it has not yet been initialised. In very rare circumstances, this value could be a valid number. Have you mixed 0(zero) with O(capital o) ? /implicit_none might help test this. My guess is that dv0 has not been initialised. Depending on the logic in your program, is it possible the initialisation has been skipped ?

Good Luck

SUBROUTINE IntegrateSpeed(Thrust,MassActual,Massflow,Alpha,g,Gamma,Density,Dref,CD,Timestep,v0,Drag,v1)

! This Subroutine will integrate the speed value. ! It takes speed and other parameters from step i and estimates the speed for step i+1.

IMPLICIT NONE

! Subroutine In- and Outputs REAL(KIND=2), INTENT(IN) :: Thrust ! Input: Thrust REAL(KIND=2), INTENT(IN) :: MassActual ! Input: Actual Mass REAL(KIND=2), INTENT(IN) :: Massflow ! Input: Actual Massflow REAL(KIND=2), INTENT(IN) :: Alpha ! Input: Angle of Attack Alpha REAL(KIND=2), INTENT(IN) :: g ! Input: g-Acceleration REAL(KIND=2), INTENT(IN) :: Gamma ! Input: Gamma REAL(KIND=2), INTENT(IN) :: Density ! Input: Actual Density REAL(KIND=2), INTENT(IN) :: Dref ! Input: Reference Diameter REAL(KIND=2), INTENT(IN) :: CD ! Input: Drag Coefficient REAL(KIND=2), INTENT(IN) :: Timestep ! Input: Timestep between step i and step i+1 REAL(KIND=2), INTENT(IN) :: v0 ! Input: Speed from step i REAL(KIND=2), INTENT(OUT) :: Drag ! Output: Drag REAL(KIND=2), INTENT(OUT) :: v1 ! Output: Speed from step i+1 ! Help variables REAL(KIND=2) :: Sref,Mass REAL(KIND=2), PARAMETER :: PI=3.1415926536 ! Pi

! Help velocities and derivatives REAL(KIND=2) :: dv0,vA,dvA,vB,dvB,vC,dvC

This is the first part of the subroutine where all the variables are initialized. I also checked the calculations for any capital o's but found none. I'll still have to try with the debugger, but as far as I can see none of the variables are undefined.

Edit: Just ran the debugger with /UNDEF on, it shows a lot of the variables as undefined but some of them come from an Input file. Sorry for not mentioning that earlier.

Your code sample 'defines' the variables, typically as REAL(KIND=2). This does not provide them with an initial value. I would also check your use of INTENT(IN), as to what value the variables retain on exiting the routine, for when the routine is called a second time. Read the fortran standard to see what INTENT(IN) means. I'd get the program working before providing any INTENT directives.

'Undefined' in the debugger refers to the value of the variable not being given, or 'initialised'. This is different to defining the type and kind of the variable.

John

Ah, I misunderstood the error then. Thanks for the help, I'll see if I can fix it now.

First of all I want to thank you for your patience and all the help you have given me so far. I got the program to work (somewhat). I took out all the INTENT declarations as you advised, however that didn't change anything. Then I gave the help variables the value 0. Now the program doesn't give me the error 112 anymore, but my whole calculation turns out to be 0. It's just as if those help variables are not changed during my calculation (as they should be) but retain the value of 0. Is there any way to prevent that?

How long is the program? Folks are just guessing at the answer to your question, but you might not be asking the right question!

E

The complete program, with every subroutine is about 965 lines long. The 2 subroutines where I had the error 112 issue are at both at the end.

Hmmmm it's too long to post here, but judging by your programming style it doesn't look too long to post somewhere for one of us to take a look at. Are you familiar with Dropbox or one of those sites where you can put stuff like code, and then send the address to someone to take a look at it?

Without the source code everyone who would like to help is just guessing.

E

Sorry for the long wait. I was not at home during the weekend.

Here is the dropbox link: https://www.dropbox.com/s/dclxymwdkdni324/main.f95

I can't even get as far as you do, as there are lots of mismatched brackets errors from line 803 onwards.

E

Ingo,

I looked at your code. Before you contemplate running it you need to remove all the coding bugs you have with your long equations. I (possibly) cleaned up a few such as: ! Runge Kutta - step by step Mass=MassActual Drag=CD*(Density/2)*(v0**2)Sref dv0 = (-gCOS((90-Gamma)*PI/180)) & + (Thrust/Mass)*COS((90-Gamma)*PI/180) * COS((90-(Alpha+Gamma))*PI/180) & + (Thrust/Mass)*SIN((90-Gamma)*PI/180) * SIN((90-(Alpha+Gamma))*PI/180) & + (Drag/Mass) vA=v0+(Timestep/2)*dv0

Mass=MassActual-Massflow*(Timestep/2)		! Reduce mass with half timestep
Drag=CD*(Density/2)*(vA**2)*Sref	! Drag with help speed A
dvA = (-g*COS((90-Gamma)*PI/180))                                            &
    + (Thrust/Mass)*COS((90-Gamma)*PI/180) * COS((90-(Alpha+Gamma))*PI/180)  &
    + (Thrust/Mass)*SIN((90-Gamma)*PI/180) * SIN((90-(Alpha+Gamma))*PI/180)  &
    + (Drag/Mass)

vB=v0+(Timestep/2)*dvA

Drag=CD*(Density/2)*(vB**2)*Sref			! Drag with help speed B
dvB = (-g*COS((90-Gamma)*PI/180))                                            &
    + (Thrust/Mass)*COS((90-Gamma)*PI/180) * COS((90-(Alpha+Gamma))*PI/180)  &
    + (Thrust/Mass)*SIN((90-Gamma)*PI/180) * SIN((90-(Alpha+Gamma))*PI/180)  &
    + (Drag/Mass)
 
vC=vB+Timestep*dvB

Mass=MassActual-Massflow*Timestep			! Reduce mass with another half step
Drag=CD*(Density/2)*(vC**2)*Sref			! Drag with help speed C
dvC = (-g*COS((90-Gamma)*PI/180))                                            &
    + (Thrust/Mass)*COS((90-Gamma)*PI/180) * COS((90-(Alpha+Gamma))*PI/180)  &
    + (Thrust/Mass)*SIN((90-Gamma)*PI/180) * SIN((90-(Alpha+Gamma))*PI/180)  &
    + (Drag/Mass)						 

v1=v0+Timestep*((dv0+2*(dvA+dvB)+dvC)/6)

but then stopped at ! Runge Kutta - step by step Mass=MassActual Lift=CL*(Density/2)(v0**2)Sref IF (v0==0) THEN ! This IF statement is needed to control that there is NO division by zero dgamma0=0 ELSE dgamma0 = (1/v0) * (ThrustSIN((90-(Alpha+gamma0))PI/180))/(MassCOS((90-gamma0)PI/180)) & + DragSIN((90-gamma0)PI/180)/(MassCOS((90-gamma0)PI/180))-Lift/Mass & - v0v0/rCOS((90-gamma0)*PI/180)*SIN((90-gamma0)PI/180)-(-gCOS((90-gamma0)PI/180) & + Thrust/MassCOS((90-gamma0)*PI/180)*COS((90-(gamma0+Alpha))PI/180) & + Thrust/MassSIN((90-gamma0)*PI/180)*SIN(90-(gamma0+Alpha))*PI/180)+Drag/Mass)*SIN((90-gamma0)*PI/180) END IF

You have left out a number of operators and brackets and I gave up guessing what you meant.

Yeah that part got a bit messy after I tried fixing the error by changing the coding around a bit. As this is my first time in Fortran I wasn't aware of it being very sensitive to this kind of thing. I'll get that into order and let you know if it solves the issue.

Quoted from JohnCampbell Ingo,

I looked at your code. ←-CUT-mecej4--> SIN((90-(Alpha+Gamma))*PI/180) & + (Drag/Mass) ←-CUT-mecej4--> You have left out a number of operators and brackets and I gave up guessing what you meant.

Expressions such as COS((90-(Alpha+Gamma)*PI/180) are sprinkled about inside the code, and are almost certainly wrong. If Alpha and Gamma are angles in degrees, Ingo ought to have PI/2 in place of 90 in these expressions.

Any procedural programming language is, as Ingo called it, 'sensitive' to blunders in the encoding of mathematical expressions.

The program originally worked with a cartesian coordinate system. All the '90-' expressions come from the transformation to a cylindrical coordinate system. However, my transformation worked in degrees on paper but the program works in rad. So it should be PI/2 and definitly not 90. I will change this as soon as possible and hopefully that will be the end of it.

My apologies for such a stupid mistake!

Edit: Subroutine IntegrateSpeed now seems to work perfectly, I fixed the math errors in IntegrateGamma as well, but I still get the error. The error seems to be related to the dgammaA,dgammaB and dgammaC variables because I do not get an error for the first calculation (I tried that by just making the other calculations 0 and the program ran without problems). The variable Radius is just a placeholder for something that still needs to be put in, which shouldn't cause problems though. I uploaded the reworked IntegrateGamma to Dropbox again (It seems to have messed up my spacing though, as it was all in order): https://www.dropbox.com/s/i5d8r93tg8dx5pi/ReworkedGamma.txt

Quoted from Ingo

Edit: Subroutine IntegrateSpeed now seems to work perfectly, I fixed the math errors in IntegrateGamma as well, but I still get the error. The error seems to be related to the dgammaA,dgammaB and dgammaC variables because I do not get an error for the first calculation (I tried that by just making the other calculations 0 and the program ran without problems). ←-CUT---> I uploaded the reworked IntegrateGamma to Dropbox again (It seems to have messed up my spacing though, as it was all in order): https://www.dropbox.com/s/i5d8r93tg8dx5pi/ReworkedGamma.txt

In that latest uploaded file, static analysis shows the following:

line 82: 'dgammaB' is used but never set. line 99: 'dgammaC' is used but never set.

So how do you propose to set the variables in this case? I assume what that means is that they do not have an initial value. I tried doing it by setting them to 0 in the definition, like I know from C++. When I do that the program is able to launch, but it just says calculating... and doesn't do anything else.

Quoted from Ingo So how do you propose to set the variables in this case? I assume what that means is that they do not have an initial value. I tried doing it by setting them to 0 in the definition, like I know from C++. When I do that the program is able to launch, but it just says calculating... and doesn't do anything else.

These matters are for you to ponder and act upon. You have to know what the calculation is intended to accomplish, and implement the algorithm using the features provided by the language.

Declaration of variables is necessary (unless IMPLICIT typing is in use) but mere declaration does not 'define' values for the variables declared.

If it is appropriate that the two variables in question be initialised to zero, add appropriate assignment statements at subroutine entry.

     dgammaB = 0
     dgammaC = 0

I got the program to work. Thank you very much for the great support!