Anisotropy and Mercury (2)

On Jun 18, 12:02 am, Eric Gisse wrote:
On Jun 17, 8:01 pm, Koobee Wublee wrote:

This is not my derivation. This is the derivation you have posted
from the website below. shrug

Plug in the numbers.

You get 43" or so, not 21.5".

I was referring to the anomaly from speed only.

You are jumping on the same wagon of the ones who blame their
ignorance on vocabularies after been presented with the proper math.
shrug

I am in no way confused about how to obtain the equations of motion.

I was not referring to this point. However, since you brought it up,
I disagree with your statement above.

I'm just pointing out what you are saying is nonsense.

YOUR vocabulary is the faulty one - it is inconsistent with how the
entire physics community uses and describes things.

Not really! Calling spacetime, proper time, spaceTIME, or other fancy
words does not make it not spacetime. shrug

Wrong! Understand the model calling out for geodesics following the
maximum accumulated spacetime does not allow a conserved quantity in
energy. There is only one conserved quantity associated with angle
--- conservation of angular momentum. You are falling into the
matheMagical realm created by the ones who choose Einstein as the
Messiah of GR. shrug

There are two conserved quantities - angular momentum and energy [per
unit mass, depending if the path is timelike or null].

You get conservation of energy because \partial_t * g_tt = 0 and
conservation of angular momentum because \partial_\phi * g_\phi\phi =
0. Familiarize yourself with killing vectors, and don't whine about
Einstein because Einstein has nothing to do with the modern
formulation of general relativity.

I meant in a general case, but you are correct in this special case
the energy is conserved even according to the model of geodesics
following the path of maximum accumulated spacetime. The energy is
always conserved under the model of geodesics where the path follows
the minimum accumulated time.

But you cannot point out one that does not contradict itself. shrug

None of them do.

You are wrong again. They all do.

You cannot claim differently because you don't own
any textbooks on GR.

I don't have to own one to read a textbook. shrug

This is not about who can find the most popular references. shrug

Who said anything about popular?

You did.

I am yet to see you post even ONE
reference that I have not already given you.

I don't post crappy references. shrug

This is still about GR and SR themselves. shrug

On Jun 18, 10:02 am, Koobee Wublee wrote:
On Jun 18, 12:02 am, Eric Gisse wrote:

On Jun 17, 8:01 pm, Koobee Wublee wrote:
This is not my derivation. This is the derivation you have posted
from the website below. shrug

Plug in the numbers.

You get 43" or so, not 21.5".

I was referring to the anomaly from speed only.

There is no speed-based anomaly. The radial equation of motion in does
not depend on dr/dt.

[...]


I don't post crappy references. shrug

Then post a good one.

Where did you learn GR from? Where did you learn SR form? Where did
you learn your math from?


This is still about GR and SR themselves. shrug

"George Dishman" wrote in message
...
"Max Keon" wrote in message
u...
"George Dishman" wrote in message
oups.com...
---

The journey from D to the perihelion radius obviously takes less
time than the journey from F to the perihelion radius, but the F
based Mercury will have still accelerated up to the same orbital
speed as the D based Mercury when it arrives at a consequently
advanced perihelion radius.

This gets difficult to illustrate and the diagram is
going to be wrong so please read all this paragraph
before commenting, you really need to use the program
to investigate it. I have added G, the next point
after F. As Mercury moves from D inward to perihelion
without the anisotropy, you are right, it would speed
up. With the anisotropy however, the path is flattened
so the next point G is actually farther from the Sun
so F becomes the perihelion.

I've shifted the diagram so that it's in clear view.

A
B
E
C
F

G D

Sun

According to you, when Mercury has fallen to F under the
influence of a lesser gravity pull than normal, and is thus
traveling at the velocity appropriate for those changed gravity
conditions, it will continue on along a tangent to the Sun if
the anisotropy is still switched on. But it then has no radial
velocity, so the anisotropy is switched off and normal gravity
is reinstated. Mercury will begin to fall again.

Assuming that the fall is in discrete steps, similar to the
above, the newly established radial velocity rekindles the
anisotropy so Mercury's fall again ceases at the next lower
level, etc, etc, until it finally reaches the true perihelion
radius.

Mercury will not begin the return journey until the true
perihelion radius has been reached. That's obvious to a blind
man George.

We deny the truth at our peril.
---

The anisotropy doesn't immediately switch on or off of course,

It doesn't switch off at all, it is always there, but
we can switch it in and off for comparison of course.

And we can switch it in discrete, 1 second stages which each
simulate the one big step described in your diagram. Each stage
has a counteractory stage that will bring Mercury to the true
perihelion radius, always.
---

This has all been a very interesting exercise George, but it
really makes no difference in the end because gravity is _always_
entirely elastic. That's the point you seem to be missing
altogether.

I'm not missing it at all, what you are missing
is that your anisotropy is inelastic so there are
two possibilities, either there is anisotropy in
gravity and gravity is _not_ elastic, or gravity
_is_ elastic and there is no anisotropy. Your
equation describes the first.

_not_ , _is_ ?? Is that your proof?

Here's the program - just copy in and run then
watch the effects. Oh, it also adds a crossing
yellow line at aphelion and perihelion. (I have
deleted some print statements and file output
to reduce the clutter.)

Very thoughtful. But I do question your need to clutter the
program with 36 lines just to identify something that's within
an accuracy of one screen pixel.

Apart from the fact that your program is designed on a false
premise, in that any variation from normal gravity is inelastic,
it's still unreliable. But I do like your program.

Make these simple changes to your program and see what results
with no anisotropy. Your earlier version was much better, by the
way. It's of little consequence to me though because adding the
anisotropy in the manner you have done is wrong regardless.

' mag = 3000 Switch it off.

dt = 1000 dt was 100

vy = 10000 vy was 38855

Switch off the lone END statement in the middle of the
section "Detect the aphelion and perihelion points."
' END

' anisotropy = Newton * (3 * vr - lastVr) / (2 * c)

' IF (orbitnum 10000.6) AND (time simLength) GOTO timestep
Replace it with GOTO timestep


Then use Ctrl and Break to halt the program.

Your earlier version displayed an error that was proportional
to dt, and possibly to do with compounding errors, but this one
has an error which changes exponentially to dt. It seems that
everything is tuned around dt = 100. There's nothing wrong with
that of course, so long as the value of dt doesn't change.

http://members.optusnet.com.au/maxkeon/george2.jpg
is the result from both versions of you program. vy = 10000
is common for both while dt is set to 2000 for the earlier
version, just to make it clearer. Doing so in your later version
causes it to dive straight off the page.

-----

Max Keon

On 19 Jun, 11:26, "Max Keon" wrote:
"George Dishman" wrote in message

... "Max Keon" wrote in message
. au...
"George Dishman" wrote in message
groups.com...

---

The journey from D to the perihelion radius obviously takes less
time than the journey from F to the perihelion radius, but the F
based Mercury will have still accelerated up to the same orbital
speed as the D based Mercury when it arrives at a consequently
advanced perihelion radius.
This gets difficult to illustrate and the diagram is
going to be wrong so please read all this paragraph
before commenting, you really need to use the program
to investigate it. I have added G, the next point
after F. As Mercury moves from D inward to perihelion
without the anisotropy, you are right, it would speed
up. With the anisotropy however, the path is flattened
so the next point G is actually farther from the Sun
so F becomes the perihelion.

I've shifted the diagram so that it's in clear view.

I've added H on the path after D:

A
B
E
C
F

G D

Sun
H

According to you, when Mercury has fallen to F under the
influence of a lesser gravity pull than normal, and is thus
traveling at the velocity appropriate for those changed gravity
conditions, ...

That is close but let me reword it to be more
accurate: when Mercury has fallen to F under the
influence of a lesser gravity pull than normal,
it is traveling at the velocity produced by those
changed gravity conditions that applied during the
fall

... , it will continue on along a tangent to the Sun if
the anisotropy is still switched on. But it then has no radial
velocity, so the anisotropy is switched off and normal gravity
is reinstated. Mercury will begin to fall again.

Stop and think Max, there are two errors there.
First, at perihelion, it has no radial velocity,
so the anisotropic acceleration is zero. Switching
off something with a value of zero makes no change.

Second, switching an acceleration off an on (if
there was any) doesn't immediately change the
velocity, it changes the rate at which the
velocity is changing. At perihelion, the outward
centrifugal force exceeds the inward gravitational
force by some margin (which is more than even the
largest value of the anisotropy) so the planet will
continue past the perihelion opoint and still start
its outward leg but at a slightly lower rate than
without the anisotropy.

Assuming that the fall is in discrete steps, similar to the
above, the newly established radial velocity ..

There is no radial velocity at the new perihelion,
and switching off the anisotropy doesn't create
any.

rekindles the
anisotropy so Mercury's fall again ceases at the next lower
level, etc, etc, until it finally reaches the true perihelion
radius.

Mercury will not begin the return journey until the true
perihelion radius has been reached. That's obvious to a blind
man George.

Look again at the diagram above. The perihelion
without the anisotropy was near or just after D
but with the anisotropy it has moved away from the
Sun to the radius of F.

We deny the truth at our peril.

But that is exactly what you are doing.

The anisotropy doesn't immediately switch on or off of course,
It doesn't switch off at all, it is always there, but
we can switch it in and off for comparison of course.

And we can switch it in discrete, 1 second stages which each
simulate the one big step described in your diagram. Each stage
has a counteractory stage that will bring Mercury to the true
perihelion radius, always.

Your equation defines the path and the effect it
has on the inward leg increases the perihelion.

This has all been a very interesting exercise George, but it
really makes no difference in the end because gravity is _always_
entirely elastic. That's the point you seem to be missing
altogether.
I'm not missing it at all, what you are missing
is that your anisotropy is inelastic so there are
two possibilities, either there is anisotropy in
gravity and gravity is _not_ elastic, or gravity
_is_ elastic and there is no anisotropy. Your
equation describes the first.

_not_ , _is_ ?? Is that your proof?

No, it is repeating what was proved before. The
proof consists of integrating the enrgy changes
round a closed path. If the nature of the force
is such that the final result must be the same
as the initial value for any arbitrary motion
then it is called elastic, otherwise it is
inelastic. For your equation, moving from radius
R1 to R2 at one speed then back from R2 to R1 at
the same speed means the planet gains and loses
the same energy on the two legs, but returning
at a different speed produces a difference between
the energy lost and gained hence it is inelastic.

Here's the program - just copy in and run then
watch the effects. Oh, it also adds a crossing
yellow line at aphelion and perihelion. (I have
deleted some print statements and file output
to reduce the clutter.)

Very thoughtful. But I do question your need to clutter the
program with 36 lines just to identify something that's within
an accuracy of one screen pixel.

I'm not sure which lines you mean. The corrections
for accuracy are less than 36 lines, mainly small
adjustments to a few existing lines. The "if"
statements that swap "mag" and "K" were added in
response to your comments regarding displaying a
reference orbit and automate the process I followed
manually.

Apart from the fact that your program is designed on a false
premise, in that any variation from normal gravity is inelastic,

Whoa hold an Max. The program is not designed on
that basis at all, it takes your equation for the
acceleration and simply integrates to find the
velocity and then position with no further assumptions
whatsoever.

My comments regarding your equation being inelastic
are merely to help you understand why the planet
would behave as the program shows but play no part
in the program. The code makes no assumption about
whether it is elastic or not.

it's still unreliable. But I do like your program.

The only 'unreliability' is in the accuracy of the
numerical integration and I have given a detailed
analysis of that. Basically, for reasonable dt values
the accuracy is of the order of metres.

Make these simple changes to your program and see what results
with no anisotropy. Your earlier version was much better, by the
way. It's of little consequence to me though because adding the
anisotropy in the manner you have done is wrong regardless.

I have added the anisotropy the way you told me.
You said it was in the same direction as normal
gravity - towards the Sun. If you want to change
that then tell me in which direction it should
act and I will modify the program accordingly.

' mag = 3000 Switch it off.

dt = 1000 dt was 100

100 is OK for a fast, rough indication but
the accuracy will be poor.

vy = 10000 vy was 38855

Such a low velocity will cause very high speeds
and accelerations near perihelion so you need to
use a much lower value of dt, probably no more
than 10. The smaller the better of course.

Switch off the lone END statement in the middle of the
section "Detect the aphelion and perihelion points."
' END

' anisotropy = Newton * (3 * vr - lastVr) / (2 * c)

' IF (orbitnum 10000.6) AND (time simLength) GOTO timestep
Replace it with GOTO timestep

Then use Ctrl and Break to halt the program.

Your earlier version displayed an error that was proportional
to dt, and possibly to do with compounding errors, but this one
has an error which changes exponentially to dt.

Any "well behaved" function can be split into a
power series. The original had an error that was
primarily in two parts, a linear part and a
quadratic. The linear part was due to the
simplification of using the velocity and
acceleration at the start of each step as if it
would be constant throughout. The improved version
predicts the average and uses that, and it
successfully removed the linear leaving the
quadratic.

It seems that
everything is tuned around dt = 100. There's nothing wrong with
that of course, so long as the value of dt doesn't change.

No, it has been corrected to eliminate the linear
term. The optimum dt is zero but of course that
isn't practical. Any non-zero value gives a small
error but that is less than a metre in the radius
over an orbit for dt=1 and is generally adequate
up to dt=100.

http://members.optusnet.com.au/maxkeon/george2.jpg
is the result from both versions of you program. vy = 10000
is common for both while dt is set to 2000 for the earlier
version, just to make it clearer. Doing so in your later version
causes it to dive straight off the page.

Using vy = 10000 and dt = 2000 simply produces
large numerical errors, the graphs are a good
illustration of pushing the program too far.

If you want to understand the effect of dt on
the accuracy of the program, run it to the
first perihelion with the anisotropy on and
note the perihelion radius. Use a series of dt
values, say 30, 25, 20, 15, 10 and 5s and plot
a graph of the radius versus dt. It should be
obvious that you get a quadratic and you can
estimate what the value would be at dt=0.

Compare that with the same thing with the
values when the anisotropy is off and you find
the effect of the anisotropy. You will find
the curves are very similar but displaced by
about 2011 km while the difference for the
different dt values is only a few metres.

Bottom line Max, is that the ASCII diagram
above shows qualitatively why the perihelion
is increased by the anisotropy during the
inward leg and the program gives you an
accurate value for that change.

George

On 20 Jun, 08:35, George Dishman wrote:
....
For your equation, moving from radius
R1 to R2 at one speed then back from R2 to R1 at
the same speed means the planet gains and loses
the same energy on the two legs, ..

Ignore that bit Max, it is rubbish. It should
have said 'velocity' instead of 'speed' and
obviously you can't have have the same velocity
when moving in opposite directions, the sign
changes. I can't give you a counter example of
motion that is elastic with your equation, but
you should be able uto understand the proof
anyway, the examples were just to assist.

George

"George Dishman" wrote in message
ups.com...
On 19 Jun, 11:26, "Max Keon" wrote:
"George Dishman" wrote:
"Max Keon" wrote:

The journey from D to the perihelion radius obviously takes less
time than the journey from F to the perihelion radius, but the F
based Mercury will have still accelerated up to the same orbital
speed as the D based Mercury when it arrives at a consequently
advanced perihelion radius.

This gets difficult to illustrate and the diagram is
going to be wrong so please read all this paragraph
before commenting, you really need to use the program
to investigate it. I have added G, the next point
after F. As Mercury moves from D inward to perihelion
without the anisotropy, you are right, it would speed
up. With the anisotropy however, the path is flattened
so the next point G is actually farther from the Sun
so F becomes the perihelion.

I've shifted the diagram so that it's in clear view.

I've added H on the path after D:

A
B
E
C
F

G D

Sun
H

According to you, when Mercury has fallen to F under the
influence of a lesser gravity pull than normal, and is thus
traveling at the velocity appropriate for those changed gravity
conditions, ...

That is close but let me reword it to be more
accurate: when Mercury has fallen to F under the
influence of a lesser gravity pull than normal,
it is traveling at the velocity produced by those
changed gravity conditions that applied during the
fall

... , it will continue on along a tangent to the Sun if
the anisotropy is still switched on. But it then has no radial
velocity, so the anisotropy is switched off and normal gravity
is reinstated. Mercury will begin to fall again.

Stop and think Max, there are two errors there.
First, at perihelion, it has no radial velocity,
so the anisotropic acceleration is zero. Switching
off something with a value of zero makes no change.

I'm trying to explain something to you using analogies George.
I think I understand the consequences of the anisotropy better
than you do.

For any sustainable concentric orbit, if the pull of gravity
is increased slightly, a fall toward the gravity source will
be initiated. A lesser pull of gravity initiates a rise from
the gravity source.

For any sustainable _eccentric_ orbit, if the pull of gravity is
increased slightly, a fall, _departing from the normal_, will be
initiated toward the gravity source. A lesser pull initiates a
rise from the gravity source, again departing from the normal.
_It's no different to the concentric orbit._

Try explaining how energy will be lost from a concentric orbit
if gravity is lessened for a time and then returned to the way it
was. After a time, orbital speed and gravitational potential will
all shift back to the way they were. And it doesn't matter how
long it takes. Meaning that the process is not linked to the
orbit cycle time in any way. Now try explaining how the eccentric
orbit will behave differently.

If the pull of gravity is varied enroute to perihelion or
aphelion, that will initiate a change from the normal, just as
it would for a varied gravity rate applied at any time around
a concentric orbit. The only thing that links the anisotropy
with the orbit cycle time is that the anisotropy is dependent on
radial velocity which always begins and ends at zero at the two
orbit radius extremes. And each of those extremes must be reached
before everything is back to where it would normally be if
nothing had changed. The orbit orientation in the Sun's inertial
frame at the time when each radius extreme is reached is totally
irrelevant.
---

Second, switching an acceleration off an on (if
there was any) doesn't immediately change the
velocity,

You are certainly correct there, but you are still miles away
from what the true acceleration rate would be.

When Mercury falls toward the perihelion, the generated gravity
anisotropy causes a fall which begins at zero velocity from where
it would normally be. When Mercury rises toward the aphelion the
anisotropic force reverses, so the anisotropic change again
begins at zero velocity from the normal at the perihelion radius,
wherever that may now be oriented in the Sun's frame. The
accelerations begin and end in every half cycle, and they
counteract each other as well, so Mercury doesn't go too far at
all.

Your error has always been to add the anisotropy directly to the
Newtonian gravity as if it was applied at its full potential.
That is _vastly_ wrong.
---

_not_ , _is_ ?? Is that your proof?

No, it is repeating what was proved before. The
proof consists of integrating the enrgy changes
round a closed path.

Your program is designed to plot the orbit coordinates for any
situation where normal gravity applies. It's not capable of
describing the consequences of the anisotropy. Get that straight
in your mind and we may start making some progress.

Your coordinate system if rigidly fixed with the screen, which
supposedly represents the Sun's inertial frame, and the only way
the orbit orientation can be indexed around is to compoundingly
add or subtract from the x and y coordinates. To you, that
represent a shift of energy. That's not the case at all. Where
the aphelion and perihelion happen to be is only to do with
the trajectory paths and the time it takes to arrive at each
radius. How can the Sun possibly assume any sort of control over
such a thing? You do live in a strange universe.
---

I've included a program which does what the introduction states.

-----

Max Keon


'-------------------------------------
' ESC exits the program (sometimes).

' The purpose of the program is to demonstrate what little
' difference the anisotropy would make to Mercury's orbit shape
' even if it was inelastic. But it's not of course.

' This equation which is part of the program,
' fall = (v - (v*(-GM/r^2)^.5/(-GM/r^2+a)^.5))^2/v^2*a
' determines the true fall rate generated by the anisotropy.
' Its function is better described at
' http://members.optusnet.com.au/maxkeon/peri.html
' Its consequence is also graphically depicted by removing the
' switch on the next line.

' GOTO ah ''' Remove the ' switch to run the attachment.

DEFDBL A-Z
SCREEN 12
CLS
COLOR 7
LOCATE 18, 18: PRINT "Press any key to continue."
CIRCLE (228, 250), 8, 14 ' Sun.
c = 300000000#
GM = -1.327D+20
multi = .000000003# ' Multiplier for the graphics.

x = 70000000000#: vy = 39000# ' Aphelion start.
'x = 46000000000#: vy = 59000# ' Perihelion start.

mx = x ' Aligns the two parts of the first program.
mvy = vy

lastradius = x
mlastradius = x

dt = 100

multib = 100#
' This multiplier is only included to establish a more accurate
' radius difference between the normal and that generated by
' the anisotropy. Adding the initial minute changes generated by
' the anisotropy nearing aphelion and perihelion, to the orbit
' radius, is beyond the scope of a 16 digit calculator. Whatever
' way I choose to magnify the anisotropy, it must also affect
' everything else accordingly. So the result isn't accurate, but
' it serves the purpose for now. Change the value to 1 and the
' result isn't all that different anyway.

aa:
mr2 = mx * mx + my * my
mradius = SQR(mr2)

mvr = (mradius - mlastradius) / dt
mlastradius = mradius

mNewton = GM / mr2

macceleration = mNewton

max = macceleration * (mx / mradius)
may = macceleration * (my / mradius)

mvx = mvx + dt * max
mvy = mvy + dt * may

mx = mx + dt * mvx
my = my + dt * mvy

'Part (2)-----------(includes anisotropy)-----------
r2 = x * x + y * y
radius = SQR(r2)

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

newton = GM / r2

anisotropy = -newton * (vr / c)

ovel = (mvx ^ 2# + mvy ^ 2#) ^ .5# ' Orbital speed no anisotropy.
ovelc = (vx ^ 2# + vy ^ 2#) ^ .5# ' Orbital speed with anisotropy.

v = ovel ' orbital speed.
r = radius
a = anisotropy

fall = (v - (v * (-GM / r ^ 2#)^ .5#/(-GM/r^2#+a)^.5#))^2#/v^2#*a

acceleration = newton - fall * multib

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

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

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

CIRCLE (230 + x * multi, 250 + y * multi), 0, 13
CIRCLE (230 + mx * multi, 250 + my * multi), 0, 11

time = time + dt

IF time 40000 THEN GOSUB ab

IF vr 0 AND fa = 0 THEN fb = 1: fa = 1: GOSUB ab: GOSUB ad
IF vr 0 AND fb = 1 THEN fa = 0: fb = 0: GOSUB ab: GOSUB ad
' f? are all flags which don't affect the result.

GOTO aa

ab:
time = 0
LOCATE 1, 1
PRINT anisotropy; "anisotropy. "
PRINT fall; "actual fall rate. "
PRINT vr; "radial velocity "; mvr; "no anisotropy. "
PRINT ovelc; "orbital speed"; ovel; "no anisotropy. "
PRINT radius; "radius"; mradius; "no anisotropy. "
PRINT (radius - mradius); "radius difference. "
PRINT (radius - mradius) / multib; "true radius difference. "
RETURN

ad:
PRINT " Press ESC at the end of a half cycle to end the program."
DO: s$ = INKEY$: LOOP UNTIL s$ ""
IF s$ = CHR$(27) THEN END
RETURN


'----Attachment-------
ah:
CLS
SCREEN 12
COLOR 8
LINE (150, 150)-(400, 150) 'Grid lines
LINE (150, 200)-(400, 200)
LINE (150, 250)-(400, 250)
LINE (150, 300)-(400, 300)
LINE (150, 350)-(400, 350)
LINE (150, 150)-(150, 350)
LINE (200, 150)-(200, 350)
LINE (250, 150)-(250, 350)
LINE (300, 150)-(300, 350)
LINE (350, 150)-(350, 350)
LINE (400, 150)-(400, 350)

COLOR 7
LOCATE 23, 19
PRINT "50 40 30 20 10 0"
LOCATE 24, 30: PRINT "km/sec"
LOCATE 10, 52: PRINT "0"
LOCATE 13, 52: PRINT "2e-7"
LOCATE 16, 52: PRINT "4e-7"
LOCATE 19, 52: PRINT "6e-7"
LOCATE 22, 52: PRINT "8e-7"
LOCATE 11, 48: PRINT "Fall rate"
LOCATE 12, 48: PRINT "m/sec^2"
LOCATE 18, 20: PRINT "48000 m/sec maintains"
LOCATE 19, 20: PRINT "a stable concentric orbit,"
LOCATE 20, 20: PRINT "in this case."
v = 48000
va = 48000
an = .0000008
multic = 250000000' graphics multiplier.
LOCATE 1, 1
af:
fall = ((v - va) ^ 2 / v ^ 2) * an
CIRCLE (400 - va / 200, 150 + fall * multic), 0, 11
va = va - 1000
IF va 0 THEN FOR s = 1 TO 8: READ a$: PRINT a$: NEXT s: END
'DO: LOOP UNTIL INKEY$ ""
GOTO af

DATA " The centrifugal force per orbital speed that maintained"
DATA " the concentric orbit reduces at a squaring rate per orbital"
DATA " speed reduction, as it should do. Zero orbital speed is -48"
DATA " km/sec relative to that required to hold a stable orbit."
DATA " The anisotropic fall rate is calculated on the minute"
DATA " change in orbital speed between that required to stabilize"
DATA " the normal, and the anisotropy affected orbits. It gives a"
DATA " vastly reduced fall rate, whatever way you look at it."

"Max Keon" wrote in message
...

"George Dishman" wrote in message
ups.com...
On 19 Jun, 11:26, "Max Keon" wrote:
"George Dishman" wrote:
"Max Keon" wrote:

The journey from D to the perihelion radius obviously takes less
time than the journey from F to the perihelion radius, but the F
based Mercury will have still accelerated up to the same orbital
speed as the D based Mercury when it arrives at a consequently
advanced perihelion radius.

This gets difficult to illustrate and the diagram is
going to be wrong so please read all this paragraph
before commenting, you really need to use the program
to investigate it. I have added G, the next point
after F. As Mercury moves from D inward to perihelion
without the anisotropy, you are right, it would speed
up. With the anisotropy however, the path is flattened
so the next point G is actually farther from the Sun
so F becomes the perihelion.

I've shifted the diagram so that it's in clear view.

I've added H on the path after D:

A
B
E
C
F

G D

Sun
H

According to you, when Mercury has fallen to F under the
influence of a lesser gravity pull than normal, and is thus
traveling at the velocity appropriate for those changed gravity
conditions, ...

That is close but let me reword it to be more
accurate: when Mercury has fallen to F under the
influence of a lesser gravity pull than normal,
it is traveling at the velocity produced by those
changed gravity conditions that applied during the
fall

... , it will continue on along a tangent to the Sun if
the anisotropy is still switched on. But it then has no radial
velocity, so the anisotropy is switched off and normal gravity
is reinstated. Mercury will begin to fall again.

Stop and think Max, there are two errors there.
First, at perihelion, it has no radial velocity,
so the anisotropic acceleration is zero. Switching
off something with a value of zero makes no change.

I'm trying to explain something to you using analogies George.

You and I could throw analogies at each other until the
cows come home and make no progress so the only way to
resolve the disagreement was to put your equation into
a program and let it calculate what would happen. I have
done that and you have seen the results.

I think I understand the consequences of the anisotropy better
than you do.

You explained the consequences a few posts back. You
said that on the inward leg the reduced gravity meant
the path would fall outside the Newtonian curve. I
agreed and we agree the diagram above. You simply have
to sit back and think about the end result of what you
told me. The same is true for the outward leg, we both
understand that the path with anisotropy will fall
inside the Newtonian orbit. Snipping previous points
and ignoring areas we agree doesn't move this forward
at all.

For any sustainable concentric orbit, if the pull of gravity
is increased slightly, a fall toward the gravity source will
be initiated. A lesser pull of gravity initiates a rise from
the gravity source.

If a planet were in a perfectly circular orbit and the
gravitational pull suddenly increased due to a change
of mass of the central object, the radius and velocity
at that instant would be unaffected. The pull would
exceed the centrifugal force and the radius would start
to decrease. The effect is that the planet is then in
an elliptical orbit which would be stable as long as
the increased mass remained constant. The point at which
the change had occurred would be the aphelion.

For any sustainable _eccentric_ orbit, if the pull of gravity is
increased slightly, a fall, _departing from the normal_, will be
initiated toward the gravity source. A lesser pull initiates a
rise from the gravity source, again departing from the normal.
_It's no different to the concentric orbit._

It is a little more complex but the principle is the
same, the planet would change from one elliptical
orbit to another such that the velocity of the two
is the same at the point where the central mass
changed.

Again, this is just what we said before, we both agree
this. The inward fall results in an increased perihelion
while the outward leg reduces aphelion. Both reduce the
eccentricity.

Try explaining how energy will be lost from a concentric orbit
if gravity is lessened for a time and then returned to the way it
was. After a time, orbital speed and gravitational potential will
all shift back to the way they were. And it doesn't matter how
long it takes. Meaning that the process is not linked to the
orbit cycle time in any way. Now try explaining how the eccentric
orbit will behave differently.

I've seen a diagram that explains this well on Wiki
but I can't find it now that I need it so I'll just
tell you and if I find it I'll post a follow-up.

For a given orbital energy, the planet could be in a
circular orbit or an elliptical with any eccentricity.
In the latter case there is an exchange between kinetic
and potential energy round the orbit but the total is
constant.

What happens as a result of your anisotropy when acting
on elliptical orbits is not primarily a change of energy,
the eccentricity reduces while keeping the total energy
pretty much constant.

If the pull of gravity is varied enroute to perihelion or
aphelion, that will initiate a change from the normal, just as
it would for a varied gravity rate applied at any time around
a concentric orbit. The only thing that links the anisotropy
with the orbit cycle time is that the anisotropy is dependent on
radial velocity which always begins and ends at zero at the two
orbit radius extremes. And each of those extremes must be reached
before everything is back to where it would normally be if
nothing had changed.

The extremes, perihelion and aphelion, vary with the
eccentricity as you can see from the diagram above
which illustrates the program output I can't do screen
capture under XP).

The orbit orientation in the Sun's inertial
frame at the time when each radius extreme is reached is totally
irrelevant.

Yes.

Second, switching an acceleration off an on (if
there was any) doesn't immediately change the
velocity,

You are certainly correct there, but you are still miles away
from what the true acceleration rate would be.

Well the acceleration value I use is simply that given
by your equation. With the adjustment to use the mean
to improve the numerical accuracy that is given by the
lines:

vr = (radius - lastRadius) / dt
anisotropy = Newton * (3 * vr - lastVr) / (2 * c)
acceleration = Newton + anisotropy

Conceptually it is easier to read the middle line as:

anisotropy = Newton * vr / c

That is where you need to make any change if the
results don't match what you expect.

When Mercury falls toward the perihelion, the generated gravity
anisotropy causes a fall ...

No, it causes a rise - the fall is slower than it would
be without the anisotropy.

... which begins at zero velocity from where
it would normally be. When Mercury rises toward the aphelion the
anisotropic force reverses, so the anisotropic change again
begins at zero velocity from the normal at the perihelion radius,
wherever that may now be oriented in the Sun's frame. The
accelerations begin and end in every half cycle, and they
counteract each other as well, ...

No they don't counteract, their effects add. Both legs
decrease the eccentricity.

so Mercury doesn't go too far at
all.

Your error has always been to add the anisotropy directly to the
Newtonian gravity as if it was applied at its full potential.
That is _vastly_ wrong.

Then change your equation because I simply compute
the amount from that.

...
Your program is designed to plot the orbit coordinates for any
situation where normal gravity applies.

The program computes the path for _any_ combination of
acceleration from _any_ type of source. Specifically I
hadn't intended to spend much time on the program as
your suggestion is so obviously wrong, but when I saw
that I could get the numerical accuracy to a useful
level, I decided to develop the program to model the
path of a solar sail with a variable aspect to the Sun
which is a pet project of mine. I can do by replacing
your anisotropic acceleration by one describing the
radiation pressure and I can add in any other thrusts,
such as drag from the solar wind, in exactly the same
way.

It's not capable of
describing the consequences of the anisotropy. Get that straight
in your mind and we may start making some progress.

No Max, you get to get it into your head that YOU
are telling ME what the acceleration is. The program
works for _any_ cause of acceleration including your
anisotropy PROVIDED the equation you supplied gives
me an accurate value for the acceleration the
anisotropy causes. If it doesn't, you need to supply
me with a different equation.

If you like, let the program run for about quarter
of an orbit and break in. Print out the radius and
use a calculator to check the Newtonian part. Print
out the radial speed (vr) and the anisotropy and
again check with your calculator that the code is
giving the right value. Check that the signs are
right, the Newtonian acceleration being negative
and the anisotropy positive (since it is the inward
leg). If the numbers aren't what they should be, we
can look for a bug in the code, but if they match
your expectation, then my path is correct.

Your coordinate system if rigidly fixed with the screen, which
supposedly represents the Sun's inertial frame, and the only way
the orbit orientation can be indexed around is to compoundingly
add or subtract from the x and y coordinates.

Right, that is what velocity does, it increments the
location in each time step, and similarly the
acceleration tells you how the velocity varies.

To you, that
represent a shift of energy. That's not the case at all.

Indeed. The energy is in two parts, kinetic based
on speed and potential based on radius. I would
need to do a calculation to find out what the
energy is, but I never use the energy so I haven't
bothered.

Where
the aphelion and perihelion happen to be is only to do with
the trajectory paths and the time it takes to arrive at each
radius. How can the Sun possibly assume any sort of control over
such a thing? You do live in a strange universe.

The only strange part is the effect of your equation,
the rest is the definition of the terms velocity (rate
of change of location) and acceleration (rate of change
of velocity).

I've included a program which does what the introduction states.

My program implements your equation accurately.
If you don't like the result, check the numbers
as I explained above, but if they match your
calculator checks, then you need to tell me a
different equation for the anisotropy if you
want a different outcome.

George

"George Dishman" wrote in message
oups.com...
"Max Keon" wrote in message
...
---

I think I understand the consequences of the anisotropy better
than you do.

You explained the consequences a few posts back. You
said that on the inward leg the reduced gravity meant
the path would fall outside the Newtonian curve. I
agreed and we agree the diagram above. You simply have
to sit back and think about the end result of what you
told me. The same is true for the outward leg, we both
understand that the path with anisotropy will fall
inside the Newtonian orbit. Snipping previous points
and ignoring areas we agree doesn't move this forward
at all.

I snip anything that is wrong. Then I go about correcting your
errors, over and over again.

For any sustainable concentric orbit, if the pull of gravity
is increased slightly, a fall toward the gravity source will
be initiated. A lesser pull of gravity initiates a rise from
the gravity source.

If a planet were in a perfectly circular orbit and the
gravitational pull suddenly increased due to a change
of mass of the central object, the radius and velocity
at that instant would be unaffected. The pull would
exceed the centrifugal force and the radius would start
to decrease. The effect is that the planet is then in
an elliptical orbit which would be stable as long as
the increased mass remained constant. The point at which
the change had occurred would be the aphelion.

And how fast do you imagine this elliptical orbit would form?
According to you, the fall begins immediately at the full extent
of the anisotropy. Again, that is grossly wrong. The fall would
very slowly progress and would take very many orbits before it
came to rest at the lesser radius required to maintain a stable
orbit, whether that be eccentric or not. You have it falling into
an eccentric orbit in only one orbit cycle. You even specify the
aphelion position in the Sun's frame. The final aphelion could
be anywhere.
---

What happens as a result of your anisotropy when acting
on elliptical orbits is not primarily a change of energy,
the eccentricity reduces while keeping the total energy
pretty much constant.

That's a convenient postulate, but quite untrue.
---

Your coordinate system if rigidly fixed with the screen, which
supposedly represents the Sun's inertial frame, and the only way
the orbit orientation can be indexed around is to compoundingly
add or subtract from the x and y coordinates.

Right, that is what velocity does, it increments the
location in each time step, and similarly the
acceleration tells you how the velocity varies.

No George. Your program causes Mercury's rise or fall to
prematurely switch off at the exact half cycle, leaving the final
approach to aphelion or perihelion somewhere in limbo. Then you
claim proof of an orbit eccentricity collapse?
---

I've included a program which does what the introduction states.

My program implements your equation accurately.

That is nonsense George.

Here's something that's not.

A mass in a concentric orbit at a radius of 5.8e10 meters from
the Sun is supposedly continually falling to the Sun at the rate
of .0395 m/sec^2, but that doesn't seem to be entirely correct
at first glance.

According to the result from compounding the acceleration until
the fall is twice the distance to the Sun, the time for the
journey has been 2424837 seconds, where the real time for the
half orbit is 2424837 * (pi/2) = 3808925 seconds. Dividing the
diameter by the orbital speed also equals the lesser time value
and suggest that the orbital speed has been the average speed
for the straight line journey.

The fall must equal the diameter length when the mass arrives at
the far side of its orbit, regardless of how it gets there. It
can't be there on one path and not be there on another at the
same time.

The reason for the inconsistency is of course that, while it's
in orbit, the fall direction doesn't always point at the Sun.
The fall is then directly related to COS and pi. The average
orbital second is 1/(pi/2) straight line seconds.

I presume you are aware of this little quirk in nature?

These are the results from compounding the acceleration.
2424837 one second steps at .039457 m/sec^2 traverse
116000058179 meters for a straight line acceleration.

The final step doesn't fall exactly on the diameter
length, so the result isn't accurate. But it serves the purpose.

____Normally:
For an orbit diameter of 116000000000 meters.
3.945689655172414D-02 is the gravity rate (newton).
47838.26919945997 is the orbital speed.

This set of figures are calculated according to the formula
shown.
3.945689655172414D-02 acceleration rate per 2/(d/v^2)
(compare with the normal).
2424836.891910577 1 second steps to travel the diameter (d/v)
2424836.891910577 1 second steps per (2*d/newton)^.5

47838.26919945997 is the orbital speed per d/(2*d/newton)^.5
(compare with the normal). Everything is identical to the normal
result, so I have complete confidence in the system.

Which brings us back to the orbital speed per fall rate dilemma
that you seem to be having so much trouble understanding.

Once again, add the anisotropy (e.g. 8e-7) as you insist on doing
d/(2*d/(newton+anisotropy))^.5
The result is 47838.75416438016 m/sec orbital speed.
The difference is only .4849649201933062 m/sec.
Or .9999898625094097 to 1 ratio

So, a 1 to 1 ratio accepts no radial change whatever, and a
..9999898625094097 to 1 ratio accepts a 100% radial change rate?
Only a 0 to 1 ratio ( 0 orbital speed) would give that rate.
Can't you see that yet?

http://members.optusnet.com.au/maxkeon/peri.html

-----

Max Keon

I wrote:
-The fall must equal the diameter length when the mass arrives at
-the far side of its orbit, regardless of how it gets there. It
-can't be there on one path and not be there on another at the
-same time.

-The reason for the inconsistency is of course that, while it's
-in orbit, the fall direction doesn't always point at the Sun.
-The fall is then directly related to COS and pi. The average
-orbital second is 1/(pi/2) straight line seconds.

This paragraph replaces the above paragraph, for obvious reasons:
The reason for the inconsistency is of course that, while it's
in orbit, the fall direction doesn't always point at the Sun
along the path of the chosen diameter. The fall is then directly
related to COS and pi. The average orbital second is 1/(pi/2)
straight line seconds.

On 29 Jun, 00:55, "Max Keon" wrote:
"George Dishman" wrote in message

oups.com... "Max Keon" wrote in message
u...

---

I think I understand the consequences of the anisotropy better
than you do.
You explained the consequences a few posts back. You
said that on the inward leg the reduced gravity meant
the path would fall outside the Newtonian curve. I
agreed and we agree the diagram above. You simply have
to sit back and think about the end result of what you
told me. The same is true for the outward leg, we both
understand that the path with anisotropy will fall
inside the Newtonian orbit. Snipping previous points
and ignoring areas we agree doesn't move this forward
at all.

I snip anything that is wrong.

No, you snip anything you find inconvenient,
including items you yourself wrote just a few
posts earlier. You told me that the anisotropy
would push the planet farther from the Sun on
the inwards legm, but when I pointed out that
I agreed and that was exactly what the program
shows, you just snipped it instead of accepting
that we both know what will happen.

Then I go about correcting your
errors, over and over again.

You keep repeating crap over and over without
learning.

For any sustainable concentric orbit, if the pull of gravity
is increased slightly, a fall toward the gravity source will
be initiated. A lesser pull of gravity initiates a rise from
the gravity source.
If a planet were in a perfectly circular orbit and the
gravitational pull suddenly increased due to a change
of mass of the central object, the radius and velocity
at that instant would be unaffected. The pull would
exceed the centrifugal force and the radius would start
to decrease. The effect is that the planet is then in
an elliptical orbit which would be stable as long as
the increased mass remained constant. The point at which
the change had occurred would be the aphelion.

And how fast do you imagine this elliptical orbit would form?

It doesn't "form" Max, either the anisotropy exists
or it doesn't, we are pretending you can switch it
off or on instantly as a means of comparing the two
hypotheses but in either one, the anisotropy is
either there or not permanently.

According to you, the fall begins immediately at the full extent
of the anisotropy. Again, that is grossly wrong.

It is correct, if you could switch acceleration
instantly then the rate change of velocity
changes instantly because that is the definition
of acceleration. We are pretending you can switch
the fall rate from one value to another instantly
two compare two situations.

What you may have missed is that I said "the
radius and velocity at that instant would be
unaffected".

What happens as a result of your anisotropy when acting
on elliptical orbits is not primarily a change of energy,
the eccentricity reduces while keeping the total energy
pretty much constant.

That's a convenient postulate, but quite untrue.

Don't try to use big words like "postulate" until
you find out what they mean. What I said is simply
the _consequence_ of your equation, not a postulate.

Your coordinate system if rigidly fixed with the screen, which
supposedly represents the Sun's inertial frame, and the only way
the orbit orientation can be indexed around is to compoundingly
add or subtract from the x and y coordinates.

Right, that is what velocity does, it increments the
location in each time step, and similarly the
acceleration tells you how the velocity varies.

No George. ...

Yes Max, those are the scientific definitions
of velocity and acceleration. Without those
definitions, there is no way to put your
equation to use.

... Your program causes Mercury's rise or fall to
prematurely switch off at the exact half cycle, ..

No, I can only guess you didn't look at it. The
code switches the anisotropy at perihelion when
the radius stops decreasing and starts increasing.

... leaving the final
approach to aphelion or perihelion somewhere in limbo. Then you
claim proof of an orbit eccentricity collapse?

The program waits until the fall to perihelion is
complete, it is triggered by the radius staring to
rise and it prints out the previous value which of
course is the smallest. That value is greater than
it would have been without the anisotropy exactly
as you said it would be a few posts back and we
drew like this (I've added dots to stop Google
collapsing some lines):

I've shifted the diagram so that it's in clear view.
I've added H on the path after D:
.
. A
. B
. E
. C
. F
.
.
. G D
.
.
. Sun
. H

AFAICS the rest of your post is based on the
situation without any anisotropy so irelevant.

George