Re: c = inverse(sqrt(epsilon nought *mu nought))

On May 18, 7:09 am, e p chandler <e...@xxxxxxxx> wrote:
On May 17, 8:39 pm, Wade Ward <zaxf...@xxxxxxxxx> wrote:





On May 15, 6:53 pm, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:

Wade Ward <zaxf...@xxxxxxxxx> wrote:
x = 0.0_dp
...
I added the above, but not without compiler complaint with respect to
*where* the statements go. When I put them before:
position(RI,RJ,RK)=....
, it creates the following error:
: error 381 - POSITION is not an array.
When I place it right after that block, it compiles fine. What gives?

Well, the compiler is right. Position isn't an array. It is intended to
be a statement function, as the comment above it notes.

Statement functions have loist of quirks, which is why many people,
myself included, don't recommend using them in new code. I won't even
try to list all the quirks. It would take way too long (and I'd miss a
bunch of them unless I spent a few hours checking first).

Statement functions are syntactically very easy to confuse with
assignment statements. One result of that is that the compiler can get
confused also. If you have something that isn't a valid statement
function, you can get an error message from the compiler trying to
interpret it as an assignment. That's what happened here. The compiler
guessed that this might be intended as an assignment to an element of an
array named position, but there is no such array declared, so you get an
error message.

It isn't a valid statement function when you put the x=0.0_dp before it
because x=0.0_dp is an executable statement. Statement functions must be
in the specification part - i.e. before any executable statements.

What puzzles me is why you even have x in this code. It seems to have
nothing to do with the rest of the code; nothing ever references it.
Since it doesn't have anything to do with the rest of the code, it is a
bit hard to suggest sensibly what to do with it.

Statement functions? That's a new one. I'll have a look at MR&C.

x was set to the LHS of statement that involved U0 and E0. Since it
was buried in 6k of stuff that I didn't know how to trim out, it's
understandable that a person would miss the statement, which was:
x = (E0*U0)**(-.5)
EO was 10**-7 * 4pi and UO was 10**-9/36 pi . In the product, the
pi's cancel leaving the inverse square root of (10**-16 * 1/9). Both
are perfect squares, ergo
x= 1/(10**-8 * 1/3) which leaves x at 3 x 10**8. The speed of light
is as much of a constant as a person can imagine.
--
Wade Ward

Perhaps it might help to look at the text where these examples may
have originated. Based on the exercise numbers of two programs cited
and chapter titles (finite difference and method of moments) along
with Appendix D (it covers solution of simultaneous equations), I
suspect these may have come from "Numerical Techniques in
Electromagnetics", Matthew N. O. Sadiku, 2000, CRC Press, ISBN
0849313953. [Thanks to Google book search.]

This still leaves un-resolved this program's problems with out-of-
bounds references to arrays. In addition, there is quite a bit of
archaic code.

In the end, I believe that you need some knowledge of the problem
domain to get a handle on this program. (Sorry, not my field at
all. :-))

-- elliot- Hide quoted text -

- Show quoted text -

program elliot6
PARAMETER( PIE=3.141592654)
integer, parameter :: dp = kind(1.0d0)
!contains real function position
! Define scatterer dimensions
PARAMETER( OI=19.5, OJ=20.0, OK=19.0, RADIUS=15.0)
real(kind=dp) :: x
! Statement function to compute position w.r.t. center of the sphere
position(RI,RJ,RK)=SQRT((RI-OI)**2+(RJ-OJ)**2+(RK-OK)**2)
! another statement function
asf(arg1) = SQRT(arg1-OI)**2
E0=(1E-9)/(36*PIE)
U0=(1E-7)*4*PIE
C =(E0*U0)**(-.5)
x = 0.0_dp
x = (E0*U0)**(-.5)
write (*,*) x, C, E0, U0
i = 4
j = 5
k = 6
IF(position(float(I)+0.5,float(J),float(K)).LE.20) then
write (*,*) "tja"
else
write (*,*) "hja"
endif
!$$$$$$ IF( asf(float(I)).GE.20) then
!$$$$$$ write (*,*) "tja"
!$$$$$$ else
!$$$$$$ write (*,*) "hja"
!$$$$$$ endif
end program elliot6
I intend to post this using the google portal and intend it as a
response to Richard Maine and Mike Metcalf as well. Google doesn't
let a person see a tree of messages that one sees in a newsbrowser, so
it's harder to tailor responses and keep track of subthreads.

I found the option in silverfrost to "Integrate with SDBG," yet don't
find a difference in the debugger as I experience it. I have a
variable list but no idea what type of function position or asf is. I
can't step into them. So I'm a little stuck guessing how to replace
them with an explicit function.

I tried to make a one-dimensional analog of position with asf. What I
have compiles but causes my computer to beep on execution instead of
giving the other branch of the if-then-else control. The variables
that serve as the arguments for the statement function remain
undefined for the duration of the program, that is, RI,RJ,RK and
arg1. Should I expect otherwise?

I've always lobbied for the existence of C-style comments in fortran,
but found that my IDE had a way to comment out (and in) highlighted
blocks, as seen in the final if statement. Very handy stuff. Right
next to those buttons are ones that will decrease (increase) the
spacing for an entire block.

With MM posting a value for c at tens of thousands of meters per
second less than 3 x 10**8, this forces either
C =(E0*U0)**(-.5) to be an approximation or
E0=(1E-9)/(36*PIE)
U0=(1E-7)*4*PIE are approximations. While I took undergrad
electromagnetics, we never calculated epsilon nought or mu nought.
These were constants in Maxwell's equations that no one argued about.
My guess is that to solve for them, you would need to make a contrived
choice of parameters and gaussian surfaces that isolates them during
the integration. The formula for the inverse of the square root of
their product equalling the speed of light I got from a book I was
reading a few years back by Bryan Green. It may have been _The
Elegant Universe_. Since the formula was in the footnotes, which was
reserved for more technical treatment, I have to think it was right.
This inclines me to the view that the transmittivity and permittivity
in free space are off. I've got a guess here though. In the fourth
of Maxwell's equation there was a term that Dr. Clerk Maxwell added to
make the theory robust. I think this term was ignored when E0 and U0
were calculated. As I recall, it involved the product of E0 and U0
and would have been orders of magnitude smaller, so ignoring it for
the sake of getting a quick and dirty result is understandable.

Anyways, I'll see if a library in Western Michigan has the book you
mention.
--
Wade Ward

.

Quantcast