forums.silverfrost.com

Ingo · Joined: 10 Oct 2012 Posts: 10

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!

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

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

Ingo · Joined: 10 Oct 2012 Posts: 10

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.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

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

Ingo · Joined: 10 Oct 2012 Posts: 10

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

Ingo · Joined: 10 Oct 2012 Posts: 10

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?

LitusSaxonicum · Posted: Fri Oct 12, 2012 12:01 pm Post subject:

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

Ingo · Joined: 10 Oct 2012 Posts: 10

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.

LitusSaxonicum · Posted: Fri Oct 12, 2012 5:39 pm Post subject:

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

Ingo · Joined: 10 Oct 2012 Posts: 10

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

LitusSaxonicum · Posted: Mon Oct 15, 2012 11:13 am Post subject:

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

E

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

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:

Ingo · Joined: 10 Oct 2012 Posts: 10

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.

mecej4 · Joined: 31 Oct 2006 Posts: 1899

Ingo · Joined: 10 Oct 2012 Posts: 10

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