Prev: Reference to derived type element by index?
Next: LAPACK string orchestra
From: e p chandler on 29 Mar 2008 22:31
On Mar 28, 3:09 pm, madhu0...(a)gmail.com wrote:
> On Mar 29, 12:03 am, madhu0...(a)gmail.com wrote:
>
>
>
>
>
> > On Mar 28, 12:34 pm, "Gerry Ford" <ge...(a)nowhere.ford> wrote:
>
> > > "Steven G. Kargl" <ka...(a)troutmask.apl.washington.edu> wrote in messagenews:fsesmg$8a6$1(a)gnus01.u.washington.edu...
>
> > > > In article
> > > > <2536c6bf-4017-43c3-aa00-5d9eb8dd3...(a)u72g2000hsf.googlegroups.com>,
> > > > madhu0...(a)gmail.com writes:
> > > >> Heres a fortran code to solve
> > > > ....
> > > >> source code:
>
> > > >> IMPLICIT NONE
> > > >>                                 REAL*8 DERIV_FX,
> > > >> DERIV_FY,N,RP,RF,RHO,UF,alpha,K,R0,U
> > > >>                                 REAL*8
> > > >> Nu,x,y,y0,THETA,DT,T0,UT0,PI,T,THETA0,Stokes
> > > >>                                 REAL*8
> > > >> UR0,b,x1,VX,VY,R,UT_K,UR_K,THETA2,MP,R2,x_i
> > > >>                                 INTEGER t_max, time
> > > >>                                 REAL*8 n_t
> > > >>                                 EXTERNAL FX, FY, DERIV_FX, DERIV_FY
> > > >>                                 COMMON Nu, RP, RF, MP, UF, alpha, K,
> > > >> PI, Stokes, x_i
> > > >>                                 CALL read_parameters (t_max, alpha,
> > > >> RHO, RP, RF, UF)
> > > >>                                 PI = 3.1415
> > > >>                                 Nu = 0.0000181
>
> > > > 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
>
> > 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]- Hide quoted text -
>
> - Show quoted text -

Looking at your program listing, I think I've found the "smoking gun".
Your very long expressions for UT0, UR0, UT_K, UR_K, UT_K and UR_K
again look similar, but have different structures. You've used
parentheses where you don't need them and the rest of your parentheses
get confusing.

Long ago I was taught this trick for figuring out precedence in a
complicated expression with many levels of parentheses.

For each statement

1. start a counter at 0
2. for each left parenthesis add 1 to the counter
3. for each right parenthesis subtract 1 from the counter

Things at the same level are part of the same expression.

Notice that in your code the levels are not consistent between
statements. Often programs have parallel structure. Even though you
may interchange variables and multiply by different constants, the
general form tends to be similar but not so in your program.

Confusing the reader with un-needed REAL exponents and NOT using
SQRT() where it should apply makes this possible problem LESS obvious.

I hope this helps.

--- e


From: Craig Powers on 31 Mar 2008 18:58
madhu0319(a)gmail.com wrote:
>
> 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]

My approach for dealing with problems like this is to do a parallel
calculation using pencil and paper. This allows me to break the problem
down into subsets with known answers. You can modify the program to
display the results of intermediate calculations, and compare with your
p&p results; you may find that simply performing the reduction
identifies the problem for you, otherwise you will likely be able to
localize it in a small piece of the calculation where it's fairly easy
to see what's wrong.
From: e p chandler on 1 Apr 2008 00:28
On Mar 31, 6:58 pm, Craig Powers <eni...(a)hal-pc.org> wrote:
> madhu0...(a)gmail.com wrote:
>
> > 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]
>
> My approach for dealing with problems like this is to do a parallel
> calculation using pencil and paper.  This allows me to break the problem
> down into subsets with known answers.  You can modify the program to
> display the results of intermediate calculations, and compare with your
> p&p results; you may find that simply performing the reduction
> identifies the problem for you, otherwise you will likely be able to
> localize it in a small piece of the calculation where it's fairly easy
> to see what's wrong.

One last try at beating this dead horse. :-(.

[to the OP]

A.

1. Is

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

the correct formula?

Not that some obvious algebraic simplification has NOT been done
particularly in the denominator.

Should the 2.0 be an exponent or remain as a factor?

2. Are the units correct?

3. Second above advice to check this formula by hand.

B. One possible reason that the particle does not go anywhere is
fairly obvious. The time step is small = 1E-9. Maybe a larger time
step would help. But more bothersome is that the GOTO 5 statement is
executed at all, and in particular for most values of n_t at time step
2.

1. Instrumenting the program with stategic WRITE statements might
help.

C. So far NO ONE has commented on the OP's use of REAL*8 to specify
DOUBLE PRECISION. I guess that the lack of comment indicates that this
usage is the least of the OP's problems here. :-<<<.

-- e [far past bedtime for me...]






From: Gerry Ford on 1 Apr 2008 02:22

"e p chandler" <epc8(a)juno.com> wrote in message
news:7b2a9762-1136-432d-99ca-74d9a04cbd3e(a)z38g2000hsc.googlegroups.com...
On Mar 31, 6:58 pm, Craig Powers <eni...(a)hal-pc.org> wrote:
> madhu0...(a)gmail.com wrote:
>
> > 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]
>
> My approach for dealing with problems like this is to do a parallel
> calculation using pencil and paper. This allows me to break the problem
> down into subsets with known answers. You can modify the program to
> display the results of intermediate calculations, and compare with your
> p&p results; you may find that simply performing the reduction
> identifies the problem for you, otherwise you will likely be able to
> localize it in a small piece of the calculation where it's fairly easy
> to see what's wrong.

One last try at beating this dead horse. :-(.

[to the OP]

A.

1. Is

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

the correct formula?

Not that some obvious algebraic simplification has NOT been done
particularly in the denominator.

Should the 2.0 be an exponent or remain as a factor?

2. Are the units correct?

3. Second above advice to check this formula by hand.

B. One possible reason that the particle does not go anywhere is
fairly obvious. The time step is small = 1E-9. Maybe a larger time
step would help. But more bothersome is that the GOTO 5 statement is
executed at all, and in particular for most values of n_t at time step
2.

1. Instrumenting the program with stategic WRITE statements might
help.

C. So far NO ONE has commented on the OP's use of REAL*8 to specify
DOUBLE PRECISION. I guess that the lack of comment indicates that this
usage is the least of the OP's problems here. :-<<<.

---> OP is lazy. Fortran can't help him.

I was hoping that we would get to discuss diff eq's rendered in fortran.

Can you bring up this topic again in a month?
--

"That this social order with its pauperism, famines, prisons, gallows,
armies, and wars is necessary to society; that still greater disaster
would ensue if this organization were destroyed; all this is said only
by those who profit by this organization, while those who suffer from it
- and they are ten times as numerous - think and say quite the contrary."

~~ Leo Tolstoy








From: Richard Maine on 1 Apr 2008 01:29
e p chandler <epc8(a)juno.com> wrote:

> C. So far NO ONE has commented on the OP's use of REAL*8 to specify
> DOUBLE PRECISION. I guess that the lack of comment indicates that this
> usage is the least of the OP's problems here. :-<<<.

Yeah. Though it is non-standard, it is pretty far down on the list of
things I'd comment about. After first worrying about getting the right
answers, I'd probably comment on some things that actually are standard
conforming, but shouldn't be done anyway...such as pretty much all of
the exponentiations in the forms used; someone already mentioned the
**(-1.0/2.0), but I don't recall if anyone also mentioned things like
**3.0.

But it seemed to me that the OP mostly needed much more fundamental help
along the lines some people have been suggesting (print out intermediate
results and hand-check them).

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
 |  Next  |  Last
Pages: 1 2
Prev: Reference to derived type element by index?
Next: LAPACK string orchestra