what is wrong with this code?can someone walk me through this?

madhu0319@gmail.com wrote:
> On Mar 26, 8:19 pm, ka...@troutmask.apl.washington.edu (Steven G.
> Kargl) wrote: 
>
> Sorry, I did not really understand what u said. I do have an
> executable file for this code that works, but i dont know how to post
> it here..What do I do abt this program, is it fixable at all?

One of the things that confuses people is that your code is hard to
read with the extra spaces on many lines and the bad line breaks.
This is a cut and paste problem with your mail program.  The lines 
would be much easier to read and understand if you reformatted
them to look like 

It's possible that you are using the TAB character to space things
out to column 7 and that when you paste it into your post, things
tab out 20 or so spaces.

Dick Hendrickson

"e p chandler" <epc8@juno.com> wrote in message
news:a77a612e-3d24-4f29-bd25-1c328ca01d1b@d62g2000hsf.googlegroups.com...
On Mar 26, 10:08 pm, madhu0...@gmail.com wrote:
> i did not use any diagnostic program. i dont even know anything abt
> it. i dont know anything abt fortran or coding..this is my project at
> school thats due in 20days..cani run this code on any compiler, i mean
> is it compatible with any? shud it return the same values on any
> compiler?
>
> pls bear with my silly questions, i am very stressed out abt this..

You CAN get your program to compile if you

1. remove leading spaces on each line
2. change

EXTERNAL FX, FY, DERIV_FX, DERIV_FY

to

EXTERNAL FX, FY

3. compile as free format source

DERIV_FX  and DERIV_FY are variables NOT functions passed as arguments
to routines so there is no need to make them EXTERNAL.

Making the numerical changes suggested by others DOES not make any
difference in the output except for trailing digits for the value of
Stokes.

When I compiled and ran the program it printed:

*** Parameters read from file particle.par
***
The Stokes is equal to:
0.0006589939662307433
n_t= 1. y= 0.000023255106965997813
n_t= 0.995 y= 0.000023138831431167825
n_t= 0.990025 y= 0.000023023137274011985
n_t= 0.985074875 y= 0.000022908021587641927
n_t= 0.9801495006250001 y= 0.000022793481479703716
n_t= 0.9752487531218751 y= 0.0000226795140723052
n_t= 0.9703725093562657 y= 0.000022566116501943672
n_t= 0.9655206468094844 y= 0.000022453285919433955
n_t= 0.960693043575437 y= 0.000022341019489836785

Note that your value of Stokes is NOT between 0.1 and 2.0 as desired.
Maybe better input data will help. Maybe better values for other
constants will help.
--->How do you know a priori what Stokes would be?

--
C. Gordon Liddy

"Virile, vigorous, potent"

"Steven G. Kargl" <kargl@troutmask.apl.washington.edu> wrote in message
news:fsesmg$8a6$1@gnus01.u.washington.edu...
> In article
> <2536c6bf-4017-43c3-aa00-5d9eb8dd305e@u72g2000hsf.googlegroups.com>,
> madhu0319@gmail.com writes: 
> .... 
>
> The problems in this code are too numerous to expend
> the effort until you actual post code that has a just
> to compile with any compiler.
You probably want that sentence back for a tune-up.

I swear I've seen the same content and coding style before, so I don't think
that the supplicant is the author.

A question for OP: what does stokes represent?  What are you doing for the
next eighteen days?
--

"I am waiting for them to prove that God is really American."

~~  Lawrence Ferlinghetti

On Mar 28, 12:34 pm, "Gerry Ford" <ge...@nowhere.ford> wrote:
> "Steven G. Kargl" <ka...@troutmask.apl.washington.edu> wrote in messagenew
s:fsesmg$8a6$1@gnus01.u.washington.edu...
> 
> 
> 
>
> You probably want that sentence back for a tune-up.
>
> I swear I've seen the same content and coding style before, so I don't thi
nk
> that the supplicant is the author.
>
> A question for OP: what does stokes represent?  What are you doing for the
> next eighteen days?
> --
>
> "I am waiting for them to prove that God is really American."
>
> ~~  Lawrence Ferlinghetti

I am not the original author and I am just trying to improve upon
someone's else code so that it works for stokes number between 0.1 and
2.0.

I am currently working full time as well as trying to finish school
simultaneously. I am trying my best to recompile the code taking into
consideration all the suggestions given by all of you and am trying to
figure how to proceed ahead (without much success) to make the program
work for stokes number between 0.1 and 2.0 within the next few days.

Stokes number is calculated using the formula (just giving a very
basic info for now)

Stokes = (2.0*RP)**2*RHO*UF/(6*PI*Nu*2.0*RF)

It varies according to the values of the input given.

On Mar 29, 12:03 am, madhu0...@gmail.com wrote:
> On Mar 28, 12:34 pm, "Gerry Ford" <ge...@nowhere.ford> wrote:
>
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> I am not the original author and I am just trying to improve upon
> someone's else code so that it works for stokes number between 0.1 and
> 2.0.
>
> I am currently working full time as well as trying to finish school
> simultaneously. I am trying my best to recompile the code taking into
> consideration all the suggestions given by all of you and am trying to
> figure how to proceed ahead (without much success) to make the program
> work for stokes number between 0.1 and 2.0 within the next few days.
>
> Stokes number is calculated using the formula (just giving a very
> basic info for now)
>
> Stokes = (2.0*RP)**2*RHO*UF/(6*PI*Nu*2.0*RF)
>
> It varies according to the values of the input given.

Stokes number is defined in the program. The actual definition for
stokes is, it is ratio of the stopping distance of a particle to a
characteristic dimension of the obstacle.

In basic terms, its a way of measuring how good the program is..say
for example instead of saying that the code doesnt work for a certain
particle radius, we say it doesnt work for this particular stokes
number and we do this by putting the radius in the formula for stokes
number, calculate the stokes number (given the radius) and say that it
is not working (the program) for this particular stokes number..its
like a standard..in viscous flows

In program terms, i should be getting output of stokes between 0.1 and
2.0 for certain values of input but unfortunately i am not getting
that, am trying to figure out why. [Baffled]

"e p chandler" <epc8@juno.com> wrote in message
news:a77a612e-3d24-4f29-bd25-1c328ca01d1b@d62g2000hsf.googlegroups.com...
On Mar 26, 10:08 pm, madhu0...@gmail.com wrote:
> i did not use any diagnostic program. i dont even know anything abt
> it. i dont know anything abt fortran or coding..this is my project at
> school thats due in 20days..cani run this code on any compiler, i mean
> is it compatible with any? shud it return the same values on any
> compiler?
>
> pls bear with my silly questions, i am very stressed out abt this..

You CAN get your program to compile if you

1. remove leading spaces on each line
2. change

EXTERNAL FX, FY, DERIV_FX, DERIV_FY

to

EXTERNAL FX, FY

3. compile as free format source

DERIV_FX  and DERIV_FY are variables NOT functions passed as arguments
to routines so there is no need to make them EXTERNAL.

Making the numerical changes suggested by others DOES not make any
difference in the output except for trailing digits for the value of
Stokes.

When I compiled and ran the program it printed:

*** Parameters read from file particle.par
***
The Stokes is equal to:
0.0006589939662307433
n_t= 1. y= 0.000023255106965997813
n_t= 0.995 y= 0.000023138831431167825
n_t= 0.990025 y= 0.000023023137274011985
n_t= 0.985074875 y= 0.000022908021587641927
n_t= 0.9801495006250001 y= 0.000022793481479703716
n_t= 0.9752487531218751 y= 0.0000226795140723052
n_t= 0.9703725093562657 y= 0.000022566116501943672
n_t= 0.9655206468094844 y= 0.000022453285919433955
n_t= 0.960693043575437 y= 0.000022341019489836785

Note that your value of Stokes is NOT between 0.1 and 2.0 as desired.
Maybe better input data will help. Maybe better values for other
constants will help.

Check the program listing against your formulas and equations. Verify
that your program is correctly transcribed.
Insert WRITE statements in the program to display the value of
variables as the program runs. Compare these to manual calculations.

What are reasonable ranges for the input variables? Try combinations
of LOW, MID and HIGH values for the input variables and see what you
get.

At this point there is no substitute for pouring over your program
listing and output with paper, pencil and a calculator.

With MINOR changes the program DOES compile. You don't have obvious
errors involving mismatched arguments to subroutines or common blocks
that do not match. You may have other

programming errors
logical errors
bad numerical behavior.

Other than the "Non-Fortran" flavor of your program, there is nothing
obviously wrong that jumps out except

goto 5
followed by
STOP. :-).

Good luck.

-- e

So, from the various suggestions given by others in this post, you should be
able to compile and run your program. You can then get answers but don't
know if they are correct or where the problem may be if there is one.
Your problem description seems well defined with parameters and differential
equations. These equations seem to require numerical solutions. It may be
more efficient to take one step back from FORTRAN and program the problem in
a computer algebra system such as MathCAD, Matlab, etc.
This approach has several advantages. You can be better assured that the
numerical results will reflect only your input and not a coding error If the
results look strange, you can more easily focus your attention. You can play
around with the problem statement changing input and checking output. You
will be free of possible errors in your differentiation and integration
procedures. You will also be able to output intermediate results which you
can then compare to your FORTRAN code. Finally, some CAS programs have
graphical tools that are simple to implement and can be very valuable, for
example showing where functions become discontinuous. In the end, you will
have a program that you know works (or not) and can then (re)program in
FORTRAN. These CAS programs are easy to use but are expensive. Universities
probably can provide free access.

Dick Hendrickson wrote:
>
> This is a potentially worse problem.  The expression (4.0/3.0)
> will be computed as approximately  1.333333 and then converted to
> double precision and become approximately 1.3333330000000.

Unless you're running a reality altering arithmetic of the Clinton
variety it's going to be something like (precision conversion noise),

1.33333337306976

with the odds of your speculative outcome coming up at about 1 in 10^7,
and more likely - never.

<madhu0319@gmail.com> wrote in message
news:e44cdbe4-96ca-47ef-8c2a-edd5388a3e96@d21g2000prf.googlegroups.com...
> On Mar 29, 12:03 am, madhu0...@gmail.com wrote:
 
>
> Stokes number is defined in the program. The actual definition for
> stokes is, it is ratio of the stopping distance of a particle to a
> characteristic dimension of the obstacle.
>
> In basic terms, its a way of measuring how good the program is..say
> for example instead of saying that the code doesnt work for a certain
> particle radius, we say it doesnt work for this particular stokes
> number and we do this by putting the radius in the formula for stokes
> number, calculate the stokes number (given the radius) and say that it
> is not working (the program) for this particular stokes number..its
> like a standard..in viscous flows
>
> In program terms, i should be getting output of stokes between 0.1 and
> 2.0 for certain values of input but unfortunately i am not getting
> that, am trying to figure out why. [Baffled]

You seem to know what you're looking for.  At this point, you simply need to
DO the things that Elliot has written.  Once you get something that
compiles, post it, along with any comments your compiler makes when it's
doing its thing.  You've said before that your source compiles.  Having an
executable and compiling from source aren't necessairly the same things.
You could have gotten the executable from the same place you got the source.

To my thinking, the next step would be going after all the losses of
precision by having a dp parameter:
INTEGER ,PARAMETER :: dp = kind(1d0)
Then you can make all your *8 declarations portable, and, also important,
you can convert whoppers like
(4.0/3.0) into (4.0_dp/3.0_dp)

You've gotten plenty of good advice from Dick and Elliot.  They need to see
evidence that they're getting through to you, and that you're making the
changes they suggest.  No one can touch your keyboard but you.

--

"I am waiting for them to prove that God is really American."

~~  Lawrence Ferlinghetti

pixel wrote:

> Dick Hendrickson wrote:
 

> Unless you're running a reality altering arithmetic of the Clinton
> variety it's going to be something like (precision conversion noise),

> 		1.33333337306976

> with the odds of your speculative outcome coming up at about 1 in 10^7,
> and more likely - never.

I don't know if there are Fortran compilers for IBM z/Architecture
machines with decimal floating point yet, but when there are the
probability will be much higher than 1D-7.

-- glen

glen herrmannsfeldt wrote:

> pixel wrote:
> 
>
> 
>
> 
>
> 
>
> 
>
>
> I don't know if there are Fortran compilers for IBM z/Architecture
> machines with decimal floating point yet, but when there are the
> probability will be much higher than 1D-7.

I'm not sure either.  We run Z/OS and Z/VM and the same old VS Fortran
77 compiler (functionally at least) is in use.

>
> -- glen
>


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford