| Topic: |
Science > Physics |
| User: |
"Max Keon" |
| Date: |
15 May 2007 10:18:51 PM |
| Object: |
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
----------------------
<P>And 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
.
|
|
| User: "George Dishman" |
|
| Title: Re: Anisotropy in the gravity force, and Mercury. |
16 May 2007 03:49:03 PM |
|
|
"Max Keon" <maxkeon@optusnet.com.au> wrote in message
news:464a7825$0$15392$afc38c87@news.optusnet.com.au...
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
.
|
|
|
| User: "Max Keon" |
|
| Title: Re: Anisotropy in the gravity force, and Mercury. |
20 May 2007 08:00:26 AM |
|
|
"George Dishman" <george@briar.demon.co.uk> wrote in message
news:f2fqlj$uuu$1@news.freedom2surf.net...
"Max Keon" <maxkeon@optusnet.com.au> wrote in message
news:464a7825$0$15392$afc38c87@news.optusnet.com.au...
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
'----------------------------
compare:
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
.
|
|
|
| User: "George Dishman" |
|
| Title: Re: Anisotropy in the gravity force, and Mercury. |
20 May 2007 11:34:08 AM |
|
|
"Max Keon" <maxkeon@optusnet.com.au> wrote in message
news:46504677$0$2869$afc38c87@news.optusnet.com.au...
"George Dishman" <george@briar.demon.co.uk> wrote in message
news:f2fqlj$uuu$1@news.freedom2surf.net...
"Max Keon" <maxkeon@optusnet.com.au> wrote in message
news:464a7825$0$15392$afc38c87@news.optusnet.com.au...
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
....
'----------------------------
compare:
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
.
|
|
|
| User: "Max Keon" |
|
| Title: Re: Anisotropy in the gravity force, and Mercury. |
23 May 2007 08:19:17 AM |
|
|
"George Dishman" <george@briar.demon.co.uk> wrote in message
news:f2pt4n$haj$1@news.freedom2surf.net...
"Max Keon" <maxkeon@optusnet.com.au> wrote in message
news:46504677$0$2869$afc38c87@news.optusnet.com.au...
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.
But I altered that in your program so that the on screen printout
showed the correct values. It was necessary so that the two sets
of results could be directly compared. Didn't you notice that?
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.
Yes, it is what I would expect. But it would cause enormous
confusion to someone who didn't.
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 do agree with that. I can see that some components of
my program were lacking explanation. Thanks for the
wake up call.
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.
Therein lies a problem. The anisotropy is an acceleration force,
but you've treated it as a continuous force which is simply added
or subtracted from the orbit radius according to radial velocity.
That's the mistake I made in the past, mainly because it gave a
result which seemed to be more sensible. But I have since
realized the folly in that action and addressed the problem
properly. I now find that the orbit radius at aphelion has
shortened by only 1.19e-3 meters when it arrives at the 180
degree mark from last perihelion. About .4 seconds later Mercury
has risen to the aphelion radius.
The fall to perihelion is much the same, but reversed.
You have added the anisotropy to Newtonian gravity and then
assumed that Mercury will fall by 100% of the added acceleration.
But that's impossible. If Mercury was held in a stable concentric
orbit around the Sun, freefalling at the rate of .039 m/sec^2,
its orbit radius would not alter one bit. If it's freefalling at
that rate plus an anisotropy of e.g. 8e-7 m/sec^2, its fall to
the Sun will be .0390008 / .039 more than the zero fall. That's
1.0000205 to 1 times the value which caused zero orbit radius
change.
You can see what I mean can't you?
---
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.
No it doesn't George. Gravity, in any form is entirely elastic.
And even if it did as you say, the distance between aphelion and
perihelion would only change by 2.25e-3 meters per orbit. Or
9337500 meters per billion years.
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.
Maybe so, but it's not just me who should be doing the improving.
Your program is _very_ seriously flawed. The basic principles are
even wrong.
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
...
'----------------------------
You inadvertently snipped this part of my program from the start
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# 'v is constant at 49018.8 m/sec.
'v is the orbit velocity applicable to the radius to the Sun at
'the offset distance in Mercury's orbit. The true orbit velocity
'for the entire cycle is proportional to that radius.
The precision in the integration is exceptional.
br = r
---------------
compare:
aa: a = -COS(f * pi / 180#)
What is "f", I don't see it declared or initialised
anywhere.
The default is always zero.
I might guess it was something like mean
anomaly.
No, it's the start point at zero degrees from the current
perihelion.
ovel = a * 10000# + v
You have no comment explaining "ovel" or "v" or why "a"
is being multiplied by 10000.
"ovel" is of course orbit velocity.
If a = 1, a = 10000. If a = -1, a = -10000. Add those values to
v, and v becomes 59018.8 and 39018.8 which is near enough to the
maximum and minimum orbit velocities.
[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]
I'm well aware of that. The affect is totally inconsequential,
so I removed it from the program. This is how it read (without the
test option).
------
'Orbit velocity change due to anisotropy is too minute to calculate.
'Remove the ' switches on the next four lines and note the result.
'ova = (SQR(ovel ^ 2# + (fall / 2#) ^ 2#) - ovel) * 2#
'ovb = ovb + ova 'stores the total change.
'PRINT ova; " Press any key"
'DO: LOOP UNTIL INKEY$ <> ""
------
It's just a simple a^2 + b^2 = c^2 calculation to determine the
difference between the hypotenuse and adjacent lengths of the
triangle scribed by the anomalous fall over the distance traveled
in 1 second. The difference is the velocity change.
There's no point in including that part of the program because
it just spits out rubbish. It's far beyond the 16 digit capacity
of Qbasic. In fact it stretches the limits of the 32 digit
Windows calculator.
http://members.optusnet.com.au/maxkeon/peri.html has been updated
slightly, and better addresses that point with a diagram. There's
also an updated version of the program which includes a fairly
comprehensive description.
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
Your dt = 1 in my program. The anisotropy is an acceleration
force, so every second needs to be integrated to do it properly.
an = rvel / c * (-G * M / b ^ 2#)
That's OK if the timestep is 1 second.
That why 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.
ratio = gravb ^ .5 / grava ^ .5
is essential in determining the true fall rate resulting from the
inclusion of the anisotropy. The added fall rate enroute to the
aphelion radius, caused by the generated anisotropy, cannot
possibly cause Mercury to fall by 100% of the anisotropy.
The reasoning is thus:
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, M = 1.99e30 and Ma = 1.990040347826087e30 kg, v for each
is 47838.2691995 and 47838.7541644 respectively. The velocity
increase ratio is 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 at the updated address.
http://members.optusnet.com.au/maxkeon/peri.html
-------
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.
You do realize that it will all balance out at the end of the
completed orbit, don't you? The advance is determined by the
geometry of the orbit trajectory beyond the 180 degree mark from
last aphelion or perihelion encounter. You claim that the
equation is inelastic. Maybe so, but its consequences are very
much elastic.
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 ...
50000 one seconds steps in my program is equal to 1000 steps in
yours. Each program ran the required number of steps before
transferring control to the other.
-----
Max Keon
.
|
|
|
| User: "George Dishman" |
|
| Title: Re: Anisotropy in the gravity force, and Mercury. |
23 May 2007 05:11:06 PM |
|
|
"Max Keon" <maxkeon@optusnet.com.au> wrote in message
news:46543f64$0$19720$afc38c87@news.optusnet.com.au...
"George Dishman" <george@briar.demon.co.uk> wrote in message
news:f2pt4n$haj$1@news.freedom2surf.net...
"Max Keon" <maxkeon@optusnet.com.au> wrote in message
news:46504677$0$2869$afc38c87@news.optusnet.com.au...
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.
But I altered that in your program so that the on screen printout
showed the correct values. It was necessary so that the two sets
of results could be directly compared. Didn't you notice that?
Sorry Max but we seem to be talking past each other.
You asked me why I used a multiplier in my original
program and I explained why I did that. Your changes
weren't the subject of the question.
Having done some more testing tonight, I see your
point though. You need to replace the format part
with ######.#### to get adequate resolution. That
is 100 km in the radius or add another # for 10 km
but there's no point going beyond that as you'll see
later, the changes are much larger than that.
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.
Yes, it is what I would expect. But it would cause enormous
confusion to someone who didn't.
I thought the comment line preceding it and the fact
that it was calculated as x^2 + y^2 made it obvious:
REM Find the square of the radius then the radius.
r2 = x * x + y * y
radius = SQR(r2)
The equation for the radius further emphasises the
point but I accept your criticism, it could have been
more explicit.
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 do agree with that. I can see that some components of
my program were lacking explanation. Thanks for the
wake up call.
Me too apparently.
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.
Therein lies a problem. The anisotropy is an acceleration force,
but you've treated it as a continuous force which is simply added
or subtracted from the orbit radius according to radial velocity.
That sentence makes very little sense so I'l take it
bit by bit.
We are treating the anisotropy like the Newtonian
gravity as an acceleration, not a force. We are
not including the mass of Mercury in any of the
calculations because it would cancel out.
The accelerations are continuous (both Newtonian and
the anisotropy) in that they apply at all times and
change smoothly with time, they aren't quantised and
changing in discrete steps.
That means that any time, the acceleration adds an
amount to the velocity which is equalt to the product
of the time and the acceleration. It doesn't add or
subtract from the radius, I don't know where you got
that idea.
For example, if an acceleration of 2m/s^2 acts for
50s then the velocity will change by 100m/s. That
might be one of my steps. You would do the same as
50 steps of 1s each so in each second the speed
changes by 2m/s and after 50 additions of 2m/s each
you get the same total of 100m/s change.
The three lines that deal with that in my program
are:
vx = vx + dt * ax
vy = vy + dt * ay
time = time + dt
That's the mistake I made in the past, mainly because it gave a
result which seemed to be more sensible.
That approach is correct, the repeated additions are
what perfom the integration. Of course by necessity
it is in discrete steps but using a small enough value
of dt gets round that at the expense of a slightly
longer run time.
I used dt=50, you use dt=1 and you might get a more
accurate result using dt=0.1 but the inaccuracy of
QBasic will become a limitation and the run time is
horrible.
But I have since
realized the folly in that action and addressed the problem
properly. I now find that the orbit radius at aphelion has
shortened by only 1.19e-3 meters when it arrives at the 180
degree mark from last perihelion.
About .4 seconds later Mercury
has risen to the aphelion radius.
The fall to perihelion is much the same, but reversed.
You have added the anisotropy to Newtonian gravity and then
assumed that Mercury will fall by 100% of the added acceleration.
But that's impossible.
No! It isn't a "fall" max, it is the change of velocity.
Most of the velocity is tangential so the bulk of the
change is used in keeping the planet orbiting the Sun
instead of flying off into space.
If Mercury was held in a stable concentric
orbit around the Sun, freefalling at the rate of .039 m/sec^2,
its orbit radius would not alter one bit.
No, but it's x and y coordinates would be changing
very rapidly. I think you are missing the fact that
it is the x,y components that are being chnaged, not
the radius itself. Also you are forgetting it is an
elliptical orbit, not circular.
If it's freefalling at
that rate plus an anisotropy of e.g. 8e-7 m/sec^2, its fall to
the Sun will be .0390008 / .039 more than the zero fall. That's
1.0000205 to 1 times the value which caused zero orbit radius
change.
You can see what I mean can't you?
I get the rough gist but you cannot tackle the problem
that way because the dynamics of the orbit counteract
the anisotropy, you have to work through the details
because the anisotropy changes the direction of motion
as well as the speed.
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.
No it doesn't George. Gravity, in any form is entirely elastic.
Sorry Max, there is no point in continually repeating
that since your equation is INelastic. If you think
gravity should be elastic then there can be no
anisotropy.
And even if it did as you say, the distance between aphelion and
perihelion would only change by 2.25e-3 meters per orbit. Or
9337500 meters per billion years.
I've done a number of checks on the program tonight.
If you set the "magnification" to zero, you remove the
anisotropy and the aphelion should be a constant 70e9
for every orbit. Using a timestep of 10s it increases
by about 4.5km per orbit and with a step of 100s it is
about 45km so a 1s step will give an error around 450m.
I haven't done that yet as it would take too long but
that gives you an idea of the accuracy of the program.
Using a "magnify" value of 10, the aphelion falls by
847000 km for one orbit on the screen, equivalent to
100 actual orbits. With magnify set to 10, it is
87600 km per screen orbit and with magnify set to 1
the result is 8800 km.
I then checked the fall for different timesteps to
see how they affected the result and the answer is
that the program is insensitive to the step size.
The aphelion varies slightly as I said above but it
falls by 8800 km for all the step sizes I tested so
it looks as though that coding is working fine.
Overall, the fall of aphelion is roughly exponential
towards about 57E9 m with 65% of that ocurring in
around 1800 orbits but I would need to leave the
computer running for some hours to get an accurate
value.
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.
Maybe so, but it's not just me who should be doing the improving.
Your program is _very_ seriously flawed. The basic principles are
even wrong.
No, the principles are correct and they are what you need
to use. You keep making the mistake of thinking that the
acceleration tells you the fall when it fact it is the
change of velocity, not radius, and most of that is
tangential. There is nothing in your program to cope with
the _direction_ of the orbital velocity which is affected
by the anisotropy.
The accuracy is better than I expected for QBASIC especially
with a crude integrator and just about adequate if your are
careful with the magnification and timestep values.
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
...
'----------------------------
You inadvertently snipped this part of my program from the start
of your program.
It was just declarations, nothing contentious.
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# 'v is constant at 49018.8 m/sec.
'v is the orbit velocity applicable to the radius to the Sun at
'the offset distance in Mercury's orbit. The true orbit velocity
'for the entire cycle is proportional to that radius.
The precision in the integration is exceptional.
Pardon? There is no integration in your program.
You use these lines to find the velocity:
aa: a = -COS(f * pi / 180#)
ovel = a * 10000# + v
br = r
---------------
compare:
aa: a = -COS(f * pi / 180#)
What is "f", I don't see it declared or initialised
anywhere.
The default is always zero.
I might guess it was something like mean
anomaly.
No, it's the start point at zero degrees from the current
perihelion.
Yes but what angle does it represent?
ovel = a * 10000# + v
You have no comment explaining "ovel" or "v" or why "a"
is being multiplied by 10000.
"ovel" is of course orbit velocity.
Actually speed, you don't have any direction information.
If a = 1, a = 10000. If a = -1, a = -10000. Add those values to
v, and v becomes 59018.8 and 39018.8 which is near enough to the
maximum and minimum orbit velocities.
You have no idea what the velocities will be because
of the anisotropy, those are conventional values. You
need to integrate the acceleration to find ovel.
[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]
I'm well aware of that. The affect is totally inconsequential,
so I removed it from the program. This is how it read (without the
test option).
------
'Orbit velocity change due to anisotropy is too minute to calculate.
Hold on, the velocity change is not just due to the
anisotropy, you need to include the whole Newtonian
acceleration as well. No wonder it didn't work
'Remove the ' switches on the next four lines and note the result.
'ova = (SQR(ovel ^ 2# + (fall / 2#) ^ 2#) - ovel) * 2#
'ovb = ovb + ova 'stores the total change.
'PRINT ova; " Press any key"
'DO: LOOP UNTIL INKEY$ <> ""
------
It's just a simple a^2 + b^2 = c^2 calculation to determine the
difference between the hypotenuse and adjacent lengths of the
triangle scribed by the anomalous fall over the distance traveled
in 1 second. The difference is the velocity change.
There's no point in including that part of the program because
it just spits out rubbish.
I'm not surprised, the method is hopelessly wrong.
It's far beyond the 16 digit capacity
of Qbasic. In fact it stretches the limits of the 32 digit
Windows calculator.
Then look at how my program does it because the
accuracy of QBasic is quite adequate and it is the
crude simplification of the integrator that produces
most of the error.
http://members.optusnet.com.au/maxkeon/peri.html has been updated
slightly, and better addresses that point with a diagram. There's
also an updated version of the program which includes a fairly
comprehensive description.
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
Your dt = 1 in my program. The anisotropy is an acceleration
force, so every second needs to be integrated to do it properly.
As ong as you change the velocity by the acceleration
times the timestep and increase the simulation time by
the timestep each time, it doesn't need to be 1. The
smaller the better of course.
an = rvel / c * (-G * M / b ^ 2#)
That's OK if the timestep is 1 second.
That why 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.
ratio = gravb ^ .5 / grava ^ .5
is essential in determining the true fall rate resulting from the
inclusion of the anisotropy. The added fall rate enroute to the
aphelion radius, caused by the generated anisotropy, cannot
possibly cause Mercury to fall by 100% of the anisotropy.
The reasoning is thus:
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,
That reasoning is wrong because it screws up the
potential energy. Simply including the anisotropy
in addition to the Newtonian force works fine.
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.
You are assuming the orbit is stable but it isn't.
The anisotropy causes the eccentricity to decay
exponentially so you cannot use those equations.
I'll snip the next bit, the basis of your method
doesn't work.
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.
You do realize that it will all balance out at the end of the
completed orbit, don't you?
It doesn't. Just do it properly without trying to
take shortcuts and you'll get the right answer.
The advance is determined by the
geometry of the orbit trajectory beyond the 180 degree mark from
last aphelion or perihelion encounter. You claim that the
equation is inelastic. Maybe so, ...
It is. To be elastic, only the radius can appear in
the equation for the force. If you include anything
else, such as radial velocity, it is no longer elastic
and can act like a drag or friction under the right
circumstances.
but its consequences are very
much elastic.
Sorry, no the effect is to cause the eccentricity
to decay. You need to go back to integrating the
acceleration properly and then it will tell you the
correct results.
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 ...
50000 one seconds steps in my program is equal to 1000 steps in
yours. Each program ran the required number of steps before
transferring control to the other.
That's OK, but your method is not workable. Look through
my code again now that I have explained how the dt value
is taken into account and you should follow the technique.
That is what you need to use.
The bottom line is that I can get ~4.5km per orbit accuracy
with 1s steps and the aphelion falls about 8800 km per orbit
at first while the perihelion is rising at about 2000 km per
orbit.
I'll run the program longer some time when the machine isn't
in use and I'm at home (we are out for the next few nights).
George
.
|
|
|
| User: "Max Keon" |
|
| Title: Re: Anisotropy in the gravity force, and Mercury. |
27 May 2007 05:15:30 AM |
|
|
"George Dishman" <george@briar.demon.co.uk> wrote in message
news:f32dve$64k$1@news.freedom2surf.net...
"Max Keon" <maxkeon@optusnet.com.au> wrote in message
news:46543f64$0$19720$afc38c87@news.optusnet.com.au...
"George Dishman" <george@briar.demon.co.uk> wrote in message
news:f2pt4n$haj$1@news.freedom2surf.net...
"Max Keon" <maxkeon@optusnet.com.au> wrote in message
news:46504677$0$2869$afc38c87@news.optusnet.com.au...
---
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.
Therein lies a problem. The anisotropy is an acceleration force,
but you've treated it as a continuous force which is simply added
or subtracted from the orbit radius according to radial velocity.
That sentence makes very little sense so I'l take it
bit by bit.
We are treating the anisotropy like the Newtonian
gravity as an acceleration, not a force. We are
not including the mass of Mercury in any of the
calculations because it would cancel out.
The accelerations are continuous (both Newtonian and
the anisotropy) in that they apply at all times and
change smoothly with time, they aren't quantised and
changing in discrete steps.
That means that any time, the acceleration adds an
amount to the velocity which is equalt to the product
of the time and the acceleration. It doesn't add or
subtract from the radius, I don't know where you got
that idea.
For example, if an acceleration of 2m/s^2 acts for
50s then the velocity will change by 100m/s.
I'm inclined to think you actually believe that George, which is
a bit disconcerting.
I'll snip the rest and concentrate on this major error, which is
obviously the root of all of the confusion.
What you say is true for Mercury while in its stable eccentric
orbit around the Sun, so long as the anisotropy isn't included.
The acceleration variations throughout Mercury's orbit cycle are
not really changing anything. Mercury is not permanently shifting
from its stable orbit path, and orbit velocity doesn't vary from
what is an integral part of the stable orbit structure.
You are claiming that the anisotropy will cause Mercury's orbital
speed to automatically change the moment that it's applied, which
is impossible. For example, if the pull of gravity is doubled,
Mercury's orbital speed doesn't magically increase to comply with
the change. It's drawn closer to the Sun until it has gained the
required speed to hold it against the added pull. It must achieve
(more than) 67653 m/sec orbital speed before the fall to the Sun
is halted. It would need to undergo the equivalent of a direct
fall (zero orbital speed) at the updated gravity rate of .079
m/sec^2 for 250823 seconds and by that time it will have fallen
nearly 2.5 million kilometers.
The gravity force is acting _directly_ toward the Sun. Are you
suggesting that it's acting in other planes as well?
The true fall rate is determined by
fallrate = vc^2 / va^2 * acceleration rate
va is the updated orbital speed required for a stable orbit
while under the influence of the changed gravity conditions.
vb is the current speed.
vc is the speed difference.
<------------------- va -------------->
<---- vc --> <----------- vb --------->
l l l
47838^2 / 67653^2 * .079 = .0395 m/sec^2 fall rate.
The figures are all constantly changing throughout the fall of
course.
A fall rate can't be established until the value of va is known.
That can be determined by, e.g. the normal average gravity rate
for Mercury of .0395 m/sec^2 plus the anisotropy (e.g. 8e-7)
= .0395008, then taking the square root of that result and
dividing it by the square root of the normal rate (.0395).
Which gives a 1.000010138 to 1 ratio.
The logic behind that was derived from determining the difference
in sustainable orbit velocities between the normal Sun mass and
a Sun mass which accounts for the acceleration due to the
anisotropy. Your objections to my doing that are quite invalid.
Even if potential energy _appears_ to vary, so what?
The varied Sun mass is 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, M = 1.99e30 and Ma = 1.990040347826087e30 kg, v for each
is 47838.2691995 and 47838.7541644 respectively. The velocity
increase ratio is 1.000010138 to 1, which is identical to that
previously determined.
http://members.optusnet.com.au/maxkeon/falrate.jpg
That's how Mercury gains orbital speed through a change in the
gravity force. Not the way you think.
-----
Max Keon
.
|
|
|
| User: "George Dishman" |
|
| Title: Re: Anisotropy in the gravity force, and Mercury. |
27 May 2007 06:54:16 AM |
|
|
"Max Keon" <maxkeon@optusnet.com.au> wrote in message
news:46595a42$0$2869$afc38c87@news.optusnet.com.au...
"George Dishman" <george@briar.demon.co.uk> wrote in message
news:f32dve$64k$1@news.freedom2surf.net...
<much snipped as there is a major probleme here>
That means that any time, the acceleration adds an
amount to the velocity which is equal to the product
of the time and the acceleration. It doesn't add or
subtract from the radius, I don't know where you got
that idea.
For example, if an acceleration of 2m/s^2 acts for
50s then the velocity will change by 100m/s.
I'm inclined to think you actually believe that George, which is
a bit disconcerting.
I hadn't realised you had a problem with that. Of
course it is fundamental, the word acceleration
is defined as the rate of change of velocity and
is unarguable and the other equations you have
tried to use are all derived form this under
various conditions.
I'll snip the rest and concentrate on this major error, which is
obviously the root of all of the confusion.
What you say is true for Mercury while in its stable eccentric
orbit around the Sun, so long as the anisotropy isn't included.
What I said above is true for all objects changing
speed for any reason whatsoever under any circumstances.
If you weren't aware of that then obviously nothing
else I said will have made any sense to you so I can
see why the conversation has been so difficult.
The acceleration variations throughout Mercury's orbit cycle are
not really changing anything. Mercury is not permanently shifting
from its stable orbit path, and orbit velocity doesn't vary from
what is an integral part of the stable orbit structure.
Sorry Max, that isn't true. You said the anisotropy
causes an extra acceleration, it acts to displace
Mercury and since it is not directly along the path
but rather points towards the Sun, it changes the
direction as well as the speed.
You are claiming that the anisotropy will cause Mercury's orbital
speed to automatically change the moment that it's applied, which
is impossible.
It is what you have been telling me. "Acceleration" is
the rate at which speed changes and normally is given by
a = -GM / r^2
in Newtonian gravitation. You said that was changed to
a = -GM / r^2 * (1 + v/c)
where v is the radial component of the velocity. That is
what my program models and you have seen the consequences.
For example, if the pull of gravity is doubled,
Mercury's orbital speed doesn't magically increase to comply with
the change.
Right, but it's _acceleration_ changes immediately
and the speed is then the integral of that. The
speed at any instant is changing by the value of
the acceleration _at_that_time_.
It's drawn closer to the Sun until it has gained the
required speed to hold it against the added pull. It must achieve
(more than) 67653 m/sec orbital speed before the fall to the Sun
is halted. It would need to undergo the equivalent of a direct
fall (zero orbital speed) at the updated gravity rate of .079
m/sec^2 for 250823 seconds and by that time it will have fallen
nearly 2.5 million kilometers.
That is all an assumption about what you might find
after you integrate the acceleration to find out what
the path will be. I can tell you it is not what your
equation produces but more importantly you have
realise it is only a guess on your part, not a result
of a computation.
The gravity force is acting _directly_ toward the Sun. Are you
suggesting that it's acting in other planes as well?
Here is a crude drawing:
v
\ ^ vy
\|
vx <--M
/|
/ |
radius / | y
/ |
/ |
/ |
Sun ---->
x
Mercury is moving in the direction shown by velocity
v which can be broken into two components, vx and vy.
The acceleration points directly towards the Sun. The
values of x, y and radius in the program represent
the distances shown in the diagram. You find how much
of the acceleration acts in the x and y directions by
noting that they are in the same proportion as the x
and y distances are to the radius:
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
In one second then, the velocity in the x direction
changes by ax so in Basic we could write vx = vx + ax
but it is better practice to allow for different time
steps of duration dt so you get
x = x + dt * vx
y = y + dt * vy
In the same period, if the speed was constant, the
planet would move a distance in the x direction given
by
x = x + dt * vx
and similarly in the y direction
y = y + dt * vy
which is the simple version I posted in the hope that
you could follow what was happening. To be more
accurate, the acceleration changes the speed during
the time dt as shown above. We can take account of
that by using the average speed in the period which
Newton kindly provided as:
x = x + (dt * vx) + 0.5 * (dt * dt * ax)
or rearranging to lose make it a little quicker to
compute:
x = x + dt * (vx + 0.5 * dt * ax)
and similarly:
y = y + dt * (vy + 0.5 * dt * ay)
The true fall rate is determined by
fallrate = vc^2 / va^2 * acceleration rate
No it isn't. You could compute the fall rate directly
from vx and vy but I thought it might be easier for
you to follow if I to take the difference in radius
over the duration of the step. First you need to find
the radius which I did in two steps so I didn't have
to recalculate the square of the radius when finding
the GM/r^2 value:
r2 = x * x + y * y
That is just Pythagoras of course, then
radius = SQR(r2)
From that, the fall rate is given simply by:
vr = (radius - lastradius) / dt
lastradius = radius
va is the updated orbital speed required for a stable orbit
The orbit isn't stable.
while under the influence of the changed gravity conditions.
vb is the current speed.
vc is the speed difference.
<------------------- va -------------->
<---- vc --> <----------- vb --------->
l l l
47838^2 / 67653^2 * .079 = .0395 m/sec^2 fall rate.
Your diagram assumes the acceleration is directly
along the path but it isn't, it points at the Sun
which is close to perpendicular to the path (but
not quite).
The figures are all constantly changing throughout the fall of
course.
Of course, hence we need to use fairly small steps.
A duration of about 100 for dt is fast to calculate
and gives an accurate enough answer.
A fall rate can't be established until the value of va is known.
That can be determined by, e.g. the normal average gravity rate
for Mercury of .0395 m/sec^2 plus the anisotropy (e.g. 8e-7)
= .0395008, then taking the square root of that result and
dividing it by the square root of the normal rate (.0395).
Which gives a 1.000010138 to 1 ratio.
No, it doesn't work because you haven't taken
account of the direction.
The logic behind that was derived from determining the difference
in sustainable orbit velocities between the normal Sun mass and
a Sun mass which accounts for the acceleration due to the
anisotropy. Your objections to my doing that are quite invalid.
Now that you have explained where your ideas came
from, the objections are that the equation you are
using is for a stable _circular_ orbit and doesn't
work for an ellipse, the orbit isn't stable even as
an ellipse and your method doesn't take account of
the direction of the acceleration which is not
tangential to the orbit as you have assumed so there
are multiple problems with your ideas.
The method I have shown you above follows directly
from the definitions of velocity and acceleration
and is definitive. The equations you are trying to
use are _derived_ from the ones I used and yours
only apply in the absence of anisotropy.
Stick to the basic approach Max, your attempts at
shortcuts aren't going to work and in fact they
will be harder to code anyway.
Even if potential energy _appears_ to vary, so what?
My energy based approach was a shortcut, as was yours,
but mine worked because it could be modified to take into
account the effects of the anisotropy. However, I always
said it was an educated estimate of the result so don't
worry about that, the method I use in the program and
which I have explained to you here is the definitive
method.
The varied Sun mass is 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.
You don't know in advance if the orbit will be
stable, and in fact it isn't, so that approach
won't work.
So, for an anisotropy of e.g. 8e-7 m/sec^2 and a radius of 5.8e10
meters, M = 1.99e30 and Ma = 1.990040347826087e30 kg, v for each
is 47838.2691995 and 47838.7541644 respectively. The velocity
increase ratio is 1.000010138 to 1, which is identical to that
previously determined.
That's because you are still making the same mistake.
http://members.optusnet.com.au/maxkeon/falrate.jpg
That's how Mercury gains orbital speed through a change in the
gravity force. Not the way you think.
Velocity is the integral of acceleration by
definition. Putting all the bits above together,
including the improved distance formula, gives
you this:
r2 = x * x + y * y
radius = SQR(r2)
vr = (radius - lastradius) / dt
lastradius = radius
Newton = GM / r2 ' The constant GM is negative
anisotropy = Newton * (vr / c)
acceleration = Newton + anisotropy
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
vx = vx + dt * ax
vy = vy + dt * ay
x = x + dt * (vx + 0.5 * dt * ax)
y = y + dt * (vy + 0.5 * dt * ay)
time = time + dt
Note that the above is all pure maths with one
exception since the velocity follows from the
acceleration by simple integration and similarly
the location follows from the velocity. The one
exception is that the acceleration is given by
the Newtonian equation plus your anisotropy,
that is where the physics comes in. The only
change you can make if the direction of the
anisotropy is the same as the Newtonian force is
to alter these two lines:
anisotropy = Newton * (vr / c)
acceleration = Newton + anisotropy
As soon as you defined acceleration due to your
anisotropy as v/c times the Newtonian gravity
and in a direction acting to oppose it, everything
else followed with no room for argument. Mercury
will lose about 8820 km per orbit from its aphelion
and all that takes is a fraction of a degree of
change it the direction of its motion when
travelling at ~48 km/s.
George
.
|
|
|
|
| User: "Eric Gisse" |
|
| Title: Re: Anisotropy in the gravity force, and Mercury. |
27 May 2007 05:22:09 AM |
|
|
On May 27, 3:15 am, "Max Keon" <maxk...@optusnet.com.au> wrote:
"George Dishman" <geo...@briar.demon.co.uk> wrote in message
news:f32dve$64k$1@news.freedom2surf.net...> "Max Keon" <maxk...@optusnet.com.au> wrote in message
news:46543f64$0$19720$afc38c87@news.optusnet.com.au...
"George Dishman" <geo...@briar.demon.co.uk> wrote in message
news:f2pt4n$haj$1@news.freedom2surf.net...
"Max Keon" <maxk...@optus | | | | | | | |
