Anisotropy and Mercury (2)

On 18 Jul, 15:38, "Warhol" wrote:
You are not alone... I have that often they cheat and I loose my post due
their censure.... But I never give up... even if need a hole day to
rewitting... Sometimes i forget the good points of the original post... Now
I backup before I send... But its happens I click send with the backup
securite mesure ... and You known what... than mostly that post doesn't show
up... Are they controling My Computer too?

Now some groups where not refreshed since more than 28 hours.... What do
they try to hide from the view of the Google Users...

"They"? That's just paranoia. I was sent a message from
another reader to let me know they were getting through.
Since Usenet is a peer-to-peer network with multiple
feeds to each server, it is very hard to prevent stuff
propagating once it is started. I was losing a few via
my local ISP but after reporting some ID numbers, they
found a bug in their software and the feed is now robust.

If you are losing some, try contacting your ISP.

"George Dishman" a écrit dans le message de news:
om...



For some reason, Google keeps saying my reply
posted successfully but nothing appears so I'll
trim this copy short to see if it makes it.

"George Dishman" wrote in message
ups.com...
On 17 Jul, 01:29, "Max Keon" wrote:
"George Dishman" wrote in message
oups.com...
On 10 Jul, 11:42, "Max Keon" wrote:

A point that you can never seem to grasp is that if Mercury is
further from the Sun than the normal perihelion radius when
radial velocity has ceased, thus reducing the anisotropy to zero
and reinstating normal gravity, Mercury will again fall because
it does not possess sufficient orbital speed to counteract the
resurrected pull of gravity.

Sorry Max, that's not the way it works. As the planet
is approaching perihelion, it already has enough speed
to throw it back out. What stops that is the momentum
directed inward and that is reduced by the anisotropy
so it doesn't get as close to the Sun before it starts
receding - the perihelion is increased.

The anisotropy does cause Mercury to fall short of reaching the
normal perihelion and aphelion radii, but that condition is
constant.

As you previously described the anisotropy, that
would not be true. On the inward leg, the reduced
gravity would mean it would not fall as far as
under Newtonian gravity alone so the perihelion
would be increased. For a given orbital energy,
that means the aphelion would have been decreased.

On the outward leg, the increased gravity meant
the aphelion would be farther reduced. The second
orbit would then repeat the process but starting
from a smaller aphelion than the first orbit and
that would continue asymptotically towards a
circular orbit.

We don't seem to be getting anywhere here, so I'll go back to
where it all began.

Yes we need to but not for the reason you thought,
your story has changed.

Yes, I know George. I became aware of my mistake not long after
I posted it. The problem stemmed from rekindling a thought that
plagued me some time ago, that the sign on radial velocity and
the anisotropy should not remain constant.

Why that thought came back to haunt me, is the perihelion
advance that resulted from physically switching the sign on the
anisotropy equation so that it didn't mimic radial velocity.
A perihelion advance was very evident.

What I didn't notice is that the same advance was occurring even
using the "elastic" equation. The rate of advance didn't slow
even when the orbit became circular, when there was no radial
velocity, or anisotropy.

The advance of the orbit orientation appears to be nothing more
than a flywheel effect that is set in motion in the very first
fall or rise from the aphelion or perihelion. The advance is
therefore present in exactly the proportions given in my previous
post. But it has nothing to do with the true perihelion advance
for Mercury in its well established orbit. But that is still a
flywheel effect, whatever maintains it.
---

Elastic versus inelastic is another matter, leave
it for a later discussion.

There's nothing left to discuss here since the problems you
highlighted were due to my error, so we can now perhaps discuss
the merits of an elastic anisotropic gravity.

Regardless of how your program depicts the affect from the
anisotropy, Mercury is drawn less to the Sun as it heads down to
the perihelion. When it arrives where the normal perihelion
should be, it cannot possibly have been drawn down to the normal
perihelion radius. That's how your program depicts it as well.
But where your program fails is in Mercury's designated orbital
speed when it arrives. Ask yourself how it got to be fast enough
to send Mercury back toward the aphelion when it was pulled to
the Sun at a lesser rate throughout the fall. It's not possible
is it. It will continue falling until its speed counteracts the
fall. Hence the perihelion advance.

The journey between aphelion and perihelion takes 3801600
seconds, while the average anisotropy over that time is
8.66e-07m/sec^2. If Mercury was stationary in the Sun's frame
it would have been accelerated by the anisotropy over a distance
of t^2 * anisotropy / 2 = 6257787 meters. Taking the average
anisotropy isn't accurate, but it serves the purpose.

With the anisotropy not multiplied, if you run your program and
check the radius change from the previous at each aphelion and
perihelion crossing, you will find that Mercury has been shifted
off course by 9.28e+6 and 4.26e+6 meters respectively in each
cycle. The average for each half cycle is 6770000 meters. So the
radius change rate has been close to the change rate that could
only apply if Mercury was stationary in the Sun's frame. But
Mercury is traveling at very close to the orbital speed that
maintained it in a completely sustainable orbit.

WHAT YOUR PROGRAM DEPICTS IS IMPOSSIBLE.

It obviously cannot correctly describe any gravity change from
the normal. Even if the anisotropy was inelastic, the radius
change per orbit would be nothing like that generated by your
program. It would be as described at this address
http://members.optusnet.com.au/maxkeon/peri.html

According to your program, Mercury is shifted off course by
4.26e+6 meters by the time it reaches the perihelion and it's
again shifted off the updated course by 9.28e+6 meters when it
reaches the aphelion. In both cases, the shift is in the same
direction in the Sun's frame.

This is the anisotropic force direction in the Sun's frame.
o o
- o o -
-- o \/ o -- (\/ orbit direction)
-- o /\ 0 o --
- o o -
o o

And this is the consequence.
o o
o o
o o
o 0 o
o o
o o
Notice that the perihelion has shifted.
And it will continue to do so.

-----

Max Keon

On 20 Jul, 13:50, "Max Keon" wrote:
"George Dishman" wrote in message
ups.com...
....
As you previously described the anisotropy, that
would not be true. On the inward leg, the reduced
gravity would mean it would not fall as far as
under Newtonian gravity alone so the perihelion
would be increased. For a given orbital energy,
that means the aphelion would have been decreased.

On the outward leg, the increased gravity meant
the aphelion would be farther reduced. The second
orbit would then repeat the process but starting
from a smaller aphelion than the first orbit and
that would continue asymptotically towards a
circular orbit.
We don't seem to be getting anywhere here, so I'll go back to
where it all began.
Yes we need to but not for the reason you thought,
your story has changed.

Yes, I know George. I became aware of my mistake not long after
I posted it. The problem stemmed from rekindling a thought that
plagued me some time ago, that the sign on radial velocity and
the anisotropy should not remain constant.

It was a good thought Max, you have actually hit
on the root cause of the disagreement. Although
I was trying to prompt you in this direction
many weeks ago, I think many of the basics needed
to be worked through to get enough common ground.

Why that thought came back to haunt me, is the perihelion
advance that resulted from physically switching the sign on the
anisotropy equation so that it didn't mimic radial velocity.
A perihelion advance was very evident.

What I didn't notice is that the same advance was occurring even
using the "elastic" equation. The rate of advance didn't slow
even when the orbit became circular, when there was no radial
velocity, or anisotropy.

The advance of the orbit orientation appears to be nothing more
than a flywheel effect that is set in motion in the very first
fall or rise from the aphelion or perihelion. The advance is
therefore present in exactly the proportions given in my previous
post. But it has nothing to do with the true perihelion advance
for Mercury in its well established orbit. But that is still a
flywheel effect, whatever maintains it.

It isn't actually a flywheel effect, if you switch
off the anisotropy, the advance would also stop,
but that's not important.

Elastic versus inelastic is another matter, leave
it for a later discussion.

There's nothing left to discuss here since the problems you
highlighted were due to my error, so we can now perhaps discuss
the merits of an elastic anisotropic gravity.

Technically, your equations are _not_ elastic. What
is happening with your version where the sign is
switched is that a small amount of energy is
actually gained from nowhere during the inward leg
and an identical amount is lost on the outward leg
so that Mercury returns to the original radius and
speed. It gives the appearance of being elastic but
in fact is not. Never mind though, that is another
matter.

Regardless of how your program depicts the affect from the
anisotropy, Mercury is drawn less to the Sun as it heads down to
the perihelion.

OK, that's what I had been assuming previously.
Because you switched the sign in your latest
version, the pull was actually increased on the
inward leg instead of being decreased and that
would make the perihelion closer to the Sun
instead of farther away. Changing back to my
single equation corrects that.

When it arrives where the normal perihelion
should be, it cannot possibly have been drawn down to the normal
perihelion radius. That's how your program depicts it as well.

If you put the sign back, yes.

But where your program fails is in Mercury's designated orbital
speed when it arrives. Ask yourself how it got to be fast enough
to send Mercury back toward the aphelion when it was pulled to
the Sun at a lesser rate throughout the fall. It's not possible
is it.

Yes it is. The speed becomes high enough to send it
back out roughly a quarter of the way round the
orbit, it is the momentum that keeps it going
inwards. The program correctly integrates the
acceleration twice to find the path so what you
see is what will happen.

It will continue falling until its speed counteracts the
fall. Hence the perihelion advance.

Yes, the perihelion is slightly later, but it
is also not as close to the Sun.

The journey between aphelion and perihelion takes 3801600
seconds, while the average anisotropy over that time is
8.66e-07m/sec^2. If Mercury was stationary in the Sun's frame
it would have been accelerated by the anisotropy over a distance
of t^2 * anisotropy / 2 = 6257787 meters. Taking the average
anisotropy isn't accurate, but it serves the purpose.

You cannot approach it that way Max. If the motion
were in a straight line it would work but not for
orbits. Your anisotropy produces a tiny change to
the direction as well as the speed and it is that
direction change that produces the change of
perihelion. Basically the inward path is less
curved so the planet turns back outwards at a
lesser distance and there is no way to address
that if you try to use that approach.

WHAT YOUR PROGRAM DEPICTS IS IMPOSSIBLE.

No Max, it isn't. You are basing your estimates on
crude approximations which would be OK if the motion
was in a straight line but don't work for orbital
mechanics. You have to go back to basics and
integrate the acceleration using a large number
of small steps. What my program shows is accurate
(to better than 1m for a sufficiently low value of
dt) GIVEN ... your equation for the acceleration.
The result may be surprising but it is correct.

George

"George Dishman" wrote in message
oups.com...
On 20 Jul, 13:50, "Max Keon" wrote:
"George Dishman" wrote in message
ups.com...
---

What I didn't notice is that the same advance was occurring even
using the "elastic" equation. The rate of advance didn't slow
even when the orbit became circular, when there was no radial
velocity, or anisotropy.

The advance of the orbit orientation appears to be nothing more
than a flywheel effect that is set in motion in the very first
fall or rise from the aphelion or perihelion. The advance is
therefore present in exactly the proportions given in my previous
post. But it has nothing to do with the true perihelion advance
for Mercury in its well established orbit. But that is still a
flywheel effect, whatever maintains it.

It isn't actually a flywheel effect, if you switch
off the anisotropy, the advance would also stop,
but that's not important.

According to your program, what you say is correct.

Elastic versus inelastic is another matter, leave
it for a later discussion.

There's nothing left to discuss here since the problems you
highlighted were due to my error, so we can now perhaps discuss
the merits of an elastic anisotropic gravity.

Technically, your equations are _not_ elastic. What
is happening with your version where the sign is
switched is that a small amount of energy is
actually gained from nowhere during the inward leg
and an identical amount is lost on the outward leg
so that Mercury returns to the original radius and
speed. It gives the appearance of being elastic but
in fact is not. Never mind though, that is another
matter.

I think we can lay to rest the idea of physical sign
manipulation because it's obviously wrong when using signed
velocity.

Regardless of how your program depicts the affect from the
anisotropy, Mercury is drawn less to the Sun as it heads down to
the perihelion.

OK, that's what I had been assuming previously.
Because you switched the sign in your latest
version, the pull was actually increased on the
inward leg instead of being decreased and that
would make the perihelion closer to the Sun
instead of farther away. Changing back to my
single equation corrects that.

When it arrives where the normal perihelion
should be, it cannot possibly have been drawn down to the normal
perihelion radius. That's how your program depicts it as well.

If you put the sign back, yes.

But where your program fails is in Mercury's designated orbital
speed when it arrives. Ask yourself how it got to be fast enough
to send Mercury back toward the aphelion when it was pulled to
the Sun at a lesser rate throughout the fall. It's not possible
is it.

Yes it is. The speed becomes high enough to send it
back out roughly a quarter of the way round the
orbit, it is the momentum that keeps it going
inwards. The program correctly integrates the
acceleration twice to find the path so what you
see is what will happen.

There seems to be enough evidence to show that it can't do as
you say.

Apart from that, your program has never before been called upon
to accommodate a gravity anisotropy, because there wasn't one.
You can only speculate that it will do as you claim, but you
really don't know at all.

It will continue falling until its speed counteracts the
fall. Hence the perihelion advance.

Yes, the perihelion is slightly later, but it
is also not as close to the Sun.

The journey between aphelion and perihelion takes 3801600
seconds, while the average anisotropy over that time is
8.66e-07m/sec^2. If Mercury was stationary in the Sun's frame
it would have been accelerated by the anisotropy over a distance
of t^2 * anisotropy / 2 = 6257787 meters. Taking the average
anisotropy isn't accurate, but it serves the purpose.

You cannot approach it that way Max.

Whether I can approach it that way or not, that's how far your
program has shifted Mercury off the normal trajectory in the
first half orbit cycle. And that enormous shift is repeated in
the opposite direction for the next half cycle.

If Mercury is shifted back and forth off course by millions of
meters in the inelastic fashion that you describe, there needs
to be some gigantic energy transfer occurring somewhere.
Where is it?

WHAT YOUR PROGRAM DEPICTS IS IMPOSSIBLE.

No Max, it isn't. You are basing your estimates on
crude approximations which would be OK if the motion
was in a straight line but don't work for orbital
mechanics. You have to go back to basics and
integrate the acceleration using a large number
of small steps. What my program shows is accurate
(to better than 1m for a sufficiently low value of
dt) GIVEN ... your equation for the acceleration.
The result may be surprising but it is correct.

It's not really surprising. And it's _not_ correct.

It's fairly obvious that any change in gravity has an immediate
consequence. i.e. If the pull of gravity on a mass in a
sustainable circular orbit was to suddenly double, centrifugal
force would not be affected until orbital speed has increased,
so the inward force would immediately be twice the restraining
force, and the fall would begin immediately, at exactly the
gravity rate increase.

In order to best describe the consequences of anomalous changes
in the gravity force I'm using a circular orbit analogy to reduce
confusion. Doing so is valid because, whether or not an orbit is
concentric, the orbit has a unique path for the specific
circumstances, and any change from that unique path must still
be governed by exactly the same laws.

A mass in a circular orbit around the Sun at a radius of 5.76e10
meters is drawn to the Sun by .04m/sec^2, while centrifugal force
is applying an outward acceleration of .04m/sec^2. Orbital speed
is 48000 m/sec. If the value of the average anisotropy of
8e-7m/sec^2 is added to the inward acceleration, the mass will
immediately accelerate to the Sun by 8e-7m/sec^2.

That part is fairly obvious.

What it apparently not so obvious is that the added acceleration
is quickly accounted for as the orbit rapidly changes to
compensate. The orbital speed of the mass only needs to increase
to 48000.48 m/sec to generate the required counteractory
centrifugal force.

This set of figures were generated using a simple program that
I've again attached to this post so that the figures can be
checked.

4283 seconds elapsed.
7.33763560000015 meter total fall.
48000.48069588798 m/sec orbital speed.
4.000080026973733D-02 m/sec^2 centrifugal force.

They were generated according to a^2 + b^2 = c^2, per diagram,
and don't take into account the reducing acceleration as orbit
velocity increases toward that required to stabilize the orbit.

(a) 48000 meters
____________________________
(b) l _ -
l_ - (c)

The accelerated leg (b) increases until (c) is 48000.48 meters.
The anisotropy is then counteracted.

But surely the trajectory is now ramped toward the Sun by 7.3 in
48000 meters, which is around 56 million meters over the half
orbit circumference? It makes no difference where it's pointing,
the trajectory reacts immediately to gravity changes.

If gravity was removed completely, the trajectory would
immediately follow a straight line path at a tangent to the
orbit. If the force of gravity changes in any way, the trajectory
will immediately adjust accordingly. There is never any delay.
Your smoothly changing planet momentum in an eccentric orbit has
nothing whatever to do with a gravity anisotropy.

If the added force is removed at 90 degrees further around in
the orbit from where it was applied, the acceleration to the Sun
is immediately reduced. Centrifugal force is now greater by
8e-7m/s^2, so the mass is immediately accelerated outward at that
rate. There's no doubt that the mass will find its way to the
original radius before its outward motion comes to a halt. Its
trajectory will again be following the same circular path as
before.

The next step is to subtract the 8e-7m/s^2 from the normal
gravity rate.

a^2 - b^2 = c^2 in this case.

(a) 48000 meters
____________________________
(b) l _ -
l_ - (c)

Then gravity is again returned to normal after 90 degrees of
travel. I'll leave it to you to sort out the consequences.

My reasoning at this address
http://members.optusnet.com.au/maxkeon/peri.html
may appear to be based on erroneous logic, but the results will
certainly be in the right ballpark.

I can justify using this analogy because it offers conclusive
proof that you are a long way further from the truth than I am.
Regardless of even the largest possible error margin, you are
millions of meters further from the truth than me.

-----

Max Keon


'------------------
DEFDBL A-Z
CLS
g = .04 ' Gravity per Newton.
v = 48000#
vv = v ' vv holds the original orbital speed.

an = .0000008# ' Average anisotropy.
anset = an ' anset is used to reset an after
' the first second has elapsed.

an = an / 2 ' The fall distance is halved for the
' first second.

aa: LOCATE 4, 1
f = f + 1
an2 = an2 + an
an3 = an3 + an2
PRINT f; "seconds elapsed. "
PRINT an3; "meter total fall. "

'PRINT f ^ 2 * an / 2; "fall distance check "
'PRINT " per t^2 * anisotropy / 2. "

s = (v ^ 2# + an3 ^ 2#) ^ .5#
PRINT s; "m/sec orbital speed. "
v = s
cf = v ^ 2# / vv ^ 2# * g
PRINT cf; "m/sec^2 centrifugal force. "
'DO: s$ = INKEY$: LOOP UNTIL s$ ""
IF s$ = CHR$(27) THEN END
an = anset

IF v 48000.48 THEN END

GOTO aa

On 26 Jul, 13:27, "Max Keon" wrote:
"George Dishman" wrote in message
oups.com...
On 20 Jul, 13:50, "Max Keon" wrote:
"George Dishman" wrote in message
roups.com...
....
The advance of the orbit orientation appears to be nothing more
than a flywheel effect that is set in motion in the very first
fall or rise from the aphelion or perihelion. The advance is
therefore present in exactly the proportions given in my previous
post. But it has nothing to do with the true perihelion advance
for Mercury in its well established orbit. But that is still a
flywheel effect, whatever maintains it.
It isn't actually a flywheel effect, if you switch
off the anisotropy, the advance would also stop,
but that's not important.

According to your program, what you say is correct.

You say the same below

"It's fairly obvious that any change in gravity has
an immediate consequence."

....
I think we can lay to rest the idea of physical sign
manipulation because it's obviously wrong when using signed
velocity.

I think so too. The thing to bear in mind is that
velocity by its nature is always signed because it
has to tell you direction so motion to the left at
some speed must be distinguished from motion to the
right at the same speed and the sign does that for
you. If you take the magnitude of the velocity by
finding sqrt(v_x^2 + v_y^2) for example in two
dimensions, you get an always-positive result (from
the square root) but you lose the direction
information so the result is no longer a velocity,
it is a speed.

....
But where your program fails is in Mercury's designated orbital
speed when it arrives. Ask yourself how it got to be fast enough
to send Mercury back toward the aphelion when it was pulled to
the Sun at a lesser rate throughout the fall. It's not possible
is it.
Yes it is. The speed becomes high enough to send it
back out roughly a quarter of the way round the
orbit, it is the momentum that keeps it going
inwards. The program correctly integrates the
acceleration twice to find the path so what you
see is what will happen.

There seems to be enough evidence to show that it can't do as
you say.

I think you mean it is clear that the orbit of
Mercury in reality is not reducing in eccentricity
as the program predicts. That is certainly true.

Apart from that, your program has never before been called upon
to accommodate a gravity anisotropy, because there wasn't one.
You can only speculate that it will do as you claim, but you
really don't know at all.

Yes I do because acceleration is DEFINED as the
rate of change of velocity as I have pointed out
repeatedly. I _know_ that integrating your equation
twice must give a valid path, so if the path does
not reflect the actual motion of the planet, it is
because your equation is wrong, not my program.

The journey between aphelion and perihelion takes 3801600
seconds, while the average anisotropy over that time is
8.66e-07m/sec^2. If Mercury was stationary in the Sun's frame
it would have been accelerated by the anisotropy over a distance
of t^2 * anisotropy / 2 = 6257787 meters. Taking the average
anisotropy isn't accurate, but it serves the purpose.
You cannot approach it that way Max.

Whether I can approach it that way or not, that's how far your
program has shifted Mercury off the normal trajectory in the
first half orbit cycle.

No, going back to my earlier post, the perihelion
is increased by 2010939 m , not 6257787 m.

And that enormous shift is repeated in
the opposite direction for the next half cycle.

Again your figure is not correct, after one full
orbit the aphelion is reduced by 9262870 m.

If Mercury is shifted back and forth off course by millions of
meters in the inelastic fashion that you describe, there needs
to be some gigantic energy transfer occurring somewhere.
Where is it?

I found the graphic I was looking for. Although it
refers to Bohr atom orbits, it is still helpful:

http://en.wikipedia.org/wiki/Image:S...d_ellipses.svg

All those ellipses have the same energy. Your theory
bassically says if a planet starts in the red orbit,
it will slowly decay through orange, green and black
until it asymptotically approaches a circular orbit.

WHAT YOUR PROGRAM DEPICTS IS IMPOSSIBLE.
No Max, it isn't. You are basing your estimates on
crude approximations which would be OK if the motion
was in a straight line but don't work for orbital
mechanics. You have to go back to basics and
integrate the acceleration using a large number
of small steps. What my program shows is accurate
(to better than 1m for a sufficiently low value of
dt) GIVEN ... your equation for the acceleration.
The result may be surprising but it is correct.

It's not really surprising. And it's _not_ correct.

Yes it is, you have defined the equation for the
acceleration, I have merely integrated that to find
the path. My contribution is purely mathematical
and I have checked that the numerical techniques
used eliminate the first order errors.

It's fairly obvious that any change in gravity has an immediate
consequence. i.e. If the pull of gravity on a mass in a
sustainable circular orbit was to suddenly double, centrifugal
force would not be affected until orbital speed has increased,
so the inward force would immediately be twice the restraining
force, and the fall would begin immediately, at exactly the
gravity rate increase.

Yes, my program applies acceleration changes at the
time they happen and velocity follows on due to the
integration. The same happens for the location as
the integral of the velocity of course.

In order to best describe the consequences of anomalous changes
in the gravity force I'm using a circular orbit analogy to reduce
confusion. Doing so is valid because, whether or not an orbit is
concentric, the orbit has a unique path for the specific
circumstances, and any change from that unique path must still
be governed by exactly the same laws.

The law is that velocity is the integral of acceleration,
in fact that's a definition, but it is _not_ valid to use
a circular orbit as an analogy because the speed varies,
and you aen't using the circular orbit correctly either
because you ignore the tangential component.

My program correctly integrates the acceleration given by
your equation, any discrepancy between the path it gives
and reality is a result of your equation failing to
describe the actual gravitational effects.

A mass in a circular orbit around the Sun at a radius of 5.76e10
meters is drawn to the Sun by .04m/sec^2, while centrifugal force
is applying an outward acceleration of .04m/sec^2. Orbital speed
is 48000 m/sec. If the value of the average anisotropy of
8e-7m/sec^2 is added to the inward acceleration, the mass will
immediately accelerate to the Sun by 8e-7m/sec^2.

In any second the radial speed changes by the average
value of the acceleration during that particular second,
I hope you didn't mean the average over hhalf an orbit.
Anyway if the average value in the second is 8e-7m/s^2
then the velocity changes by 8e-7m/s TOWARDS THE SUN.
You then have to add the initial speed and that change
taking account of the direction of both in order to find
the new speed at the end of the second. That is exactly
what my program does.

That part is fairly obvious.

What it apparently not so obvious is that the added acceleration
is quickly accounted for as the orbit rapidly changes to
compensate.

What is not accounted for in that approach is that the
direction of the motion is changed. That is what causes
the overall change as I have said to you since we first
discussed this, and as long as you ignore that change,
you will not get valid results. Your code does not take
that into account.

George

"George Dishman" wrote in message
oups.com...
On 26 Jul, 13:27, "Max Keon" wrote:
"George Dishman" wrote in message
oups.com...
On 20 Jul, 13:50, "Max Keon" wrote:
---

One thing I didn't have time to address in my previous post is
your reply to this next paragraph. I don't think you actually
believe what you wrote though.

But where your program fails is in Mercury's designated orbital
speed when it arrives. Ask yourself how it got to be fast enough
to send Mercury back toward the aphelion when it was pulled to
the Sun at a lesser rate throughout the fall. It's not possible
is it.

Yes it is. The speed becomes high enough to send it
back out roughly a quarter of the way round the
orbit, it is the momentum that keeps it going
inwards.

Think about that George. Mercury was pulled to the Sun at a
lesser rate throughout the entire journey. How can it possibly
arrive at a larger radius perihelion and have a higher orbital
speed than normal? It's not possible.
----------------

The journey between aphelion and perihelion takes 3801600
seconds, while the average anisotropy over that time is
8.66e-07m/sec^2. If Mercury was stationary in the Sun's frame
it would have been accelerated by the anisotropy over a distance
of t^2 * anisotropy / 2 = 6257787 meters. Taking the average
anisotropy isn't accurate, but it serves the purpose.

You cannot approach it that way Max.

Whether I can approach it that way or not, that's how far your
program has shifted Mercury off the normal trajectory in the
first half orbit cycle.

No, going back to my earlier post, the perihelion
is increased by 2010939 m , not 6257787 m.

Within the first few cycles, from perihelion to next perihelion
is twice that amount.

And that enormous shift is repeated in
the opposite direction for the next half cycle.

Again your figure is not correct, after one full
orbit the aphelion is reduced by 9262870 m.

That's correct from aphelion to next aphelion. The average
eccentricity decay per orbit is initially somewhere around
6257787 meters per orbit. That's all according to your program
of course.

If Mercury is shifted back and forth off course by millions of
meters in the inelastic fashion that you describe, there needs
to be some gigantic energy transfer occurring somewhere.
Where is it?

I found the graphic I was looking for. Although it
refers to Bohr atom orbits, it is still helpful:

http://en.wikipedia.org/wiki/Image:S...d_ellipses.svg

All those ellipses have the same energy. Your theory
bassically says if a planet starts in the red orbit,
it will slowly decay through orange, green and black
until it asymptotically approaches a circular orbit.

My theory says no such thing. The problem is only due to your
misinterpretation of basic principles.

WHAT YOUR PROGRAM DEPICTS IS IMPOSSIBLE.

No Max, it isn't. You are basing your estimates on
crude approximations which would be OK if the motion
was in a straight line but don't work for orbital
mechanics. You have to go back to basics and
integrate the acceleration using a large number
of small steps. What my program shows is accurate
(to better than 1m for a sufficiently low value of
dt) GIVEN ... your equation for the acceleration.
The result may be surprising but it is correct.

It's not really surprising. And it's _not_ correct.

Yes it is, you have defined the equation for the
acceleration, I have merely integrated that to find
the path. My contribution is purely mathematical
and I have checked that the numerical techniques
used eliminate the first order errors.

And you are still in error by millions of meters.

It's fairly obvious that any change in gravity has an immediate
consequence. i.e. If the pull of gravity on a mass in a
sustainable circular orbit was to suddenly double, centrifugal
force would not be affected until orbital speed has increased,
so the inward force would immediately be twice the restraining
force, and the fall would begin immediately, at exactly the
gravity rate increase.

Yes, my program applies acceleration changes at the
time they happen and velocity follows on due to the
integration. The same happens for the location as
the integral of the velocity of course.

In order to best describe the consequences of anomalous changes
in the gravity force I'm using a circular orbit analogy to reduce
confusion. Doing so is valid because, whether or not an orbit is
concentric, the orbit has a unique path for the specific
circumstances, and any change from that unique path must still
be governed by exactly the same laws.

The law is that velocity is the integral of acceleration,
in fact that's a definition, but it is _not_ valid to use
a circular orbit as an analogy because the speed varies,
and you aen't using the circular orbit correctly either
because you ignore the tangential component.

The purpose of using a circular orbit and changing the pull of
gravity by a set amount is to highlight your error. The orbit is
not affected in the way you think it is.

Since you've missed the point completely, I guess I'll have to
do it all again.

In a concentric orbit, the pointing direction of the orbiting
mass is along the line of the circular orbit. In a stable
eccentric orbit, the true pointing direction is still parallel
with the circular orbit path, even though it has a sideways
momentum that will carry it toward and away from the gravity
source in a cyclic motion. It's a circular orbit that has been
pushed off course in the plane perpendicular to the line of
motion.

On the journey inward, orbital speed increases as it falls and
orbit radius shrinks. Since centrifugal force is proportional to
radius and to the square of orbital speed, the end result is that
the mass is simply oscillating back and forth in the middle of an
invisible spring located perpendicular to the direction of
motion.

None of that has anything to do with an anomalous change in the
pull of gravity.

If a force which is acting in the same direction as gravity is
applied to a mass in a stable concentric orbit, the mass will
immediately accelerate inward. Your program assumes that the
acceleration will continue on until the added force is removed.
That is the root of your error. The mass will accelerate inward,
only while centrifugal force remains less than the inward force.
When the balance is restored, the orbit is again stable and the
true pointing direction is again parallel with the circular orbit
path, but inward motion will continue on until it reaches the
elastic limit that's developing against the increasing
centrifugal force, from which it will simply spring back out
again. That will happen with the added force still in place.

When the added force is removed, centrifugal force is greater
than the inward force by exactly what was removed, so the
process is reversed until centrifugal force has reduced to align
with the lesser inward force. Apart from an inherent oscillation,
it will be right back where it started from.

Applying the added force as a sinewave which encompasses the
entire orbit sets up an oscillation cycle to match. But it's
certainly not orbit cycle time dependent. The reaction to a
shorter duration force of the same magnitude would have similar
consequences.

-----

Max Keon

On 29 Jul, 13:40, "Max Keon" wrote:
"George Dishman" wrote in message
oups.com...
On 26 Jul, 13:27, "Max Keon" wrote:
"George Dishman" wrote in message
groups.com...
On 20 Jul, 13:50, "Max Keon" wrote:

---

One thing I didn't have time to address in my previous post is
your reply to this next paragraph. I don't think you actually
believe what you wrote though.

But where your program fails is in Mercury's designated orbital
speed when it arrives. Ask yourself how it got to be fast enough
to send Mercury back toward the aphelion when it was pulled to
the Sun at a lesser rate throughout the fall. It's not possible
is it.

Yes it is. The speed becomes high enough to send it
back out roughly a quarter of the way round the
orbit, it is the momentum that keeps it going
inwards.

Think about that George. Mercury was pulled to the Sun at a
lesser rate throughout the entire journey. How can it possibly
arrive at a larger radius perihelion and have a higher orbital
speed than normal? It's not possible.

You misundrstand what I said. Compare a circular
orbit with a slightly elliptical one of the same
energy. The elliptical path is inside the circular
path for about half the orbit. The centrifugal
force becomes sufficient to throw the planet out
roughly where the paths cross but momentum keeps
the planet moving inward to perihelion in the
elliptical case. You say the same yourself later,
I just expressed it from a different point of view.

The journey between aphelion and perihelion takes 3801600
seconds, while the average anisotropy over that time is
8.66e-07m/sec^2. If Mercury was stationary in the Sun's frame
it would have been accelerated by the anisotropy over a distance
of t^2 * anisotropy / 2 = 6257787 meters. Taking the average
anisotropy isn't accurate, but it serves the purpose.

You cannot approach it that way Max.

Whether I can approach it that way or not, that's how far your
program has shifted Mercury off the normal trajectory in the
first half orbit cycle.

No, going back to my earlier post, the perihelion
is increased by 2010939 m , not 6257787 m.

Within the first few cycles, from perihelion to next perihelion
is twice that amount.

You gave the distance of 6257787 meters for
a time of 3801600 seconds which is just half
an orbit. In that time, the effect of the
anisotropy is to increase the perihelion by
2010939m compared to the same starting
conditions without the anisotropy.

And that enormous shift is repeated in
the opposite direction for the next half cycle.

Again your figure is not correct, after one full
orbit the aphelion is reduced by 9262870 m.

That's correct from aphelion to next aphelion. The average
eccentricity decay per orbit is initially somewhere around
6257787 meters per orbit. That's all according to your program
of course.

Yes, that is all according to your equation for
the anisotropy.

If Mercury is shifted back and forth off course by millions of
meters in the inelastic fashion that you describe, there needs
to be some gigantic energy transfer occurring somewhere.
Where is it?

I found the graphic I was looking for. Although it
refers to Bohr atom orbits, it is still helpful:

http://en.wikipedia.org/wiki/Image:S...d_ellipses.svg

All those ellipses have the same energy. Your theory
bassically says if a planet starts in the red orbit,
it will slowly decay through orange, green and black
until it asymptotically approaches a circular orbit.

My theory says no such thing.

Sorry Max, that's exactly the consequence of your
equation. The shapes are exaggerated of course
but suppose Mercury started at the aphelion of
the orange ellipse. The effect of the anisotropy
on the inward leg takes it on a path that goes
to the perihelion of the green path (in addition
there would be a small advance of the perihelion).
On the outward leg it goes smoothly from there to
the aphelion of the blue curve, then to the aphelion
of the black curve and so on. The eccentricity is
reducing all the time but the energy isn't changing
significantly.

The problem is only due to your
misinterpretation of basic principles.

The _only_ principle involved is that velocity
is the integral of acceleration. _Your_ problem
is your lack of familiarity with calculus.

WHAT YOUR PROGRAM DEPICTS IS IMPOSSIBLE.

No Max, it isn't. You are basing your estimates on
crude approximations which would be OK if the motion
was in a straight line but don't work for orbital
mechanics. You have to go back to basics and
integrate the acceleration using a large number
of small steps. What my program shows is accurate
(to better than 1m for a sufficiently low value of
dt) GIVEN ... your equation for the acceleration.
The result may be surprising but it is correct.

It's not really surprising. And it's _not_ correct.

Yes it is, you have defined the equation for the
acceleration, I have merely integrated that to find
the path. My contribution is purely mathematical
and I have checked that the numerical techniques
used eliminate the first order errors.

And you are still in error by millions of meters.

Nope, less than 1m for small but practical values
of dt.

....
In order to best describe the consequences of anomalous changes
in the gravity force I'm using a circular orbit analogy to reduce
confusion. Doing so is valid because, whether or not an orbit is
concentric, the orbit has a unique path for the specific
circumstances, and any change from that unique path must still
be governed by exactly the same laws.

The law is that velocity is the integral of acceleration,
in fact that's a definition, but it is _not_ valid to use
a circular orbit as an analogy because the speed varies,
and you aen't using the circular orbit correctly either
because you ignore the tangential component.

The purpose of using a circular orbit and changing the pull of
gravity by a set amount is to highlight your error. The orbit is
not affected in the way you think it is.

There is no error, velocity is the integral of
acceleration and that is how it is calculated.

Since you've missed the point completely, I guess I'll have to
do it all again.

In a concentric orbit, the pointing direction of the orbiting
mass is along the line of the circular orbit. In a stable
eccentric orbit, the true pointing direction is still parallel
with the circular orbit path, ...

Nonsense because ..

.. even though it has a sideways
momentum that will carry it toward and away from the gravity
source in a cyclic motion. It's a circular orbit that has been
pushed off course in the plane perpendicular to the line of
motion.

Yes, it has been "pushed off course" as you
say which of course changes the direction.
However, what you write next is more
reasonable.

On the journey inward, orbital speed increases as it falls and
orbit radius shrinks. Since centrifugal force is proportional to
radius and to the square of orbital speed, the end result is that
the mass is simply oscillating back and forth in the middle of an
invisible spring located perpendicular to the direction of
motion.

None of that has anything to do with an anomalous change in the
pull of gravity.

Right, and that's a good way of looking
at how it works. If you were moving in a
circular orbit following Mercury with the
Sun always off to your left, you would see
the planet swinging to the left and right
of your path like a pendulum.

Your anisotropy then applies a force to the
planet other than when it is at aphelion and
perihelion where the radial velocity is zero.
During the inward leg, the planet moves from
right to left but the anisotropy pushes from
left to right. It is a small force so the
effect is slight but it reduces the length of
the swing just as pushing against a pendulum
would reduce its swing.

On the outward leg, the planet moves from
left to right but the anisotropy pushes from
right to left. It again reduces the length of
the swing so slowly the swing is damped out
until you are left with the planet in a
circular orbit.

If a force which is acting in the same direction as gravity is
applied to a mass in a stable concentric orbit, the mass will
immediately accelerate inward. Your program assumes that the
acceleration will continue on until the added force is removed.
That is the root of your error.

That is not an error, your acceleration _adds_
to that produced by the centrifugal force and
that of gravity at all times.

The mass will accelerate inward,
only while centrifugal force remains less than the inward force.

To be exact, only while the sum of the
centrifugal force and the anisotropic force
remains less than the inward gravitational
force. Yes, but that happens roughly half
way between aphelion and perihelion.
Thereafter it is accelerating outwards even
though it is moving inwards due to its
momentum. The effect of the outward
accleleration is to slowly reduce the
inward speed to zero at the new perihelion.

When the balance is restored, the orbit is again stable and the
true pointing direction is again parallel with the circular orbit
path, but inward motion will continue ...

Sorry, that's not possible, if the direction is
parallel to a circular orbit, i.e. perpendicular
to the line between the planet and the Sun, then
there is no inward or outward motion. From that
point on, it accelerates outward because the
centrifugal force has been greater than the
gravitational for roughly the last quarter of
the orbit (there is no anisotropic force at that
point of course since there is no radial velocity)
and will remain greater for roughly the next
quarter of the orbit too.

George

"George Dishman" wrote in message
ups.com...
On 29 Jul, 13:40, "Max Keon" wrote:
"George Dishman" wrote in message
oups.com...
On 26 Jul, 13:27, "Max Keon" wrote:
---

If Mercury is shifted back and forth off course by millions of
meters in the inelastic fashion that you describe, there needs
to be some gigantic energy transfer occurring somewhere.
Where is it?

I found the graphic I was looking for. Although it
refers to Bohr atom orbits, it is still helpful:

http://en.wikipedia.org/wiki/Image:S...d_ellipses.svg

All those ellipses have the same energy. Your theory
bassically says if a planet starts in the red orbit,
it will slowly decay through orange, green and black
until it asymptotically approaches a circular orbit.

My theory says no such thing.

Sorry Max, that's exactly the consequence of your
equation. The shapes are exaggerated of course
but suppose Mercury started at the aphelion of
the orange ellipse. The effect of the anisotropy
on the inward leg takes it on a path that goes
to the perihelion of the green path (in addition
there would be a small advance of the perihelion).
On the outward leg it goes smoothly from there to
the aphelion of the blue curve, then to the aphelion
of the black curve and so on. The eccentricity is
reducing all the time but the energy isn't changing
significantly.
---

In a concentric orbit, the pointing direction of the orbiting
mass is along the line of the circular orbit. In a stable
eccentric orbit, the true pointing direction is still parallel
with the circular orbit path, ...

Nonsense because ..

.. even though it has a sideways
momentum that will carry it toward and away from the gravity
source in a cyclic motion. It's a circular orbit that has been
pushed off course in the plane perpendicular to the line of
motion.

Yes, it has been "pushed off course" as you
say which of course changes the direction.
However, what you write next is more
reasonable.

On the journey inward, orbital speed increases as it falls and
orbit radius shrinks. Since centrifugal force is proportional to
radius and to the square of orbital speed, the end result is that
the mass is simply oscillating back and forth in the middle of an
invisible spring located perpendicular to the direction of
motion.

None of that has anything to do with an anomalous change in the
pull of gravity.

Right, and that's a good way of looking
at how it works.

It certainly is George. But you still don't understand the
consequences of an anomalous force being applied to a naturally
stable orbit at all.

What probably hasn't helped is that the previous program I
posted was wrong because I failed to notice that the orbital
speed increase was already being compounded in the equation
v = s. I was compounding it twice over. The immediate fall
distance resulting from adding .0000008 to the .04m/sec^2
normal gravity rate was fairly obviously going to be more than
the 7.33 meters generated by the program.

The attached program plots the path of a mass in a circular
orbit (plotted in a linear fashion) after an anomalous force is
suddenly applied. If you run the program you will notice that
centrifugal force has increased to twice the anomalous force
before the fall is halted. That's exactly what should be
expected.

This equation s = (v^2 + (ana^2 * dt)^ 2)^.5 extracted from
the program, is used as a means of determining orbital speed
increase according to a^2 + b^2 = c^2. v is the previous
orbital speed, representing (a), ana is the accelerated fall
rate for any given second (b) while dt determines the chunk size
in seconds. The square root of the final result is of course the
triangle hypotenuse, and that holds the orbital speed increase.

I attempted using signed fall direction in the same manner as
signed velocity, but I encountered a problem that scuttled the
whole idea. The problem was in the above equation, in that
orbital speed continues to increase when the value stored in
'ana' becomes negative. I had little choice but to go back to
physical sign manipulation. That doesn't make the result wrong
either, it makes it right.

This is the result from running the program, along with the
figures generated for the final plot point.
http://members.optusnet.com.au/maxkeon/wave.jpg
Or for the whole story;
http://optusnet.com.au/maxkeon/proven2.html

The program in this format is a necessary precursor to fitting
it to a program which will correctly accommodate a gravity
anisotropy because it demonstrates very clearly the consequences
of an abrupt gravity change. While the anomalous force remains
active, if the oscillations can be elastically diminished to zero
through some external means, the mass will come to rest in an
orbit that has reduced in radius by half the depth of the
oscillation, and there it will stay. Removing the force sets the
reverse process in motion, until the mass returns again to the
original orbit. That process simulates the rise from perihelion
to aphelion, regardless of how long it takes.

The negative of that process simulates the fall from aphelion
to perihelion, once again, regardless of how long it takes.

Notice that the process is entirely elastic?

The consequences of the anisotropy will be far less obvious
because the result from an anomalous gravity change that follows
a natural sine wave will generate smoothly flowing changes that
follow a single sine wave shape for the entire orbit. But that
will overshoot the previous perihelion at the end of each cycle
because the fall always lags behind the centripital-centrifugal
force imbalance that drives it. The question is, by how much.

The slightest change to gravity does have an immediate
consequence, as you have been saying all along. But that
consequence is far removed from what you perceived.

-----

Max Keon


'-----------------
' The program plots the natural oscillation of a mass that was
' in a stable circular orbit prior to the application of a sudden
' anomalous change in the pull of gravity. The program ends after
' a complete orbit cycle.

' The same oscillation would not be set up by a gravity
' anisotropy because it's applied in a sine wave fashion.
' The fall distance would follow the same sine wave but would
' always lag behind.

' The inward moving mass overshoots the balance point between
' centrifugal force and the inward force by twice the current
' fall distance. Centrifugal force needs to be double the
' anomalous inward force that drives it before it has gained
' the required force to halt the moving mass and send it back
' from whence it came, in an entirely elastic operation.

DEFDBL A-Z
SCREEN 12
CLS : COLOR 7
LINE (200, 320)-(200, 450), 8
r = 58000000000# ' Orbit radius.
g = .04# ' Gravity per Newton.
v = 48000#
vv = v ' vv holds the original orbital speed.

an = .0000008# ' Anomalous gravity change (m/sec^2).
' -.0000008# gives the negative result.

dt = 100 ' Set dt as required.

aa:
f = f + 1 ' Holds elapsed time.
ana = ana + dt * cfx ' Stores the current fall rate.
' cfx is later defined.
anb = anb + dt * ana ' Stores the total fall distance.

'-------This physical sign manipulation is necessary because the
' result of ana^2 is always positive and orbital speed continues
' to increase regardless of the true value stored in ana. If
' there's any doubt, remove the switch on the next line.
' LOCATE 1, 1: PRINT (ana ^ 2 * dt) ^ .5: PRINT ana

IF anc = anb THEN s = (v ^ 2# + -(ana ^ 2 * dt)) ^ .5#
IF anc anb THEN s = (v ^ 2# + (ana ^ 2 * dt)) ^ .5#
anc = anb
'-------------------

v = s
' v holds the updated orbital speed for the next cycle.

cf = v ^ 2# / vv ^ 2# * g ' cf is centrifgual force.

cfx = g + an - cf ' Compares the inward force including
' the anomalous acceleration, with the current centrifugal force
' value. The result gives the true acceleration rate, which is
' added to ana, above.

CIRCLE (10 + f * dt / 16000, 280 + anb / 4000), 0, 14
' 16000 and 4000 are multipliers for the graphics.

IF f * dt 7603200 THEN GOSUB ab: END
fa = fa + 1: IF fa * dt 100000 THEN GOSUB ab: fa = 0

GOTO aa

ab: LOCATE 4, 1
PRINT f * dt; "seconds elapsed time. "
PRINT ana; "meter fall per"; dt; "second batch. "
PRINT anb; "meter total fall so far. "
PRINT s; "m/sec orbital speed. "
PRINT cf; "m/sec^2 centrifugal force. "
LOCATE 24, 18
PRINT r - anb; "radius. "
RETURN

I wrote:
This is the result from running the program, along with the
figures generated for the final plot point.
http://members.optusnet.com.au/maxkeon/wave.jpg
Or for the whole story;
http://optusnet.com.au/maxkeon/proven2.html

The link address should be
http://members.optusnet.com.au/maxkeon/proven2.html

On Aug 2, 7:02 pm, "Max Keon" wrote:
I wrote:
This is the result from running the program, along with the
figures generated for the final plot point.
http://members.optusnet.com.au/maxkeon/wave.jpg
Or for the whole story;
http://optusnet.com.au/maxkeon/proven2.html

The link address should be
http://members.optusnet.com.au/maxkeon/proven2.html

You do realize that you are completely wasting everyone's, including
your own, time right?