Anisotropy in the gravity force, and Mercury.

This post, along with the pretty pictures, is stored at
http://members.optusnet.com.au/maxkeon/peri.html
------------------

Mercury's perihelion advance in a zero origin universe.

In the zero origin universe, the entire dimension surrounding
every bit of matter in the universe is shifting inward into its
own gravity well at the rate of (GM/r^2) (times two) meters in
each second and is updated at the speed of light. Meaning that
its acceleration capability diminishes to zero for anything
moving at light speed toward its center of mass. As a consequence,
the gravity force on matter moving toward a gravity source will
be decreased, and will be increased for outward moving matter.

The equation representing the anisotropy is v/c(GM/r^2).

The force of gravity is determined by GM/r^2. The altered
gravity force generated by the anisotropy is equivalent to a
variation in the mass of the Sun, and that can be determined
by Ma = (GM/r^2 + an) * r^2 / G . 'an' is the anisotropy.

The velocity required to hold anything in a sustainable
concentric orbit for the normal Sun mass is determined by
(GM/r)^.5, and that becomes (G*Ma/r)^.5 for the updated Sun mass.
So, for an anisotropy of e.g. 8e-7 m/sec^2 and a radius of 5.8e10
meters, v for each is 47838.2691995 and 47838.7541644
respectively. That's a mass increase ratio of 1.000010138 to 1.

If the normal gravity rate is 3.94569e-02 m/sec^2, adding the
anisotropy to that = 3.94577e-2, then taking the square root of
that result and dividing it by the square root of the normal rate
gives a 1.000010138 to 1 ratio. The reason why it's the same
as the previous ratio should be fairly obvious.

The velocity change from the normal is essential in determining
Mercury's true fall rate due to the anisotropy, and since the
latter method is by far the more convenient, that's the one I've
chosen to use.

The next step is to determine Mercury's fall rate now that it's
traveling too slowly to maintain a stable orbit. Mercury would
fall zero distance to the Sun under the influence of normal
gravity while orbiting at 47838.27 m/sec. The minute added force
is going to change that only _very_ slightly, as is clearly
shown in this graph.

http://members.optusnet.com.au/maxkeon/falrate.jpg

When Mercury arrives at the 180 degree mark from the point of
last perihelion orientation in the Sun's inertial frame, it
arrives 1.19e-3 meters short of the true aphelion radius, and it
will continue to rise until it reaches that radius.

http://members.optusnet.com.au/maxkeon/arc7.jpg

12907 meters is the straight line travel distance from where
Mercury resides at the 180 degree mark, where the aphelion was
to be. The distance to the aphelion radius would be considerably
more than is shown because Mercury's trajectory can't point
directly at the aphelion and then abruptly change course when it
reaches its target. Its rise will slow as it nears the peak.

Mercury's position at the 360 degree mark is 1.058e-3 meters
beyond the perihelion radius. The distance from that point to the
tangent point of the perihelion radius is 9866 meters. That too
is a little short of the true perihelion advance because Mercury
is not falling directly to that point.

12907 + 9866 = 22773 meter perihelion advance per orbit. The
observed shift is 27118 meters. That shortfall can certainly be
accommodated.

The only other apparent contribution of any significance seems
to be the advance caused by Mercury being held at a lesser radius
for a longer time than normal on the rise to the aphelion radius,
and at a greater radius for a longer time than normal on the fall
back. The contribution is fairly insignificant though, only 110
meters per orbit.

This analogy should demonstrate my point.
If the pull of gravity is reduced at aphelion, so that Mercury
is held in a concentric orbit around the Sun, the aphelion will
continue to advance at the current orbit velocity until the pull
of gravity is increased. That will be the updated aphelion. If
the pull of gravity is increased at perihelion so that Mercury
is held in a concentric orbit around the Sun the perihelion will
continue to advance at the current orbit velocity until the pull
of gravity is reduced.

The same will apply proportionally for even the slightest
anomaly in the pull of gravity, anywhere at all during the orbit
cycle.

This is part 1 of the program that generated the numbers I've
been quoting. It can be extended to cover the entire orbit, but
that's not really valid because the anisotropy reduces to zero
when radial motion ceases at turnaround and everything is back
to normal, so Mercury must rise to the aphelion radius before it
begins the return journey.

-------------------

'Mercury's aphelion advance in 1 second steps

DEFDBL A-Z
CLS
c = 299792458#
G = .0000000000667#
M = 1.99D+30
ra = 46000000000#
rb = 70000000000#
r = 55240000000#
pi = 3.1416#
v = (G * M / r) ^ .5#
br = r

aa: aa = SIN(f * pi / 180#)
a = COS(f * pi / 180#)
ovel = a * 10000# + v
b = 58000000000# - a * 12000000000# 'actual radius.
IF f 0 THEN ba = bb - b
bb = b
bc = bc + ba 'must equal -2.4e10 meters at the end.
rvel = -ba

an = rvel / c * (-G * M / b ^ 2#)

grava = G * M / b ^ 2#
gravb = grava + an 'an is negative.
ratio = gravb ^ .5 / grava ^ .5
ovelb = ovel * ratio

fall = (ovelb - ovel) ^ 2 / ovelb ^ 2 * an

ana = ana + fall
anb = anb + ana
anc = anc + ana * ovel

f = f + .00004735#

fa = fa + 1
IF fa = 21120 THEN fa = 0: GOSUB ab
IF f 180 THEN GOSUB ab: END

GOTO aa

ab: PRINT "Ctrl_Break halts the program at any time."
PRINT
PRINT INT(f); "degrees."
PRINT ovel; "m/sec orbit velocity."
PRINT rvel; "m/sec radial velocity."
PRINT b; "meter orbit radius."
PRINT an; "true anisotropy."
PRINT fall; "m/sec^2 actual radius change rate."
PRINT anb; "meter total radius change so far."
'PRINT bc; "meter (radial velocity test. 2.4e10 at end)."
PRINT anc; "meter aphelion advance per velocity."
PRINT
RETURN

----------------------
PAnd part 2 (they are two individual programs). /P
----------------------

'Mercury's perihelion advance in 1 second steps

DEFDBL A-Z
CLS
c = 299792458#
G = .0000000000667#
M = 1.99D+30
ra = 46000000000#
rb = 70000000000#
r = 55240000000#
pi = 3.1416#
v = (G * M / r) ^ .5#
br = r

f = 180

aa: aa = SIN(f * pi / 180#)
a = COS(f * pi / 180#)
ovel = a * 10000# + v
b = 58000000000# - a * 12000000000# 'actual radius.
IF f 180 THEN ba = bb - b
bb = b
bc = bc + ba 'must equal 2.4e10 meters at the end.
rvel = -ba

an = rvel / c * (-G * M / b ^ 2#)

grava = G * M / b ^ 2#
gravb = grava + an 'an is positive.
IF f 180 THEN ratio = gravb ^ .5 / grava ^ .5
ovelb = ovel * ratio

IF f 180 THEN fall = (ovelb - ovel) ^ 2 / ovelb ^ 2 * an

IF f 180 THEN ana = ana + fall
anb = anb + ana
anc = anc + ana * ovel

f = f + .00004735#

fa = fa + 1
IF fa = 21120 THEN fa = 0: GOSUB ab
IF f 360 THEN GOSUB ab: END

GOTO aa

ab: PRINT "Ctrl_Break halts the program at any time."
PRINT
PRINT INT(f); "degrees."
PRINT ovel; "m/sec orbit velocity."
PRINT rvel; "m/sec radial velocity."
PRINT b; "meter orbit radius."
PRINT an; "true anisotropy."
PRINT fall; "m/sec^2 actual radius change rate."
PRINT anb; "meter total radius change so far."
'PRINT bc; "meter (radial velocity test. 2.4e10 at end)."
PRINT anc; "meter perihelion advance per velocity."
PRINT
RETURN

------------------------

These are the final results from each program.

0 to 180 degrees.
39018.79377747644 m/sec orbit velocity.
-.06585693359375 m/sec radial velocity.
69999999999.70139 meter orbit radius.
5.950639390486846D-12 true anisotropy.
7.179020689981973D-32 m/sec^2 actual radius change rate.
-1.190269684003358D-03 meter total radius change so far.
-52.05059130021925 meter aphelion advance per velocity.

180 to 360 degrees.
59018.79377619071 m/sec orbit velocity.
.1387176513671875 m/sec radial velocity.
46000000001.24426 meter orbit radius.
-2.90251365219588D-11 true anisotropy.
-1.553589704780447D-30 m/sec^2 actual radius change rate.
1.057712343670121D-03 meter total radius change so far.
58.14226684403394 meter perihelion advance per velocity.

Even though the velocity related advance generated by the first
program carries a negative sign the advance is still positive.
The above analogy should explain why.

Note that the total change to the orbit radii per orbit is
2.25e-3 meters. At that rate, Mercury would fall to the Sun by
only 4 million kilometers in a billion years. But if it was to
do so, it would mean that the process is not elastic, and there
could be no perihelion advance.

http://members.optusnet.com.au/maxkeon/the1-1a.html is the home
of the zero origin concept.

-----

Max Keon

On May 15, 8:18 pm, "Max Keon" wrote:

[...]

All Newtonian forms of gravitation are wrong. Your theory is DOA.

"Max Keon" wrote in message
u...
This post, along with the pretty pictures, is stored at
http://members.optusnet.com.au/maxkeon/peri.html


This post repeats a previous thread where it was pointed
out that Max's ides on the consequences of his theory were
incorrect. He posted a Basic program with major errors in
almost all of the code. I include a corrected version below.
My apologies for the repetition but Max seems incapable of
sticking to one thread.

------------------

Mercury's perihelion advance in a zero origin universe.

In the zero origin universe, the entire dimension surrounding
every bit of matter in the universe is shifting inward into its
own gravity well at the rate of (GM/r^2) (times two) meters in
each second and is updated at the speed of light. Meaning that
its acceleration capability diminishes to zero for anything
moving at light speed toward its center of mass. As a consequence,
the gravity force on matter moving toward a gravity source will
be decreased, and will be increased for outward moving matter.

The equation representing the anisotropy is v/c(GM/r^2).

The force of gravity is determined by GM/r^2. ...

OK, so far. I will snip Max's text since the above equations
are all we need together with Max's previous statements that
the anisotropy increases the Newton gravitational acceleration
when moving away from the Sun and decreases it when approaching.

This is part 1 of the program that generated the numbers I've
been quoting. It can be extended to cover the entire orbit, but
that's not really valid because the anisotropy reduces to zero
when radial motion ceases at turnaround and everything is back
to normal, so Mercury must rise to the aphelion radius before it
begins the return journey.

Modelling the other half _is_ necessary because that is where
Max gets the sign wrong. The following program correctly
simulates the effect. Enter a 'magnification' of about 400
to increase the size of the effect to an easily visible
level.

Max, I have separated the anisotropy and added some screen
updates showing which leg and the effect of the anisotropy.
This program gives a qualitatively correct indication but
a better integration rule would improve the accuracy. It
wouldn't change the conclusion. The effect is to rapidly
change an elliptical orbit to circular without any advance
of the perihelion.

George



DIM c AS DOUBLE, GM AS DOUBLE
DIM time AS DOUBLE, dt AS DOUBLE
DIM x AS DOUBLE, y AS DOUBLE
DIM px AS DOUBLE, py AS DOUBLE
DIM scale AS DOUBLE, xoffset AS DOUBLE, yoffset AS DOUBLE
DIM vx AS DOUBLE, vy AS DOUBLE, vr AS DOUBLE
DIM ax AS DOUBLE, ay AS DOUBLE
DIM r2 AS DOUBLE, radius AS DOUBLE, lastradius AS DOUBLE
DIM Newton AS DOUBLE, acceleration AS DOUBLE, anisotropy AS DOUBLE
DIM magnify AS DOUBLE, simlength AS DOUBLE
DIM update AS INTEGER

SCREEN 12
CLS

REM Constants - all values are in SI units. Note
REM that the GM product is negative as the Newtonian
REM force pulls the body towards the Sun.

c = 299792458#
GM = -1.327D+20

REM Simulation time step and maximum duration.

dt = 50
simlength = 200000000

REM Screen scaling factors.

scale = 2E-09
xoffset = 320
yoffset = 300

PSET (xoffset, yoffset)

REM Initial values correspond to aphelion.

x = 70000000000#
y = 0
vx = 0
vy = 39000

time = 0
lastradius = x

REM Allow a user-selectable magnification of the effect
REM to reduce run time.

PRINT "The value of magnification is:"
PRINT " 0 for no anisotropy"
PRINT " 1 for the theoretical anisotropy"
PRINT " 1 for an exagerated level"
INPUT "Enter magnification: "; magnify

LOCATE 7, 1, 0
PRINT "Radial vel."
LOCATE 8, 1, 0
PRINT "Newton * 10^3"
LOCATE 9, 1, 0
PRINT "Anisotropy * 10^9"
update = 0

timestep:

REM Find the square of the radius then the radius.

r2 = x * x + y * y
radius = SQR(r2)

REM Find the Newtonian acceleration.

Newton = GM / r2

REM The anisotropy depends on the radial speed which is
REM the rate of change of radius or change divided by
REM delta time.

vr = (radius - lastradius) / dt
lastradius = radius

REM Modify acceleration for the effect of anisotropy.

anisotropy = Newton * (vr / c)
acceleration = Newton + magnify * anisotropy

REM Display the current values

IF update 1000 THEN
LOCATE 7, 20, 0
PRINT USING "######.###"; vr;
IF vr 0 THEN
PRINT ; " Outward leg"
ELSE
PRINT ; " Inward leg "
END IF

LOCATE 8, 20, 0
PRINT USING "######.###"; Newton * 1000!

LOCATE 9, 20, 0
PRINT USING "######.###"; anisotropy * 1E+09;
IF anisotropy 0 THEN
PRINT ; " Decreases Newtonian gravity"
ELSE
PRINT ; " Increases Newtonian gravity"
END IF

update = 0
ELSE
update = update + 1
END IF

REM Find the acceleration components.

ax = acceleration * (x / radius)
ay = acceleration * (y / radius)

REM Now step the time forward by a delta. Euler's
REM method is crude but understandable and sufficient
REM to illustrate the effects of Keon's theory.

x = x + dt * vx
y = y + dt * vy

vx = vx + dt * ax
vy = vy + dt * ay

time = time + dt

REM Convert location to screen coordinates.

px = xoffset + x * scale
py = yoffset - y * scale

PSET (px, py)

REM Check for completion - compare against the duration for
REM the desired number of orbits and some simple limits.

IF radius 10000000000# THEN END
IF radius 180000000000# THEN END

IF time simlength GOTO timestep

END

"George Dishman" wrote in message
...
"Max Keon" wrote in message
u...
This post, along with the pretty pictures, is stored at
http://members.optusnet.com.au/maxkeon/peri.html

This post repeats a previous thread where it was pointed
out that Max's ides on the consequences of his theory were
incorrect. He posted a Basic program with major errors in
almost all of the code.

My most significant error in the past has been in not realizing
how minute the effect of the anisotropy would be. By all means,
point out the errors in my latest program. My only agenda is
truth afterall.

I include a corrected version below.
My apologies for the repetition but Max seems incapable of
sticking to one thread.

It was pointless replying to your final post because you were
just repeating the same old claim over and over again. You have
not once been able to explain how energy can be transferred from
the Sun-Mercury gravity link, yet you insist that it's inelastic.

------------------

Mercury's perihelion advance in a zero origin universe.

In the zero origin universe, the entire dimension surrounding
every bit of matter in the universe is shifting inward into its
own gravity well at the rate of (GM/r^2) (times two) meters in
each second and is updated at the speed of light. Meaning that
its acceleration capability diminishes to zero for anything
moving at light speed toward its center of mass. As a consequence,
the gravity force on matter moving toward a gravity source will
be decreased, and will be increased for outward moving matter.

The equation representing the anisotropy is v/c(GM/r^2).

The force of gravity is determined by GM/r^2. ...

OK, so far. I will snip Max's text since the above equations
are all we need together with Max's previous statements that
the anisotropy increases the Newton gravitational acceleration
when moving away from the Sun and decreases it when approaching.

This is part 1 of the program that generated the numbers I've
been quoting. It can be extended to cover the entire orbit, but
that's not really valid because the anisotropy reduces to zero
when radial motion ceases at turnaround and everything is back
to normal, so Mercury must rise to the aphelion radius before it
begins the return journey.

Modelling the other half _is_ necessary because that is where
Max gets the sign wrong. The following program correctly
simulates the effect. Enter a 'magnification' of about 400
to increase the size of the effect to an easily visible
level.

These are the final figures generated by the first of the two
programs I posted, when I change the cutoff point to 360 degrees
instead of 180. There has been no midpoint sign manipulation of
course.

0 - 360 degrees.
59018.79377623228 m/sec orbit velocity.
.1358261108398437 m/sec radial velocity.
46000000001.19438 meter orbit radius.
-2.842011360144941D-11 true anisotropy.
-1.458448304362808D-30 m/sec^2 actual radius change rate.
-2.380621747268387D-03 meter total radius change so far.
-104.105889461453 meter ??helion advance per velocity.

First of all, the negative sign on the "advance per velocity"
obviously can't mean that the advance is negative. But have a
good look at the "total radius change so far". How will that
affect the rapid decline in orbit eccentricity that your program
suggests?

Max, I have separated the anisotropy and added some screen
updates showing which leg and the effect of the anisotropy.
This program gives a qualitatively correct indication but
a better integration rule would improve the accuracy. It
wouldn't change the conclusion. The effect is to rapidly
change an elliptical orbit to circular without any advance
of the perihelion.

I have a few grumbles about your program.
Firstly, your x and y seem to be in the wrong planes according
to the screen printout which I've included as a test of the final
x,y result at the end of the first cycle. It shouldn't make any
difference over the complete cycle though.
Next, I don't understand why you magnified the gravity and
anisotropy rates for the on screen printout?
Then there's your choice of r2 as a variable, in a place where
r^2 is commonly found. Is that common practice?

And finally; When using Qbasic as a communication tool, it's best
to remove unecessary clutter.

I've made some inconsequential changes to your program because
I've integrated my program into it, which has been modified so
that Mercury falls by 100% of the anisotropy, which is what you
seem to be attempting to use in the graphics. But because you've
chosen close to 50000 second duration chunks of the orbit for
each step, you've sidestepped an enormous amount of the
acceleration. The fall distance at the end of the cycle according
to my program is a whopping 11232907 meters, which is nothing
like your result. Nor is it in any way correct. The real fall
rate per orbit cycle is 2.38e-3 meters
http://members.optusnet.com.au/maxkeon/falrate.jpg so Mercury's
orbit ellipse would take billions of years to become circular as
well. And even then, only if anisotropic gravity is inelastic.

-----

Max Keon

----------------
For obvious reasons I've removed the "" from each line of your
program.


DEFDBL A-Z
'These constants relate to stage 2 of the program (mine).
'c = 299792458#
G = .0000000000667#
M = 1.99D+30
ra = 46000000000#
rb = 70000000000#

r = 55240000000#
'5.524e10 is the focal point for an orbit eccentricity of .385
'7e10 - 4.6e10 = 2.4e10 : 2.4e10 * .385 + 4.6e10 = 5.524e10

pi = 3.1416#
v = (G * M / r) ^ .5#
br = r
'-----------------

DIM update AS INTEGER

SCREEN 12
CLS

REM Constants - all values are in SI units. Note
REM that the GM product is negative as the Newtonian
REM force pulls the body towards the Sun.

c = 299792458#
GM = -1.327D+20

REM Simulation time step and maximum duration.

dt = 50#
simlength = 200000000#

REM Screen scaling factors.

scale = .000000002#
xoffset = 320#
yoffset = 300#

PSET (xoffset, yoffset)

REM Initial values correspond to aphelion.

x = 70000000000#
y = 0#
vx = 0#
vy = 39000#

time = 0#
lastradius = x

magnify = 1

LOCATE 7, 1, 0
PRINT "Radial vel."
LOCATE 8, 1, 0
PRINT "Newton"
LOCATE 9, 1, 0
PRINT "Anisotropy"
update = 0#

timestep:
IF update = 1000 THEN GOTO compare
step2:

REM Find the square of the radius then the radius.

r2 = x * x + y * y
radius = SQR(r2)

REM Find the Newtonian acceleration.

Newton = GM / r2

REM The anisotropy depends on the radial speed which is
REM the rate of change of radius or change divided by
REM delta time.

vr = (radius - lastradius) / dt
lastradius = radius

REM Modify acceleration for the effect of anisotropy.

anisotropy = Newton * (vr / c)
acceleration = Newton + magnify * anisotropy

REM Display the current values

IF update 1000 THEN
LOCATE 7, 20, 0
PRINT USING "######.###"; vr;
IF vr 0 THEN
PRINT ; " Outward leg"
ELSE
PRINT ; " Inward leg "
END IF

LOCATE 8, 20, 0
PRINT USING "##.######"; Newton;

LOCATE 9, 20, 0
PRINT USING "##.#########"; anisotropy;
IF anisotropy 0 THEN
PRINT ; " Decreases Newtonian gravity"
ELSE
PRINT ; " Increases Newtonian gravity"
END IF

update = 0#
ELSE
update = update + 1#
END IF

REM Find the acceleration components.

ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
'---------------------------------------
bx = bx + ax
by = by + ay
LOCATE 1, 1: PRINT bx; "total fall in the x plane "
PRINT by; "total fall in the y plane. "
'---------------------------------------
REM Now step the time forward by a delta. Euler's
REM method is crude but understandable and sufficient
REM to illustrate the effects of Keon's theory.

x = x + dt * vx
y = y + dt * vy

vx = vx + dt * ax
vy = vy + dt * ay

time = time + dt

REM Convert location to screen coordinates.

px = xoffset + x * scale
py = yoffset - y * scale

PSET (px, py)

REM Check for completion - compare against the duration for
REM the desired number of orbits and some simple limits.

IF radius 10000000000# THEN END
IF radius 180000000000# THEN END

IF time simlength GOTO timestep

END

'----------------------------

compa

aa: a = -COS(f * pi / 180#)
ovel = a * 10000# + v

b = 58000000000# - a * 12000000000# 'actual radius.
'If a = 1 then b = 4.6e10: If a = -1 then b = 7e10.

IF f 0 THEN ba = bb - b
bb = b
rvel = -ba
an = rvel / c * (-G * M / b ^ 2#)

'grava = G * M / b ^ 2#
'gravb = grava + an 'an is negative.
'ratio = gravb ^ .5 / grava ^ .5
'ovelb = ovel * ratio
'fall = (ovelb - ovel) ^ 2 / ovelb ^ 2 * an

fall = an
'The fall rate is now 100% of the anisotropy.

ana = ana + fall
anb = anb + ana
'anc = anc + ana * ovel

f = f + .00004735#
IF f 360 THEN END
fa = fa + 1

IF fa = 50000 THEN fa = 0: GOSUB ab: GOTO step2
'The 50000 one second steps align the two programs.

GOTO aa

ab: LOCATE 14, 1
PRINT "Ctrl_Break halts the program at any time."
PRINT
PRINT INT(f); "degrees."
PRINT ovel; "m/sec orbit velocity."
PRINT rvel; "m/sec radial velocity."
PRINT b; "radius."
PRINT an; "true anisotropy."
PRINT fall; "m/sec^2 actual radius change rate."
PRINT anb; "meter total radius change so far."
'PRINT anc; "meter aphelion advance per velocity."
PRINT
RETURN

In article ,
"Max Keon" wrote:


My most significant error in the past has been in not realizing
how minute the effect of the anisotropy would be. By all means,
point out the errors in my latest program. My only agenda is
truth afterall.


1)

You quote various parameters to a significant number of digits, but how
confident are you that the programming language you are using is able to
maintain such accuracy?

--
COOSN-174-07-82116: Official Science Team mascot and alt.astronomy's favourite
poster (from a survey taken of the saucerhead high command).

Sacred keeper of the Hollow Sphere, and the space within the Coffee Boy
singularity.

In article ,
"Max Keon" wrote:

And finally; When using Qbasic as a communication tool, it's best
to remove unecessary clutter.

QBasic? Are you aware of the accuracy limits of QBasic?

--
COOSN-174-07-82116: Official Science Team mascot and alt.astronomy's favourite
poster (from a survey taken of the saucerhead high command).

Sacred keeper of the Hollow Sphere, and the space within the Coffee Boy
singularity.

"Max Keon" wrote in message
...

"George Dishman" wrote in message
...
"Max Keon" wrote in message
u...
This post, along with the pretty pictures, is stored at
http://members.optusnet.com.au/maxkeon/peri.html

This post repeats a previous thread where it was pointed
out that Max's ides on the consequences of his theory were
incorrect. He posted a Basic program with major errors in
almost all of the code.

My most significant error in the past has been in not realizing
how minute the effect of the anisotropy would be. By all means,
point out the errors in my latest program. My only agenda is
truth afterall.

Mine too, we should be able to work together towards
that common goal.

I include a corrected version below.
My apologies for the repetition but Max seems incapable of
sticking to one thread.

It was pointless replying to your final post because you were
just repeating the same old claim over and over again. You have
not once been able to explain how energy can be transferred from
the Sun-Mercury gravity link, yet you insist that it's inelastic.

The equation you post is inelastic. To be elastic,
ythe force must depend only on the radius so when
you include velocity it is no longer elastic.
Whether you can explain the mechanism behind that
is not my concern.

------------------

Mercury's perihelion advance in a zero origin universe.

In the zero origin universe, the entire dimension surrounding
every bit of matter in the universe is shifting inward into its
own gravity well at the rate of (GM/r^2) (times two) meters in
each second and is updated at the speed of light. Meaning that
its acceleration capability diminishes to zero for anything
moving at light speed toward its center of mass. As a consequence,
the gravity force on matter moving toward a gravity source will
be decreased, and will be increased for outward moving matter.

The equation representing the anisotropy is v/c(GM/r^2).

The force of gravity is determined by GM/r^2. ...

OK, so far. I will snip Max's text since the above equations
are all we need together with Max's previous statements that
the anisotropy increases the Newton gravitational acceleration
when moving away from the Sun and decreases it when approaching.

This is part 1 of the program that generated the numbers I've
been quoting. It can be extended to cover the entire orbit, but
that's not really valid because the anisotropy reduces to zero
when radial motion ceases at turnaround and everything is back
to normal, so Mercury must rise to the aphelion radius before it
begins the return journey.

Modelling the other half _is_ necessary because that is where
Max gets the sign wrong. The following program correctly
simulates the effect. Enter a 'magnification' of about 400
to increase the size of the effect to an easily visible
level.

These are the final figures generated by the first of the two
programs I posted, when I change the cutoff point to 360 degrees
instead of 180. There has been no midpoint sign manipulation of
course.

In my program I added a display of the key values
of the Newtonian force, the radial velocity and
the anisotropy. The Newtonian force is always
negative of course since it always acts towards
the Sun. The radial velocity should be negative
when moving towards the Sun and positive when
moving away. You can see that "Inward" or "Outward"
is shown depending on the radial velocity, "vr" and
you can check the sign is right.

Similarly, you said the anisotropy decreases gravity
on the inward leg so it should be positive during the
first half of the orbit and go to zero at perihelion.
After that Mercury moves outwards like Pioneer so the
anisotropy should be negative, it increases the effect
of the Newtonian force which is also negative. Again
the anisotropy is displayed and you can see the sign
changes as expected.

I'll snip your numbers and comment later.

Max, I have separated the anisotropy and added some screen
updates showing which leg and the effect of the anisotropy.
This program gives a qualitatively correct indication but
a better integration rule would improve the accuracy. It
wouldn't change the conclusion. The effect is to rapidly
change an elliptical orbit to circular without any advance
of the perihelion.

I have a few grumbles about your program.
Firstly, your x and y seem to be in the wrong planes according
to the screen printout which I've included as a test of the final
x,y result at the end of the first cycle. It shouldn't make any
difference over the complete cycle though.

I don't understand that. x and y are just the usual
screen coordinates and I started with Mercury at
aphelion on the right hand side. The motion is anti-
clockwise as it would be seen from above the Sun's
north pole. The xy plane is that of the orbit.

Next, I don't understand why you magnified the gravity and
anisotropy rates for the on screen printout?

Simply so that I could use the "USING" command
to get a fixed point layout rather than using
scientific notation. It is harder to read when it
changes rapidly on the screen. It makes no
difference to the simulation.

The "magnify" value of course only applies to the
anisotropy and has the effect of exagerating the
effects on the screen. You can set it to 1 but
then you need many orbits to see a change and the
integrator needs to be much better or the errors
will swamp the effect.

Then there's your choice of r2 as a variable, in a place where
r^2 is commonly found. Is that common practice?

I didn't think I could use the circumflex character
in a variable name. The value is the radius squared
as you would expect.

And finally; When using Qbasic as a communication tool, it's best
to remove unecessary clutter.

I'm not sure what you consider unnecessary, all the
comments were there to explain the meaning of the
variables and in my professional work would be
considered the minimum you could get away with.

I've made some inconsequential changes to your program because
I've integrated my program into it, which has been modified so
that Mercury falls by 100% of the anisotropy, which is what you
seem to be attempting to use in the graphics. But because you've
chosen close to 50000 second duration chunks of the orbit for
each step, you've sidestepped an enormous amount of the
acceleration.

Two points there - first the delta time is "dt"
which was set to 50 seconds and you can reduce
that value if you like. The 'update' value means
the screen is only updated every 1000 points but
each point is calculated. Changing the number
will not alter the path but it makes the program
run faster since writing to the screen is slow,
that's all.

Second, if you look at where I do the integration
you will see it says

vx = vx + dt * ax

so ax is multiplied by dt. Larger time steps produce
proportionally larger changes of velocity and only
the accuracy suffers.

If you like, just set dt=1 and you get one second
steps. Again the program will run slower but the
results won't significantly change.

For the distance, you could replace

x = x + dt * vx

with

x = x + (dt * vx) + 0.5 * (dt * dt * ax)

to include Newton's "1/2 a t^2" term but really a much
better integrator is needed. I kept it at its simplest
so that you could see the principle: in each timestep
of duration dt, the x speed changes by ax*dt and the
x location changes by vx*dt.

The fall distance at the end of the cycle according
to my program is a whopping 11232907 meters, which is nothing
like your result. Nor is it in any way correct. The real fall
rate per orbit cycle is 2.38e-3 meters

There is something seriously wrong here and I notice
in your attempts to modify my program you have:

bx = bx + ax

The variable ax is the acceleration so your bx
becomes the integrated acceleration but without
the 'dt' factor so it is the X velocity divided
by the timestep. You have labelled it

"total fall in the x plane "

which should be a distance, not a speed.

Now you have to bear in mind that the planet
'falls' from aphelion to perihelion because it
is in an elliptical orbit. You need to decide
if you mean the actual fall or the _difference_
from the normal elliptical orbit which isn't
presently calculated. Note that the reduction
of the eccentricity causes the perihelion to
increase while the aphelion decreases.

It is easy enough to add a printout of the radius
as well, or you could capture the minimum and
maximum radius on each orbit and show that or best
of all calculate the eccentricity from that then
you can see how it is affected.

http://members.optusnet.com.au/maxkeon/falrate.jpg so Mercury's
orbit ellipse would take billions of years to become circular as
well. And even then, only if anisotropic gravity is inelastic.

The point was to show the principle of integrating
the acceleration to predict the orbit which you
seem to now understand. There is a lot that could
be done to improve it.

For obvious reasons I've removed the "" from each line of your
program.

Sure. I'll snip the unaffected parts:

....
REM Find the acceleration components.

ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
'---------------------------------------
bx = bx + ax
by = by + ay
LOCATE 1, 1: PRINT bx; "total fall in the x plane "
PRINT by; "total fall in the y plane. "
'---------------------------------------
REM Now step the time forward by a delta. Euler's
REM method is crude but understandable and sufficient
REM to illustrate the effects of Keon's theory.

x = x + dt * vx
y = y + dt * vy

vx = vx + dt * ax
vy = vy + dt * ay

time = time + dt
....
'----------------------------

compa

aa: a = -COS(f * pi / 180#)

What is "f", I don't see it declared or initialised
anywhere. I might guess it was something like mean
anomaly.

ovel = a * 10000# + v

You have no comment explaining "ovel" or "v" or why "a"
is being multiplied by 10000.

[Later you say it is the orbital velocity but that
needs to be integrated as it is affected by the
anisotropy - the above lines don't work]

b = 58000000000# - a * 12000000000# 'actual radius.
'If a = 1 then b = 4.6e10: If a = -1 then b = 7e10.

OK, "b" is the radius for some value of "f"

IF f 0 THEN ba = bb - b
bb = b
rvel = -ba

Your "rvel" is the change in radius but you have not
taken the size of the timestep into account. My code
for that is:

vr = (radius - lastradius) / dt
lastradius = radius

an = rvel / c * (-G * M / b ^ 2#)

That's OK if the timestep is 1 second.

'grava = G * M / b ^ 2#

That is the same as my "Newton" and should be negative
at all times.

'gravb = grava + an 'an is negative.

"an" is the anisotropy and should be positive when
approaching the sun and negative on the outward leg.


So far Max, it's not too bad. From here on though
you lose it entirely:

'ratio = gravb ^ .5 / grava ^ .5
'ovelb = ovel * ratio
'fall = (ovelb - ovel) ^ 2 / ovelb ^ 2 * an

fall = an
'The fall rate is now 100% of the anisotropy.

ana = ana + fall
anb = anb + ana
'anc = anc + ana * ovel

None of the above makes any sense at all. The
velocity is not pointing towards the Sun so you
cannot use 1/2 a t^2 to calculate the distance
it falls if that is what you are trying. You
need to break the total acceleration into ax
and ay components and integrate them to get the
new values of the vx,vy velocity and the x,y
location coordinates.

f = f + .00004735#

The location doesn't move by equal angles in
equal times. You are tied to steps of 1 second
so you need to solve Kepler's Equation if you
want to do it that way, but really the need to
integrate the speeds to incorporate the anisotropy
means you can't take this shortcut.

IF f 360 THEN END
fa = fa + 1

IF fa = 50000 THEN fa = 0: GOSUB ab: GOTO step2
'The 50000 one second steps align the two programs.

To align them, you need use

IF fa dt then ...

You also need to enter "magnify" as 1 in my program
but the accuracy will be inadequate unless you improve
the integrator lines.

GOTO aa

ab: LOCATE 14, 1
PRINT "Ctrl_Break halts the program at any time."
PRINT
PRINT INT(f); "degrees."
PRINT ovel; "m/sec orbit velocity."
PRINT rvel; "m/sec radial velocity."
PRINT b; "radius."
PRINT an; "true anisotropy."
PRINT fall; "m/sec^2 actual radius change rate."
PRINT anb; "meter total radius change so far."
'PRINT anc; "meter aphelion advance per velocity."

Nothing in your program is capable of correctly finding
the perihelion. You could put in some code to capture the
value of "f" for the lowest value of "b" but you need to
correct the other major errors before this is of any use.

George

On May 20, 6:17 am, Phineas T Puddleduck
wrote:
In article ,
"Max Keon" wrote:



My most significant error in the past has been in not realizing
how minute the effect of the anisotropy would be. By all means,
point out the errors in my latest program. My only agenda is
truth afterall.

1)

You quote various parameters to a significant number of digits, but how
confident are you that the programming language you are using is able to
maintain such accuracy?

He doesn't even use the right values for physical constants.

I have repeatedly pointed out that he _does not_ have 15 digits of
precision, and he always ignores me. He has also ignored every time I
point out he also does not understand error analysis [this was back
when he was doing his idiot little 'smoke wheel' experiments].


--
COOSN-174-07-82116: Official Science Team mascot and alt.astronomy's favourite
poster (from a survey taken of the saucerhead high command).

Sacred keeper of the Hollow Sphere, and the space within the Coffee Boy
singularity.

In article . com,
Eric Gisse wrote:

On May 20, 6:17 am, Phineas T Puddleduck
wrote:
In article ,
"Max Keon" wrote:



My most significant error in the past has been in not realizing
how minute the effect of the anisotropy would be. By all means,
point out the errors in my latest program. My only agenda is
truth afterall.

1)

You quote various parameters to a significant number of digits, but how
confident are you that the programming language you are using is able to
maintain such accuracy?

He doesn't even use the right values for physical constants.

I have repeatedly pointed out that he _does not_ have 15 digits of
precision, and he always ignores me. He has also ignored every time I
point out he also does not understand error analysis [this was back
when he was doing his idiot little 'smoke wheel' experiments].


I'm amazed that someone can claim such results as he does with his stated
"accuracy" without the faintest idea of error analysis OR the errors inherent
in floating point storage.

QBasic FFS!

At least try something like IDL or Fortran. But using Qbasic for his
"revolution" in physics is akin to taking a hippo for a ride on a pushbike.

--
COOSN-174-07-82116: Official Science Team mascot and alt.astronomy's favourite
poster (from a survey taken of the saucerhead high command).

Sacred keeper of the Hollow Sphere, and the space within the Coffee Boy
singularity.

On May 20, 1:33 pm, Phineas T Puddleduck
wrote:
In article . com,
Eric Gisse wrote:



On May 20, 6:17 am, Phineas T Puddleduck
wrote:
In article ,
"Max Keon" wrote:

My most significant error in the past has been in not realizing
how minute the effect of the anisotropy would be. By all means,
point out the errors in my latest program. My only agenda is
truth afterall.

1)

You quote various parameters to a significant number of digits, but how
confident are you that the programming language you are using is able to
maintain such accuracy?

He doesn't even use the right values for physical constants.

I have repeatedly pointed out that he _does not_ have 15 digits of
precision, and he always ignores me. He has also ignored every time I
point out he also does not understand error analysis [this was back
when he was doing his idiot little 'smoke wheel' experiments].

I'm amazed that someone can claim such results as he does with his stated
"accuracy" without the faintest idea of error analysis OR the errors inherent
in floating point storage.

It continually amuses me to see him pretend he has 15 significant
figures of accuracy when he doesn't use the right value for c, or that
G is only good to 4 or 5 significant figures.


QBasic FFS!

At least try something like IDL or Fortran. But using Qbasic for his
"revolution" in physics is akin to taking a hippo for a ride on a pushbike.

Yea I never did "get" the choice of QBasic.


--
COOSN-174-07-82116: Official Science Team mascot and alt.astronomy's favourite
poster (from a survey taken of the saucerhead high command).

Sacred keeper of the Hollow Sphere, and the space within the Coffee Boy
singularity.