Anisotropy and Mercury (2)
Max Keon
> news:46595a42$0$2869$afc3...@news.optusnet.com.au...
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>> news:f32dve$64k$1...@news.freedom2surf.net...
Forgive me for starting a new thread, but the old one has become
fairly redundant due to the huge bulk of posts that seem to serve
no purpose other than to bury the thread under a layer of wader
depth bullshit.
> <much snipped as there is a major probleme here>
>>> That means that any time, the acceleration adds an
>>> amount to the velocity which is equal to the product
>>> of the time and the acceleration. It doesn't add or
>>> subtract from the radius, I don't know where you got
>>> that idea.
>>>
>>> For example, if an acceleration of 2m/s^2 acts for
>>> 50s then the velocity will change by 100m/s.
>>
>> I'm inclined to think you actually believe that George, which is
>> a bit disconcerting.
> I hadn't realised you had a problem with that. Of
> course it is fundamental, the word acceleration
> is defined as the rate of change of velocity and
> is unarguable and the other equations you have
> tried to use are all derived form this under
> various conditions.
>> I'll snip the rest and concentrate on this major error, which is
>> obviously the root of all of the confusion.
>>
>> What you say is true for Mercury while in its stable eccentric
>> orbit around the Sun, so long as the anisotropy isn't included.
> What I said above is true for all objects changing
> speed for any reason whatsoever under any circumstances.
Certainly _not_ under any circumstances George. Your calculations
apply for any normal trajectory taken by an object naturally
moving to or from a gravity source. The curved trajectory forms
a natural part of the orbit shape, regardless of whether or not
a complete orbit will eventually form. The only reason for it not
forming is that there is other matter in the universe. But in all
cases, the average radius per orbit, or potential orbit, remains
unchanged.
You of course agree that an object in a sustainable concentric
orbit around the Sun will not shorten the radius between it and
the Sun? You also agree that the radius will shorten at the full
gravity rate only if its orbital speed is zero. AND ONLY THEN?
The same of course applies for an eccentric orbit.
Do you reject any of that so far?
Centrifigal forces change at the rate of orbital speed squared,
so if Mercury was traveling at an average of 24000 m/sec instead
of the average 48000 m/sec, it would be restrained from falling
at the full rate by 24000^2 / 48000^2 = .25 of the .0395 m/sec^2
gravity rate. The fall rate is .25 * .0395 = 9.875e-3 m/sec^2.
I hope you can see that now.
> If you weren't aware of that then obviously nothing
> else I said will have made any sense to you so I can
> see why the conversation has been so difficult.
>> The acceleration variations throughout Mercury's orbit cycle are
>> not really changing anything. Mercury is not permanently shifting
>> from its stable orbit path, and orbit velocity doesn't vary from
>> what is an integral part of the stable orbit structure.
> Sorry Max, that isn't true. You said the anisotropy
> causes an extra acceleration, it acts to displace
> Mercury and since it is not directly along the path
> but rather points towards the Sun, it changes the
> direction as well as the speed.
>> You are claiming that the anisotropy will cause Mercury's orbital
>> speed to automatically change the moment that it's applied, which
>> is impossible.
> It is what you have been telling me. "Acceleration" is
> the rate at which speed changes and normally is given by
>
> a = -GM / r^2
>
> in Newtonian gravitation. You said that was changed to
>
> a = -GM / r^2 * (1 + v/c)
>
> where v is the radial component of the velocity. That is
> what my program models and you have seen the consequences.
>> For example, if the pull of gravity is doubled,
>> Mercury's orbital speed doesn't magically increase to comply with
>> the change.
> Right, but it's _acceleration_ changes immediately
> and the speed is then the integral of that. The
> speed at any instant is changing by the value of
> the acceleration _at_that_time_.
There's no point in replying to the rest of your post until
this has all been cleared up. You are repeating the same old
mistakes over and over again, again.
The gravity force is pointing directly at the Sun, so unless
Mercury falls closer to the Sun on average its orbital speed
cannot be increased. Adding a new force does not change the pull
direction, so orbital speed cannot change from the normal unless
the average radial length changes. Can you now see that?
-----
Max Keon
Max Keon
Koobee Wublee
> [...]
>
> Centrifigal forces change at the rate of orbital speed squared,
> so if Mercury was traveling at an average of 24000 m/sec instead
> of the average 48000 m/sec, it would be restrained from falling
> at the full rate by 24000^2 / 48000^2 = .25 of the .0395 m/sec^2
> gravity rate. The fall rate is .25 * .0395 = 9.875e-3 m/sec^2.
>
> [...]
>
> The gravity force is pointing directly at the Sun, so unless
> Mercury falls closer to the Sun on average its orbital speed
> cannot be increased. Adding a new force does not change the pull
> direction, so orbital speed cannot change from the normal unless
> the average radial length changes. Can you now see that?
Have you asked yourself why the centrifugal force is (m v^2 / r)?
In spacetime with the Schwarzschild metric, the Euler-Lagrange
equation associated with r can simply be derived as the following
where the orbital motion is confined to the equatorial plane of the
gravitating body.
d^2r/ds^2 - (1 - 3 U) r (dO/ds)^2 = - U / r
Where
** O = Longitude
** s = Spacetime
** U = G M / c^2 / r
Say the orbit is circular. That mean the following.
d^2r/ds^2 = 0
We have the following.
(1 - 3 U) r (dO/ds)^2 = U / r
Or
(1 - 3 U) r^2 (dO/ds)^2 = U
Or
v^2 / c^2 = U / (1 - 3 U)
Where (through BS but another chapter of discussion)
** v / c = r dO/ds
It actually takes a little bit higher speed than Newtonian result to
complete an orbit.
Thus back to the Euler-Lagrange equation associated with r, we must
have the centrifugal force identified as the following.
m c^2 (1 - 3 U) r (dO/ds)^2
The curvature in Schwarzschild spacetime actually causes a weaker
centrifugal force. In order to keep an equilibrium orbit, the speed
must be a little higher than the Newtonian result. If not, it will
fly spirally away.
Thus, the advance of Mercury's perihelion must have two components
identified as follows.
** Orbital geometric anomaly (dwelled on by physicists)
** Orbital speed anomaly (eluded physicists <sigh>)
GR prediction based on orbital geometric anomaly alone somewhat
satisfies the observation. However, including the orbital speed
anomaly, it falls far short. This of course is based on the
speculation that the geodesic motion follows the path of maximum
accumulated spacetime. If the model of geodesics is to follow the
path of least accumulated time or the principle of least time, you
will find the orbital geometric anomaly describes almost the result of
observation while the orbital speed anomaly is null. The net result
fits the observation almost perfectly. But don't celebrate the
achievement of GR yet, because under this model of geodesics it
predicts photons would travel beyond the speed of light due to the
Euler-Lagrange equation associated with r. Dealing with second order
effects, everything must fit in place before betting on a new
hypothesis. GR does not.
George Dishman
> > "Max Keon" <maxk...@optusnet.com.au> wrote in message
> >news:46595a42$0$2869$afc3...@news.optusnet.com.au...
> >> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> >>news:f32dve$64k$1...@news.freedom2surf.net...
>
> Forgive me for starting a new thread, but the old one has become
> fairly redundant due to the huge bulk of posts that seem to serve
> no purpose other than to bury the thread under a layer of wader
> depth bullshit.
I totally agree.
> > <much snipped as there is a major probleme here>
> >>> That means that any time, the acceleration adds an
> >>> amount to the velocity which is equal to the product
> >>> of the time and the acceleration. It doesn't add or
> >>> subtract from the radius, I don't know where you got
> >>> that idea.
> >>>
> >>> For example, if an acceleration of 2m/s^2 acts for
> >>> 50s then the velocity will change by 100m/s.
>
> >> I'm inclined to think you actually believe that George, which is
> >> a bit disconcerting.
> >
> > I hadn't realised you had a problem with that. Of
> > course it is fundamental, the word acceleration
> > is defined as the rate of change of velocity and
> > is unarguable and the other equations you have
> > tried to use are all derived form this under
> > various conditions.
> >
> >> I'll snip the rest and concentrate on this major error, which is
> >> obviously the root of all of the confusion.
> >>
> >> What you say is true for Mercury while in its stable eccentric
> >> orbit around the Sun, so long as the anisotropy isn't included.
> >
> > What I said above is true for all objects changing
> > speed for any reason whatsoever under any circumstances.
>
> Certainly _not_ under any circumstances George.
Yes, under _any_ circumstances Max. The word
"acceleration" is _defined_ as rate of change
of velocity so in a short time dt the velocity
will change from an initial value v_i to a final
value v_f given by
v_f = v_i + a * dt
where a is the acceleration. v_i, v_f and a are
all vectors and can be handled as x and y
components as I do in the code. (You need z too
in general of course but our orbits are two
dimensional).
> Your calculations
> apply for any normal trajectory taken by an object naturally
> moving to or from a gravity source.
No, it applies to _all_ motion of _any_ nature
whatsoever. That is fundamental to the whole
of dynamics and the process of integrating
acceleration to find velocity is pure maths.
...
> You of course agree that an object in a sustainable concentric
> orbit around the Sun will not shorten the radius between it and
> the Sun?
Obviously since concentric just means at constant
radius.
> You also agree that the radius will shorten at the full
> gravity rate only if its orbital speed is zero. AND ONLY THEN?
No! You are missing the whole point. Compare two
similar but slightly different motions for Mercury.
In the first it is in a perfectly circular orbit at
some radius with an orbital speed of 48km/s:
^
|
Sun M
|
In the second we have a snapshot of part of some
more complex path when the planet is also moving
at 48km/s:
^
\
Sun M
\
The difference is in the direction of motion, not
the speed. If the angle between the two paths is
just 1 degree the Mercury will move 48000*sin(1)
or 837.7m closer to the Sun in 1 second and that
is without even considering additional acceleration
effects.
> The same of course applies for an eccentric orbit.
>
> Do you reject any of that so far?
It is virtually all wrong, you don't seem to know the
definition of acceleration and you have completely
failed to grasp the importance of the direction of
motion.
> There's no point in replying to the rest of your post until
> this has all been cleared up. You are repeating the same old
> mistakes over and over again, again.
I'm not making any mistakes Max, everything I
said follows directly from the definition of
velocity and acceleration. The problem is that
you have forgotten about the effect of the
direction of motion and discarded fundamentals
to try to get the answer you want. Velocity is
the integral of acceleration, _always_.
> The gravity force is pointing directly at the Sun, ...
Yes, and Mercury is moving almost at right angles to
that, so the major influence is to change the direction
of motion, not the speed.
> so unless
> Mercury falls closer to the Sun on average its orbital speed
> cannot be increased. Adding a new force does not change the pull
> direction, so orbital speed cannot change from the normal unless
> the average radial length changes. Can you now see that?
Change of orbital speed is a secondary effect due to
the slow reduction of radius (Mercury moves faster
than the outer planets), what you are missing is that
increasing or decreasing the pull towards the Sun
changes the rate at which the direction of motion
alters. My code includes that effect and the results
follow.
George
Eric Gisse
> Max Keon wrote:
> > [...]
>
> > Centrifigal forces change at the rate of orbital speed squared,
> > so if Mercury was traveling at an average of 24000 m/sec instead
> > of the average 48000 m/sec, it would be restrained from falling
> > at the full rate by 24000^2 / 48000^2 = .25 of the .0395 m/sec^2
> > gravity rate. The fall rate is .25 * .0395 = 9.875e-3 m/sec^2.
>
> > [...]
>
> > The gravity force is pointing directly at the Sun, so unless
> > Mercury falls closer to the Sun on average its orbital speed
> > cannot be increased. Adding a new force does not change the pull
> > direction, so orbital speed cannot change from the normal unless
> > the average radial length changes. Can you now see that?
>
> Have you asked yourself why the centrifugal force is (m v^2 / r)?
I wonder if you have ever studied Newton's second law in a rotating
coordinate system....
>
> In spacetime with the Schwarzschild metric, the Euler-Lagrange
> equation associated with r can simply be derived as the following
> where the orbital motion is confined to the equatorial plane of the
> gravitating body.
It isn't "spacetime", chuckles. It is an affine parameter.
>
> d^2r/ds^2 - (1 - 3 U) r (dO/ds)^2 = - U / r
>
> Where
>
> ** O = Longitude
> ** s = Spacetime
> ** U = G M / c^2 / r
[snip all]
Wrong.
The actual radial equation of motion is:
d^2r/dl^2 + GM/r^3 * (r - 2GM) * (dt/dl)^2 - GM/r(r-2GM) *(dr/dl)^2 -
r(r-2GM)[(d\theta/dl)^2 + sin(\theta)^2*(d\phi/dl)^2] = 0, where l is
an arbitrary affine parameter [none of this 'spacetime' bullshit].
Notice this isn't anywhere even close to your idiotic equation. As
usual you get even the simplest mathematics totally and completely
wrong.
Koobee Wublee
> On May 29, 11:41 pm, Koobee Wublee <koobee.wub...@gmail.com> wrote:
> > In spacetime with the Schwarzschild metric, the Euler-Lagrange
> > equation associated with r can simply be derived as the following
> > where the orbital motion is confined to the equatorial plane of the
> > gravitating body.
>
> It isn't "spacetime", chuckles. It is an affine parameter.
>
> > d^2r/ds^2 - (1 - 3 U) r (dO/ds)^2 = - U / r
>
> > Where
>
> > ** O = Longitude
> > ** s = Spacetime
> > ** U = G M / c^2 / r
>
> The actual radial equation of motion is:
>
> d^2r/dl^2 + GM/r^3 * (r - 2GM) * (dt/dl)^2 - GM/r(r-2GM) *(dr/dl)^2 -
> r(r-2GM)[(d\theta/dl)^2 + sin(\theta)^2*(d\phi/dl)^2] = 0, where l is
> an arbitrary affine parameter [none of this 'spacetime' bullshit].
This is wrong. It should be corrected as follows using your symbols
and notations.
d^2r/dl^2 + GM/r^3 * (r - 2GM) * (dt/dl)^2 - (GM/r)/(r-2GM) *(dr/dl)^2
- (r-2GM)[(d\theta/dl)^2 + sin(\theta)^2*(d\phi/dl)^2] = 0
For simplicity without sacrificing the accuracy of the mathematical
model, we can easily establish the following.
** \theta = 0
** \phi = O
** ds = dl
** U = G M [/ c^2] / r
In doing so, your equation after my correction leads to the following.
dr^2/ds^2 - (1 - 2 U) r (dO/ds)^2 = - [c^2] (1 - 2 U) (dt/ds)^2 U / r
+ (dr/ds)^2 (U / r) / (1 - 2 U)
Furthermore, we can also easily establish the following from the
spacetime equation with the Schwarzschild metric.
** [c^2] (1 - 2 U) (dt/ds)^2 = 1 + (dr/ds)^2 / (1 - 2 U) + r^2 (dO/
ds)^2
Thus finally, your equation after my correction eventually leads to a
much simpler and elegant equation as I have already presented. Here
it is once again.
d^2r/ds^2 - (1 - 3 U) r (dO/ds)^2 = - U / r
Centrifugal force is not a farce. It is very real in direct contrast
from denials from Dr. Roberts.
> Notice this isn't anywhere even close to your idiotic equation. As
> usual you get even the simplest mathematics totally and completely
> wrong.
You know how to copy equations without understanding them. <shrug>
You have no capability to copy equations correctly. <sigh>
You are hopelessly beyond any help. <get lost>
He knows not and not knows that he knows not is a fool. Shun Gisse
and his pathetic cronies.
Eric Gisse
> On May 30, 1:24 pm, Eric Gisse <jowr...@gmail.com> wrote:
>
>
>
> > On May 29, 11:41 pm, Koobee Wublee <koobee.wub...@gmail.com> wrote:
> > > In spacetime with the Schwarzschild metric, the Euler-Lagrange
> > > equation associated with r can simply be derived as the following
> > > where the orbital motion is confined to the equatorial plane of the
> > > gravitating body.
>
> > It isn't "spacetime", chuckles. It is an affine parameter.
>
> > > d^2r/ds^2 - (1 - 3 U) r (dO/ds)^2 = - U / r
>
> > > Where
>
> > > ** O = Longitude
> > > ** s = Spacetime
> > > ** U = G M / c^2 / r
>
> > The actual radial equation of motion is:
>
> > d^2r/dl^2 + GM/r^3 * (r - 2GM) * (dt/dl)^2 - GM/r(r-2GM) *(dr/dl)^2 -
> > r(r-2GM)[(d\theta/dl)^2 + sin(\theta)^2*(d\phi/dl)^2] = 0, where l is
> > an arbitrary affine parameter [none of this 'spacetime' bullshit].
>
> This is wrong. It should be corrected as follows using your symbols
> and notations.
No, it isn't. This is the radial equation of motion for the
Schwarzschild metric. Refer to any relativity textbook, or derive the
damn thing yourself.
>
> d^2r/dl^2 + GM/r^3 * (r - 2GM) * (dt/dl)^2 - (GM/r)/(r-2GM) *(dr/dl)^2
> - (r-2GM)[(d\theta/dl)^2 + sin(\theta)^2*(d\phi/dl)^2] = 0
>
> For simplicity without sacrificing the accuracy of the mathematical
> model, we can easily establish the following.
>
> ** \theta = 0
> ** \phi = O
> ** ds = dl
> ** U = G M [/ c^2] / r
I was using geometrized units - there was no c, so you have no idea if
you are inserting it in the right spots.
>
> In doing so, your equation after my correction leads to the following.
>
> dr^2/ds^2 - (1 - 2 U) r (dO/ds)^2 = - [c^2] (1 - 2 U) (dt/ds)^2 U / r
> + (dr/ds)^2 (U / r) / (1 - 2 U)
>
> Furthermore, we can also easily establish the following from the
> spacetime equation with the Schwarzschild metric.
The phrase "spacetime equation" is nonsense. Quit expecting people to
understand your nonstandard and self-created vocabulary about a
technical subject which you routinely mangle.
Your inability to communicate in an understandable language says much
about your understanding of general relativity.
>
> ** [c^2] (1 - 2 U) (dt/ds)^2 = 1 + (dr/ds)^2 / (1 - 2 U) + r^2 (dO/
> ds)^2
>
> Thus finally, your equation after my correction eventually leads to a
> much simpler and elegant equation as I have already presented. Here
> it is once again.
>
> d^2r/ds^2 - (1 - 3 U) r (dO/ds)^2 = - U / r
Wrong, and wrong.
Where did dt/ds go? Where did c go? You insisted on putting it in, why
did you remove it? Where did the free floating 1 go? Where did the "3"
come from? There is no way for you to pick up an extra (1 - U)r(dO/
ds)^2 term.
The equations of motion /eventually/ fold into a single equation of
motion with an effective potential and effective energy _after_ the
application of 3 conserved quantities - none of which you have
mentioned or show any amount of understanding. The rigorous derivation
of said equation of motion takes about a page of math, _all_ of which
you have ignored - and isn't anywhere NEAR what you have written
down.
>
> Centrifugal force is not a farce. It is very real in direct contrast
> from denials from Dr. Roberts.
Stooooopid. That's classical mechanics, which you don't even
understand.
Centrifugal force follows directly from the expression of Newton's 2nd
law in a rotating coordinate system. Tom Roberts knows this, because
he has an actual education in physics instead of whatever you pulled
from a cracker jack box. Centrifugal force exists only in coordinate
systems that are rotating - it is a fake force that arises from your
coordinate choice. Tom Roberts also knows this, and has explained this
to you and others on numerous occasions, apparently to no effect.
[snip remaining whining]
Max Keon
>>> "Max Keon" <maxk...@optusnet.com.au> wrote in message
>>> news:46595a42$0$2869$afc3...@news.optusnet.com.au...
>>>> I'll snip the rest and concentrate on this major error, which is
>> You of course agree that an object in a sustainable concentric
I don't know how to get it through to George, but you are wrong
and I am right. Go and study it properly.
http://members.optusnet.com.au/maxkeon/peri.html
It seems to me that you may have a problem understanding what is
actually going on here. A gravity anisotropy is something you've
never encountered before and you are trying to explain it using
reasoning that you are accustomed to. That doesn't work.
Perhaps it might help if you realize that you are in no better
a position to see the truth than anyone else who has evolved
through any other society where "truth" has been indoctrinated
into them over many years. I use the word "indoctrinated" because
that's exactly what it is in every form of learning. One cannot
progress if they don't, at least temporarily, blindly accept
certain elements of the learning program.
But if you do know that what I say is correct, that's a whole
new ball game.
I'm going to need to elaborate quite a bit, so don't nod off.
I just happened to catch the final episode of a series, titled
"The Root Of All Evil", within the parent program "Compass" which
is aired on the ABC (Australia). Richard Dawkins of Oxford
University (you perhaps know him) highlighted the consequences
of the religious indoctrination of the young. He described it as
a virus of faith which is transmitted from the older generation
to the new. It's a never ending cycle that divides a community
and leads to a religious intolerance that extends to everyone
who is not likewise indoctrinated.
He also mentioned that even though science is constantly
falsifying the basis for creationism, the message doesn't seem
to be getting through.
The problem is, no matter what evidence science may find, it
could have been created as an integral part of the universe
while the universe was being made in the designated time of 6
or 7 days, depending what one wants to believe. So, it really
doesn't matter a damn what evidence is found.
I don't want to seem overly critical but offering the big bang
theory as an alternative reality is absolutely useless. It does
not describe how the universe began, or how it will end. All it
does is attempt to explain why the universe is what it is.
How can that constitute reality to anyone? The door is wide open.
It's about time the zero origin universe assumed the role of
explaining reality, that's what I think. That universe naturally
has a beginning which can be seen when we look back in time. We
see how the universe has evolved up until now, but we can't see
into the future to the ultimate end of the universe.
If you understood the consequences of that origin and where we
are heading, you would probably realize that life is not about
the individual or the fulfillment of one's self indulgent
desires, including working toward claiming the pot of eternal
bliss at the end of life's rainbow. All life, even in a primitive
state of evolution, is unbounded in its potential for future
development. Every bit of life in this universe has infinitely
more chance of averting the ultimate fate of everything that
exists in this universe than no life at all.
I watch my cat loafing around with no apparent purpose in life.
What is he waiting for? What is the point to the life of a tiny
amoeba floating about at the edge of a backwater? What is the
point to my life, or your life? Life may not seem to offer much
hope in the grand scheme of the universe, BUT WITHOUT IT, THERE
IS NO HOPE AT ALL. No matter how mundane a life may appear to be,
it still can be of absolute importance. Who knows what the future
consequences of its existence will be?
But there is a catch22. The demand for the planet's dwindling
resources in the rapidly developing countries is rising
exponentially. And that doesn't really take into account the
enormous future impact that 220000 plus per day world population
growth. Even a blind man could see that it MUST eventually come
to a sticky end. Choosing to ignore that obvious fact and
blundering down the same old path will lead to the self
extinction of mankind and just about everything else on the
planet. So why did we even bother in the first place.
It would have been far better for us to stay in the backwater
with the amoebas and let something else have a go.
Even though Richard Dawkins would probably tell me I have no
right to impose my own personal morality on anyone, any more than
does anyone have the right to impose their own personal morality
on me, which is invariably not just a moral issue but always
extends to the imposition of one's entire "reality", one thing is
for certain, if we can't all learn to live together as one united
community, there is not one hope in hell of us ever getting out
of the mess that we have so stupidly created here on Earth.
I don't know what the fix will be, but I do know that I won't
like it any more than will anybody else. But failure here is
not an option.
Do you now understand the importance of knowing the truth?
-----
Max Keon
You know the question, just as I did.
What is the Matrix?
Power, control,
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1180509979....@o5g2000hsb.googlegroups.com...
>> On 30 May, 00:38, "Max Keon" <maxk...@optusnet.com.au> wrote:
>>> George Dishman wrote:
>>>> "Max Keon" <maxk...@optusnet.com.au> wrote in message
>>>> news:46595a42$0$2869$afc3...@news.optusnet.com.au...
I'll put back part you snipped as it is the
core of the disagreement:
>>>>>> For example, if an acceleration of 2m/s^2 acts for
>>>>>> 50s then the velocity will change by 100m/s.
...
>>>> What I said above is true for all objects changing
>>>> speed for any reason whatsoever under any circumstances.
>>>
>>> Certainly _not_ under any circumstances George.
>
>> Yes, under _any_ circumstances Max. The word
>> "acceleration" is _defined_ as rate of change
>> of velocity so in a short time dt the velocity
>> will change from an initial value v_i to a final
>> value v_f given by
>>
>> v_f = v_i + a * dt
>>
>> where a is the acceleration. v_i, v_f and a are
>> all vectors and can be handled as x and y
>> components as I do in the code. (You need z too
>> in general of course but our orbits are two
>> dimensional).
...
>> .. it applies to _all_ motion of _any_ nature
>> whatsoever. That is fundamental to the whole
>> of dynamics and the process of integrating
>> acceleration to find velocity is pure maths.
<snip application of above until we get
this agreed.>
> I don't know how to get it through to George, but you are wrong
> and I am right. Go and study it properly.
These may help you:
http://www.staff.amu.edu.pl/~romangoc/M1-3-acceleration.html
http://hep.physics.indiana.edu/~rickv/More_Kinematics.html
http://www.blurtit.com/q286865.html
You could also look at the "Force and Motion"
topic here:
http://learningcenter.nsta.org/products/science_objects.aspx
It concentrates mainly on position and velocity
and is a bit light on acceleration but it is
well presented and has lots of questions to let
you check your progress. Once you have gone
through that, look again at what I said at the
top:
>>>>>> For example, if an acceleration of 2m/s^2 acts for
>>>>>> 50s then the velocity will change by 100m/s.
Do you still deny that?
> It seems to me that you may have a problem understanding what is
> actually going on here. A gravity anisotropy is something you've
> never encountered before and you are trying to explain it using
> reasoning that you are accustomed to. That doesn't work.
I have encountered anisotropy in many areas but
actually that doesn't matter, you have done the
work on that side and all I need is your result.
You have told me that the effect is to change
the acceleration due to gravity from Newton's
equation:
a = -GM / r^2
to
a = -GM / r^2 * (1 + v/c)
where v is the radial speed, the rate of change
of the radius, and the direction is the same
as Newton's.
You have specified the acceleration Max, all
that is left is to integrate it once to get
velocity and a second time to get position and
the results fall out of that calculation. I
don't need to know anything more about your
ideas at all. Now if that equation doesn't
represent your idea then obviously my comments
will similarly be misplaced but that is what
you have provided so I am taking it at face
value.
<snip diatribe>
> Do you now understand the importance of knowing the truth?
Of course, so go and look up the definition of
"acceleration" and you will find I have been
telling you the truth throughout. Your analysis
is wrong for numerous reasons that I listed
before and which you have ignored.
I have only made one significant error during
the course of the discussion which was when I
did a very quick simulation of your equation
and accidentally got the sign wrong, I used
(1 - v/c) instead of (1 + v/c) so the
eccentricity increased instead of decreasing
but that was some time ago and the Basic code
has the correct sign for your theory. It is
available for anyone to peer review [1] and
I'll repeat the part relevant to the physics
here since we have changed thread since it was
posted:
r2 = x * x + y * y
radius = SQR(r2)
vr = (radius - lastradius) / dt
lastradius = radius
Newton = GM / r2 ' The constant GM is negative
anisotropy = Newton * (vr / c)
acceleration = Newton + anisotropy
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
vx = vx + dt * ax
vy = vy + dt * ay
x = x + dt * (vx + 0.5 * dt * ax)
y = y + dt * (vy + 0.5 * dt * ay)
time = time + dt
George
[1] If anyone actually peer reviews that code,
be aware that in the actual version I run,
the acceleration for the next time step
uses a linear prediction from the current
and previous acceleration values to get:
forward_mean = (3 * current - previous) / 2
Max Keon
turned one paragraph into what can probably be describes as
illegible babble. I can't leave it that way.
----------------------
"George Dishman" <geo...@briar.demon.co.uk> wrote in message
news:1180509979....@o5g2000hsb.googlegroups.com...
> On 30 May, 00:38, "Max Keon" <maxk...@optusnet.com.au> wrote:
---
>> Do you reject any of that so far?
> It is virtually all wrong, you don't seem to know the
> definition of acceleration and you have completely
> failed to grasp the importance of the direction of
> motion.
---
enormous future impact of the 220000 plus per day world
population growth. Even a blind man could see that it MUST
eventually come to a sticky end. Choosing to ignore that obvious
fact and blundering down the same old path will lead to the self
extinction of mankind and just about everything else on the
planet. So why did we even bother in the first place.
It would have been far better for us to stay in the backwater
with the amoebas and let something else have a go.
In the aforementioned program, Richard Dawkins made it very clear
that _nobody_ has the right to impose their own personal morality
on anybody else. What he didn't mention is the fact that that
imposition eventually extends to one's entire version of reality.
Professor Dawkins would no doubt point the critical finger at me
for trying to impose my reality on the world. But my reality
cannot be scientifically faulted. And that reality demands
absolute compliance with the laws of nature on this planet, if
we are to survive with any purpose.
That is all an impossible dream unless we learn to live together
as one united community. Otherwise there is not one hope in hell
Phineas T Puddleduck
"Max Keon" <max...@optusnet.com.au> wrote:
> In the aforementioned program, Richard Dawkins made it very clear
> that _nobody_ has the right to impose their own personal morality
> on anybody else. What he didn't mention is the fact that that
> imposition eventually extends to one's entire version of reality.
> Professor Dawkins would no doubt point the critical finger at me
> for trying to impose my reality on the world. But my reality
> cannot be scientifically faulted.
Yawn. Another loon with the sole track to truth.
--
COOSN-174-07-82116: Official Science Team mascot and alt.astronomy's favourite
poster (from a survey taken of the saucerhead high command).
Official maintainer of the supra-cosmic space fluid pump (Mon and Tues only).
George Dishman
> During the process of a quick edit just prior to posting, I
> turned one paragraph into what can probably be describes as
> illegible babble. I can't leave it that way.
You needn't have worried, I think we both want to be sure
we have the correct analysis. The pages below will help
you do that.
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1180509979....@o5g2000hsb.googlegroups.com...
>> On 30 May, 00:38, "Max Keon" <maxk...@optusnet.com.au> wrote:
> ---
>
>>> Do you reject any of that so far?
>
>> It is virtually all wrong, you don't seem to know the
>> definition of acceleration and you have completely
>> failed to grasp the importance of the direction of
>> motion.
> ---
>
> I don't know how to get it through to George, but you are wrong
> and I am right. Go and study it properly.
You are not right Max, here again are some pages for you
to study. You can find lots more through Google:
http://www.staff.amu.edu.pl/~romangoc/M1-3-acceleration.html
http://hep.physics.indiana.edu/~rickv/More_Kinematics.html
http://www.blurtit.com/q286865.html
Also look at the "Force and Motion" topic here:
http://learningcenter.nsta.org/products/science_objects.aspx
The tutorial I have been giving you are the basic laws
of motion from which the equations you have tried to
use are derived. Those derivations no longer work when
you include anisotropy but the laws from which they came
are still valid.
George
George Dishman
Let me just pick up a point that Phineas noted:
> ... But my reality
> cannot be scientifically faulted. And that reality demands
> absolute compliance with the laws of nature on this planet, ...
Your model of reality has certainly been "scientifically
faulted". What we have done is take your revised equation
for the Newtonian force and calculated the resulting
motion. Your attempted method for doing that is grossly
wrong in many ways and is at odds with the laws of nature.
Given an acceleration, which is our strating point, the
laws require that velocity is the integral of acceleration
and position is the integral of velocity. You have not done
that and consequently your conclusions are hopelessly
flawed. Correctly applying those laws of nature tells you
that, should your anisotropy exist, Mercury's eccentricity
would fall nearly exponentially to zero within a few
thousand orbits, and the effect of the "mass of the rest of
the universe" which you suggested explained the Pioneer
anomaly would reduce Mercury's mean orbital radius until it
collided with the Sun in little over a million years.
Those obviously haven't happened so, while science may not
have all the answers yet, we know for a fact that your
suggested level of anisotropy does not exist in nature.
In a previous reply, I have repeated the list of tutorials
on basic mechanics that you need to learn if you are to use
the known laws to analyse such proposals in the future.
Good luck with your studies.
George
Phineas T Puddleduck
George Dishman <geo...@briar.demon.co.uk> wrote:
> On 3 Jun, 01:46, "Max Keon" <maxk...@optusnet.com.au> wrote:
>
> Let me just pick up a point that Phineas noted:
>
> > ... But my reality
> > cannot be scientifically faulted. And that reality demands
> > absolute compliance with the laws of nature on this planet, ...
>
> Your model of reality has certainly been "scientifically
> faulted". What we have done is take your revised equation
> for the Newtonian force and calculated the resulting
> motion. Your attempted method for doing that is grossly
> wrong in many ways and is at odds with the laws of nature.
Thank you George.
Although I pointed it out for a different reason, your analysis cuts to the
bone. The act of claiming that "your" way of thinking cannot be faulted is not
science, it is religion...
Max Keon
> "Max Keon" <max...@optusnet.com.au> wrote in message
> news:46613a1e$0$16033$afc3...@news.optusnet.com.au...
> I'll put back part you snipped as it is the
> core of the disagreement:
I'll snip that and reply where it reappears.
---
>> I don't know how to get it through to George, but you are wrong
>> and I am right. Go and study it properly.
> These may help you:
>
> http://www.staff.amu.edu.pl/~romangoc/M1-3-acceleration.html
>
> http://hep.physics.indiana.edu/~rickv/More_Kinematics.html
>
> http://www.blurtit.com/q286865.html
>
> You could also look at the "Force and Motion"
> topic here:
>
> http://learningcenter.nsta.org/products/science_objects.aspx
>
> It concentrates mainly on position and velocity
> and is a bit light on acceleration but it is
> well presented and has lots of questions to let
> you check your progress. Once you have gone
> through that, look again at what I said at the
> top:
>
>>>>>> For example, if an acceleration of 2m/s^2 acts for
>>>>>> 50s then the velocity will change by 100m/s.
>
> Do you still deny that?
I don't think I ever denied it in the sense that you've written
it. But I certainly disagree that velocity will change as you
propose if the force is that of gravity acting on an object which
is in a stable orbit. Radial velocity will vary according to the
degree of eccentricity, but the average orbit radius is not going
to change at all. Neither is average orbital speed.
If the gravity force was to double, accelerating the object at
4 m/sec^2, the average orbit radius is not going to shrink by
the added rate of 2 m/sec^2, but would fall inward at a much
lesser rate.
127645 m/sec orbital speed had previously counteracted the
2 m/sec^2 fall pointing directly at the Sun while the object was
held in a stable orbit at a radius of 8146563693 meters, but now
the required orbital speed to hold it in a stable orbit at that
radius around the double Sun mass is 180517 m/sec.
It should be obvious that if the object falls directly inward at
4 m/sec^2 when its orbital speed is zero and zero distance when
its orbital speed is 180517 m/sec, the direct fall rate is going
to reduce proportionally as orbital speed increases.
So what is the true direct fall rate of the object now that it's
traveling to slowly to counteract the direct fall? That rate is
obviously not linear, in the realm of gravity.
http://members.optusnet.com.au/maxkeon/falrate.jpg demonstrates
what that rate would be.
From the graph:
l <----------va-------------------> l
l l <-----vb-------------> l
l----------l------------------------l
l <--vc--> l
vc^2 / va^2 * gravity = fall rate
vc = va - vb
180517 - 127645 = 52872
52872^2 / 180517^2 * 4 = .343 m/sec^2 inward fall rate.
Let's hope my message has been noted and understood, however it
was presented.
>> Do you now understand the importance of knowing the truth?
> Of course, so go and look up the definition of
> "acceleration" and you will find I have been
> telling you the truth throughout. Your analysis
> is wrong for numerous reasons that I listed
> before and which you have ignored.
>
> I have only made one significant error during
> the course of the discussion which was when I
> did a very quick simulation of your equation
> and accidentally got the sign wrong, I used
> (1 - v/c) instead of (1 + v/c) so the
> eccentricity increased instead of decreasing
> but that was some time ago and the Basic code
> has the correct sign for your theory. It is
> available for anyone to peer review [1] and
> I'll repeat the part relevant to the physics
> here since we have changed thread since it was
> posted:
I've added to your program extract so that it can be run and
tested. The resident text explains what I've done.
Take note while it's running, that Mercury falls closer to the
Sun on both the up and the down leg of the orbit. Regardless of
what the math says, that is wrong. A fundamental consequence of
the anisotropy is that it will be drawn more to the Sun on the
way up and less on the way down. The trajectory on the down leg
should move toward being further from the Sun than normal, and
that doesn't happen.
The other thing that you still don't seem to grasp is the _fact_
that the whole process is entirely elastic. I've demonstrated why
many times. Should I do it again?
-----
Max Keon
------------------
'In the duplicated program following "ac:", the anisotropy is excluded.
'The program is now set up to test your updated method against your
'previous method. I know you can do it yourself because you wrote the
'program, but I've included some examples to make it easier for anyone
'else who wants to run it.
'The purple curve only, includes the anisotropy.
'Control-break halts the program. It's the only way out. Any other
'method just bogs the program down. F4 brings back the result.
DEFDBL A-Z
SCREEN 12
CLS
LOCATE 16, 66: PRINT "Aphelion"
c = 300000000#
GM = -1.327D+20
x = 70000000000#
multi = .000000005# ' Multiplier for the graphics.
mx = x ' Aligns program 2 with program 1.
' Program 2 has no anisotropy.
'---------------------------------
vy = 39000#: dt = 1000#
' vy = 39000#: dt = 100#
' vy = 8000#: dt = 50#
' vy = 8000#: dt = 10#
' The current program setup is for Mercury according to your latest
' program update. dt is 1000 second chunks. Swap the switch to run line
' 2 of the set and note the difference. Mercury now falls at a different
' rate. dt must therefore be set to 1 for it to run properly. But even
' then, Mercury is falling almost as fast without an anisotropy. I don't
' think that was intended. Why did you change the program anyway? It
' better represented your view before. Am I doing something wrong?
' I am very impressed with what your program does though.
'---------------------------------
mvy = vy ' Aligns program 2 with program 1.
aa: ' END ' Remove this switch to end the program.
r2 = x * x + y * y
radius = SQR(r2)
vr = (radius - lastradius) / dt
lastradius = radius
Newton = GM / r2 ' The constant GM is negative
anisotropy = Newton * (vr / c)
acceleration = Newton + anisotropy
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
vx = vx + dt * ax
vy = vy + dt * ay
'-------------------------------------
x = x + dt * (vx + .5 * dt * ax) ' Updated method.
y = y + dt * (vy + .5 * dt * ay)
' x = x + dt * vx ' Previous method.
' y = y + dt * vy ' Swap the switches in both programs.
'-------------------------------------
time = time + dt
IF time > 1000 THEN GOSUB ab
GOSUB ac
GOTO aa
ab:
time = 0
CIRCLE (200 + x * multi, 250 + y * multi), 0, 13
CIRCLE (200 + mx * multi, 250 + my * multi), 0, 11
RETURN
ac:
mr2 = mx * mx + my * my
mradius = SQR(mr2)
mvr = (mradius - mlastradius) / dt
mlastradius = mradius
mNewton = GM / mr2 ' The constant GM is negative
' manisotropy = mNewton * (mvr / c)
macceleration = mNewton ' + manisotropy
max = macceleration * (mx / mradius)
may = macceleration * (my / mradius)
mvx = mvx + dt * max
mvy = mvy + dt * may
'----------------------------------------
mx = mx + dt * (mvx + .5 * dt * max) ' Updated method.
my = my + dt * (mvy + .5 * dt * may)
' mx = mx + dt * mvx ' Previous method.
' my = my + dt * mvy ' Swap the switches.
'----------------------------------------
RETURN
Max Keon
> On 3 Jun, 01:46, "Max Keon" <maxk...@optusnet.com.au> wrote:
> Let me just pick up a point that Phineas noted:
>> ... But my reality
>> cannot be scientifically faulted. And that reality demands
>> absolute compliance with the laws of nature on this planet, ...
> Your model of reality has certainly been "scientifically
> faulted". What we have done is take your revised equation
> for the Newtonian force and calculated the resulting
> motion. Your attempted method for doing that is grossly
> wrong in many ways and is at odds with the laws of nature.
At odds with your laws of physics is more to the point.
> Given an acceleration, which is our strating point, the
> laws require that velocity is the integral of acceleration
> and position is the integral of velocity. You have not done
> that and consequently your conclusions are hopelessly
> flawed. Correctly applying those laws of nature tells you
> that, should your anisotropy exist, Mercury's eccentricity
> would fall nearly exponentially to zero within a few
> thousand orbits, and the effect of the "mass of the rest of
> the universe" which you suggested explained the Pioneer
> anomaly would reduce Mercury's mean orbital radius until it
> collided with the Sun in little over a million years.
>
> Those obviously haven't happened so, while science may not
> have all the answers yet, we know for a fact that your
> suggested level of anisotropy does not exist in nature.
I've demonstrated very clearly that the anisotropy does exist
in nature. But I can understand why it's not welcome in physics.
> In a previous reply, I have repeated the list of tutorials
> on basic mechanics that you need to learn if you are to use
> the known laws to analyse such proposals in the future.
Basic mechanics is fine George, but what happens if an unknown
law of nature rears its ugly head and contradicts the very
foundation of your physics? Einstein's theories will be thrown
into the trash can of course. Do you expect anyone to believe
that? The ugly head will more likely be labeled an anomaly, or
paradox, or something. Then it can be business as usual again.
If just one element of reality is postulated, which means that
it cannot be explained as a natural consequence of anything
real, and is introduced as a component of reality, the reality
which is built around it is not reality at all. The whole thing
becomes a virus of faith, with the postulate as the focal point
around which all of the building blocks of reality are firmly
cemented in place. _It becomes the foundation of reality_.
If just one block contradicts the postulate, it _MUST_ be deemed
wrong if the postulate and the entire reality that's built around
it is to survive. Where have we seen that before?
A virus of faith infects every generation that it touches.
-----
Max Keon
George Dishman
Here is the quote, it sounds as though you objected:
[GD:]
>>> For example, if an acceleration of 2m/s^2 acts for
>>> 50s then the velocity will change by 100m/s.
[MK:]
>> I'm inclined to think you actually believe that George, which is
>> a bit disconcerting.
Anyway, you seem to say the same again:
> But I certainly disagree that velocity will change as you
> propose if the force is that of gravity acting on an object which
> is in a stable orbit.
Acceleration is defined as being the rate at which the
velocity is changing. No matter what the circumstances,
that means that the velocity is found by integrating the
acceleration. If a constant acceleration of 2m/s^2, or
"2m/s per second" applies for 50 seconds then the change
of speed will be 50 * 2 or 100 m/s. The fact that it is
gravity that produces the acceleration is not important,
if the velocity didn't change by 100 m/s in the 50s then
the value of the acceleration would be something else,
it would be dv/50 where dv is the change in velocity.
Of course the acceleration isn't constant and in a stable
orbit, integrating the acceleration over a whole orbit
must get the speed back to its original value - that's
what stable means.
The point here though is that you have changed the formula
for the acceleration by adding the anisotropy and we must
integrate that to find out whether the orbit is stable or
not.
> Radial velocity will vary according to the
> degree of eccentricity, but the average orbit radius is not going
> to change at all. Neither is average orbital speed.
You don't know that until you do the calculation and
that's what the program is about. However, your own
description below matches mine so I'm not sure why
you are saying this.
> If the gravity force was to double, accelerating the object at
> 4 m/sec^2, the average orbit radius is not going to shrink by
> the added rate of 2 m/sec^2, but would fall inward at a much
> lesser rate.
If the force doubled for just 1 second at the middle
of the inward leg and then went back to normal, it
would cause a slight change in the direction of the
motion towards the sun but the change of energy would
be negligible. That would decrease the perihelion and
since the planet is back in a stable elliptical orbit
with the same energy, it would also increase the
aphelion half an orbit later, hence it would change
the eccentricity.
In fact you said the anisotropy _decreases_ the force
on the inward leg so that increases the perihelion
distance and decreases the aphelion reducing the
eccentricity. Suppose the planet would move from
A to B to C to D without the anisotropy, it goes
from A to B to E to F if the anisotropy is switched
on between B and E then off again:
A
B
E
C
F
D
Sun
The same happens on the outward leg, the slight
_increase_ in gravity as the planet is moving away
pulls it round to point more towards the Sun again
reducing the aphelion.
Sun
A
B
E
C F
D
Because that happens on every orbit, the eccentricity
falls on both the outward and inward legs of every
orbit and it ends up circular, which is the only
stable two-body configuration when your anisotropy is
included.
>> <snip diatribe>
>
> Let's hope my message has been noted and understood, however it
> was presented.
We are both aiming to understand accurately what your
modification to the formula predicts so:
>>> Do you now understand the importance of knowing the truth?
was unnecessary.
>> Of course, so go and look up the definition of
>> "acceleration" and you will find I have been
>> telling you the truth throughout. Your analysis
>> is wrong for numerous reasons that I listed
>> before and which you have ignored.
>>
>> I have only made one significant error during
>> the course of the discussion which was when I
>> did a very quick simulation of your equation
>> and accidentally got the sign wrong, I used
>> (1 - v/c) instead of (1 + v/c) so the
>> eccentricity increased instead of decreasing
>> but that was some time ago and the Basic code
>> has the correct sign for your theory. It is
>> available for anyone to peer review [1] and
>> I'll repeat the part relevant to the physics
>> here since we have changed thread since it was
>> posted:
>
> I've added to your program extract so that it can be run and
> tested. The resident text explains what I've done.
>
> Take note while it's running, that Mercury falls closer to the
> Sun on both the up and the down leg of the orbit. Regardless of
> what the math says, that is wrong.
I agree, that would be wrong, but it is farther
away when I run my original program. I'll recheck
and maybe post some numbers later in case you
changed something by mistake when editing but I
have other pressing (boring) stuff to do first.
> A fundamental consequence of
> the anisotropy is that it will be drawn more to the Sun on the
> way up and less on the way down. The trajectory on the down leg
> should move toward being further from the Sun than normal, and
> that doesn't happen.
You are absolutely correct, that is what I said
above, and when I run my program that is what
happens. I'll run your version later and see if
I can find why you think it is the opposite.
Can you not see that moving the planet away from
the Sun on the inward leg increases perihelion
while drawing it toward the Sun on the up leg
decreases aphelion so both reduce the eccentricity
as I have been saying?
> The other thing that you still don't seem to grasp is the _fact_
> that the whole process is entirely elastic. I've demonstrated why
> many times. Should I do it again?
Max, you have never demonstrated that at all and
you cannot do so. The requirement for it to be
elastic is that the force must be a function of
radial distance _only_. Since you include speed
in the formula, it isn't elastic.
Let me just pull out one other point:
> ' ... Why did you change the program anyway? It
> ' better represented your view before. Am I doing something wrong?
I assume you mean this bit:
> vx = vx + dt * ax
> vy = vy + dt * ay
>
> '-------------------------------------
> x = x + dt * (vx + .5 * dt * ax) ' Updated method.
> y = y + dt * (vy + .5 * dt * ay)
> ' x = x + dt * vx ' Previous method.
> ' y = y + dt * vy ' Swap the switches in both programs.
> '-------------------------------------
The equations apply to a single small time step
lasting dt seconds. Take some simple numbers for
the x values as an example, suppose the step is
dt = 3 seconds, the speed at the start is
vx = 100 m/s and the acceleration is ax = 6 m/s^2.
vx = vx + dt * ax
says that speed at the end of the step will have
risen from 100 m/s to 118 m/s.
The simpler equation
x = x + dt * vx
says the location has changed by 3 * 100 = 300 m
during that time, but the speed isn't a constant
100m/s, it changed from 100 m/s to 118 m/s. The
_average_ speed during the period is 109 m/s so
the accurate calculation of distance moved is
3 * 109 = 327 m.
The formula
x = x + dt * (vx + .5 * dt * ax)
gives a shift of
dt * (vx + .5 * dt * ax)
= 3 * (100 + 0.5 * 3 * 6)
= 3 * (100 + 9)
= 327 m
which is correct. The change just improves the
accuracy.
In the program I'm running at the moment, I have
another small change that does the same sort of
thing to account for the slight change of the
acceleration during the time step.
The aim of all this is that better accuracy of
the basic equations means we can use a larger
step duration so get the program to run faster.
George
George Dishman
> "Max Keon" <max...@optusnet.com.au> wrote in message
> news:4664a011$0$22547$afc3...@news.optusnet.com.au...
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>> news:f3rien$ca9$1...@news.freedom2surf.net...
>>> "Max Keon" <max...@optusnet.com.au> wrote in message
>>> news:46613a1e$0$16033$afc3...@news.optusnet.com.au...
...
I ran a series of tests yesterday to demonstrate
the accuracy the program achieves and lead on to
understanding what values of dt imply. For all of
this I commented out tha anisotropy as you did so
that the orbit was a simple ellipse. The values I
used are from this NSSDC page:
http://nssdc.gsfc.nasa.gov/planetary/factsheet/mercuryfact.html
x = 69820000000#
y = 0
vx = 0
vy = 38855
After one orbit the aphelion should return to
exactly 69820000000m. The measure of accuracy I
used is how far the aphelion departs from that.
First I used the simplest equations:
x = x + dt * vx
vx = vx + dt * ax
(and similar for y of course, I'll just discuss
the x formulae but y always matches).
Using a step of dt = 1 second, the aphelion
after 1 orbit is 69820924110m which is an error
of 924110m.
This table shows the error for different values
of timestep:
dt error
3000 2765316363
1000 923341546
300 277164323
100 92403433
30 27722635
10 9241031
3 2772325
1 924110
It should be obvious the error is almost
proportional to dt. To get the error down
to 0.9 m would require dt = 1e-6 which
is clearly impractical.
I then changed the first formula which assumed
the velocity was constant during the step to:
x = x + dt * (vx + .5 * dt * ax)
That allows for the change of velocity during
the step due to the acceleration. The errors
reduced to:
dt error
3000 1384408535
1000 461860143
300 138599001
100 46203587
30 13861485
10 4620534
3 1386164
1 462055
That's half the above and suggests that while
I have fixed on source of error, there is at
least one more.
> In the program I'm running at the moment, I have
> another small change that does the same sort of
> thing to account for the slight change of the
> acceleration during the time step.
The second equation I showed you some time ago is
vx = vx + dt * ax
That assumes constant acceleration during the
time step but we expect it to change. We can use
a method similar to that above but we need an
estimate of the change in acceleration during dt.
Suppose the current value of acceleration is C and
the previous value was P. We want the next value N.
The simplest estimate is that it will change by the
same amount. The change was C - P so we can use:
N = C + (C - P)
or
N = 2C - P
To find the change in speed, we need to use the
average acceleration A over the coming step which is
A = (C + N) / 2
so substituting for N:
A = (3C - P) / 2
The code for this then becomes:
ax = acceleration * (x / radius)
axMean = (3 * ax - axPrev) / 2
x = x + dt * (vx + .5 * dt * axMean)
vx = vx + dt * axMean
axPrev = ax
and similar for y. This is what happens to the error:
dt error
3000 217307
1000 23258
300 2073
100 234
30 21
10 2
3 0
1 0
Obviously the accuracy has improved immensely. Here
are the three tables for easy comparison:
dt simplest velocity acceleration
equations corrected corrected
3000 2765316363 1384408535 217307.2872
1000 923341546 461860143 23258.3085
300 277164323 138599001 2073.3289
100 92403433 46203587 233.8231
30 27722635 13861485 20.8139
10 9241031 4620534 2.3414
3 2772325 1386164 0.2152
1 924110 462055 0.0228
The second point to note is that the error in the
third column depends on the _square_ of dt, so
each time dt increases by 10, the error increases
by 100 times. It's not easy to explain but that
tells me I have the most accurate possible
equations using first order corrections.
> The aim of all this is that better accuracy of
> the basic equations means we can use a larger
> step duration so get the program to run faster.
Notice now that I can get better than 1m accuracy
withtime steps of 4 seconds instead of the one
microsecond required when using the simpler, less
accurate equations.
As a final check, you will have noticed I keep a
running count of the time:
time = time + dt
I checked that at the end of the run and it said
7601043s. That is 87.975 days and from the NSSDC
data sheet you can see the correct value is 87.969
days. That error is 0.006 days, an error in the
fifth significant place, but the values on the
web page are only given to four places so the
program again is as good as possible. In fact you
can slightly alter the 38855 m/s initial y speed
to get an exact match but the base numbers just
aren't that accurate.
I added decimals on the last error column but just
to be sure you appreciate it, notice that after a
complete orbit of some 7.6 million steps of 1s each,
where the planet moves over 38km each time, the
location of Mercury is wrong by just 22.8 mm or
less than an inch!
Now let's look at the effect of the anisotropy:
>> Take note while it's running, that Mercury falls closer to the
>> Sun on both the up and the down leg of the orbit. Regardless of
>> what the math says, that is wrong.
>...
>> A fundamental consequence of
>> the anisotropy is that it will be drawn more to the Sun on the
>> way up and less on the way down. The trajectory on the down leg
>> should move toward being further from the Sun than normal, and
>> that doesn't happen.
>
> You are absolutely correct, that is what I said
> above, and when I run my program that is what
> happens. ...
Here are the values for perihelion and aphelion
without then with the anisotropy using dt = 3s:
Anisotropy Perihelion Aphelion
Without 45999733190 69820000000
With 46001744129 69810737130
Difference 2010939 -9262870
As you can see, the perihelion is increased by
2011 km, the planet is drawn toward the Sun 'less
on the way down' as you said. I don't know why you
thought the program said otherwise.
We can use the same method as above to assess the
error in this figure by using higher dt values:
dt difference error
100 2010952 13
30 2010943 4
10 2010939 0
3 2010939 0
Again the error is proportional to dt so there is
scope for improvement. The source of this error is
the simple equation:
vr = (radius - lastRadius) / dt
That is actually the average over the _last_ time
step and we want the average of the next. I could
do that but I haven't bothered as we can see the
error is only a few metres in 2011 km. Using a dt
of 10 seconds means the error is about 1.3 m (the
display rounding makes it look like 0 but it is one
tenth of the 13m error at dt=100) and it is entirely
inconsequential.
George
Max Keon
> "Max Keon" <max...@optusnet.com.au> wrote in message
> news:4664a011$0$22547$afc3...@news.optusnet.com.au...
>>
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>> news:f3rien$ca9$1...@news.freedom2surf.net...
>>> "Max Keon" <max...@optusnet.com.au> wrote in message
>>> news:46613a1e$0$16033$afc3...@news.optusnet.com.au...
>>>>>>> For example, if an acceleration of 2m/s^2 acts for
>>>>>>> 50s then the velocity will change by 100m/s.
>>>
>>> Do you still deny that?
>>
>> I don't think I ever denied it in the sense that you've written
>> it.
> Here is the quote, it sounds as though you objected:
> [GD:]
>>>> For example, if an acceleration of 2m/s^2 acts for
>>>> 50s then the velocity will change by 100m/s.
> [MK:]
>>> I'm inclined to think you actually believe that George, which is
>>> a bit disconcerting.
This is what I was responding to:
----------------
>>>> We are treating the anisotropy like the Newtonian
>>>> gravity as an acceleration, not a force. We are
>>>> not including the mass of Mercury in any of the
>>>> calculations because it would cancel out.
>>>>
>>>> The accelerations are continuous (both Newtonian and
>>>> the anisotropy) in that they apply at all times and
>>>> change smoothly with time, they aren't quantised and
>>>> changing in discrete steps.
>>>>
>>>> That means that any time, the acceleration adds an
>>>> amount to the velocity which is equalt to the product
>>>> of the time and the acceleration. It doesn't add or
>>>> subtract from the radius, I don't know where you got
>>>> that idea.
>>>>
>>>> For example, if an acceleration of 2m/s^2 acts for
>>>> 50s then the velocity will change by 100m/s.
>>>
>>> I'm inclined to think you actually believe that George, which is
>>> a bit disconcerting.
-----------------
Firstly, I ignored your comment that it doesn't add or subtract
from the radius because that is obviously wrong. The altered pull
of gravity _must_ act to alter the radius. I had assumed that
"velocity" was referring to radial change rate, not the orbital
_speed_ change.
> Anyway, you seem to say the same again:
We've been through all this before George. I'll snip what is
obvious and get to the point.
---
>> I've added to your program extract so that it can be run and
>> tested. The resident text explains what I've done.
>>
>> Take note while it's running, that Mercury falls closer to the
>> Sun on both the up and the down leg of the orbit. Regardless of
>> what the math says, that is wrong.
> I agree, that would be wrong, but it is farther
> away when I run my original program. I'll recheck
> and maybe post some numbers later in case you
> changed something by mistake when editing but I
> have other pressing (boring) stuff to do first.
The problem is that I forgot to define the initial value for
'lastradius' and 'mlastradius' in the program. It now does fall
less to the Sun on the first trip to perihelion.
---
>> The other thing that you still don't seem to grasp is the _fact_
>> that the whole process is entirely elastic. I've demonstrated why
>> many times. Should I do it again?
> Max, you have never demonstrated that at all and
> you cannot do so. The requirement for it to be
> elastic is that the force must be a function of
> radial distance _only_. Since you include speed
> in the formula, it isn't elastic.
Radial velocity, speed of light, a variable pull of gravity?
Why on earth is that inelastic? The reason why it's an anomalous
acceleration is because you don't have the maths to describe it.
That makes your maths inelastic.
I've used this analogy before, but you don't seem to understand
what I'm getting at. I'll try using words and not diagrams.
Picture Mercury having just arrived at the aphelion radius, where
an unpredicted gravity anisotropy is suddenly applied, and it is
such that it reduces the pull of gravity by the exact amount that
will allow Mercury to remain orbiting at that radius. No energy
is transferred through the action of the anisotropy, so Mercury
continues on unrestricted. The point where the anisotropy is
turned off, and everything is back to normal, is the new aphelion
orientation in the Sun's frame. It should be obvious that the
aphelion has advanced and _nothing_ is lost?
The same applies at the perihelion radius if the anisotropy
increases the pull of gravity so that Mercury is held orbiting
for a while at that radius.
In both cases, there has been a definite change in the pull of
gravity, with no consequence other than the advance of the
aphelion and perihelion in the Sun's frame.
Now temporarily reduce the pull of gravity somewhere enroute the
perihelion. The anisotropy again affects Mercury's natural orbit
path, shifting it from the normal in the same way as before.
Regardless of what direction the natural orbit path is taking at
the time, would the change have different consequences to when
it occurred at aphelion or perihelion? Why would it? And how
would it?
It's not for me to show why the energy is _not_ transferred
through some mysterious action of the anisotropy, it's for you
to show how it _is_.
> Let me just pull out one other point:
>> ' ... Why did you change the program anyway? It
>> ' better represented your view before. Am I doing something wrong?
> I assume you mean this bit:
Exactly.
>>> vx = vx + dt * ax
>>> vy = vy + dt * ay
>>>
>>> '-------------------------------------
>> x = x + dt * (vx + .5 * dt * ax) ' Updated method.
>> y = y + dt * (vy + .5 * dt * ay)
>> ' x = x + dt * vx ' Previous method.
>> ' y = y + dt * vy ' Swap the switches in both programs.
>> '-------------------------------------
> The equations apply to a single small time step
> lasting dt seconds. Take some simple numbers for
> the x values as an example, suppose the step is
> dt = 3 seconds, the speed at the start is
> vx = 100 m/s and the acceleration is ax = 6 m/s^2.
I've just read read your other reply and you appear to have
addressed minor error problems in only a few orbits so that
those errors won't escalate too much over time. But if you
run your program using the "updated method", it really doesn't
work at all over time. Run the program and see for yourself.
Then change the value of dt and note the path difference that
Mercury takes as well. It's not just a minor error you're
dealing with, it's enormous.
Anyway, while running your program using the "Previous method",
I noticed that Mercury's average orbit radius shrinks fairly
rapidly. Didn't you notice that when you claimed that the
acceleration doesn't add or subtract from the radius?
The attached updated version of your program should demonstrate
what I mean. I've added the elastic anisotropy to your program
as well, to see how it fares. It passes the test with flying
colors, naturally. The radius difference on the "up" leg is
-1e-3 and for the "down" leg it's 3.8e-4 meters.
And do realize that the errors are common to both paths in the
setup I'm using.
-----
Max keon
'----------------------------
'ESC exits the program, if that part of the program is not
'switched off. Pressing Control and Break is the only other way
'out of the program. It halts the program at any time.
'The program is currently set up to test the elastic anisotropy.
'It's set to run fairly slowly because just the one orbit is all
'that's required in the test. It's easy enough to make it run
'faster of course. Switch off all GOSUB lines and increase dt.
'The switch manipulations required to change the program back to
'the way it was are highlighted thus //////////.
DEFDBL A-Z
SCREEN 12
CLS
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 program 1 and 2.
'Program 1 has no anisotropy.
mvy = vy 'Aligns the two programs.
lastradius = x
mlastradius = x
dt = 100
'//////////
multib = 10000#
'multib = 1#
'This multiplier is only included to establish a more accurate
'radius difference between the normal and that generated by
'the elastic anisotropy. If it's not set as 1 the only reliable
'result is the radius difference.
aa:
mr2 = mx * mx + my * my
mradius = SQR(mr2)
mvr = (mradius - mlastradius) / dt
mlastradius = mradius
mNewton = GM / mr2 ' The constant GM is negative
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 ' The constant GM is negative
anisotropy = -newton * (vr / c)
ovel = (mvx ^ 2# + mvy ^ 2#) ^ .5# 'Orbital speed no anisotropy.
ovelc = (vx ^ 2# + vy ^ 2#) ^ .5# 'Orbital speed with anisotropy.
'--------------------------------
grava = -newton + anisotropy
gravb = -newton
ratio = grava ^ .5# / gravb ^ .5#
ovelb = ovel * ratio
'These equations are not active until "fall" is switched on
'for option (2) below. Their purpose, and the relevant fall
'rate below, is all explained at
' http://members.optusnet.com.au/maxkeon/peri.html
'Briefly; Mercury cannot accelerate to the full extent of the
'elastic anisotropy while it's in orbit.
'--------------------------------
'//////////
'fall = anisotropy 'assumes that the fall is continuous.
fall = (ovelb - ovel) ^ 2# / ovelb ^ 2# * anisotropy
'Switching (2) on initializes a fall from a start point of
'zero fall rate. That's the initial direct fall rate from the
'aphelion or the perihelion radius if the system is entirely
'elastic. Mercury must fall to the previous perihelion radius,
'or rise to the previous aphelion radius before it begins the
'return journey, so each half of the full cycle must be run
'individually, starting from aphelion, and starting from
'perihelion. Swap the 'x switches at the start of the program
'to run each half. The result is much the same as in my original
'program, designed around COS(xxxx).
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 > 20000 THEN GOSUB ab
IF vr>0 AND fa= 0 THEN fb = 1: fa = 1: ff = 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) / multib; "radius difference. "
RETURN
ad: PRINT " Press ESC to end this half cycle. "
DO: s$ = INKEY$: LOOP UNTIL s$ <> ""
IF s$ = CHR$(27) THEN PRINT " Swap the 'x switch and re-run": END
RETURN
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:f4bo4l$589$1...@news.freedom2surf.net...
>
> >news:4664a011$0$22547$afc3...@news.optusnet.com.au...
>
> >> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> >>news:f3rien$ca9$1...@news.freedom2surf.net...
OK, we have been a bit at cross purposes, in fact
we are both correct. The acceleration adds directly
to the velocity as I said, but the consequence of
that is that the velocity has changed and therefore
the radius will be affected. My point was that
numerically you have to add the acceleration to the
velocity (taking account of the time step of course).
You then integrate the velocity to find the new
location and from that the new radius.
> I had assumed that
> "velocity" was referring to radial change rate, not the orbital
> _speed_ change.
It is neither, and that may be the root of your
problem. The velocity is the speed _and_ direction
of the planet. In general the acceleration is
neither along the path nor perpendicular to it.
It will be perpendicular only at aphelion and
perihelion so in general you need to take account
of the angle between the acceleration (towards the
Sun) and the velocity (along the path) in the
calculations. That is the part that your program
missed. I'll illustrate that more below ....
> > Anyway, you seem to say the same again:
>
> We've been through all this before George. I'll snip what is
> obvious and get to the point.
> ---
>
> >> I've added to your program extract so that it can be run and
> >> tested. The resident text explains what I've done.
>
> >> Take note while it's running, that Mercury falls closer to the
> >> Sun on both the up and the down leg of the orbit. Regardless of
> >> what the math says, that is wrong.
> > I agree, that would be wrong, but it is farther
> > away when I run my original program. I'll recheck
> > and maybe post some numbers later in case you
> > changed something by mistake when editing but I
> > have other pressing (boring) stuff to do first.
>
> The problem is that I forgot to define the initial value for
> 'lastradius' and 'mlastradius' in the program. It now does fall
> less to the Sun on the first trip to perihelion.
OK, easily done. So I guess you agree with this as
it is the same as you were saying:
>> In fact you said the anisotropy _decreases_ the force
>> on the inward leg so that increases the perihelion
>> distance and decreases the aphelion reducing the
>> eccentricity. Suppose the planet would move from
>> A to B to C to D without the anisotropy, it goes
>> from A to B to E to F if the anisotropy is switched
>> on between B and E then off again:
>>
>> A
>> B
>> E
>> C
>> F
>>
>> D
>>
>> Sun
To explain the point about velocity and vectors above,
if the locations shown here:
A
B
P
Q
are one second apart then the mean velocity during the first
second would be an arrow from A to B and during the next
second it would be from B to P if there was no acceleration.
So I can write B->P = A->B.
If the acceleration is an arrow from P to Q, then the
new velocity is B->Q = B->P + P->Q.
Anyway, you presumably also agree this:
>> The same happens on the outward leg, the slight
>> _increase_ in gravity as the planet is moving away
>> pulls it round to point more towards the Sun again
>> reducing the aphelion.
>>
>> Sun
>>
>> A
>>
>> B
>>
>> E
>> C F
>>
>> D
Can you then see that it implies this:
>> Because that happens on every orbit, the eccentricity
>> falls on both the outward and inward legs of every
>> orbit and it ends up circular, which is the only
>> stable two-body configuration when your anisotropy is
>> included.
That is what the program displays.
> >> The other thing that you still don't seem to grasp is the _fact_
> >> that the whole process is entirely elastic. I've demonstrated why
> >> many times. Should I do it again?
> > Max, you have never demonstrated that at all and
> > you cannot do so. The requirement for it to be
> > elastic is that the force must be a function of
> > radial distance _only_. Since you include speed
> > in the formula, it isn't elastic.
>
> Radial velocity, speed of light, a variable pull of gravity?
> Why on earth is that inelastic?
Because energy change is force times the distance over
which it acts. If force is a function of radius _only_
then any energy gained moving towards the Sun is exactly
balanced by the energy lost moving away from it, back to
the original radius. If you involve speed in the formula
then you can move inwards at one speed and outwards at
another and the energy changes no longer balance. The
consequence is simple in this context, if the force is a
function of distance only, it is elastic but if it depends
on anything else then it is inelastic.
> The reason why it's an anomalous
> acceleration is because you don't have the maths to describe it.
> That makes your maths inelastic.
>
> I've used this analogy before, but you don't seem to understand
> what I'm getting at. I'll try using words and not diagrams.
No need, it's really simple - you have speed in the equation .
> Picture Mercury having just arrived at the aphelion radius, where
> an unpredicted gravity anisotropy is suddenly applied, and it is
> such that it reduces the pull of gravity by the exact amount that
> will allow Mercury to remain orbiting at that radius. No energy
> is transferred through the action of the anisotropy, ...
I told you before, that changes the potential energy. If you
work out all the numbers, energy is not conserved if you move
from one radius to another and then back again.
> ... so Mercury
> continues on unrestricted. The point where the anisotropy is
> turned off, and everything is back to normal, is the new aphelion
> orientation in the Sun's frame. It should be obvious that the
> aphelion has advanced and _nothing_ is lost?
Nope, do the sums and be careful to include potential energy.
The amount you gain when the anisotropy is switched on at one
radius is different from when it is switched off at another
so they don't cancel out.
I'll snip the rest since you have missed the PE entirely.
...
> It's not for me to show why the energy is _not_ transferred
> through some mysterious action of the anisotropy, it's for you
> to show how it _is_.
No Max, it is for _you_ to explain why it _is_ lost
since that is the consequence of the equations you
post.
> > Let me just pull out one other point:
> >> ' ... Why did you change the program anyway? It
> >> ' better represented your view before. Am I doing something wrong?
> > I assume you mean this bit:
>
> Exactly.
>
> >>> vx = vx + dt * ax
> >>> vy = vy + dt * ay
>
> >>> '-------------------------------------
> >> x = x + dt * (vx + .5 * dt * ax) ' Updated method.
> >> y = y + dt * (vy + .5 * dt * ay)
> >> ' x = x + dt * vx ' Previous method.
> >> ' y = y + dt * vy ' Swap the switches in both programs.
> >> '-------------------------------------
> > The equations apply to a single small time step
> > lasting dt seconds. Take some simple numbers for
> > the x values as an example, suppose the step is
> > dt = 3 seconds, the speed at the start is
> > vx = 100 m/s and the acceleration is ax = 6 m/s^2.
>
> I've just read read your other reply and you appear to have
> addressed minor error problems in only a few orbits so that
> those errors won't escalate too much over time. But if you
> run your program using the "updated method", it really doesn't
> work at all over time. Run the program and see for yourself.
I put a lot of information into these two posts and
you would do well to read them carefully and be sure
you understand each part, you'll learn quite a bit
about numerical methods from them.
I have run the program over many orbits and I'll upload a
plot showing both aphelion and perihelion of the first few
thousand orbits, probably tomorrow as I'm out tonight. I
also ran it for about a week at the end of May with some
adjustments to cope with the low eccentricity. That version
also included your "rest of the universe" mass based on the
Pioneer Anomaly and I can see the gradual decay of the orbit
I demonstrated using the energy approach some time ago. I
haven't compared them to check the long term accuracy yet
though but IIRC it ran about half a million orbits so any
cumulative errors should show up.
> Then change the value of dt and note the path difference that
> Mercury takes as well. It's not just a minor error you're
> dealing with, it's enormous.
If you look at the other post, you will se this table
dt error
3000 217307
1000 23258
300 2073
100 234
30 21
10 2
3 0
1 0
For a 3 second value of dt, the error is 0.2m per orbit,
hardly "enormous". In comparison to the 2011 km increase
in perihelion and the 9263 km decrease in the aphelion on
the first orbit alone, a fraction of a metre is totally
insignificant.
> Anyway, while running your program using the "Previous method",
> I noticed that Mercury's average orbit radius shrinks fairly
> rapidly.
Yes, that is correct. Eccentricity has a greater effect
on aphelion than on perihelion.
> Didn't you notice that when you claimed that the
> acceleration doesn't add or subtract from the radius?
Yes, but we were talking at a different level, you don't
directly add the acceleration to the radius as I thought
you were suggesting, you use the acceleration to change
the velocity (which mostly affects the direction, not the
speed) and then see where that new velocity carries the
planet. The change of radius is a secondary effect in
that sense.
Note that although the aphelion starts by reducing, the
perihelion is increasing so the total orbital energy
changes by a fairly small amount, it is mainly the
eccentricity that is being reduced.
Again, that is entirely in keeping with your own comments
in your previous post.
> The attached updated version of your program should demonstrate
> what I mean. I've added the elastic anisotropy to your program
> as well, to see how it fares. It passes the test with flying
> colors, naturally. The radius difference on the "up" leg is
> -1e-3 and for the "down" leg it's 3.8e-4 meters.
The correct figures are a 2011 km increase in perihelion and a
9263 km decrease in aphelion on the first orbit so your program
is grossly wrong. Again I will point out that none of the methods
you are using is valid because the anisotropy alters all the
usual short-cut equations. You have no choice but to go back to
basics and solve the integrals for acceleration and velocity.
Let me just remind you of what you said before, something that
is quite true:
> ... A fundamental consequence of
> the anisotropy is that it will be drawn more to the Sun on the
> way up and less on the way down. The trajectory on the down leg
> should move toward being further from the Sun than normal ...
It should be obvious that, after the inward leg, if the planet is
in an orbit with almost the same energy but a higher perihelion,
it must be nearer to circular so the aphelion will be less than
the starting point. On the outward leg, being "drawn more toward
the Sun" further reduces the aphelion, so clearly it cannot be
back where it started. You need to apply some critical thought
because you own words tell you the numbers you got above are
wrong. However, your description exactly fits the output of my
program.
George
Max Keon
> On 12 Jun, 04:09, "Max Keon" <maxk...@optusnet.com.au> wrote:
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>> news:f4bo4l$589$1...@news.freedom2surf.net...
>>> "Max Keon" <maxk...@optusnet.com.au> wrote in message
>>> news:4664a011$0$22547$afc3...@news.optusnet.com.au...
>> The problem is that I forgot to define the initial value for
>> 'lastradius' and 'mlastradius' in the program. It now does fall
>> less to the Sun on the first trip to perihelion.
> OK, easily done. So I guess you agree with this as
> it is the same as you were saying:
>
>>> In fact you said the anisotropy _decreases_ the force
>>> on the inward leg so that increases the perihelion
>>> distance and decreases the aphelion reducing the
>>> eccentricity. Suppose the planet would move from
>>> A to B to C to D without the anisotropy, it goes
>>> from A to B to E to F if the anisotropy is switched
>>> on between B and E then off again:
>>>
>>> A
>>> B
>>> E
>>> C
>>> F
>>>
>>> D
>>>
>>> Sun
Very carefully note the gravitational potential at F compared
with D when normal gravity is reinstated. Also note that
Mercury's orbital velocity is slower than if it had been drawn
down the normal path.
Mercury's fall to the radius of C, which is now labeled F, has
been delayed, but the prevailing conditions are exactly as they
would have been at C. It will now begin the same fall to the Sun
as it would have from C.
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.
It doesn't matter to which part of the orbit your logic is
applied, no energy will be shifted from the Sun-Mercury closed
gravitating system.
The anisotropy doesn't immediately switch on or off of course,
but it can be pictured as a multitude of minute on or off steps
that increment and decrement proportionally to radial velocity
change. Each rise step has a counteractory fall step over each
half cycle.
Perhaps you can understand what I mean now?
> To explain the point about velocity and vectors above,
> if the locations shown here:
>
> A
> B
> P
> Q
>
> are one second apart then the mean velocity during the first
> second would be an arrow from A to B and during the next
> second it would be from B to P if there was no acceleration.
> So I can write B->P = A->B.
>
> If the acceleration is an arrow from P to Q, then the
> new velocity is B->Q = B->P + P->Q.
>
> Anyway, you presumably also agree this:
>
>>> The same happens on the outward leg, the slight
>>> _increase_ in gravity as the planet is moving away
>>> pulls it round to point more towards the Sun again
>>> reducing the aphelion.
>>>
>>> Sun
>>>
>>> A
>>>
>>> B
>>>
>>> E
>>> C F
>>>
>>> D
>
> Can you then see that it implies this:
I can see very clearly that Mercury at F is in a position of
lower gravitational potential when the anisotropy is switched
off and is orbiting faster than if it had arrived at D. Remember
that the anisotropy is just like any other gravity, acting along
a direct line to the Sun, and if the pull holds Mercury more to
the Sun its orbital velocity must remain higher, around a tighter
curve.
Try to remember that the anisotropy is only gravity.
I imagine that you have again not included a normal orbit as a
test of your program, so I've attached a version of your program
to the end of this post which does. It's based on your most
recent method update, which I assume hasn't changed.
This time it's set up to plot every one second step of an
orbit which is more eccentric than that of Mercury so as to
highlight any possible problems. As well as showing the supposed
anisotropic decay, it clearly shows a fairly rapid decay in the
normal orbit (blue curve) in the very first cycle. Is that what
you expected?
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.
-----
Max Keon
'--------------------------------
'The blue curve is a normal elliptical orbit.
'The purple curve includes the anisotropy.
'Control-break halts the program. It's the only way out.
'F4 brings back the result.
DEFDBL A-Z
SCREEN 12
CLS
LOCATE 16, 70: PRINT "Aphelion"
c = 300000000#
GM = -1.327D+20
x = 70000000000#
multi = .000000005# ' Multiplier for the graphics.
mx = x ' Aligns program 2 with program 1.
' Program 2 has no anisotropy.
vy = 8000#
dt = 1#
mvy = vy ' Aligns program 2 with program 1.
aa:
r2 = x * x + y * y
radius = SQR(r2)
vr = (radius - lastradius) / dt
lastradius = radius
Newton = GM / r2 ' The constant GM is negative
anisotropy = Newton * (vr / c)
acceleration = Newton + anisotropy
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
vx = vx + dt * ax
vy = vy + dt * ay
x = x + dt * (vx + .5 * dt * ax) ' Updated method.
y = y + dt * (vy + .5 * dt * ay)
time = time + dt
'---Program 2-----------------------------------
mr2 = mx * mx + my * my
mradius = SQR(mr2)
mvr = (mradius - mlastradius) / dt
mlastradius = mradius
mNewton = GM / mr2 ' The constant GM is negative
macceleration = mNewton
max = macceleration * (mx / mradius)
may = macceleration * (my / mradius)
mvx = mvx + dt * max
mvy = mvy + dt * may
mx = mx + dt * (mvx + .5 * dt * max) ' Updated method.
my = my + dt * (mvy + .5 * dt * may)
CIRCLE (200 + x * multi, 250 + y * multi), 0, 13
CIRCLE (200 + mx * multi, 250 + my * multi), 0, 11
GOTO aa
doug
<sniped>
>
> 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.
>
> -----
>
> Max Keon
>
Ever patient George keeps pointing out to you that your proposed
effect is inelastic and you keep ignoring that. Gravity is not
proportional to velocity so it is elastic. Your proposed effect
is proportional to velocity so it is inelastic. Your proposal
is dead in the water but you have been missing that altogether.
Koobee Wublee
> Max Keon wrote:
> > 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.
>
> No, you are the one forgetting that gravity is always elastic.
> Ever patient George keeps pointing out to you that your proposed
> effect is inelastic and you keep ignoring that. Gravity is not
> proportional to velocity so it is elastic. Your proposed effect
> is proportional to velocity so it is inelastic. Your proposal
> is dead in the water but you have been missing that altogether.
Gerber's gravity is basically a modification to the Newtonian
gravitational potential. Gerber's gravitational potential is
U = ((G M / c^2) / r) / (1 - dr/dt / c)^2
With that gravitational potential, Gerber was able to show Mercury's
orbital anomaly in terms of advance in its perihelion. The
mathematical method pioneered by Gerber to derive the advancement in
angle was adopted by Einstein almost 16 years without referencing to
GR. In fact, it is still the choice of tools among all textbooks
since then.
Thus, what you are saying just does not prove anything.
Eric Gisse
Gerber again?!
http://groups.google.com/group/sci.physics.relativity/msg/3a57c809c15fa348?dmode=source
[Notice how I can find my own posts yet you are incapable of managing
this yourself]
http://www.mathpages.com/home/kmath527/kmath527.htm
Gerber's potential has no actual motivation. The result Gerber used is
derivable from first principles - Gerber simply postulates it. It is
fantastically untrue to say that Einstein used his result.
>
> Thus, what you are saying just does not prove anything.
Thus, Koobe Wublee babbles about a subject he does not understand.
Again.
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1181653643.0...@z28g2000prd.googlegroups.com...
>> On 12 Jun, 04:09, "Max Keon" <maxk...@optusnet.com.au> wrote:
>>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>>> news:f4bo4l$589$1...@news.freedom2surf.net...
>>>> "Max Keon" <maxk...@optusnet.com.au> wrote in message
>>>> news:4664a011$0$22547$afc3...@news.optusnet.com.au...
> ---
>
>> it is the same as you were saying:
>>
>>>> In fact you said the anisotropy _decreases_ the force
>>>> on the inward leg so that increases the perihelion
>>>> distance and decreases the aphelion reducing the
>>>> eccentricity. Suppose the planet would move from
>>>> A to B to C to D without the anisotropy, it goes
>>>> from A to B to E to F if the anisotropy is switched
>>>> on between B and E then off again:
>>>>
>>>> A
>>>> B
>>>> E
>>>> C
>>>> F
>>>>
>>>>
>>>> Sun
>
> Very carefully note the gravitational potential at F compared
> with D when normal gravity is reinstated.
The potential at F is a smaller negative number compared
to D. You don't need to say "normal gravity is reinstated",
the potential is the same regardless and the anisotropy
never switches off, though it goes to zero at perihelion
and aphelion of course.
> Also note that
> Mercury's orbital velocity is slower than if it had been drawn
> down the normal path.
Yes that is correct as well
> Mercury's fall to the radius of C, which is now labeled F, has
> been delayed, ...
Yes that is correct again.
> but the prevailing conditions are exactly as they
> would have been at C. It will now begin the same fall to the Sun
> as it would have from C.
No, that is where you are missing a subtlety. The
path from B to F has fallen the same distance (same
change of radius) but Mercury moved farther round in
its orbit. If you imagine a circular orbit passing
through C and F, the path BC meets it at a larger
angle than the path BF. That change of direction is
critical to understanding what happens: the path with
the anisotropy has a direction that is more like the
circular orbit than the path without.
> 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. Now you are right, the
perihelion moves farther round the orbit but I can't
easily alter the diagram to show that so you will
have to imagine that the segment ABEFG ahs been moved
anticlockwise round from where it should be just for
comparison (or ease of drawing).
> It doesn't matter to which part of the orbit your logic is
> applied, no energy will be shifted from the Sun-Mercury closed
> gravitating system.
A small amount is lost but it is almost negligible in
this context, energy really only becomes important
when considering the "rest of the universe" question.
Your point above is correct, at F the planet has less
kinetic energy and more potential energy so the total
is virtually the same as at point C.
The major effect is not on the energy of the orbit but
on the eccentricity. The perihelion has moved outward
by 2010938 m compared to the orbit without anisotropy.
> 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.
> but it can be pictured as a multitude of minute on or off steps
> that increment and decrement proportionally to radial velocity
> change. Each rise step has a counteractory fall step over each
> half cycle.
>
> Perhaps you can understand what I mean now?
I don't dispute any of what you said but you have
missed the key point again, the direction of
motion (angle relative to a circular orbit or to
the planet-Sun line) at F is not the same as at C,
and that change increases the perihelion as you
said in your previous post.
Yes that's right, it is really a mirror of the inward
leg only this time the aphelion is reduced rather than
perihelion being increased. Again it reduces eccentricity.
> Remember
> that the anisotropy is just like any other gravity, acting along
> a direct line to the Sun, and if the pull holds Mercury more to
> the Sun its orbital velocity must remain higher, around a tighter
> curve.
That's right, that's why it turns it back at a lower
aphelion value.
> Try to remember that the anisotropy is only gravity.
It is additional to it but that's semantics.
I approached it a different way, I set a breakpoint
on the detection of aphelion and perihelion and
commented out the anisotropy or left it in for each
part and changed the colour of the plot points. I
haven't found a way to do screen grabs from XP yet
but the sequence was this:
1) Run a full orbit with anisotropy off.
2) Run an inward leg only with anisotropy on.
You can see it reaches perihelion later and
it is farther from the Sun.
3) Run a full orbit with anisotropy off.
That lets you see the new reference elliptical
orbit and how the increased perihelion means
the aphelion has to decrease for the same total
energy.
4) Run an outward leg only with anisotropy on.
The path falls inside the ellipse of step 3 so
the aphelion is reduced even farther. It falls
9262870 m inside the original aphelion and is
again later in the orbit.
5) Run a full orbit with anisotropy off.
That lets you see how the reduced aphelion means
another increase of perihelion for the same energy.
It is important that each time you just change the
anisotropy calculation and then continue because the
speeds and location need to carry through to the next
step. The display is clearer if you multiply the
anisotropy by 3000 but use 1 times if you are saving
actual numbers.
> It's based on your most
> recent method update, which I assume hasn't changed.
I explained the penultimate refinement regarding
mean acceleration. The final one hasn't been posted
yet (I think) but is the same approach applied to
the anisotropy. Both changes only make a difference
of a few metres so I'll not bother posting the details
unless you are interested.
> This time it's set up to plot every one second step of an
> orbit which is more eccentric than that of Mercury so as to
> highlight any possible problems. As well as showing the supposed
> anisotropic decay, it clearly shows a fairly rapid decay in the
> normal orbit (blue curve) in the very first cycle. Is that what
> you expected?
I couldn't get the second leg to run but maybe
because I edited it incorrectly. I'll include my
version below. The pure elliptical paths without
anisotropy are green, blue and magenta. The
transitional paths with anisotropy are grey then
red. In reality, only the grey then red would
occur of course, the others are just for reference.
Note "mag" is set to 3000, change it to 1 for real
values (no effect on the display). K = 0 if the
anisotropy is 0 when anisotropy is of or K = mag
when it is on.
> 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.
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.)
George
DIM c AS DOUBLE, GM AS DOUBLE
DIM time AS DOUBLE, dt AS DOUBLE, sinceTurn AS DOUBLE
DIM x AS DOUBLE, y AS DOUBLE
DIM px AS DOUBLE, py AS DOUBLE, lastPx AS DOUBLE, lastPy AS DOUBLE
DIM lastX AS DOUBLE, lastY AS DOUBLE
DIM prevX AS DOUBLE, prevY AS DOUBLE
DIM scale AS DOUBLE, xOffset AS DOUBLE, yOffset AS DOUBLE
DIM vx AS DOUBLE, vy AS DOUBLE, vr AS DOUBLE, lastVr AS DOUBLE
DIM ax AS DOUBLE, ay AS DOUBLE, ar AS DOUBLE
DIM axPrev AS DOUBLE, ayPrev AS DOUBLE
DIM axMean AS DOUBLE, ayMean AS DOUBLE
DIM radiusSquared AS DOUBLE, radius AS DOUBLE, turnRadius AS DOUBLE
DIM lastRadius AS DOUBLE, prevRadius AS DOUBLE
DIM Newton AS DOUBLE, acceleration AS DOUBLE, anisotropy AS DOUBLE
DIM simLength AS DOUBLE, orbitnum AS DOUBLE
DIM hemi AS INTEGER, show AS INTEGER
DIM K AS DOUBLE, mag AS DOUBLE, colour AS INTEGER
SCREEN 12
CLS
K = 0
mag = 3000
colour = 2
REM Constants - all values are in SI units. Note
REM that the GM product is negative as the Newtonian
REM force pulls the body towards the Sun.
c = 299792458#
GM = -1.327D+20
REM Simulation timestep of 30s and maximum duration.
dt = 100
simLength = 10000000000#
REM Screen scaling factors.
scale = 2E-09
xOffset = 320
yOffset = 240
PSET (xOffset, yOffset)
REM Initial values
x = 69820000000#
y = 0
vx = 0
vy = 38855
REM Internal variables
time = 0
orbitnum = 0
lastRadius = x
prevRadius = x
lastX = x
lastY = y
prevX = x
prevY = y
REM ==========================
REM ==== Start the loop ====
REM ==========================
timestep:
REM Find the square of the radius then the radius.
radiusSquared = x * x + y * y
radius = SQR(radiusSquared)
REM ======================================================
REM ==== Detect the aphelion and perihelion points. ====
REM ======================================================
IF hemi = 1 THEN
IF radius < lastRadius THEN ' Found aphelion
hemi = 0
show = 1
IF orbitnum < .7 THEN
K = mag
colour = 8
ELSEIF orbitnum < 1.7 THEN
' continue second ellipse
ELSEIF orbitnum < 2.7 THEN
K = 0
colour = 5
ELSE
END
END IF
END IF
ELSE
IF radius > lastRadius THEN ' Found perihelion
hemi = 1
show = 1
IF orbitnum < .2 THEN
' continue first ellipse
ELSEIF orbitnum < 1.2 THEN
K = 0
colour = 3
ELSEIF orbitnum < 2.2 THEN
K = mag
colour = 4
END IF
END IF
END IF
IF show = 1 THEN
PSET (px - 1, py), 14
PSET (px + 1, py), 14
show = 0
orbitnum = orbitnum + .5
END IF
REM ===================================================
REM ==== Do the physics to move to the next step ====
REM ===================================================
REM Find the Newtonian acceleration.
Newton = GM / radiusSquared
REM ===================================================
REM The anisotropy depends on the radial speed which is
REM the rate of change of radius or change divided by
REM delta time.
REM ===================================================
lastVr = vr
vr = (radius - lastRadius) / dt
REM ===================================================
REM ==== Modify acceleration for the anisotropy. ====
REM ===================================================
anisotropy = Newton * (3 * vr - lastVr) / (2 * c)
acceleration = Newton + anisotropy * K
REM ======================================================
REM Capture the current values for use in various places
REM before moving on a step.
REM ======================================================
prevRadius = lastRadius
prevX = lastX
prevY = lastY
lastRadius = radius
lastX = x
lastY = y
axPrev = ax
ayPrev = ay
REM ===================================================
REM ==== Integrate the acceleration and velocity ====
REM ===================================================
REM Find the present acceleration components.
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
REM This is a modified Verlet integrator using a
REM linear forward estimator for the acceleration.
REM The Mean values are over the coming time step
REM based on assuming the same rate of change of
REM acceleration as over the previous step.
axMean = (3 * ax - axPrev) / 2
ayMean = (3 * ay - ayPrev) / 2
REM The locations change by the mean velocity times the
REM step duration which is given by Newton's equation:
REM s = ut + 1/2 a t^2.
x = x + dt * (vx + .5 * dt * axMean)
y = y + dt * (vy + .5 * dt * ayMean)
REM The velocity changes by the mean acceleration
REM multiplied by the timestep duration.
vx = vx + dt * axMean
vy = vy + dt * ayMean
REM Finally step the time forward. Time is not currently
time = time + dt
REM ======================================
REM ==== Show the graphical display ====
REM ======================================
REM Convert location to screen coordinates.
px = xOffset + x * scale
py = yOffset - y * scale
IF (px <> lastPx) OR (py <> lastPy) THEN
PSET (px, py), colour
lastPx = px
lastPy = py
END IF
REM =======================================================
REM ==== Check for completion of the desired orbits. ====
REM =======================================================
REM The time check is a safeguard in case the
REM aphelion/perihelion detection gets broken.
IF (orbitnum < 10000.6) AND (time < simLength) GOTO timestep
END
Koobee Wublee
> On Jun 15, 10:32 pm, Koobee Wublee <koobee.wub...@gmail.com> wrote:
> > Gerber's gravity is basically a modification to the Newtonian
> > gravitational potential. Gerber's gravitational potential is
>
> > U = ((G M / c^2) / r) / (1 - dr/dt / c)^2
>
> > With that gravitational potential, Gerber was able to show Mercury's
> > orbital anomaly in terms of advance in its perihelion. The
> > mathematical method pioneered by Gerber to derive the advancement in
> > angle was adopted by Einstein almost 16 years without referencing to
> > GR. In fact, it is still the choice of tools among all textbooks
> > since then.
>
> Gerber again?!
Yes, Mr. Keon's modification of the Newtonian gravitational potential
is very similar to what Gerber did. <shrug>
> http://groups.google.com/group/sci.physics.relativity/msg/3a57c809c15...
>
> [Notice how I can find my own posts yet you are incapable of managing
> this yourself]
Maybe I just don't have all this free time as you do. <shrug>
Hint: I have a life.
> http://www.mathpages.com/home/kmath527/kmath527.htm
>
> Gerber's potential has no actual motivation.
Bullsh*t! His motivation was to explain Mercury's orbital anomaly.
<shrug>
> The result Gerber used is
> derivable from first principles - Gerber simply postulates it.
Einstein did exactly the same crap before GR. <shrug>
GR is the same crap. <shrug>
> It is
> fantastically untrue to say that Einstein used his result.
The result is the 43" of observation. I said Einstein and modern
physicists all have used Gerber's methodology to derive Mercury's
orbital anomaly. In Gerber's circumstance, it is valid. However,
under the concept of spacetime, it is not. Why?
Hint:
** ds^2 = g_11 dt^2 - g_22 dr^2 - g_33 dO^2
And
** d^2r/dO^2 = d^2r/dOds ds/dO + dr^2r/dOdt dt/dO
> > Thus, what you are saying just does not prove anything.
>
> Thus, Koobe Wublee babbles about a subject he does not understand.
> Again.
You are so wrong again. <shrug>
Eric Gisse
[...]
>
> > It is
> > fantastically untrue to say that Einstein used his result.
>
> The result is the 43" of observation. I said Einstein and modern
> physicists all have used Gerber's methodology to derive Mercury's
> orbital anomaly. In Gerber's circumstance, it is valid. However,
> under the concept of spacetime, it is not. Why?
The question is based upon the false premise that physicists use
"Gerber's methodology". This is not true - consult any intermediate
text on general relativity.
Way back in February I gave you a /good/ reference on Gerber's
gravity:
http://www.mathpages.com/home/kmath527/kmath527.htm
There is an explicit comparison of the equations of motion - read the
following:
"It just so happens that the term +3mu2 in the GR equation of motion
and the term -6mu d2u/dq2 in Gerber's equation of motion both result
in a first-order precession of 6pm/L in the slow weak-field limit.
Thus Gerber did not in any way anticipate the two-body equation of
motion predicted by general relativity, let alone the field equations
from which the relativistic equation of motion is derived."
The explicit derivation of the equations of motion is here:
http://www.mathpages.com/rr/s6-02/6-02.htm
You continue to talk about stuff you just /do not understand/.
[snip crap]
Koobee Wublee
> On Jun 16, 7:40 pm, Koobee Wublee <koobee.wub...@gmail.com> wrote:
> > The result is the 43" of observation. I said Einstein and modern
> > physicists all have used Gerber's methodology to derive Mercury's
> > orbital anomaly. In Gerber's circumstance, it is valid. However,
> > under the concept of spacetime, it is not. Why?
>
> The question is based upon the false premise that physicists use
> "Gerber's methodology". This is not true - consult any intermediate
> text on general relativity.
The following website quoted describes exactly how Gerber did it.
http://www.mathpages.com/home/kmath527/kmath527.htm
The methodology is exactly what modern physicists do to derive
Mercury's orbital anomaly. <shrug>
> Way back in February I gave you a /good/ reference on Gerber's
> gravity:
>
> http://www.mathpages.com/home/kmath527/kmath527.htm
I know about that one for years. Thank you.
> There is an explicit comparison of the equations of motion - read the
> following:
>
> "It just so happens that the term +3mu2 in the GR equation of motion
> and the term -6mu d2u/dq2 in Gerber's equation of motion both result
> in a first-order precession of 6pm/L in the slow weak-field limit.
> Thus Gerber did not in any way anticipate the two-body equation of
> motion predicted by general relativity, let alone the field equations
> from which the relativistic equation of motion is derived."
When Gerber derived the result, GR was still 16 years in the future.
<shrug>
However, the term, 3mu2 (3 G M /c^2 U^2), describes in term of orbital
speed that Mercury will complete a circle in exactly sqrt(3 G M /
c^2 / R) in radian faster than the Newtonian result. This translates
to half of 43" per century!!!
> The explicit derivation of the equations of motion is here:
>
> http://www.mathpages.com/rr/s6-02/6-02.htm
The equation right below (5) is not valid because r can also be a
function of t and O according to the spacetime equation. <shrug>
> You continue to talk about stuff you just /do not understand/.
This appears to you so because you don't understand the stuff.
<shrug>
Eric Gisse
[...]
>
> When Gerber derived the result, GR was still 16 years in the future.
> <shrug>
>
> However, the term, 3mu2 (3 G M /c^2 U^2), describes in term of orbital
> speed that Mercury will complete a circle in exactly sqrt(3 G M /
> c^2 / R) in radian faster than the Newtonian result. This translates
> to half of 43" per century!!!
No, it doesn't.
Of course, if you want to argue the point I will gladly look at your
derivation. If you don't have a derivation to show me, then I am
uninterested in your assertions.
>
> > The explicit derivation of the equations of motion is here:
>
> >http://www.mathpages.com/rr/s6-02/6-02.htm
>
> The equation right below (5) is not valid because r can also be a
> function of t and O according to the spacetime equation. <shrug>
The phrase "spacetime equation" is nonsense.
The spatial variable r is trivially a function of time and angle, but
those functionalities are unimportant because of the conserved
quantities associated with the manifold.
>
> > You continue to talk about stuff you just /do not understand/.
>
> This appears to you so because you don't understand the stuff.
> <shrug>
I can point to a handful of books and resources and say 'this is where
I have learned general relativity'. Why don't you point to the
resources _YOU_ learned GR from so I can see where your coming from?
If you don't have them, why are you even arguing?
Koobee Wublee
> On Jun 16, 10:37 pm, Koobee Wublee <koobee.wub...@gmail.com> wrote:
> > When Gerber derived the result, GR was still 16 years in the future.
> > <shrug>
>
> > However, the term, 3mu2 (3 G M /c^2 U^2), describes in term of orbital
> > speed that Mercury will complete a circle in exactly sqrt(3 G M /
> > c^2 / R) in radian faster than the Newtonian result. This translates
> > to half of 43" per century!!!
>
> No, it doesn't.
I meant sqrt(1 + 3 G M / c^2 / R).
> Of course, if you want to argue the point I will gladly look at your
> derivation. If you don't have a derivation to show me, then I am
> uninterested in your assertions.
This is not my derivation. This is the derivation you have posted
from the website below. <shrug>
> > >http://www.mathpages.com/rr/s6-02/6-02.htm
>
> > The equation right below (5) is not valid because r can also be a
> > function of t and O according to the spacetime equation. <shrug>
>
> The phrase "spacetime equation" is nonsense.
The equation is the familiar one describing a segment of spacetime.
<shrug>
You are jumping on the same wagon of the ones who blame their
ignorance on vocabularies after been presented with the proper math.
<shrug>
> The spatial variable r is trivially a function of time and angle, but
> those functionalities are unimportant because of the conserved
> quantities associated with the manifold.
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>
> > This appears to you so because you don't understand the stuff.
> > <shrug>
>
> I can point to a handful of books and resources and say 'this is where
> I have learned general relativity'.
But you cannot point out one that does not contradict itself. <shrug>
> Why don't you point to the
> resources _YOU_ learned GR from so I can see where your coming from?
This is not about who can find the most popular references. <shrug>
> If you don't have them, why are you even arguing?
This is about GR and SR themselves. <shrug>
Eric Gisse
> On Jun 17, 1:58 am, Eric Gisse <jowr...@gmail.com> wrote:
>
> > On Jun 16, 10:37 pm, Koobee Wublee <koobee.wub...@gmail.com> wrote:
> > > When Gerber derived the result, GR was still 16 years in the future.
> > > <shrug>
>
> > > However, the term, 3mu2 (3 G M /c^2 U^2), describes in term of orbital
> > > speed that Mercury will complete a circle in exactly sqrt(3 G M /
> > > c^2 / R) in radian faster than the Newtonian result. This translates
> > > to half of 43" per century!!!
>
> > No, it doesn't.
>
> I meant sqrt(1 + 3 G M / c^2 / R).
>
> > Of course, if you want to argue the point I will gladly look at your
> > derivation. If you don't have a derivation to show me, then I am
> > uninterested in your assertions.
>
> 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".
>
> > > >http://www.mathpages.com/rr/s6-02/6-02.htm
>
> > > The equation right below (5) is not valid because r can also be a
> > > function of t and O according to the spacetime equation. <shrug>
>
> > The phrase "spacetime equation" is nonsense.
>
> The equation is the familiar one describing a segment of spacetime.
> <shrug>
>
> 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'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.
>
> > The spatial variable r is trivially a function of time and angle, but
> > those functionalities are unimportant because of the conserved
> > quantities associated with the manifold.
>
> 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.
>
> > > This appears to you so because you don't understand the stuff.
> > > <shrug>
>
> > I can point to a handful of books and resources and say 'this is where
> > I have learned general relativity'.
>
> But you cannot point out one that does not contradict itself. <shrug>
None of them do. You cannot claim differently because you don't own
any textbooks on GR.
>
> > Why don't you point to the
> > resources _YOU_ learned GR from so I can see where your coming from?
>
> This is not about who can find the most popular references. <shrug>
Who said anything about popular? I am yet to see you post even ONE
reference that I have not already given you.
Koobee Wublee
> On Jun 17, 8:01 pm, Koobee Wublee <koobee.wub...@gmail.com> 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>
Eric Gisse
> On Jun 18, 12:02 am, Eric Gisse <jowr...@gmail.com> wrote:
>
> > On Jun 17, 8:01 pm, Koobee Wublee <koobee.wub...@gmail.com> 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?
Max Keon
> "Max Keon" <max...@optusnet.com.au> wrote in message
> news:46733161$0$29666$afc3...@news.optusnet.com.au...
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>> news:1181653643.0...@z28g2000prd.googlegroups.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
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>
> >news:46733161$0$29666$afc3...@news.optusnet.com.au...
> >> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> >>news:1181653643.0...@z28g2000prd.googlegroups.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
George Dishman
...
> 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
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
Max Keon
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."
George Dishman
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
Max Keon
> "Max Keon" <max...@optusnet.com.au> wrote in message
> news:467c7239$0$4364$afc3...@news.optusnet.com.au...
>> 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
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
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>
> >news:467c7239$0$4364$afc3...@news.optusnet.com.au...
>
> ---
>
> >> 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
George Dishman
It is wrong anyway since it is changed by the anisotropy.
In fact all the formulae and assumptions you are trying
to use are susceptible to being invalidated by your
change to gravity. Only the raw definitions remain valid
so this really is very simple:
1) you gave me an equation for the acceleration
2) acceleration is defined as rate of change of velocity
3) velocity is defined as rate of change of location
Therefore if I integrate your modified acceleration (Newton
plus anisotropy) twice, I get the location as a function of
time, i.e. the path of the planet.
That's what the program does, so for the anisotropy you have
described, the program results are valid to the accuracy I
demonstrated. That's the beginning and end of this argument.
George
Max Keon
> "Max Keon" <max...@optusnet.com.au> wrote in message
> news:46845573$0$13845$afc3...@news.optusnet.com.au...
Firstly, I've included two paragraphs from your other reply
because I don't wish to go off on another tangent that repeats
what will be addressed here.
>> ... 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.
Maybe the trigger point does index around, but the aphelion
and perihelion approach is still halted at that point because
you are assuming that anisotropic gravity is inelastic. But
you have no evidence to support that assumption.
> That value is greater than
> it would have been without the anisotropy exactly
> as you said it would be a few posts back
"exactly as I said it would be", was according to your reasoning
George, not mine. If I agree with the consequences of your
reasoning, that doesn't mean I accept your reasoning in
principle.
-------------
>> 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.
> It is wrong anyway since it is changed by the anisotropy.
I take it that you were not aware that Mercury's fall distance
for each half orbit is equal to the orbit diameter, and that it's
equal to the time for the half orbit divided by pi/2 multiplied
by the orbital speed, because the consequences of that are far
reaching and would have been well documented by now. And you
would have made use of that logic when you were attempting to
calculate the acceleration distance in each chosen batch size
of dt seconds in length for your program, instead of going about
it the way you did.
Elaborating; The fall distance for Mercury's half orbit is
d = 3801600 / (pi/2) * 48000 = 1.16e11 meters, which is
of course the orbit diameter from aphelion to perihelion.
Or, 2/(d/v^2) = newton = .0397m/sec^2, being the average
acceleration rate to the far side of the orbit.
It can also be stated as dt = (2*d/newton)^.5 = 2417400 seconds.
That can be adjusted to include fall = (dt * newton^.5)^2 / 2
The values of dt and newton can then be set to suit one's needs,
and the result will always be correct. newton can be replaced by
anything, even the anisotropy.
Words don't mean much though, so I've modified your program
again and attached it to the post to prove my point. There's no
need to thank me.
> In fact all the formulae and assumptions you are trying
> to use are susceptible to being invalidated by your
> change to gravity. Only the raw definitions remain valid
> so this really is very simple:
>
> 1) you gave me an equation for the acceleration
>
> 2) acceleration is defined as rate of change of velocity
>
> 3) velocity is defined as rate of change of location
>
> Therefore if I integrate your modified acceleration (Newton
> plus anisotropy) twice, I get the location as a function of
> time, i.e. the path of the planet.
Without the anisotropy, you are plotting the path of a planet
in a sustainable orbit, and it makes no difference if the orbit
is elliptical or circular the same rules apply. The total radius
change is zero, even though the fall distance per half orbit
cycle is twice the radius.
Even though you deny that the radius changes, you attempt to
change it by the full extent of the anisotropy, which is
_blatantly_ wrong.
With dt set to 2417400 seconds, being half the orbit cycle time
/ (pi/2) and an added acceleration rate of e.g. 8e-7, according
to (dt * newton^.5)^2 / 2, fall = (2417400 *.0397008^.5)^2 / 2
= 116002219315 meters for the half cycle. The fall without the
added acceleration is 115999881786 meters. That's a ratio of
1.00002015 to 1. That's comparable with va^2 / vb^2 found at this
address http://members.optusnet.com.au/maxkeon/peri.html
-----
Max Keon
'------------------------------
' This program does not represent reality. It's geared more to
' demonstrate that it doesn't.
' If you run the program you will notice that there is little or
' no orbit eccentricity decay due to the anisotropy. But there is
' a distinct radial contraction, as should be expected if the
' anisotropy is inelastic. Where the energy would go still
' remains a mystery.
' There are a couple of problems in running the program.
' XP becomes bogged down when the keyboard is rapidly accessed
' using the INKEY$ function. Constant key pushing is required
' to keep it going.
' And
' The greater the dt value the faster is the fall to the Sun.
' That is probably due to the greater degree of overlap at the
' end of each half cycle for the higher dt values, encroaching
' into the realm of the following half cycle.
DEFDBL A-Z
SCREEN 12
CLS
b$ = "Press any key to check progress. Escape exits the program."
c$ = "The program normally halts at aphelion and perihelion."
colr = 1 ' This sets the initial color for the orbit.
' The need for the color mix will become apparent.
CIRCLE (250, 250), 8, 14 ' Sun.
COLOR 7
c = 299792458#
G = .0000000000667#
M = 1.99D+30
multi = .000000002#' Multiplier for the graphics.
pi = 3.1416#
x = 69820000000#: vy = 38850# ' Aphelion start.
'x = 45961000000#: vy = 59017# ' Perihelion start.
' Swap the ' switches.
lastradius = x
dt = 100 ' Set dt to whatever you like.
' dt = 5000, 10000, 20000 gives a good comparison
' when fk is set to 1.
' f? are all flags.
fk = 0 ' Set fk = 1 to remove printing delays. Control Break
' is then the only way to break out of the program.
' The program can bog down when it's set to 0.
fs = 0 ' Set fs = 1 to exclude the anisotropy.
' Note that the orbit orientation spirals
' anticlockwise for either, an aphelion or perihelion
' start when the anisotropy is excluded. The probable
' cause is given in the intro. Whatever course the
' orbit orientation is following, it can still
' represent a stable orbit. When the anisotropy is
' included, an aphelion start spirals clockwise,
' further removing it from the stable orbit, while
' a perihelion start initially spirals anticlockwise
' at a faster rate than the stable orbit, then slowly
' reverts to a clockwise spiral as it falls to the
' Sun. Which is to be expected if anisotropic gravity
' is inelastic.
IF fk = 0 THEN LOCATE 26, 6: PRINT b$: LOCATE 27, 6: PRINT c$
aa:
r2 = x * x + y * y
radius = SQR(r2)
IF radius > 1000000000000# THEN PRINT fr; "cycles": END
' This only applies after the fall has reached the Sun.
vr = (radius - lastradius) / dt
lastradius = radius
newton = G * M / r2
an = (vr / c) * newton
' 'an' is the anisotropy.
'v = (vx ^ 2# + vy ^ 2#) ^ .5# ' Orbital speed.
acceleration = -newton
IF fs = 0 THEN GOSUB af
IF fs = 1 THEN GOSUB ag
' These original equations have been shifted.
' 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 (250 + x * multi, 250 + y * multi), 0, colr
IF an > 0 THEN fx = 0
IF an < 0 THEN an = -an: fx = 1 'The sign change accommodates
' an^.5 in the next equation if 'an' is negative.
fall = (dt * an ^ .5) ^ 2 / 2
' This equation gives the same result as compounding
' the anisotropy for each second.
IF fx = 1 THEN fall = -fall: an = -an ' The sign change to 'an',
' and its consequences are reset to the way they would
' normally be.
stora = stora + fall
storb = storb + stora ' Total fall storage.
IF fk = 0 THEN GOSUB ad ' Screen print options.
IF fk = 1 THEN GOSUB ae
IF fw > 2000 THEN colr = colr + 1: fw = 0
IF colr > 15 THEN colr = 1
fw = fw + 1
GOTO aa
'---This section simply compiles the anisotropic acceleration
'---for each second and stores it in stord. It provides the true
'---result with which to test the equation fall = (dt*an^.5)^2/2
'---
ab: IF ft = 0 THEN ana = an / 2: ft = 1
' The fall over the first second is .5 of the
' final acceleration rate at the end of that second.
storc = storc + ana
stord = stord + storc
tx = tx + 1
ana = an
IF tx < dt THEN GOTO ab
LOCATE 6, 1
PRINT stord; "fall distance check per 1 second increments. "
tx = 0: storc = 0: stord = 0: ft = 0
'----------------
ac: LOCATE 1, 1: PRINT fr; "cycles "
PRINT " Batch size ="; dt; " seconds. "
PRINT radius; "radius "
PRINT an; "anisotropy "
PRINT fall; "meter fall distance per batch size. "
PRINT
PRINT -storb; "radius change. "
DO: s$ = INKEY$: LOOP UNTIL s$ <> ""
IF s$ = CHR$(27) THEN END
s$ = ""
RETURN
ad:
s$ = INKEY$: IF s$ <> "" THEN GOSUB ab
IF vr > 0 AND fa = 0 THEN fb = 1: fa = 1: fr = fr + .5: GOSUB ab
IF vr < 0 AND fb = 1 THEN fa = 0: fb = 0: fr = fr + .5: GOSUB ab
RETURN
ae:
IF vr > 0 AND fa = 0 THEN fb = 1: fa = 1: fr = fr + .5
IF vr < 0 AND fb = 1 THEN fa = 0: fb = 0: fr = fr + .5
' Cycle count (erroneously adds an extra half cycle
' for perihelion start).
RETURN
af:
ax = acceleration * (x / (radius + storb))
ay = acceleration * (y / (radius + storb))
' Apart from the improved precision, adjusting the
' radius with the total anisotropic fall for each dt
' second batch is no different to adding the
' anisotropy directly to newton and multiplying it
' by dt.
RETURN
ag:
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
' No anisotropy.
RETURN
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:f63elr$eff$3...@news.freedom2surf.net...
> >news:46845573$0$13845$afc3...@news.optusnet.com.au...
...
> >> ... 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.
>
> Maybe the trigger point does index around, but the aphelion
> and perihelion approach is still halted at that point because
> you are assuming that anisotropic gravity is inelastic.
No, you can read how the program works yourself,
there is no such assumption anywhere in it. I
find the perihelion and aphelion simply from the
minimum and maximum radius values, the radius is
found trivially by applying Pythagoras to the x
and y coordinates, and those in turn are found
by _correctly_ integrating the acceleration that
Newton plus your anisotropy provide.
> But
> you have no evidence to support that assumption.
I have told you repeatedly what the evidence is,
an elastic equation cannot depend on any variable
other than radius. You have speed in the equation
so it is inelastic, but this is irrelevant since
it does not appear anywhere in the program, a fact
you can check for yourself quite easily.
> > That value is greater than
> > it would have been without the anisotropy exactly
> > as you said it would be a few posts back
>
> "exactly as I said it would be", was according to your reasoning
> George, not mine. If I agree with the consequences of your
> reasoning, that doesn't mean I accept your reasoning in
> principle.
No, it means I accepted yours. You said the path
would be farther from the Sun and I agree, you
were correct.
> >> 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.
Since, for a given starting aphelion, the next
perihelion radius is increased by the anisotropy,
the "diameter" is not the same as it would be
without the anisotropy. The rest of the part of
your argument based on that assumption is
therefore invalid, as is your alternative program.
> >> 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.
> > It is wrong anyway since it is changed by the anisotropy.
>
> I take it that you were not aware that Mercury's fall distance
> for each half orbit is equal to the orbit diameter,
It depends what you mean by "fall distance". I
took that to be the difference between aphelion
and perihelion but what you call the "diameter",
by which I assume you mean the major axis, is
the sum of the two, not the difference. In that
sense what you are saying makes no sense, but
since the length of the major axis is changed
by the anisotropy, it isn't relevant anyway.
> and that it's
> equal to the time for the half orbit divided by pi/2 multiplied
> by the orbital speed, because the consequences of that are far
> reaching and would have been well documented by now. And you
> would have made use of that logic when you were attempting to
> calculate the acceleration distance in each chosen batch size
> of dt seconds in length for your program, instead of going about
> it the way you did.
No, the definition of acceleration requires
that it be used exactly the way I used it. You
need to learn these basic definitions Max, there
is no flexibility in how you do this part, your
options are limited to changing the equation for
the acceleration if you don't like the outcome,
and if the equation is correctly derived from
your concepts then those concepts are wrong.
> Elaborating; The fall distance for Mercury's half orbit is
> d = 3801600 / (pi/2) * 48000 = 1.16e11 meters, which is
> of course the orbit diameter from aphelion to perihelion.
> Or, 2/(d/v^2) = newton = .0397m/sec^2, being the average
> acceleration rate to the far side of the orbit.
No, acceleration is a vector and includes direction.
You are trying to use it as a scalar which is wrong
and will not work.
> Words don't mean much though, so I've modified your program
> again and attached it to the post to prove my point. There's no
> need to thank me.
Since your approach is completely wrong, I feel no
temptation to do so. The program I gave you uses
the acceleration correctly. The values are of course
taken from your equation but now that I have showed
you how acceleration has to be used, you might want
to reconsider your equation.
> > In fact all the formulae and assumptions you are trying
> > to use are susceptible to being invalidated by your
> > change to gravity. Only the raw definitions remain valid
> > so this really is very simple:
>
> > 1) you gave me an equation for the acceleration
>
> > 2) acceleration is defined as rate of change of velocity
>
> > 3) velocity is defined as rate of change of location
>
> > Therefore if I integrate your modified acceleration (Newton
> > plus anisotropy) twice, I get the location as a function of
> > time, i.e. the path of the planet.
>
> Without the anisotropy, you are plotting the path of a planet
> in a sustainable orbit, and it makes no difference if the orbit
> is elliptical or circular the same rules apply. The total radius
> change is zero, even though the fall distance per half orbit
> cycle is twice the radius.
>
> Even though you deny that the radius changes, ..
At no time did I say the radius wasn't affected, you
have picked up a misunderstanding somewhere. Perhaps
it was when we were talking of a circular orbit.
> .. you attempt to
> change it by the full extent of the anisotropy, which is
> _blatantly_ wrong.
Of course, and that is _correct_. You have in effect
told me how much to use when you included the term v/c
in your equation for the anisotropy, I include v/c
times the Newtonian value. If you think that is too
much, you need to change the factor v/c to something
smaller, but it is up to you to do that, I just add
whatever your equation demands.
> With dt set to 2417400 seconds, being half the orbit cycle time
> / (pi/2) and an added acceleration rate of e.g. 8e-7, according
> to (dt * newton^.5)^2 / 2, fall = (2417400 *.0397008^.5)^2 / 2
> = 116002219315 meters for the half cycle. The fall without the
> added acceleration is 115999881786 meters.
Meaningless numbers Max, you have never understood that
acceleration is a _vector_, it includes _direction_ as
I explained to you in the very first exchanges on this
subject. It is the rate of change of velocity so that
means you have no choice but to find the velocity from
the acceleration by simple integration, which is what
my program does. As I have suggested before, you need
to go away and learn what a vector is before you can
sensibly continue this conversation.
George
Max Keon
> On 4 Jul, 03:04, "Max Keon" <maxk...@optusnet.com.au> wrote:
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>> news:f63elr$eff$3...@news.freedom2surf.net...
>>> "Max Keon" <maxk...@optusnet.com.au> wrote in message
>>> news:46845573$0$13845$afc3...@news.optusnet.com.au...
>>>> 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.
> Since, for a given starting aphelion, the next
> perihelion radius is increased by the anisotropy,
> the "diameter" is not the same as it would be
> without the anisotropy.
The diameter from aphelion to perihelion is the sum of the two
radii because the perihelion will have advanced slightly by the
time Mercury has fallen to the true perihelion radius.
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. Nothing is lost of course because
it's always in a position of higher gravitational potential until
the perihelion radius has been reached. That's where orbital
speed will all be put back to the way it would normally be.
And that's also why the perihelion advances.
---
>> and that it's
>> equal to the time for the half orbit divided by pi/2 multiplied
>> by the orbital speed, because the consequences of that are far
>> reaching and would have been well documented by now. And you
>> would have made use of that logic when you were attempting to
>> calculate the acceleration distance in each chosen batch size
>> of dt seconds in length for your program, instead of going about
>> it the way you did.
> No, the definition of acceleration requires
> that it be used exactly the way I used it. You
> need to learn these basic definitions Max, there
> is no flexibility in how you do this part, your
> options are limited to changing the equation for
> the acceleration if you don't like the outcome,
> and if the equation is correctly derived from
> your concepts then those concepts are wrong.
I keep on telling you that the maths you are using is incapable
of describing the anisotropy. You are miles away from the truth
with what you are doing.
>> Elaborating; The fall distance for Mercury's half orbit is
>> d = 3801600 / (pi/2) * 48000 = 1.16e11 meters, which is
>> of course the orbit diameter from aphelion to perihelion.
>> Or, 2/(d/v^2) = newton = .0397m/sec^2, being the average
>> acceleration rate to the far side of the orbit.
> No, acceleration is a vector and includes direction.
> You are trying to use it as a scalar which is wrong
> and will not work.
So you are saying that vectors and scalars are impossible to
compare? I seem to always get exactly the same fall distance from
dt^2 * anisotropy / 2 as from compounding the acceleration for
each second of dt.
Try running this program.
CLS : dt = 10000: an = 1: ax = an: ax = an / 2
aa: a = a + ax: b = b + a: ax = an: fa = fa + 1
IF fa < dt THEN GOTO aa
PRINT b; "per compounding steps"
PRINT dt ^ 2 * an / 2; "per dt^2*an/2"
---
>>> In fact all the formulae and assumptions you are trying
>>> to use are susceptible to being invalidated by your
>>> change to gravity. Only the raw definitions remain valid
>>> so this really is very simple:
>>>
>>> 1) you gave me an equation for the acceleration
>>>
>>> 2) acceleration is defined as rate of change of velocity
>>>
>>> 3) velocity is defined as rate of change of location
>>>
>>> Therefore if I integrate your modified acceleration (Newton
>>> plus anisotropy) twice, I get the location as a function of
>>> time, i.e. the path of the planet.
>>
>> Without the anisotropy, you are plotting the path of a planet
>> in a sustainable orbit, and it makes no difference if the orbit
>> is elliptical or circular the same rules apply. The total radius
>> change is zero, even though the fall distance per half orbit
>> cycle is twice the radius.
>>
>> Even though you deny that the radius changes, ..
> At no time did I say the radius wasn't affected, you
> have picked up a misunderstanding somewhere. Perhaps
> it was when we were talking of a circular orbit.
The following is an extract from your reply dated 23-5-07. The
subject title was then; Anisotropy in the gravity force, and
Mercury.
--------------------------
I wrote:
-> Therein lies a problem. The anisotropy is an acceleration force,
-> but you've treated it as a continuous force which is simply added
-> or subtracted from the orbit radius according to radial velocity.
You wrote:
-That sentence makes very little sense so I'l take it
-bit by bit.
-
-We are treating the anisotropy like the Newtonian
-gravity as an acceleration, not a force. We are
-not including the mass of Mercury in any of the
-calculations because it would cancel out.
-
-The accelerations are continuous (both Newtonian and
-the anisotropy) in that they apply at all times and
-change smoothly with time, they aren't quantised and
-changing in discrete steps.
-
-That means that any time, the acceleration adds an
-amount to the velocity which is equalt to the product
-of the time and the acceleration. It doesn't add or
-subtract from the radius, I don't know where you got
-that idea.
-------------------------
If you hadn't included "(both Newtonian and the anisotropy)" you
could have been referring to the Newtonian component only. But
you were probably talking about average radius.
That should have prompted you to question your program though
because inelastic gravity _must_ cause the average radius to
decay.
>> .. you attempt to
>> change it by the full extent of the anisotropy, which is
>> _blatantly_ wrong.
> Of course, and that is _correct_. You have in effect
> told me how much to use when you included the term v/c
> in your equation for the anisotropy, I include v/c
> times the Newtonian value. If you think that is too
> much, you need to change the factor v/c to something
> smaller, but it is up to you to do that, I just add
> whatever your equation demands.
Your whole concept is completely wrong. You have treated the
anisotropy as being entirely elastic, up to the point where
Mercury should fall to the normal aphelion or perihelion radius.
That's the part your program cannot accommodate.
If the anisotropy is elastic, then it is elastic. If it's
inelastic, it's inelastic, meaning that Mercury must lose energy
and _must_ fall to the Sun. What you have is an entirely elastic
situation which removes no energy from the system, but for some
obscure reason, the eccentricity decays.
That's hardly logical, is it!
There are several ways to arrive at the true fall distance for
the inelastic anisotropy. This one is very straight forward.
For the conditions:
anisotropy = 8e-7
r = 58000000000 meters
newton = GM/r^2
(GM/r)^.5 = 47838.26919945997 (v), is the orbital speed
required to maintain a normal stable orbit.
(newton + anisotropy)^.5 / (newton)^.5 * v
= 47838.75416438016 (vv), is the orbital speed required to
maintain a stable orbit if the anisotropy is included.
The ratio is, as always, 1.00001014 to 1.
With the added pull of gravity the orbital speed required to hold
a sustainable orbit is higher than its current speed, and so it
will fall to the Sun to some degree. But the fall will most
certainly not be to the full extent of the anisotropy. That fall
rate could only occur when orbital speed is zero.
Even if you don't agree with this equation,
fall = (vv - v) ^ 2 / v ^ 2 * anisotropy = 8.22e-17m/sec^2, you
must agree that the fall will be nothing like 100% of the
anisotropy while it's traveling 1 / 1.00001014 * 100 = 99.998986%
of the speed required to maintain a sustainable orbit _which has
no average radius reduction whatever_.
The elastic anisotropy simply travels the missing distance to
the true aphelion and perihelion radii.
>> With dt set to 2417400 seconds, being half the orbit cycle time
>> / (pi/2) and an added acceleration rate of e.g. 8e-7, according
>> to (dt * newton^.5)^2 / 2, fall = (2417400 *.0397008^.5)^2 / 2
>> = 116002219315 meters for the half cycle. The fall without the
>> added acceleration is 115999881786 meters.
> Meaningless numbers Max, you have never understood that
> acceleration is a _vector_, it includes _direction_ as
> I explained to you in the very first exchanges on this
> subject. It is the rate of change of velocity so that
> means you have no choice but to find the velocity from
> the acceleration by simple integration, which is what
> my program does. As I have suggested before, you need
> to go away and learn what a vector is before you can
> sensibly continue this conversation.
It's not my understanding that's in question here George, it's
yours.
Perhaps your confusion stems from this simple fact.
For a mass in a stable concentric orbit around the Sun at a
radius of 5.8e10 meters, traveling at 48000m/sec, if the
.04m/sec^2 pull of gravity is suddenly switched off, its
trajectory will immediately shift along a straight line path
at a tangent to the orbit radius. The change is immediate.
An obvious consequence is that the process can be reversed so
that if the mass is traveling a straight line path at 48000m/sec
and the pull of gravity is suddenly applied when it's path is
perpendicular to the Sun at a radius of 5.8e11 meters, the mass
will undergo an immediate change of direction that takes it away
from its straight line path by .02 meters in the first second.
It's immediately accelerated to the Sun at the rate of .04
m/sec^2, falling into a concentric orbit around the Sun. Again
there is no delay.
But if the central mass was twice that of the Sun, the pull of
gravity is immediately applied at .08m/sec^2, so the mass
immediately shifts course by .04 meters in the first second and
continues to accelerate at .08m/sec^2. The change is again
immediate.
If the tangent radius was 4.1e10 meters, the resulting orbit
would again be circular. But if the radius remained as before,
the orbit becomes elliptical, with an aphelion radius of 5.8e10
meters.
By adding the anisotropy directly to newton, you have varied
the orbit shape according to each gravity change in the same way
as did the original shift from the straight line path. You have
simply shifted it from whatever path it was on at the time.
There's nothing wrong with that part, but you forgot to continue
on to the true aphelion and perihelion radii.
If this line represents the normal orbit trajectory between
aphelion and perihelion
- - - - - - - - - - - - - - - -
this is how the anisotropy changes the trajectory enroute to
perihelion.
_ - ->> - _
- -
Aphelion Perihelion
SUN
Note that Mercury is heading more toward the Sun than normal at
the end of the journey, where the perihelion would normally be
if there was no advance. And it has arrived there with a lesser
orbital speed than normal.
And this is how it affects the trajectory enroute to aphelion.
Aphelion Perihelion
- _ _ -
- <<- -
SUN
Mercury is now heading more away from the Sun at journey's end
where the aphelion would normally be if there was no advance.
Its path was nearer to the Sun so it arrives with a higher
orbital speed than normal. The consequence of that is obvious.
That's where your program fails to deliver.
I have previously assumed that your program causes the anisotropy
to generate a relatively enormous radius change for the up and
the down legs of Mercury's orbit. But in the process of pointing
out the root of your confusion, it has become apparent that the
cause is only that the anisotropy has been added to the normal
orbit as a distinct change which occurred suddenly at either
the aphelion or perihelion. That sudden change will have the same
consequences as applying gravity to the straight line path,
above.
A completely new orbit structure is forming.
-----
Max Keon
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1183533792.9...@k79g2000hse.googlegroups.com...
>
> > On 4 Jul, 03:04, "Max Keon" <maxk...@optusnet.com.au> wrote:
> >> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> >>news:f63elr$eff$3...@news.freedom2surf.net...
> >>> "Max Keon" <maxk...@optusnet.com.au> wrote in message
> >>>news:46845573$0$13845$afc3...@news.optusnet.com.au...
> >>>> 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.
> >
> > Since, for a given starting aphelion, the next
> > perihelion radius is increased by the anisotropy,
> > the "diameter" is not the same as it would be
> > without the anisotropy.
>
> The diameter from aphelion to perihelion is the sum of the two
> radii because the perihelion will have advanced slightly by the
> time Mercury has fallen to the true perihelion radius.
Yes, that makes it not quite a "diameter" but more of
a dogleg shape but that's a secondary point.
> 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.
...
> >> and that it's
> >> equal to the time for the half orbit divided by pi/2 multiplied
> >> by the orbital speed, because the consequences of that are far
> >> reaching and would have been well documented by now. And you
> >> would have made use of that logic when you were attempting to
> >> calculate the acceleration distance in each chosen batch size
> >> of dt seconds in length for your program, instead of going about
> >> it the way you did.
> > No, the definition of acceleration requires
> > that it be used exactly the way I used it. You
> > need to learn these basic definitions Max, there
> > is no flexibility in how you do this part, your
> > options are limited to changing the equation for
> > the acceleration if you don't like the outcome,
> > and if the equation is correctly derived from
> > your concepts then those concepts are wrong.
>
> I keep on telling you that the maths you are using is incapable
> of describing the anisotropy.
Yes, you keep telling me lots of crap and I keep
pointing out that fact. I am using the DEFINITION of
acceleration and therefore the maths I am doing is
correct.
> You are miles away from the truth
> with what you are doing.
What I am doing is correct BASED ON your eqiation
which tells me the acceleration. If my result is
wrong it must be because your equation is wrong.
> >> Elaborating; The fall distance for Mercury's half orbit is
> >> d = 3801600 / (pi/2) * 48000 = 1.16e11 meters, which is
> >> of course the orbit diameter from aphelion to perihelion.
> >> Or, 2/(d/v^2) = newton = .0397m/sec^2, being the average
> >> acceleration rate to the far side of the orbit.
> > No, acceleration is a vector and includes direction.
> > You are trying to use it as a scalar which is wrong
> > and will not work.
>
> So you are saying that vectors and scalars are impossible to
> compare?
Of course. One is a single number and the other is a set
of numbers.
> I seem to always get exactly the same fall distance from
> dt^2 * anisotropy / 2 as from compounding the acceleration for
> each second of dt.
That's because you are ignoring the direction.
Even limiting ourselves to the plane of the
orbit, acceleration is pair of numbers.
> Try running this program.
>
> CLS : dt = 10000: an = 1: ax = an: ax = an / 2
> aa: a = a + ax: b = b + a: ax = an: fa = fa + 1
> IF fa < dt THEN GOTO aa
> PRINT b; "per compounding steps"
> PRINT dt ^ 2 * an / 2; "per dt^2*an/2"
You have ax but where is ay?
> >>> In fact all the formulae and assumptions you are trying
> >>> to use are susceptible to being invalidated by your
> >>> change to gravity. Only the raw definitions remain valid
> >>> so this really is very simple:
>
> >>> 1) you gave me an equation for the acceleration
>
> >>> 2) acceleration is defined as rate of change of velocity
>
> >>> 3) velocity is defined as rate of change of location
>
> >>> Therefore if I integrate your modified acceleration (Newton
> >>> plus anisotropy) twice, I get the location as a function of
> >>> time, i.e. the path of the planet.
>
> >> Without the anisotropy, you are plotting the path of a planet
> >> in a sustainable orbit, and it makes no difference if the orbit
> >> is elliptical or circular the same rules apply. The total radius
> >> change is zero, even though the fall distance per half orbit
> >> cycle is twice the radius.
>
> >> Even though you deny that the radius changes, ..
> > At no time did I say the radius wasn't affected, you
> > have picked up a misunderstanding somewhere. Perhaps
> > it was when we were talking of a circular orbit.
>
> The following is an extract from your reply dated 23-5-07. The
> subject title was then; Anisotropy in the gravity force, and
> Mercury.
>
> --------------------------I wrote:
>
> -> Therein lies a problem. The anisotropy is an acceleration force,
> -> but you've treated it as a continuous force which is simply added
> -> or subtracted from the orbit radius according to radial velocity.
>
> You wrote:
>
> -That sentence makes very little sense so I'l take it
> -bit by bit.
> -
> -We are treating the anisotropy like the Newtonian
> -gravity as an acceleration, not a force. We are
> -not including the mass of Mercury in any of the
> -calculations because it would cancel out.
> -
> -The accelerations are continuous (both Newtonian and
> -the anisotropy) in that they apply at all times and
> -change smoothly with time, they aren't quantised and
> -changing in discrete steps.
> -
> -That means that any time, the acceleration adds an
> -amount to the velocity which is equalt to the product
> -of the time and the acceleration. It doesn't add or
> -subtract from the radius, I don't know where you got
> -that idea.
> -------------------------
OK, all of that is correct.
> If you hadn't included "(both Newtonian and the anisotropy)" you
> could have been referring to the Newtonian component only. But
> you were probably talking about average radius.
No I was talking about the accelerations only. I said:
> -The accelerations are continuous (both Newtonian and
> -the anisotropy) in that they apply at all times and
> -change smoothly with time, they aren't quantised and
> -changing in discrete steps.
which means the Newtonian acceleration is continuous
and also the acceleration from the anisotropy is
continuous. Neither of them changes in discrete steps
though we model them that way when writing software
and have to use tricks to remove the small errors that
causes.
> That should have prompted you to question your program though
> because inelastic gravity _must_ cause the average radius to
> decay.
I think you are misreading the final paragraph. You
had previously said something like "acceleration
adds to the radius" and I said "No, acceleration adds
to the velocity". Of course during each one second
step, the velocity then adds to the radius but I was
pointing out that you had missed a step in the
process, not that the radius would be unaffected. Do
you see the difference?
> >> .. you attempt to
> >> change it by the full extent of the anisotropy, which is
> >> _blatantly_ wrong.
> > Of course, and that is _correct_. You have in effect
> > told me how much to use when you included the term v/c
> > in your equation for the anisotropy, I include v/c
> > times the Newtonian value. If you think that is too
> > much, you need to change the factor v/c to something
> > smaller, but it is up to you to do that, I just add
> > whatever your equation demands.
>
> Your whole concept is completely wrong. You have treated the
> anisotropy as being entirely elastic, up to the point where
> Mercury should fall to the normal aphelion or perihelion radius.
> That's the part your program cannot accommodate.
I have told you several times, and you have the
code so you can check for yourself - the program
does not make any assumption one way or the other,
it does nothing other than integrate the acceleration
to get the velocity and then integrate that to get
the path. That follows automatically from the
definition of acceleration so cannot be wrong.
> If the anisotropy is elastic, then it is elastic. If it's
> inelastic, it's inelastic, meaning that Mercury must lose energy
> and _must_ fall to the Sun. What you have is an entirely elastic
> situation which removes no energy from the system, but for some
> obscure reason, the eccentricity decays.
> That's hardly logical, is it!
It is perfectly logical - the eccentricity can change while
the energy in the system can stay the same.
> There are several ways to arrive at the true fall distance for
> the inelastic anisotropy. This one is very straight forward.
The way I have done it correct. If your methods give the
same result, then they may be equivalent but if they
give a different answer they are wrong. This approach is
definitely not going to work:
> For the conditions:
> anisotropy = 8e-7
> r = 58000000000 meters
> newton = GM/r^2
>
> (GM/r)^.5 = 47838.26919945997 (v), is the orbital speed
> required to maintain a normal stable orbit.
For a circular orbit, yes.
> (newton + anisotropy)^.5 / (newton)^.5 * v
> = 47838.75416438016 (vv), is the orbital speed required to
> maintain a stable orbit if the anisotropy is included.
No, for a circular orbit there is no _radial_ speed
towards or away from the Sun so the "v/c" in your
equation is zero and there is no anisotropy. The
stable speed must therefore be identical to the case
of Newtonian gravity only.
> The ratio is, as always, 1.00001014 to 1.
It should be 1.0 precisely.
> With the added pull of gravity ...
There is no added pull because the radial speed is
zero. I'll snip the next bit since you had previously
agreed that there would be no anisotropy for a circular
orbit and I can only imagine you got a bit confused
this time round.
> I have previously assumed that your program causes the anisotropy
> to generate a relatively enormous radius change for the up and
> the down legs of Mercury's orbit. But in the process of pointing
> out the root of your confusion, it has become apparent that the
> cause is only that the anisotropy has been added to the normal
> orbit as a distinct change which occurred suddenly at either
> the aphelion or perihelion. ..
I think you have misread the program. It adds to
the velocity in each time step, not at aphelion or
perihelion, and it adds only as much as occurs
during the step, no matter what value you choose
for dt. A smaller choice of dt means smaller
amounts are added, but of course there are more
steps per orbit. The overall cumulative effect is
then the same.
In reality, your anisotropy would act continuously
all the time at a very low level, and the program
takes account of that as far as is practical so that
it is adequately accurate.
George
Max Keon
>> 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. The orbit shape is permanently changed to a different
shape that remains thus until something else changes it again.
We don't seem to be getting anywhere here, so I'll go back to
where it all began.
-------------------
I've also stored this part of the post on a web page so that
the images become an integral part of the story, at
http://members.optusnet.com.au/maxkeon/proven.html
-------------------
The original equation representing the effect of the anisotropy
on an upward moving mass relative to a gravity source was given
as ((c+v)^2/c^2)^.5*G*M/r^2-(G*M/r^2), while
((c-v)^2/c^2)^.5*G*M/r^2-(G*M/r^2) represented its effect on
a downward moving mass.
The equations have since been simplified to v/c(GM/r^2) and
-v/c(GM/r^2). The physical sign manipulation between the up and
the down legs of Mercury's eccentric orbit was essential when
using unsigned velocity so that the anisotropy could be
represented as it's supposed to be. i.e. The pull of gravity is
lessened for motion toward a gravity source and increased for
outward motion.
Using signed radial velocity automatically changes the sign on
the anisotropy, but in doing so, the relationship between radial
velocity and the anisotropy remains constant. It never changes.
That was an obvious concern for me when I was pressured into
using signed velocity to automate the anisotropy sign change,
thus making the equation elastic. The problem was that the
equation no longer represented the anisotropy.
The radial velocity and anisotropy relationship should cause the
orbit trajectory to fall less to the Sun than normal on the way
down and more than normal on the way up. That can't possibly
happen if the sign relationship remains constant.
The attached program demonstrates the true effect of the
anisotropy on Mercury's eccentric orbit. And take note that
Mercury's trajectory now obeys the laws of the theory.
In roughly determining the perihelion advance rate it was
necessary to magnify the anisotropy to arrive at a sensible
result because the distance covered in the final step at
perihelion or aphelion is greater than the observed advance rate
of 29000 meters per orbit cycle. The error margin is dependent
on the step size represented by dt in the program, and is at
least 1 second of travel time at 48000m/sec.
The program setup is currently dt=1000, with anisotropy * 1000,
which would seem to be back at square 1 with no multipliers. But
doubling the multiplier value for the anisotropy causes a four
fold increase in the perihelion advance rate, so the multiplier
alters the result at a squaring rate.
http://members.optusnet.com.au/maxkeon/a501.jpg
http://members.optusnet.com.au/maxkeon/a1001.jpg
http://members.optusnet.com.au/maxkeon/a2001.jpg
Each of these images was generated over 20 orbit cycles. The dark
blue circles indicate the aphelion and perihelion advance.
The actual advance can be determined by physically measuring the
angle of advance and dividing that by the number of cycles, the
multiplier squared, etc. For multipliers, 500, 1000 and 2000,
with the consequent results from running 20 cycles, 6.25, 25,
and 100 degrees (per images)
(1) 6.25 / 20 / (500^2 * 360) * 2.89e11 = 1003 meters.
(2) 25 / 20 / (1000^2 * 360) * 2.89e11 = 1003 meters.
(3) 100 / 20 / (2000^2 * 360) * 2.89e11 = 1003 meters.
(2.89e11 is the circumference at the perihelion radius)
The observed advance is 29000 meters per orbit. A long way short?
I wouldn't be too concerned because the anisotropy affects
everything that moves in the universe, which affects every
calculation to do motion and gravity. There's still a long way
to go yet.
The advance can also be determined by monitoring the y axis
length when Mercury is close to perihelion.
To eliminate the initial orbit wobble when the anisotropy is
first applied, the program was run until Mercury's advance had
arrived at the 180 mark, where the y axis was again crossing
through zero. These figures were generated from the first three
orbit cycles beyond the perihelion, using dt=100 and 2000 for
the anisotropy multiplier.
(a) y = -881201184: Initial chosen perihelion.
(b) y = -4797789427: Perihelion at next orbit.
(c) y = -8679411745: Next perihelion.
(d) y = -12497773124: Next perihelion.
(b - a) / 2000^2 = -979 meter advance.
(c - b) / 2000^2 = -970 meter advance.
(d - c) / 2000^2 = -955 meter advance.
-----
Max Keon
'----------------------
DEFDBL A-Z
SCREEN 12
CLS
CIRCLE (250, 250), 8, 14 'Sun
COLOR 7
c = 299792458#
G = .0000000000667#
M = 1.99D+30
multi = .000000002#' Multiplier for the graphics.
pi = 3.1416#
x = 69820000000#: vy = 38850# ' Aphelion start.
'x = 45961000000#: vy = 59017# ' Perihelion start.
' Swap the ' switches.
lastradius = x
dt = 1000
aa:
ryx = x * x + y * y
radius = SQR(ryx)
vr = (radius - lastradius) / dt
lastradius = radius
newton = G * M / ryx
IF vr > 0 THEN anisotropy = -vr / c * newton * 1000
IF vr < 0 THEN anisotropy = vr / c * newton * 1000
' -----The anisotropy is now correctly represented-----
acceleration = -newton + anisotropy
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
vx = vx + dt * ax
vy = vy + dt * ay
v = (vx ^ 2# + vy ^ 2#) ^ .5# ' Orbital speed.
' Direction of orbital speed change identifies the aphelion and
' perihelion (changing from increasing to decreasing speed, or
' vice versa).
x = x + dt * vx
y = y + dt * vy
CIRCLE (250 + x * multi, 250 - y * multi), 0, 11
IF lastv < v AND fa = 0 THEN fb = 1: fa = 1: GOSUB ad
IF lastv > v AND fb = 1 THEN fa = 0: fb = 0: GOSUB ad
' Detects aphelion or perihelion.
lastv = v
GOTO aa
ad:
CIRCLE (250 + x * multi, 250 - y * multi), 2, 14
' Identifies the aphelion and perihelion.
LOCATE 1, 1
cycl = cycl + .5
PRINT cycl; "cycles "
PRINT " x ="; x, " y ="; y
' x is only included to indicate where the
' y axis is measured (aphelion or perihelion).
PRINT " last x ="; xx, "last y ="; yy
xx = x: yy = y
IF cycl > 20 THEN END
'DO: LOOP UNTIL INKEY$ <> ""
RETURN
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1184072076.5...@r34g2000hsd.googlegroups.com...
> On 10 Jul, 11:42, "Max Keon" <maxk...@optusnet.com.au> 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.
> The original equation representing the effect of the anisotropy
> on an upward moving mass relative to a gravity source was given
> as ((c+v)^2/c^2)^.5*G*M/r^2-(G*M/r^2), while
> ((c-v)^2/c^2)^.5*G*M/r^2-(G*M/r^2) represented its effect on
> a downward moving mass.
>
> The equations have since been simplified to v/c(GM/r^2) and
> -v/c(GM/r^2). The physical sign manipulation between the up and
> the down legs of Mercury's eccentric orbit was essential when
> using unsigned velocity so that the anisotropy could be
> represented as it's supposed to be. i.e. ...
This next bit is VERY important:
> ... The pull of gravity is
> lessened for motion toward a gravity source and increased for
> outward motion.
That is the key statement here.
> Using signed radial velocity automatically changes the sign on
> the anisotropy, but in doing so, the relationship between radial
> velocity and the anisotropy remains constant. It never changes.
Yes that is correct, an inward velocity is negative
and the anisotropy needs to be positive if it is to
lessen the pull of gravity.
An outward velocity is positive and the anisotropy
needs to be negative if it is to increase the pull
of gravity.
The relationship is constant, the anisotropy should
always have the opposite sign from the velocity.
> That was an obvious concern for me when I was pressured into
> using signed velocity to automate the anisotropy sign change,
> thus making the equation elastic.
Elastic versus inelastic is another matter, leave
it for a later discussion.
> The problem was that the
> equation no longer represented the anisotropy.
Not true Max, the equation _does_ represent what
you said above, inward motion decreases the pull
while outward motion increases it.
> The radial velocity and anisotropy relationship should cause the
> orbit trajectory to fall less to the Sun than normal on the way
> down and more than normal on the way up. That can't possibly
> happen if the sign relationship remains constant.
Right, but it does happen if the pull of gravity is
increased on the outward leg as you said above.
> The attached program demonstrates the true effect of the
> anisotropy on Mercury's eccentric orbit. And take note that
> Mercury's trajectory now obeys the laws of the theory.
I have trimmed your code as most is uncontentious
(there are minor point if others want to nitpick).
This is the key section:
> ryx = x * x + y * y
> radius = SQR(ryx)
>
> vr = (radius - lastradius) / dt
> lastradius = radius
That is valid. Note that, on the inward leg radius
is always less than lastradius hence vr is negative
while on the outward leg radius is always greater
than lastradius hence vr is positive.
> newton = G * M / ryx
The Newtonian force is inward so that should be -G
instead of G (since you defined G as a positive
number) but you apply the negation when finding the
acceleration a few lines later so that's OK.
> IF vr > 0 THEN anisotropy = -vr / c * newton * 1000
> IF vr < 0 THEN anisotropy = vr / c * newton * 1000
> ' -----The anisotropy is now correctly represented-----
Is it? Let's see:
> acceleration = -newton + anisotropy
The value of newton is always positive.
On the outward leg, vr is positive so the first
line is implemented and anisotropy gets a negative
number.That makes acceleration a larger negative
number - it increases the pull of gravity as you
said above so appears OK.
On the inward leg however, vr is negative so the
second line applies. Since vr is neagtive, so is
anisotropy and again the pull of gravity is
increased. That is NOT what you told me.
This is why I suggested you stop the program after
1/4 and 3/4 of an orbit and look at the values of
newton and anisotropy and check the signs. You will
find two things:
a) acceleration is a larger negative number
than -newton in both cases
b) the value for at any specific radius
should be identical there will be small
numerical errors (unless you use a very
small value of dt).
The latter is what causes the path to return to
the constant perihelion and aphelion values.
Clearly Max, if you change from saying the pull
is reduced on the inward leg to writing code in
which it is increased, the result is going to
be entirely different.
George
George Dishman
posted successfully but nothing appears so I'll
trim this copy short to see if it makes it.
On 17 Jul, 01:29, "Max Keon" <maxk...@optusnet.com.au> wrote:
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1184072076.5...@r34g2000hsd.googlegroups.com...
...
> We don't seem to be getting anywhere here, so I'll go back to
> where it all began.
This next bit is VERY important:
> ... The pull of gravity is
> lessened for motion toward a gravity source and increased for
> outward motion.
That is the key statement here.
> Using signed radial velocity automatically changes the sign on
> the anisotropy, but in doing so, the relationship between radial
> velocity and the anisotropy remains constant. It never changes.
Yes that is correct, an inward velocity is negative
and the anisotropy needs to be positive if it is to
lessen the pull of gravity.
An outward velocity is positive and the anisotropy
needs to be negative if it is to increase the pull
of gravity.
The relationship is constant, the anisotropy should
always have the opposite sign from the velocity.
> The problem was that the
> equation no longer represented the anisotropy.
The equation I used represents what you said above.
You have offered an alternative in the code below
so let's look at that and see what you have done.
> The radial velocity and anisotropy relationship should cause the
> orbit trajectory to fall less to the Sun than normal on the way
> down and more than normal on the way up. That can't possibly
> happen if the sign relationship remains constant.
Right, but it does happen if the pull of gravity is
increased on the outward leg as you said above.
> The attached program demonstrates the true effect of the
> anisotropy on Mercury's eccentric orbit. And take note that
> Mercury's trajectory now obeys the laws of the theory.
I have trimmed your code as most is uncontentious
(there are minor point if others want to nitpick).
> ryx = x * x + y * y
> radius = SQR(ryx)
>
> vr = (radius - lastradius) / dt
> lastradius = radius
That is valid. Note that, on the inward leg radius
is always less than lastradius hence vr is negative
while on the outward leg radius is always greater
than lastradius hence vr is positive.
> newton = G * M / ryx
The Newtonian force is inward so that should be -G
instead of G (since you defined G as a positive
number) but you apply the negation when finding the
acceleration a few lines later so that's OK.
This is the key section:
> IF vr > 0 THEN anisotropy = -vr / c * newton * 1000
> IF vr < 0 THEN anisotropy = vr / c * newton * 1000
> ' -----The anisotropy is now correctly represented-----
Is it? Let's see:
> acceleration = -newton + anisotropy
The value of newton is always positive.
On the outward leg, vr is positive so the first
line is implemented and anisotropy gets a negative
number.That makes acceleration a larger negative
number - it increases the pull of gravity as you
said above so appears OK.
On the inward leg however, vr is negative so the
second line applies. Since vr is neagtive, so is
anisotropy and again the pull of gravity is
increased. That is NOT what you told me.
This is why I suggested you stop the program after
1/4 and 3/4 of an orbit and look at the values of
newton and anisotropy and check the signs. You will
find two things:
a) acceleration is a larger negative number
than -newton in both cases
b) the value for at any specific radius
should be identical there will be small
numerical errors (unless you use a very
small value of dt).
The latter is what causes the path to return to
the constant perihelion and aphelion values.
Clearly Max, if you say the pull is _reduced_ on
the inward leg but then write code in which it is
_increased_, the result is going to be entirely
different.
BTW, I agree that the results you should get with
that change to the anisotropy are what you have
shown in your graphics, though gut feel suggests
you will find the amount of perihelion advance is
greater than is observed.
George
George Dishman
posted successfully but nothing appears so I'll
trim this copy short to see if it makes it.
On 17 Jul, 01:29, "Max Keon" <maxk...@optusnet.com.au> wrote:
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1184072076.5...@r34g2000hsd.googlegroups.com...
...
> We don't seem to be getting anywhere here, so I'll go back to
> where it all began.
This next bit is VERY important:
> ... The pull of gravity is
> lessened for motion toward a gravity source and increased for
> outward motion.
That is the key statement here.
> Using signed radial velocity automatically changes the sign on
> the anisotropy, but in doing so, the relationship between radial
> velocity and the anisotropy remains constant. It never changes.
Yes that is correct, an inward velocity is negative
and the anisotropy needs to be positive if it is to
lessen the pull of gravity.
An outward velocity is positive and the anisotropy
needs to be negative if it is to increase the pull
of gravity.
The relationship is constant, the anisotropy should
always have the opposite sign from the velocity.
> The problem was that the
> equation no longer represented the anisotropy.
The equation I used represents what you said above.
You have offered an alternative in the code below
so let's look at that and see what you have done.
> The radial velocity and anisotropy relationship should cause the
> orbit trajectory to fall less to the Sun than normal on the way
> down and more than normal on the way up. That can't possibly
> happen if the sign relationship remains constant.
Right, but it does happen if the pull of gravity is
increased on the outward leg as you said above.
> The attached program demonstrates the true effect of the
> anisotropy on Mercury's eccentric orbit. And take note that
> Mercury's trajectory now obeys the laws of the theory.
I have trimmed your code as most is uncontentious
(there are minor point if others want to nitpick).
> ryx = x * x + y * y
> radius = SQR(ryx)
>
> vr = (radius - lastradius) / dt
> lastradius = radius
That is valid. Note that, on the inward leg radius
is always less than lastradius hence vr is negative
while on the outward leg radius is always greater
than lastradius hence vr is positive.
> newton = G * M / ryx
The Newtonian force is inward so that should be -G
instead of G (since you defined G as a positive
number) but you apply the negation when finding the
acceleration a few lines later so that's OK.
This is the key section:
> IF vr > 0 THEN anisotropy = -vr / c * newton * 1000
> IF vr < 0 THEN anisotropy = vr / c * newton * 1000
> ' -----The anisotropy is now correctly represented-----
Is it? Let's see:
> acceleration = -newton + anisotropy
The value of newton is always positive.
Warhol
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...
"George Dishman" <geo...@briar.demon.co.uk> a écrit dans le message de news:
1184762138....@d30g2000prg.googlegroups.com...
George Dishman
> 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" <geo...@briar.demon.co.uk> a écrit dans le message de news:
> 1184762138.376436.53...@d30g2000prg.googlegroups.com...
Max Keon
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
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
...
> > 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
Max Keon
> On 20 Jul, 13:50, "Max Keon" <maxk...@optusnet.com.au> wrote:
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>> news:1184742250.6...@e9g2000prf.googlegroups.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.
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
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1184941197.5...@q75g2000hsh.googlegroups.com...
> > On 20 Jul, 13:50, "Max Keon" <maxk...@optusnet.com.au> wrote:
> >> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> >>news:1184742250.6...@e9g2000prf.googlegroups.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:Sommerfeld_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
Max Keon
> On 26 Jul, 13:27, "Max Keon" <maxk...@optusnet.com.au> wrote:
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>> news:1184941197.5...@q75g2000hsh.googlegroups.com...
>>> On 20 Jul, 13:50, "Max Keon" <maxk...@optusnet.com.au> 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:Sommerfeld_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
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1185522931.1...@q75g2000hsh.googlegroups.com...
> > On 26 Jul, 13:27, "Max Keon" <maxk...@optusnet.com.au> wrote:
> >> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> >>news:1184941197.5...@q75g2000hsh.googlegroups.com...
> >>> On 20 Jul, 13:50, "Max Keon" <maxk...@optusnet.com.au> 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:Sommerfeld_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
Max Keon
> On 29 Jul, 13:40, "Max Keon" <maxk...@optusnet.com.au> wrote:
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>> news:1185522931.1...@q75g2000hsh.googlegroups.com...
>>> On 26 Jul, 13:27, "Max Keon" <maxk...@optusnet.com.au> 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:Sommerfeld_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
Max Keon
> 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
Eric Gisse
You do realize that you are completely wasting everyone's, including
your own, time right?
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message news:1185785372.6...@57g2000hsv.googlegroups.com...
> > On 29 Jul, 13:40, "Max Keon" <maxk...@optusnet.com.au> wrote:
> >> "George Dishman" <geo...@briar.demon.co.uk> wrote in message news:1185522931.1...@q75g2000hsh.googlegroups.com...
> >>> On 26 Jul, 13:27, "Max Keon" <maxk...@optusnet.com.au> wrote:
> >> 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.
Max, there is no point in my replying if all you
do is snip what I say and go off on a new tack
every time. Your description above goes a long
way towards understanding the situation so follow
it through and you will grasp what your equation
implies. This is how it works:
> > 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.
Think about that Max.
> But you still don't understand the
> consequences of an anomalous force being applied to a naturally
> stable orbit at all.
The consequences are stated above. Think carefully
about the direction your force acts in and you will
see what I said is exactly what you have been telling
me all along.
> 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.
Pythagoras is only valid if a and b are at right
angles. That is not the case for an elliptical
orbit.
Max, I've said this many times but you are still
not listening - you CANNOT work out the correct
answers without taking the DIRECTION into account.
> 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.
It should have been a warning that something was amiss
somewhere. To solve the problem break both the velocity
and acceleration into x and y components and apply the
same rules. Since you no longer need the square root,
the correct signs are preserved. If you do that, you
will find you have reproduced my program.
> ... 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. ...
Not an "external means", your equation for the
anisotropy is INELASTIC and does the job of
slowly diminishing the eccentricity.
> Notice that the process is entirely elastic?
Now that should have set your alarms bells ringing,
your equation is inelastic.
> The slightest change to gravity does have an immediate
> consequence, as you have been saying all along.
Thank you.
> But that
> consequence is far removed from what you perceived.
When you correct the errors in your maths you
will find that you end up with the same program
as I wrote and that my results are precisely
what your equation predicts. Keep going though,
you are gradually finding the flaws in your
thinking and correcting them. The main thing you
need to address remains the direction of motion,
you _can_ use the familiar equations from linear
motion but only if you split the motion and
accelerations into x and y components and process
them independently, trying to apply it to the
radial speed and acceleration (effectively using
polar coordinates) doesn't work unless you include
coriolis force as well as centrifugal and that will
be much more complex.
George
Max Keon
"Eric Gisse" <jow...@gmail.com> wrote in message
news:1186112656.8...@q3g2000prf.googlegroups.com...
Thankfully, you're not the smartest person on this planet and
you're not everyone. So I just keep on plodding along.
Don't kid yourself Eric, truth is much bigger than you and me,
or the fear of its cataclysmic consequences. The ooooohhhhh
factor may work in superstitious beliefs, but it has no place
in physics.
-----
Max Keon.
Max Keon
> On 3 Aug, 03:50, "Max Keon" <maxk...@optusnet.com.au> wrote:
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
news:1185785372.6...@57g2000hsv.googlegroups.com...
>>> On 29 Jul, 13:40, "Max Keon" <maxk...@optusnet.com.au> wrote:
>>>> 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.
> Max, there is no point in my replying if all you
> do is snip what I say and go off on a new tack
> every time.
That's certainly what I do George, and it's called progress.
Which has been an unusual event in theoretical physics ever since
postulates were introduced into our reality. That's not intended
as humor either.
I snip what you say when I think the rest of your reply has been
addressed, which is quite understandably what you do with my
posts.
> Your description above goes a long
> way towards understanding the situation so follow
> it through and you will grasp what your equation
> implies. This is how it works:
---
>>> 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.
> Think about that Max.
>> But you still don't understand the
>> consequences of an anomalous force being applied to a naturally
>> stable orbit at all.
> The consequences are stated above. Think carefully
> about the direction your force acts in
Do you think I'm stupid. I can see exactly where the force is
acting and why you are led to believe that it will cause an
orbit eccentricity decay. But I can also see why you are wrong.
>> 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.
> Pythagoras is only valid if a and b are at right
> angles. That is not the case for an elliptical
> orbit.
It makes no difference. The true tangential speed can be
obtained using a^2+b^2=c^2. The fall rate for every second is
already known, so the same equation will give an accurate orbital
speed increase per second.
Regardless of how accurate the result may be, nothing changes
the obvious fact that what is lost while the anisotropy is
increasing is reclaimed in full when it has again reduced to
zero at aphelion or perihelion.
I can only suggest that you visit this web page,
http://members.optusnet.com.au/maxkeon/proven2.html
or refer back to my previous reply.
The set of equations in your program describe every possible
naturally occurring orbit, between a circular orbit and a direct
fall. Every one of those orbits are therefore identical. They
are each equivalent to a circular orbit, or to any other orbit
as well. Whatever applies for a circular orbit also applies for
every other orbit, _AND VICE VERSA_.
Is that clear enough?
I think your problem stems from the belief that because those
equations accurately describe nature, they can also be used
to determine the laws of nature.
> Max, I've said this many times but you are still
> not listening - you CANNOT work out the correct
> answers without taking the DIRECTION into account.
I can do EXACTLY as truth dictates.
>> 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.
> It should have been a warning that something was amiss
> somewhere. To solve the problem break both the velocity
> and acceleration into x and y components and apply the
> same rules. Since you no longer need the square root,
> the correct signs are preserved. If you do that, you
> will find you have reproduced my program.
>> ... 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. ...
> Not an "external means", your equation for the
> anisotropy is INELASTIC and does the job of
> slowly diminishing the eccentricity.
No it's doesn't. For some reason, you continue to miss the point
altogether.
I'll snip the rest because it no longer applies.
I've included another progress report in the form of a Qbasic
program. Note that my position has never changed at all. Meaning
that I'm not "off on a new tack", as you put it. I am in fact
still on my original tack because you have not shown me anything
that could sway me one bit toward yours.
The total fall distance is now added to the radius in the same
manner as described at the above address. That is the proper
method of applying an anomalous gravity change to a circular
orbit, _so it must apply for every other natural orbit_,
regardless of its shape.
The program now detects Mercury's aphelion position within 3900
meters and the perihelion position within 5900 meters, in the
direction motion. That's within .1 seconds of travel time.
The results are not exactly reproduced for different
values of dt, but they are always similar, while the average
advance wanders all over the place from one cycle to the next
in a cyclic fashion when the anisotropy is included. It's fairly
evident that an oscillation has been set in motion right at the
start of the first cycle. It's necessarily very dependent on the
precision at the start.
The advance must be positive for both the aphelion or perihelion
detection because the Sun is always to the left of the start point,
and the orbit direction is anticlockwise.
I've tried to keep the program as understandable as possible,
mainly so that I can understand what it's all about next month.
The added clutter is necessary to eliminate the need for me to
stuff around with animations and JPEG images. You can make your
own simply by running the program. It may take some time, but at
least the result is falsifiable.
-----
Max Keon
'-----------Control/Break halts the program at any time.-------
' The only adjustments required are highlighted thus
'//////////////////////
' A perihelion start generates the most obvious orbit
' instability, and that just keeps on resonating around the
' orbit. The greatest change in orbit advance is obviously when
' the oscillation peak coincides with the perihelion.
' Taking the total over a long period will pull the sinewave
' down to show the true advance. Maybe?
DEFDBL A-Z
SCREEN 12: CLS: COLOR 7
LINE (30, 380)-(600, 380) ' y axis zero, for the added graph.
LOCATE 24, 4: PRINT "0"
PRINT "Light blue is current advance position."
PRINT "Red is the total advance."
CIRCLE (250, 250), 4, 14 ' Sun.
c = 299792458#
G = .0000000000667#
M = 1.99D+30
multi = .000000002# ' Multiplier for the graphics.
colr = 3 ' sets the initial graphics color.
LOCATE 12, 1
'////// Swap the 'x switch /////////////////////////////////
x = 69820000000#: vy = 38850#: fl = 0 ' Aphelion start.
'x = 45961000000#: vy = 59017#: fl = 1 ' Perihelion start.
'///////////////////////////////////////////////////////////
IF fl = 0 THEN PRINT " meter aphelion radius detection error."
IF fl = 1 THEN PRINT " meter perihelion radius detection error."
vv = (G * M / x) ^ .5 ' Sets the initial centripetal-centrifugal
' force imbalance to zero.
vz = vv
lastradius = x
rad = x
initrad = x ' Initial start radius is compared with
' the updated aphelion-perihelion radius.
dt = 200 ' dt = 600 is the upper limit for the current setup.
' dt = 200 is the lower limit.
df = dt ' df is used to later reset dt following the dt = .1
' subroutine, where the aphelion detection is within .1 seconds.
aa: '-------- This section is as described at -------------
' http://members.optusnet.com.au/maxkeon/proven2.html
ana = ana + dt * cfx ' ana stores the current fall distance.
anb = anb + ana ' anb stores the total fall distance.
IF anc >= anb THEN s = (vz ^ 2# - (ana ^ 2 * dt)) ^ .5#
IF anc < anb THEN s = (vz ^ 2# + (ana ^ 2 * dt)) ^ .5#
anc = anb ' anc determines which of the two equations is active.
vz = s
cf = vz ^ 2# / vv ^ 2# * newton
cfx = newton + anisotropy - cf ' cfx holds the true fall
' rate, which is the difference between centripetal and
' centrifugal forces.
'---------------------------------------------------
ryx = x * x + y * y
radius = SQR(ryx)
'////////////////////
radius = radius + anb ' Switch off this line for no anisotropy.
'////////////////////
' The total anisotropic fall distance is now added to the radius
' in the same manner as described at the web address. That is the
' way it MUST be applied to a natural orbit, whatever its shape.
vr = (radius - lastradius) / dt
lastradius = radius
newton = G * M / ryx
anisotropy = vr / c * -newton
acceleration = -newton
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
vx = vx + dt * ax
vy = vy + dt * ay
x = x + dt * vx
y = y + dt * vy
v = (vx ^ 2# + vy ^ 2#) ^ .5# ' Orbital speed.
CIRCLE (250 + x * multi, 250 - y * multi), 0, colr
IF fl = 0 THEN GOSUB ag ' aphelion start
IF fl = 1 THEN GOSUB ah ' perihelion start
aph = radius ' previous radius compare routine.
ft = ft + 1 ' ft is only included to eliminate startup errors.
GOTO aa
'--------------------------
ad:
CIRCLE (250 + x * multi, 250 - y * multi), 2, 14
' Identifies the aphelion or perihelion.
LOCATE 1, 1: cycl = cycl + 1
PRINT cycl; "cycles"
PRINT x; "x", y; "y"
rr = (radius - rad)
rad = radius: PRINT radius; "radius"
PRINT
fw = fw + rr
PRINT rr; "meter radius change (now - last)"
PRINT fw; "total radius change."
PRINT y; "total advance."
PRINT y - lasty; "position on the y axis for this cycle."
GOSUB ak ' Loops through the graph subroutine.
lasty = y
initrad = radius
colr = colr + 1: IF colr > 15 THEN colr = 1
IF cycl = 20 THEN END
fa = 0
RETURN
ag:
IF initrad - radius > 10000 THEN dt = df: fa = 0: fb = 0
IF ft > 1000 AND fb = 0 AND initrad-radius <10000 THEN dt=.1:fa=1
' 20000 for dt=100. 10000 for higher dt.
LOCATE 11, 1
IF fa = 1 THEN PRINT aph - radius
IF fa = 1 AND aph - radius > 0 THEN GOSUB ad: fb = 1
' Detects aphelion.
RETURN
ah:
IF radius - initrad > 100000 THEN dt = df: fa = 0: fb = 0
IF ft > 1000 AND fb=0 AND radius -initrad <100000 THEN dt=.1:fa=1
LOCATE 11, 1
IF fa = 1 THEN PRINT aph - radius
IF fa = 1 AND aph - radius < 0 THEN GOSUB ad: fb = 1
' Detects perihelion.
RETURN
ak:
ub = y - lasty ' This is only included to
ua = y / cycl ' shorten the next two lines.
LINE (50 + incb, 380 - ud / 160000)-(50 + inca, 380-ua/160000),12
LINE (50 + incb, 380 - uc / 160000)-(50 + inca, 380-ub/160000),11
'////////////////// It's necessary to change the 160000 divisor
' to 80 for 2000x graph magnification when the anisotropy is not
' included.
'///////////////////////////////////
incb = inca: uc = ub: ud = ua
inca = inca + 25
RETURN
George Dishman
>
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1186131233....@w3g2000hsg.googlegroups.com...
>> On 3 Aug, 03:50, "Max Keon" <maxk...@optusnet.com.au> wrote:
>>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1185785372.6...@57g2000hsv.googlegroups.com...
>>>> On 29 Jul, 13:40, "Max Keon" <maxk...@optusnet.com.au> wrote:
>
>>>>> 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.
>
>> Max, there is no point in my replying if all you
>> do is snip what I say and go off on a new tack
>> every time.
>
> That's certainly what I do George, and it's called progress.
No, it's called "rude" when you disregard my work
entirely, but ...
> Which has been an unusual event in theoretical physics ever since
> postulates were introduced into our reality. That's not intended
> as humor either.
>
> I snip what you say when I think the rest of your reply has been
> addressed, which is quite understandably what you do with my
> posts.
Yes, I have no objection to you doing that,
it reduces duplication.
>> Your description above goes a long
>> way towards understanding the situation so follow
>> it through and you will grasp what your equation
>> implies. This is how it works:
> ---
>>>> 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.
>
>> Think about that Max.
>
>>> But you still don't understand the
>>> consequences of an anomalous force being applied to a naturally
>>> stable orbit at all.
>
>> The consequences are stated above. Think carefully
>> about the direction your force acts in
>
> Do you think I'm stupid.
I can only judge from what you write and based on
that I would say you are innumerate. You did not
know the basic laws of arithmetic and you are still
making a serious mistake with the sign of the
velocity, one you repeat in the code at the bottom
even though you corrected it a few posts back.
Further you don't appear to have any knowledge at
all of calculus which is fundamental to this problem,
there is NO other way to get from the acceleration
to the resulting path. These are basic aspects of
maths which you should have mastered in your early
teens. I cannot say whether you have a learning
disability, or perhaps you were home-schooled by
parents who didn't cover maths, or maybe you are
yet to reach your teens, but your inability to
handle the maths is evident whatever the reason.
> I can see exactly where the force is
> acting and why you are led to believe that it will cause an
> orbit eccentricity decay. But I can also see why you are wrong.
I've said it before but it seems I must repeat it,
acceleration is defined as the derivative of velocity
which in turn is the derivative of the location.
Integrate the acceleration twice and you get the path.
The is what the program I wrote for you does, and the
path is produces is the _consequence_ of your equation.
>>> 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.
>
>> Pythagoras is only valid if a and b are at right
>> angles. That is not the case for an elliptical
>> orbit.
>
> It makes no difference.
Yes it does, and that remark certainly qualifies as stupid.
It means you cannot use it in the circumstances.
> The true tangential speed can be
> obtained using a^2+b^2=c^2. The fall rate for every second is
> already known,
The "fall rate" is NOT known, you are calculating it as
if the planet were moving directly towards the Sun which
it is not and a again your results are entirely wrong as
a result.
> so the same equation will give an accurate orbital
> speed increase per second.
>
> Regardless of how accurate the result may be, nothing changes
> the obvious fact that what is lost while the anisotropy is
> increasing is reclaimed in full when it has again reduced to
> zero at aphelion or perihelion.
>
> I can only suggest that you visit this web page,
> http://members.optusnet.com.au/maxkeon/proven2.html
> or refer back to my previous reply.
I have looked at the page and it is riddled with the same
basic mathematical errors that were in all your previous
replies. Until you learn basic maths, you have no hope of
correcting these.
> The set of equations in your program describe every possible
> naturally occurring orbit, between a circular orbit and a direct
> fall.
Yes.
> Every one of those orbits are therefore identical.
Don't be silly, obviously an ellipse is not identical to
a circle.
> They
> are each equivalent to a circular orbit, or to any other orbit
> as well. Whatever applies for a circular orbit also applies for
> every other orbit, _AND VICE VERSA_.
>
> Is that clear enough?
It is very clear, you have no idea what you are talking
about. The various coloured lines on this diagram are
far from identical:
http://en.wikipedia.org/wiki/Image:Sommerfeld_ellipses.svg
You are certainly supplying evidence for anyone to call
you stupid so perhaps you should rethink your statement.
> I think your problem stems from the belief that because those
> equations accurately describe nature, they can also be used
> to determine the laws of nature.
No, my view is trivial actually, it is that the rules
of mathematics (not physics) allow me to calculate the
path which results from your equation and that is what
I have done. If the path predicted by my calculation
doesn't happen in nature (and we know it does not) then
you equation does not "accurately describe nature", the
equation is wrong.
>> Max, I've said this many times but you are still
>> not listening - you CANNOT work out the correct
>> answers without taking the DIRECTION into account.
>
> I can do EXACTLY as truth dictates.
When calculating the path from the equation, you can
only do what the rules of maths dictate.
...
>>> ... 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. ...
>
>> Not an "external means", your equation for the
>> anisotropy is INELASTIC and does the job of
>> slowly diminishing the eccentricity.
>
> No it's doesn't. For some reason, you continue to miss the point
> altogether.
>
> I'll snip the rest because it no longer applies.
>
> I've included another progress report in the form of a Qbasic
> program. Note that my position has never changed at all. Meaning
> that I'm not "off on a new tack", as you put it. I am in fact
> still on my original tack because you have not shown me anything
> that could sway me one bit toward yours.
>
> The total fall distance ...
Stop there. What you call the "total fall distance" is calculated
as if the planet was falling directly towards the planet but it
is not. That formula and everything thereafter is therefore wrong.
> is now added to the radius in the same
> manner as described at the above address. That is the proper
> method of applying an anomalous gravity change to a circular
> orbit,
Wrong it is not the proper way to add any acceleration to
any orbit. The only valid way is to add the change of velocity
due to acceleration to the current velocity taking into account
the directions because that is the DEFINITION of acceleration.
Try to get that into your skull Max, acceleration is DEFINED
as the rate of change of velocity.
I'll snip most of the rest, since it is invalidated by that
error in your approach already, but I will pick up on this
again:
> IF anc >= anb THEN s = (vz ^ 2# - (ana ^ 2 * dt)) ^ .5#
> IF anc < anb THEN s = (vz ^ 2# + (ana ^ 2 * dt)) ^ .5#
If you swap the sign, you change an increase of gravity into a
decrease or vice versa. Your program _appears_ to restore the
planet to its starting radius after each orbit because you have
reversed the effect of the anisotropy on one leg, either gravity
is increased on both the inward and outward legs or, depending
on other signs, it might be decreased on both. Either way, that
is why you get a different result from me. If you check that it
is decreased on the inward leg and increased on the outward,
then once you get rid of the other errors, you will get the same
result as my program.
George
Max Keon
>"Max Keon" <max...@optusnet.com.au> wrote in message
>news:46bb1bab$0$30511$afc3...@news.optusnet.com.au...
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>> news:1186131233....@w3g2000hsg.googlegroups.com...
>>> On 3 Aug, 03:50, "Max Keon" <maxk...@optusnet.com.au> wrote:
>>>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>>>> news:1185785372.6...@57g2000hsv.googlegroups.com...
>>>>> 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.
>>>
>>> Think about that Max.
>>>
>>>> But you still don't understand the
>>>> consequences of an anomalous force being applied to a naturally
>>>> stable orbit at all.
>>>
>>> The consequences are stated above. Think carefully
>>> about the direction your force acts in
>>
>> Do you think I'm stupid.
> I can only judge from what you write and based on
> that I would say you are innumerate. You did not
> know the basic laws of arithmetic and you are still
> making a serious mistake with the sign of the
> velocity, one you repeat in the code at the bottom
> even though you corrected it a few posts back.
I'm not really buying your rather uncharacteristically emotional
reply because, apart from justifying the emotional rant, it
doesn't seem to be you at all. But it's a shame that you wasted
it on a false premise, in that I'm not actually wrong this time.
Do get this straight though George, in the quest for truth, not
getting it right yesterday or today is of no consequence, so long
as I get it right tomorrow.
The tangential speed at any given time can be calculated using
Pythagoras. i.e. At one point in Mercury's elliptical orbit,
Mercury is heading toward x. (c) length per chosen time duration
is already known from the current orbital speed, while (b) is
(vr) according to your equations. (a) now has a value to which
the anisotropic acceleration can be correctly applied. It cannot
be applied as a component of the natural orbit, as you propose.
a
o_--------.
- _ . b
c -x
0
Sun
>> so the same equation will give an accurate orbital
>> speed increase per second.
>>
>> Regardless of how accurate the result may be, nothing changes
>> the obvious fact that what is lost while the anisotropy is
>> increasing is reclaimed in full when it has again reduced to
>> zero at aphelion or perihelion.
>>
>> I can only suggest that you visit this web page,
>> http://members.optusnet.com.au/maxkeon/proven2.html
>> or refer back to my previous reply.
> I have looked at the page and it is riddled with the same
> basic mathematical errors that were in all your previous
> replies. Until you learn basic maths, you have no hope of
> correcting these.
>> The set of equations in your program describe every possible
>> naturally occurring orbit, between a circular orbit and a direct
>> fall.
> Yes.
>> Every one of those orbits are therefore identical.
> Don't be silly, obviously an ellipse is not identical to
> a circle.
It's time to take off your rose colored glasses and face reality.
An elliptical orbit is nothing more than a circular orbit which
has been kicked off center. And by the way, energy must be
transferred from somewhere to somewhere for that imbalance to be
removed, in a completely closed system George. How do you propose
to do that?
---
Exactly. And the force direction determines where that
acceleration is pointing, which is always (near enough to)
directly toward each gravitating body. The RADIAL velocity is
the only one of any consequence, not the tangential "velocity",
or any part thereof. You are still plotting natural orbits.
Get over it!
> Try to get that into your skull Max, acceleration is DEFINED
> as the rate of change of velocity.
So what's the problem? The anisotropy causes Mercury to
anomalously accelerate _DIRECTLY_ toward or away from the Sun.
It's not pushed sideways by the anisotropy, as you claim.
> I'll snip most of the rest, since it is invalidated by that
> error in your approach already, but I will pick up on this
> again:
>
>> IF anc >= anb THEN s = (vz ^ 2# - (ana ^ 2 * dt)) ^ .5#
>> IF anc < anb THEN s = (vz ^ 2# + (ana ^ 2 * dt)) ^ .5#
> If you swap the sign, you change an increase of gravity into a
> decrease or vice versa. Your program _appears_ to restore the
> planet to its starting radius after each orbit
No George. My program restores the planet to its true perihelion
and aphelion radii after the anisotropy finally reduces to zero
at each turnaround point in the orbit.
> because you have
> reversed the effect of the anisotropy on one leg, either gravity
> is increased on both the inward and outward legs or, depending
> on other signs, it might be decreased on both.
You should know very well why the sign must be physically
changed. If you plug these numbers into your calculator you will
always get the same answer from each one, regardless of the sign
on ana.
dt = 1
ana = 1
# = ((-ana)^2 * dt)^.5 is always 1.
# = (ana^2 * dt)^.5 is always 1.
- ((-ana)^2 * dt)^.5 = -1
In the program, I have left out the set of brackets around
((ana). It still gives the correct result when ana becomes
negative, even if it's not supposed to. Perhaps that has confused
you. Anyway, I've added the brackets to the program, and that has
now been updated to generate a 250 cycle data file, which is used
to plot some quite interesting graphs.
I won't clutter the post with details this time. You seem to
ignore most of them anyway.
http://members.optusnet.com.au/maxkeon/proven2.html
-----
Max Keon
George Dishman
Max Keon wrote:
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message news:f9hpf4$d3$1...@news.freedom2surf.net...
> >"Max Keon" <max...@optusnet.com.au> wrote in message news:46bb1bab$0$30511$afc3...@news.optusnet.com.au...
> >> "George Dishman" <geo...@briar.demon.co.uk> wrote in message news:1186131233....@w3g2000hsg.googlegroups.com...
> >>> On 3 Aug, 03:50, "Max Keon" <maxk...@optusnet.com.au> wrote:
> >>>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message news:1185785372.6...@57g2000hsv.googlegroups.com...
>
> >>>>> 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.
> >>>
> >>> Think about that Max.
You still aren't thinking about it.
> >>>> But you still don't understand the
> >>>> consequences of an anomalous force being applied to a naturally
> >>>> stable orbit at all.
> >>>
> >>> The consequences are stated above. Think carefully
> >>> about the direction your force acts in
> >>
> >> Do you think I'm stupid.
>
> > I can only judge from what you write and based on
> > that I would say you are innumerate. You did not
> > know the basic laws of arithmetic and you are still
> > making a serious mistake with the sign of the
> > velocity, one you repeat in the code at the bottom
> > even though you corrected it a few posts back.
>
> I'm not really buying your rather uncharacteristically emotional
> reply because, apart from justifying the emotional rant, it
> doesn't seem to be you at all.
It's not me normally but you specifically asked so
I gave a quiet and measured reply, not a rant. Your
difficulties with maths are at the bottom of all of this
and until you recognise and address them, there is
no way to resolve the disagreement.
> But it's a shame that you wasted
> it on a false premise, in that I'm not actually wrong this time.
You are wrong in the way you calculate the orbit
from the equation, the methods you are trying to
use don't work. The method I showed you in the
program where the acceleration, velocity and location
are all treated as separate x and y components is
the rigorous and correct method and any alternative
must be equivalent, giving the same answer.
> Do get this straight though George, in the quest for truth, not
> getting it right yesterday or today is of no consequence, so long
> as I get it right tomorrow.
Yes, that's why I have continued. Eventually, if you
get fed up with me pointing out the same errors in
your maths each time, I hope you will go off and try
to find a maths book or website where you can find
the truth in the hope of disproving my statements.
When you do that, you will find every source says
the same thing and that I am right about the maths.
OK, if I follow the diagram, Mercury is at 'o' heading for 'x'.
The orbital speed is the length of ox = 'c' and you break
that into components 'a' and 'b' using Pythagoras where
line 'b' points to the Sun. That is OK but you are missing
two points, firstly, in the next time period, Mercury will be
to the right of this diagram hence the line 'b' must be
slightly rotated to still point at the Sun. That mixes up
the components so some of speed 'b' from this diagram
becomes part of speed 'a' in the next and vice versa, hence
as I said the fall rate is not known. Secondly the speed 'c'
is not constant. For an elliptical orbit, the speed is greater
at perihelion than aphelion and your diagram will not
reproduce that since you are not including the basic
gravitational force in the calculations.
> >> The set of equations in your program describe every possible
> >> naturally occurring orbit, between a circular orbit and a direct
> >> fall.
>
> > Yes.
>
> >> Every one of those orbits are therefore identical.
>
> > Don't be silly, obviously an ellipse is not identical to
> > a circle.
>
> It's time to take off your rose colored glasses and face reality.
I am telling you reality, your maths is wrong and you
nedd to lay aside the physics for a while and study
basic schoolboy calculus as a _pure_ maths topic
before you will resolve that.
> An elliptical orbit is nothing more than a circular orbit which
> has been kicked off center.
Rubbish, the major axis is longer than the minor axis.
> And by the way, energy must be
> transferred from somewhere to somewhere for that imbalance to be
> removed, in a completely closed system George. How do you propose
> to do that?
You should already know that in a standard Keplerian orbit
energy transfers between kinetic and potential to an extent
dependent on the eccentricity. The mechanism is the
Newtonian gravitational force.
> >> I've included another progress report in the form of a Qbasic
> >> program. Note that my position has never changed at all. Meaning
> >> that I'm not "off on a new tack", as you put it. I am in fact
> >> still on my original tack because you have not shown me anything
> >> that could sway me one bit toward yours.
> >>
> >> The total fall distance ...
>
> > Stop there. What you call the "total fall distance" is calculated
> > as if the planet was falling directly towards the planet but it
> > is not. That formula and everything thereafter is therefore wrong.
>
> >> is now added to the radius in the same
> >> manner as described at the above address. That is the proper
> >> method of applying an anomalous gravity change to a circular
> >> orbit,
>
> > Wrong it is not the proper way to add any acceleration to
> > any orbit. The only valid way is to add the change of velocity
> > due to acceleration to the current velocity taking into account
> > the directions because that is the DEFINITION of acceleration.
>
> Exactly. And the force direction determines where that
> acceleration is pointing, which is always (near enough to)
> directly toward each gravitating body.
The force is always EXACTLY towards the Sun in Newtonian
gravitation, and as I understand your suggestion, the anisotropy
is just a chaneg in the size of that force, not the direction.
> The RADIAL velocity is
> the only one of any consequence, not the tangential "velocity",
> or any part thereof.
Sorry Max, both matter. You cannot just ignore aspects
simply because you don't have the mathematical ability
to include them.
> You are still plotting natural orbits.
> Get over it!
I am plotting what happens to the orbit if you add an
anisotropic effect to the Newtonian force which is
exactly what you have been describing. My plots are
mathematically correct and accurate to better than a
metre per orbit.
> > Try to get that into your skull Max, acceleration is DEFINED
> > as the rate of change of velocity.
>
> So what's the problem?
The problem is that you don't have enough mathematical
ability to do the integration and have tried to use alternative
methods that use too many simplifications and don't work
as a consequence. I have done the integration for you.
> The anisotropy causes Mercury to
> anomalously accelerate _DIRECTLY_ toward or away from the Sun.
> It's not pushed sideways by the anisotropy, as you claim.
I havn't suggested it is pushed sideways by the anisotropy
but even for a normal Keplerian orbit, the orbital speed
varies. It is higher at perihelion than at aphelion and the
direction of motion is purely tangential at both points so
there is clearly a change of tangential speed. Your method
doesn't reproduce that and again that is symptomatic of
your errors in the maths.
> > I'll snip most of the rest, since it is invalidated by that
> > error in your approach already, but I will pick up on this
> > again:
> >
> >> IF anc >= anb THEN s = (vz ^ 2# - (ana ^ 2 * dt)) ^ .5#
> >> IF anc < anb THEN s = (vz ^ 2# + (ana ^ 2 * dt)) ^ .5#
>
> > If you swap the sign, you change an increase of gravity into a
> > decrease or vice versa. Your program _appears_ to restore the
> > planet to its starting radius after each orbit
>
> No George. My program restores the planet to its true perihelion
> and aphelion radii after the anisotropy finally reduces to zero
> at each turnaround point in the orbit.
Yes Max, and that is wrong. the radii at those points are
changed by the anisotropy.
> > because you have
> > reversed the effect of the anisotropy on one leg, either gravity
> > is increased on both the inward and outward legs or, depending
> > on other signs, it might be decreased on both.
>
> You should know very well why the sign must be physically
> changed. If you plug these numbers into your calculator you will
> always get the same answer from each one, regardless of the sign
> on ana.
>
> dt = 1
> ana = 1
>
> # = ((-ana)^2 * dt)^.5 is always 1.
> # = (ana^2 * dt)^.5 is always 1.
>
> - ((-ana)^2 * dt)^.5 = -1
>
> In the program, I have left out the set of brackets around
> ((ana). It still gives the correct result when ana becomes
> negative, even if it's not supposed to.
If it results in the aphelion radius reverting to the original
value then you have the sign wrong. Starting from aphelion,
the radius at the first perihelion should be increased
compared to the usual Keplerian value while the next
aphelion will be reduced from the Keplerian value for that
orbit.
> Perhaps that has confused
> you.
I haven't actually checked your signs because it depends
on a number of other factors as well, but if the perihelion
is restored, you either have an increase of gravity on both
legs or a decrease on both where in fact you should get
a decrease on the inward leg and an increase on the
outward. I'll leave it to you to find out which leg is wrong.
> Anyway, I've added the brackets to the program, and that has
> now been updated to generate a 250 cycle data file, which is used
> to plot some quite interesting graphs.
>
> I won't clutter the post with details this time. You seem to
> ignore most of them anyway.
Indeed, I have told you what is wrong with your maths
and studying results I know to be wrong is pointless.
I have a already put plots of what your equation actually
predicts on the web - you saw them some weeks ago,
and although I haven't published it I also ran a slight
variation of the program which added the "rest of the
universe" effect and confirmed the slower decay of the
circular orbit that we derived some months ago.
Until you sort out your problems with calculus, there
isn't any point in discussing my results either because
neither of us accepts the other's method.
George
Max Keon
> Max Keon wrote:
>> George Dishman wrote:
>>> Max Keon wrote:
>> Do get this straight though George, in the quest for truth, not
>> getting it right yesterday or today is of no consequence, so long
>> as I get it right tomorrow.
> Yes, that's why I have continued. Eventually, if you
> get fed up with me pointing out the same errors in
> your maths each time, I hope you will go off and try
> to find a maths book or website where you can find
> the truth in the hope of disproving my statements.
> When you do that, you will find every source says
> the same thing and that I am right about the maths.
How can "every source" possibly say anything relating to a
gravity anisotropy when a gravity anisotropy has never been
represented in mathematics?
You alone have chosen the maths to suit the outcome you want.
That is nonsense.
This is the error per second for the circular orbit specified
below. It will be much the same for the tangential speed of any
part of an eccentric orbit.
__b____
l .
l
a l .
l c
l .
l.
l
a = 5.8e10 meters
b = 48000
c = sqr(a^2 + b^2)
c = sqr(5.8e10^2 + 48000^2) = 58000000000.01986
c - a = .01986
And then:
a
-----------------l
- _ l b
c - l
a = 48000
b = .01986
c = sqr(a^2 + b^2)
c = sqr(48000^2 + .01986^2) = 48000.00000000411
c - a = 4.11e-9
The orbital speed error is 4.11e-9 m/sec or 0.0312 meters per
orbit. The fall rate is known to a high enough degree of
accuracy for the purpose.
> Secondly the speed 'c'
> is not constant. For an elliptical orbit, the speed is greater
> at perihelion than aphelion and your diagram will not
> reproduce that since you are not including the basic
> gravitational force in the calculations.
>>>> The set of equations in your program describe every possible
>>>> naturally occurring orbit, between a circular orbit and a direct
>>>> fall.
>>>
>>> Yes.
>>>
>>>> Every one of those orbits are therefore identical.
>>>
>>> Don't be silly, obviously an ellipse is not identical to
>>> a circle.
>>
>> It's time to take off your rose colored glasses and face reality.
> I am telling you reality, your maths is wrong and you
> nedd to lay aside the physics for a while and study
> basic schoolboy calculus as a _pure_ maths topic
> before you will resolve that.
>> An elliptical orbit is nothing more than a circular orbit which
>> has been kicked off center.
> Rubbish, the major axis is longer than the minor axis.
How could it not be? You really are missing the point here.
>> And by the way, energy must be
>> transferred from somewhere to somewhere for that imbalance to be
>> removed, in a completely closed system George. How do you propose
>> to do that?
> You should already know that in a standard Keplerian orbit
> energy transfers between kinetic and potential to an extent
> dependent on the eccentricity. The mechanism is the
> Newtonian gravitational force.
What are you trying to say? Are you suggesting that if an
anomalous change in gravity occurs enroute to the aphelion and
is removed prior to arriving, the rise to the previous aphelion
radius will somehow be prematurely halted? Why on earth would
you think that? Or were you not really saying anything at all?
---
>> You are still plotting natural orbits.
>> Get over it!
> I am plotting what happens to the orbit if you add an
> anisotropic effect to the Newtonian force which is
> exactly what you have been describing. My plots are
> mathematically correct and accurate to better than a
> metre per orbit.
Very impressive George. It's a shame that you can't apply the
gravity anisotropy the way you do.
Your plots are mathematically correct according to a program
which can plot the coordinates for any degree of eccentricity,
to a perfect circle. That's all it does. You have CHOSEN to add
the anisotropy in such a manner as to generate the result that
best suits your purpose. And you alone have made that choice
because there cannot be anything already established to support
it. A gravity anisotropy has not previously been known to exist.
This is how it works
http://members.optusnet.com.au/maxkeon/proven2.html
---
You are still on the wrong tram. The sign change is correct.
But your reasoning is not.
>> Anyway, I've added the brackets to the program, and that has
>> now been updated to generate a 250 cycle data file, which is used
>> to plot some quite interesting graphs.
>>
>> I won't clutter the post with details this time. You seem to
>> ignore most of them anyway.
> Indeed, I have told you what is wrong with your maths
> and studying results I know to be wrong is pointless.
>
> I have a already put plots of what your equation actually
> predicts on the web - you saw them some weeks ago,
> and although I haven't published it I also ran a slight
> variation of the program which added the "rest of the
> universe" effect and confirmed the slower decay of the
> circular orbit that we derived some months ago.
You've had your little rant, now it must be my turn.
If you've applied the same logic as you have in the past, you
are wrong again. But I think I understand why at this time you
feel the need to denounce a gravity anisotropy which is acting
on anything that moves relative to the local frame of the
universe. I saw that post on sci.astro.research too. It seems
that your dark matter faces yet another dilemma.
I was quite taken by one of the possible causes, that dark matter
is possibly affected, not only by gravity but also by some as yet
unknown interaction between dark matter particles. That amazingly
postulated speculation was then labeled "an exciting
alternative". An exciting alternative that would require new
physics.
Einstein's theories cannot explain what nature is clearly
demonstrating, so they break down if some reason for the anomaly
is not forthcoming. So we dream up anything that will fill the
void, even if there is no prior evidence of its existence
whatever. So long as it fills the void, that's all that matters.
Let's just say that it's invisible. Hey, we're the scientists,
so we can say whatever we like.
Do you really think that the world is going along for the ride
with you on this? Do you not realize that the world is rapidly
turning its back on physics, that the credibility of physics is
rapidly eroding away. Do you not know that you are just jabbering
amongst yourselves? Do you not know that the future of humankind
is in crisis?
As Richard Dawkins put it, militant faith is again on the march
despite the progress of science.
Can you guess why? Throwing in more bullshit just makes the pile
bigger doesn't it.
The only thing that will neutralize bullshit is stark reality,
and it's about time you all started doing the job the world is
paying you to do.
> Until you sort out your problems with calculus, there
> isn't any point in discussing my results either because
> neither of us accepts the other's method.
Maths can't make your result any less wrong because your basic
principles are wrong. Sort out _your_ problems George.
We will never agree to disagree either because YOU ARE WRONG.
-----
Max Keon
George Dishman
Max Keon wrote:
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1187338532.4...@r34g2000hsd.googlegroups.com...
> > Max Keon wrote:
> >> George Dishman wrote:
> >>> Max Keon wrote:
>
> >> Do get this straight though George, in the quest for truth, not
> >> getting it right yesterday or today is of no consequence, so long
> >> as I get it right tomorrow.
>
> > Yes, that's why I have continued. Eventually, if you
> > get fed up with me pointing out the same errors in
> > your maths each time, I hope you will go off and try
> > to find a maths book or website where you can find
> > the truth in the hope of disproving my statements.
> > When you do that, you will find every source says
> > the same thing and that I am right about the maths.
>
> How can "every source" possibly say anything relating to a
> gravity anisotropy when a gravity anisotropy has never been
> represented in mathematics?
Because you have expressed that anisotropy as an
acceleration and the relationship between acceleration,
velocity and location are fixed by their definitions.
> You alone have chosen the maths to suit the outcome you want.
There is no possible choce to make Max, acceleration
is DEFINED and the rate of change of velocity so you
get the velocity by integrating the total acceleration.
That is the ONLY method permitted by the definition
and other techniques can only be equivalent to that
or wrong.
It is complex admittedly but it is correct. It leads to
the apparent centrifugal and coriolis pseudo-forces.
Sorry, you are missing Kepler's Law, the speed varies
in an eliptical orbit.
> The fall rate is known to a high enough degree of
> accuracy for the purpose.
Nothing like it, you have now missed two major
effects. What you have said above is badly flawed.
> > Secondly the speed 'c'
> > is not constant. For an elliptical orbit, the speed is greater
> > at perihelion than aphelion and your diagram will not
> > reproduce that since you are not including the basic
> > gravitational force in the calculations.
>
> >>>> The set of equations in your program describe every possible
> >>>> naturally occurring orbit, between a circular orbit and a direct
> >>>> fall.
> >>>
> >>> Yes.
> >>>
> >>>> Every one of those orbits are therefore identical.
> >>>
> >>> Don't be silly, obviously an ellipse is not identical to
> >>> a circle.
> >>
> >> It's time to take off your rose colored glasses and face reality.
>
> > I am telling you reality, your maths is wrong and you
> > nedd to lay aside the physics for a while and study
> > basic schoolboy calculus as a _pure_ maths topic
> > before you will resolve that.
>
> >> An elliptical orbit is nothing more than a circular orbit which
> >> has been kicked off center.
>
> > Rubbish, the major axis is longer than the minor axis.
>
> How could it not be?
Look at the diagram of the ellipses I cited a few posts
back, it is obvious that the high eccentricity values
have a long, narrow shape, they are nowhere near
being circles.
> You really are missing the point here.
You are talking complete rubbish here.
> >> And by the way, energy must be
> >> transferred from somewhere to somewhere for that imbalance to be
> >> removed, in a completely closed system George. How do you propose
> >> to do that?
>
> > You should already know that in a standard Keplerian orbit
> > energy transfers between kinetic and potential to an extent
> > dependent on the eccentricity. The mechanism is the
> > Newtonian gravitational force.
>
> What are you trying to say?
You asked how energy was "transferred from somewhere
to somewhere" in a "completely closed system" when I
previously talked about the change of speed between
perihelion and aphelion so I guess you are asking how
the kinetic energy is transferred to permit that speed
change. If not, make your question clearer.
> Are you suggesting that if an
> anomalous change in gravity occurs enroute to the aphelion and
> is removed prior to arriving, the rise to the previous aphelion
> radius will somehow be prematurely halted? Why on earth would
> you think that? Or were you not really saying anything at all?
I was trying to answer the question you asked which
relates to the newtonian part of gravity, nothing to do
with the anisotropy.
> >> You are still plotting natural orbits.
> >> Get over it!
>
> > I am plotting what happens to the orbit if you add an
> > anisotropic effect to the Newtonian force which is
> > exactly what you have been describing. My plots are
> > mathematically correct and accurate to better than a
> > metre per orbit.
>
> Very impressive George. It's a shame that you can't apply the
> gravity anisotropy the way you do.
That is the ONLY way permitted by the definition of
acceleration. You need to learn the basics of calculus
before we cann talk sensibly.
> Your plots are mathematically correct according to a program
> which can plot the coordinates for any degree of eccentricity,
> to a perfect circle. That's all it does. You have CHOSEN to add
> the anisotropy in such a manner as to generate the result that
> best suits your purpose.
No, I have NO choice. I have added the anisotropic
acceleration in the only way permitted by the rules
of mathematics.
> And you alone have made that choice
> because there cannot be anything already established to support
> it. A gravity anisotropy has not previously been known to exist.
Acceleration is a uniquely defined quantity, there is
no option in how you use it. Your equation defines
an acceleration and my maths handles that in the
only way posible.
> This is how it works
> http://members.optusnet.com.au/maxkeon/proven2.html
Sorry Max, until you learn calculus, you are not going
to be able to work this out.
...
> > I haven't actually checked your signs because it depends
> > on a number of other factors as well, but if the perihelion
> > is restored, you either have an increase of gravity on both
> > legs or a decrease on both where in fact you should get
> > a decrease on the inward leg and an increase on the
> > outward. I'll leave it to you to find out which leg is wrong.
>
> You are still on the wrong tram. The sign change is correct.
> But your reasoning is not.
All I will suggest is that you break your program at the
one quarter and three quarter orbit points and check
for yourself whether the anisotropy is increasing or
decreasing the Newtonian acceleration. I think you
will find it is the same in both cases when they should
differ. Don't take my word for it, check.
> >> Anyway, I've added the brackets to the program, and that has
> >> now been updated to generate a 250 cycle data file, which is used
> >> to plot some quite interesting graphs.
> >>
> >> I won't clutter the post with details this time. You seem to
> >> ignore most of them anyway.
>
> > Indeed, I have told you what is wrong with your maths
> > and studying results I know to be wrong is pointless.
> >
> > I have a already put plots of what your equation actually
> > predicts on the web - you saw them some weeks ago,
> > and although I haven't published it I also ran a slight
> > variation of the program which added the "rest of the
> > universe" effect and confirmed the slower decay of the
> > circular orbit that we derived some months ago.
>
> You've had your little rant, now it must be my turn.
Sorry Max, a 'rant' is an emotional outburst, what I said
is simply a factual statement that I have run the
simulation and posted some of the results.
> If you've applied the same logic as you have in the past, you
> are wrong again. But I think I understand why at this time you
> feel the need to denounce a gravity anisotropy which is acting
> on anything that moves relative to the local frame of the
> universe. I saw that post on sci.astro.research too. It seems
> that your dark matter faces yet another dilemma.
>
> I was quite taken by one of the possible causes, that dark matter
> is possibly affected, not only by gravity but also by some as yet
> unknown interaction between dark matter particles. That amazingly
> postulated speculation was then labeled "an exciting
> alternative". An exciting alternative that would require new
> physics.
Dark matter is non-baryonic so new physics would not
be surprising, it is an exciting prospect indeed. The best
handle we have so far seems to be the Bullet Cluster
where the two clumps of dark matter associatated with
the galaxies have passed through each other.
> Einstein's theories cannot explain what nature is clearly
> demonstrating, so they break down if some reason for the anomaly
> is not forthcoming.
You seem confused. It is the gravitational lensing of
Einsein's theory that provides the tool we use to
investigate dark matter. Lensing of more distant
objects allows us the map the distribution of the
dark matter.
> So we dream up anything that will fill the
> void, even if there is no prior evidence of its existence
> whatever. So long as it fills the void, that's all that matters.
> Let's just say that it's invisible. Hey, we're the scientists,
> so we can say whatever we like.
Again you are confused, dark matter has similar
charateristics to neutrinos but seems to have a
slightly higher mass.
<snip rant>
> > Until you sort out your problems with calculus, there
> > isn't any point in discussing my results either because
> > neither of us accepts the other's method.
>
> Maths can't make your result any less wrong because your basic
> principles are wrong. Sort out _your_ problems George.
There are no problems in my maths Max, get
yourself a book on calculus and find out what
the definition of acceleration is.
> We will never agree to disagree either because YOU ARE WRONG.
Sorry Max, this is not something that is open to
debate. I am right about the maths, end of story.
You can confirm that by reading any high school
text books covering calculus and basic mechanics.
Your equation predicts eccentricity will decay to
zero in a two body situation and therafter the orbit
will be stable. With three or more bodies, it says
even the circular orbit will decay though more
slowly. For Mercury, it is still fast enough to crash
it into the Sun in a million years.
Your emotional outbusts may make you feel better
but they will not changes the rules of maths and
they won't change the consequences of your
equation, it is undoubtedly wrong.
George
Max Keon
> Max Keon wrote:
>> George Dishman wrote:
>>> Max Keon wrote:
>> How can "every source" possibly say anything relating to a
>> gravity anisotropy when a gravity anisotropy has never been
>> represented in mathematics?
> Because you have expressed that anisotropy as an
> acceleration and the relationship between acceleration,
> velocity and location are fixed by their definitions.
>> You alone have chosen the maths to suit the outcome you want.
> There is no possible choce to make Max, acceleration
> is DEFINED and the rate of change of velocity
Well why do you have such a problem understanding why you are
wrongly applying the anisotropy? The rate of change of velocity
in the direction along which the force is applied, being directly
toward the Sun, _and only directly toward the Sun,_ is exactly
what it should be. Your own _personal_ assumption that the force
points in other directions as well is completely false.
When the anisotropy is correctly applied, it still has
consequences of course, but nothing like what you have proposed.
Those consequences are exactly as described at this address,
http://members.optusnet.com.au/maxkeon/proven2.html
See if you can get it right this time.
> so you
> get the velocity by integrating the total acceleration.
No. You only get it right if you apply the anisotropy correctly,
along the line of the force and nowhere else, then note the
consequences that it has on the natural eccentricity of the
orbit.
> That is the ONLY method permitted by the definition
> and other techniques can only be equivalent to that
> or wrong.
????
---
>>>> You are still plotting natural orbits.
>>>> Get over it!
>>>
>>> I am plotting what happens to the orbit if you add an
>>> anisotropic effect to the Newtonian force which is
>>> exactly what you have been describing. My plots are
>>> mathematically correct and accurate to better than a
>>> metre per orbit.
>>
>> Very impressive George. It's a shame that you can't apply the
>> gravity anisotropy the way you do.
> That is the ONLY way permitted by the definition of
> acceleration. You need to learn the basics of calculus
> before we cann talk sensibly.
>> Your plots are mathematically correct according to a program
>> which can plot the coordinates for any degree of eccentricity,
>> to a perfect circle. That's all it does. You have CHOSEN to add
>> the anisotropy in such a manner as to generate the result that
>> best suits your purpose.
> No, I have NO choice. I have added the anisotropic
> acceleration in the only way permitted by the rules
> of mathematics.
You have done no such thing.
---
>>> I haven't actually checked your signs because it depends
>>> on a number of other factors as well, but if the perihelion
>>> is restored, you either have an increase of gravity on both
>>> legs or a decrease on both where in fact you should get
>>> a decrease on the inward leg and an increase on the
>>> outward. I'll leave it to you to find out which leg is wrong.
>>
>> You are still on the wrong tram. The sign change is correct.
>> But your reasoning is not.
> All I will suggest is that you break your program at the
> one quarter and three quarter orbit points and check
> for yourself whether the anisotropy is increasing or
> decreasing the Newtonian acceleration. I think you
> will find it is the same in both cases when they should
> differ. Don't take my word for it, check.
There's no doubt about it George. The physical sign manipulation
is essential because the required equations always give a
positive result even when the anisotropy becomes negative.
Just in case you've forgotten;
dt = 1
ana = 1
# = (ana^2 * dt)^.5 is always 1.
# = ((-ana)^2 * dt)^.5 is always 1.
# = -((-ana)^2 * dt)^.5 is always -1
---
>> If you've applied the same logic as you have in the past, you
>> are wrong again. But I think I understand why at this time you
>> feel the need to denounce a gravity anisotropy which is acting
>> on anything that moves relative to the local frame of the
>> universe. I saw that post on sci.astro.research too. It seems
>> that your dark matter faces yet another dilemma.
>>
>> I was quite taken by one of the possible causes, that dark matter
>> is possibly affected, not only by gravity but also by some as yet
>> unknown interaction between dark matter particles. That amazingly
>> postulated speculation was then labeled "an exciting
>> alternative". An exciting alternative that would require new
>> physics.
> Dark matter is non-baryonic so new physics would not
> be surprising, it is an exciting prospect indeed. The best
> handle we have so far seems to be the Bullet Cluster
> where the two clumps of dark matter associatated with
> the galaxies have passed through each other.
And the latest evidence doesn't comply with that.
>> Einstein's theories cannot explain what nature is clearly
>> demonstrating, so they break down if some reason for the anomaly
>> is not forthcoming.
> You seem confused. It is the gravitational lensing of
> Einsein's theory that provides the tool we use to
> investigate dark matter. Lensing of more distant
> objects allows us the map the distribution of the
> dark matter.
How can a fact of nature be taken aside and labeled "Einstein's
theory" ? Such lensing was obviously going to be present long
before Einstein came along. It _is_ a fact of nature you know.
Anyway, what makes you think the lensing is causes by dark
matter? Why not something that nature predicts, like a black
hole(s)? They are almost certainly a component of a galaxy
center and can be scattered according to how they collide, or
don't collide. There's no reason why the deflection directions
can't be along the line to the Earth.
>> So we dream up anything that will fill the
>> void, even if there is no prior evidence of its existence
>> whatever. So long as it fills the void, that's all that matters.
>> Let's just say that it's invisible. Hey, we're the scientists,
>> so we can say whatever we like.
> Again you are confused, dark matter has similar
> charateristics to neutrinos but seems to have a
> slightly higher mass.
So what's the mandatory speed at which these dark matter beasties
travel? The so called massive neutrino is compelled by some man
made law of nature to travel at a speed which is vaguely less
than the speed of E/M radiation. If the speed of dark matter is
anything like that, it could not be constrained to cycle about a
galaxy unless the galaxy was almost dense enough to form a black
hole. The massive neutrino would be trapped only just prior to
light. Dark matter would become entrapped before that.
But the speed of dark matter can be no more than the orbital
speed required to hold a mass in the outer region of a galaxy,
otherwise it will fly off into the universe.
Has a dark matter speed been established?
What god is telling you all of this stuff George.
Here's a Universe that's not an alternative to the big
bang theory or any other theory. It's the real Universe,
and it clearly predicts a gravity anisotropy.
http://members.optusnet.com.au/maxkeon/the1-1a.html
> <snip rant>
You've snipped the wrong part.
>>> Until you sort out your problems with calculus, there
>>> isn't any point in discussing my results either because
>>> neither of us accepts the other's method.
>>
>> Maths can't make your result any less wrong because your basic
>> principles are wrong. Sort out _your_ problems George.
> There are no problems in my maths Max,
The problem has never been with your maths, only with the way
you apply it.
> get
> yourself a book on calculus and find out what
> the definition of acceleration is.
>> We will never agree to disagree either because YOU ARE WRONG.
> Sorry Max, this is not something that is open to
> debate. I am right about the maths, end of story.
> You can confirm that by reading any high school
> text books covering calculus and basic mechanics.
>
> Your equation predicts eccentricity will decay to
> zero in a two body situation and therafter the orbit
> will be stable. With three or more bodies, it says
> even the circular orbit will decay though more
> slowly. For Mercury, it is still fast enough to crash
> it into the Sun in a million years.
>
> Your emotional outbusts may make you feel better
They are designed as a wake up call George.
But you're not yet ready to be unplugged.
-----
Max Keon
George Dishman
>
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1187594178.8...@g4g2000hsf.googlegroups.com...
>> Max Keon wrote:
>>> George Dishman wrote:
>>>> Max Keon wrote:
>
>>> How can "every source" possibly say anything relating to a
>>> gravity anisotropy when a gravity anisotropy has never been
>>> represented in mathematics?
>
>> Because you have expressed that anisotropy as an
>> acceleration and the relationship between acceleration,
>> velocity and location are fixed by their definitions.
>
>>> You alone have chosen the maths to suit the outcome you want.
>
>> There is no possible choce to make Max, acceleration
>> is DEFINED and the rate of change of velocity
>
> Well why do you have such a problem understanding why you are
> wrongly applying the anisotropy?
I am applying as your equation dictates - I have
no choice.
> The rate of change of velocity
> in the direction along which the force is applied, being directly
> toward the Sun, _and only directly toward the Sun,_ is exactly
> what it should be. Your own _personal_ assumption that the force
> points in other directions as well is completely false.
I am applying it exactly towards the Sun. A long
time ago I spent several weeks trying to get you
to clarify the direction and eventually I gathered
that was what you meant though you were never
entirely clear on the point.
The program calculates the _magnitude_ of the
anisotropy using (v_r/c) times the Newtonian value
and assumes the direction is the same as the
Newtonian force, i.e. directly towards the Sun.
> When the anisotropy is correctly applied, it still has
> consequences of course, but nothing like what you have proposed.
The consequences of the equation as you have written
it and an assumed direction of towards the Sun are
as I have told you.
> Those consequences are exactly as described at this address,
> http://members.optusnet.com.au/maxkeon/proven2.html
Your methods are mathematically incorrect, I have
explained repeatedly how to do it properly but if
you continue to refuse to get out your maths books
and learn how to handle vectors and calculus, you
are not going to correct your errors
> See if you can get it right this time.
>
>> so you
>> get the velocity by integrating the total acceleration.
>
> No. You only get it right if you apply the anisotropy correctly,
> along the line of the force and nowhere else,
That is precisely what my program does.
> then note the
> consequences that it has on the natural eccentricity of the
> orbit.
Yes, it decays rapidly.
>> That is the ONLY method permitted by the definition
>> and other techniques can only be equivalent to that
>> or wrong.
>
> ????
Acceleration is defined as the derivative of the
velocity. The inverse operation to differentiation
is integration. To get the velocity therefore, you
must integrate the acceleration. Since your equation
fully defines the acceleration and the results of
integration are unique, it follows that the result
of that process is unique. The consequence my program
calculates is the _only_ correct result.
>> No, I have NO choice. I have added the anisotropic
>> acceleration in the only way permitted by the rules
>> of mathematics.
>
> You have done no such thing.
Yes I have, open up a maths textbook and find out.
>> All I will suggest is that you break your program at the
>> one quarter and three quarter orbit points and check
>> for yourself whether the anisotropy is increasing or
>> decreasing the Newtonian acceleration. I think you
>> will find it is the same in both cases when they should
>> differ. Don't take my word for it, check.
>
> There's no doubt about it George.
Then do the test I suggest and find out.
The physical sign manipulation
> is essential because the required equations always give a
> positive result even when the anisotropy becomes negative.
>
> Just in case you've forgotten;
>
> dt = 1
> ana = 1
> # = (ana^2 * dt)^.5 is always 1.
This is just another example of your problems with
simple maths. You are again taking the root of a
square
# = (ana^2 * dt)^.5
is the same as
# = ana * sqrt(dt)
But why are you calculating that in the first place?
If you are trying to find the distance moved due to
acceleration it should be s = 1/2 * ana^2 * dt and
if you are finding the change of speed it is
dv = ana * dt, neither involves the square root of
the time.
>> Dark matter is non-baryonic so new physics would not
>> be surprising, it is an exciting prospect indeed. The best
>> handle we have so far seems to be the Bullet Cluster
>> where the two clumps of dark matter associatated with
>> the galaxies have passed through each other.
>
> And the latest evidence doesn't comply with that.
Cite the paper please.
>>> Einstein's theories cannot explain what nature is clearly
>>> demonstrating, so they break down if some reason for the anomaly
>>> is not forthcoming.
>
>> You seem confused. It is the gravitational lensing of
>> Einsein's theory that provides the tool we use to
>> investigate dark matter. Lensing of more distant
>> objects allows us the map the distribution of the
>> dark matter.
>
> How can a fact of nature be taken aside and labeled "Einstein's
> theory" ?
What I labelled "Einstein's theory" gives us the maths
that describes that aspect of Nature.
> Such lensing was obviously going to be present long
> before Einstein came along. It _is_ a fact of nature you know.
Of course.
> Anyway, what makes you think the lensing is causes by dark
> matter?
Dark matter just means something that has mass but
doesn't interact with light, it is a 'catch all'
generic term and deliberately vague.
> Why not something that nature predicts, like a black
> hole(s)?
Because microlensing surveys should detect them.
The find some events but not enough.
> They are almost certainly a component of a galaxy
> center and can be scattered according to how they collide, or
> don't collide. There's no reason why the deflection directions
> can't be along the line to the Earth.
>
>>> So we dream up anything that will fill the
>>> void, even if there is no prior evidence of its existence
>>> whatever. So long as it fills the void, that's all that matters.
>>> Let's just say that it's invisible. Hey, we're the scientists,
>>> so we can say whatever we like.
>
>> Again you are confused, dark matter has similar
>> charateristics to neutrinos but seems to have a
>> slightly higher mass.
>
> So what's the mandatory speed at which these dark matter beasties
> travel?
There are a number of fairly complex measurements
that suggest they move slowly while neutrinos move
near the speed of light. You will hear the term
"cold dark matter" often abbreviated to "CDM" and
that refers to the mean speed being much less than
the speed of light.
> The so called massive neutrino is compelled by some man
> made law of nature to travel at a speed which is vaguely less
> than the speed of E/M radiation. If the speed of dark matter is
> anything like that, it could not be constrained to cycle about a
> galaxy unless the galaxy was almost dense enough to form a black
> hole.
Even then it would either fall in or escape, the
stable region is negligibly thin. You are exactly
right, that is a key piece of evidence that DM is
cold, it has less than the escape velocity of the
galaxies with which it is associated.
> The massive neutrino would be trapped only just prior to
> light. Dark matter would become entrapped before that.
>
> But the speed of dark matter can be no more than the orbital
> speed required to hold a mass in the outer region of a galaxy,
> otherwise it will fly off into the universe.
>
> Has a dark matter speed been established?
>
> What god is telling you all of this stuff George.
No god Max, you have a good understanding of how
that aspect is worked out.
> Here's a Universe that's not an alternative to the big
> bang theory or any other theory. It's the real Universe,
> and it clearly predicts a gravity anisotropy.
> http://members.optusnet.com.au/maxkeon/the1-1a.html
>
>
>> <snip rant>
>
> You've snipped the wrong part.
It had no more scientific content.
>>>> Until you sort out your problems with calculus, there
>>>> isn't any point in discussing my results either because
>>>> neither of us accepts the other's method.
>>>
>>> Maths can't make your result any less wrong because your basic
>>> principles are wrong. Sort out _your_ problems George.
>
>> There are no problems in my maths Max,
>
> The problem has never been with your maths, only with the way
> you apply it.
It is the only method permitted by the rules of
mathematics Max, you need to get your schoolbooks
out again and do some revision.
>> get
>> yourself a book on calculus and find out what
>> the definition of acceleration is.
>
>>> We will never agree to disagree either because YOU ARE WRONG.
>
>> Sorry Max, this is not something that is open to
>> debate. I am right about the maths, end of story.
>> You can confirm that by reading any high school
>> text books covering calculus and basic mechanics.
>>
>> Your equation predicts eccentricity will decay to
>> zero in a two body situation and therafter the orbit
>> will be stable. With three or more bodies, it says
>> even the circular orbit will decay though more
>> slowly. For Mercury, it is still fast enough to crash
>> it into the Sun in a million years.
>>
>> Your emotional outbusts may make you feel better
>
> They are designed as a wake up call George.
> But you're not yet ready to be unplugged.
Unplugged from the rules of maths? No I don't
think that would help.
George
Max Keon
> Max Keon wrote:
>> George Dishman wrote:
>>> Max Keon wrote:
>>>> How can "every source" possibly say anything relating to a
>>>> gravity anisotropy when a gravity anisotropy has never been
>>>> represented in mathematics?
>>>
>>> Because you have expressed that anisotropy as an
>>> acceleration and the relationship between acceleration,
>>> velocity and location are fixed by their definitions.
>>>
>>>> You alone have chosen the maths to suit the outcome you want.
>>>
>>> There is no possible choce to make Max, acceleration
>>> is DEFINED and the rate of change of velocity
>>
>> Well why do you have such a problem understanding why you are
>> wrongly applying the anisotropy?
> I am applying as your equation dictates - I have
> no choice.
You profess to know all about the consequences of a gravity
anisotropy when you obviously can't. You have never had reason
to address such a thing in the past, and the course you've chosen
is the one that gives the best result for your purpose. But your
method of applying the anisotropic acceleration is totally wrong.
You are adding it to the naturally flowing acceleration in a
naturally occurring eccentric orbit. Which is of course nothing
more than a circular orbit that has been knocked off center.
Can you not see that?
One thing that you have never given a satisfactory explanation
for is why Mercury's fall to its previous perihelion radius is
prematurely halted as a consequence of a gravity anisotropy.
Perhaps if you try demonstrating that mathematically, it will
help you to understand why you are wrong. You will come to
realize that Mercury's orbital speed cannot be fast enough to
generate the required centrifugal force to prematurely halt its
fall and whiz it back out toward the aphelion because the
anisotropy has caused it to be drawn more slowly to the Sun
throughout the inward journey, so by the time Mercury reaches
the point of last perihelion, it has obviously fallen less
distance than normal and is traveling at a lesser speed than
normal. So how on earth does it turn around and go back out
again.
You will open up a whole new universe for me if you can prove
that it does, where nothing is impossible, or predictable.
>> The rate of change of velocity
>> in the direction along which the force is applied, being directly
>> toward the Sun, _and only directly toward the Sun,_ is exactly
>> what it should be. Your own _personal_ assumption that the force
>> points in other directions as well is completely false.
> I am applying it exactly towards the Sun. A long
> time ago I spent several weeks trying to get you
> to clarify the direction and eventually I gathered
> that was what you meant though you were never
> entirely clear on the point.
>
> The program calculates the _magnitude_ of the
> anisotropy using (v_r/c) times the Newtonian value
> and assumes the direction is the same as the
> Newtonian force, i.e. directly towards the Sun.
Yes, and that's probably why you are confused. Your program is
designed _only_ to plot a natural orbit path, _even circular_.
The Newtonian acceleration is no doubt pointing directly at the
Sun throughout the entire orbit, but directly adding the
anisotropy in the way you have done is still wrong.
My method may not yet be precise, but you are millions of meters
away from your claim of precision within 1 meter.
---
>>> All I will suggest is that you break your program at the
>>> one quarter and three quarter orbit points and check
>>> for yourself whether the anisotropy is increasing or
>>> decreasing the Newtonian acceleration. I think you
>>> will find it is the same in both cases when they should
>>> differ. Don't take my word for it, check.
>>
>> There's no doubt about it George.
> Then do the test I suggest and find out.
I recently made the mistake of not doing such a test before
jumping to conclusions and I'm not about to do it again just
yet. But thanks anyway.
>> The physical sign manipulation
>> is essential because the required equations always give a
>> positive result even when the anisotropy becomes negative.
>>
>> Just in case you've forgotten;
>>
>> dt = 1
>> ana = 1
>> # = (ana^2 * dt)^.5 is always 1.
> This is just another example of your problems with
> simple maths. You are again taking the root of a
> square
>
> # = (ana^2 * dt)^.5
>
> is the same as
>
> # = ana * sqrt(dt)
(ana^2 * dt)^.5 is only part of the equation. The proper
equation is derived from a^2 + b^2 = c^2. It becomes
s = (v^2 + ana^2)^.5 if dt is removed (s is the updated orbital
speed).
> But why are you calculating that in the first place?
I'm trying to determine the orbital speed changes according to
the path taken when the anisotropy is included as compared with
the unaffected path. I've used Pythagoras to do that.
Previous orbital speed
______________________
- _ l Anomalous
New orbital speed - l acceleration
I don't need you to tell me that I'm wrong either, only that
it's not the way you would do it. But we already know that.
I've included the program that was designed to demonstrate the
true effect of an anomalous change in gravity, and it does so
exceptionally well. It demonstrates that the orbiting mass
behaves exactly as it should according to the forces acting on
it, with centrifugal force rising to twice the anomalous force
before the falling mass can be halted and sent back out again.
You will notice that I've treated the "previous orbital speed"
as if it was tangential to the gravity source, but that is of
virtually no consequence. The largest error is an adjacent length
of 48000.0000005569 instead of 48000. The hypotenuse length
change due to the anomalous acceleration is not going to change
much if I use the extended length, is it.
This program justifies the method I'm now using to include the
anisotropy in your program.
I've added comments within the program. Feel free to reply to
them.
'-------------
' Control_break halts the program at any time.
' 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, and is, 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. It's an entirely elastic operation.
DEFDBL A-Z
SCREEN 12
CLS : COLOR 7
'-----------
LINE (176, 280)-(261, 280), 8 ' Shows the scale distortion.
LINE (261, 280)-(261, 358), 8
LINE (176, 280)-(261, 358), 8
LINE (150, 240)-(185, 284), 10
LINE (200, 360)-(200, 450), 8
LOCATE 20, 30: PRINT "313000"
LOCATE 18, 26: PRINT "6.5e10"
LOCATE 15, 10: PRINT "2.76e-4 degrees"
'-----------
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 ' Program cycle count.
ana = ana + dt * cfx ' Stores the current fall rate.
' cfx is later defined.
anb = anb + dt * ana ' Stores the total fall distance.
'-------The physical sign manipulation is necessary because the
' result of (ana)^2 is always positive, whatever the sign on ana,
' and orbital speed continues to increase regardless of the true
' value stored in ana.
IF anc >= anb THEN s = (v ^ 2# - ((ana) ^ 2 * dt)) ^ .5#
IF anc < anb THEN s = (v ^ 2# + (ana ^ 2 * dt)) ^ .5#
' s is updated orbital speed.
' The manner in which dt is included gives exactly the same result
' for all values of dt, including dt = 1. Remove dt from the
' equations altogether if it causes confusion.
' The point is that it can't be wrong because it always gives the
' same result as with no dt at all.
anc = anb
'-------------------
v = s
' v holds the updated orbital speed for the next cycle.
cf = v ^ 2# / vv ^ 2# * g ' cf is centrifugal 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 > 10000 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 - vv; "m/sec orbital speed change from the normal. "
PRINT cf; "m/sec^2 centrifugal force. "
LOCATE 24, 18
PRINT r - anb; "radius. "
RETURN
'---------------------
http://members.optusnet.com.au/maxkeon/proven2.html
has been updated slightly.
---
>>> Dark matter is non-baryonic so new physics would not
>>> be surprising, it is an exciting prospect indeed. The best
>>> handle we have so far seems to be the Bullet Cluster
>>> where the two clumps of dark matter associatated with
>>> the galaxies have passed through each other.
>>
>> And the latest evidence doesn't comply with that.
> Cite the paper please.
http://www.eurekalert.org/pub_releases/2007-08/cxc-dmm081607.php
seems to indicate that the Abell 520 system "train wreck" is not
as previously noted, as in the Bullet Cluster where the "dark
matter" and galaxies have stayed together.
>>>> Einstein's theories cannot explain what nature is clearly
>>>> demonstrating, so they break down if some reason for the anomaly
>>>> is not forthcoming.
>>>
>>> You seem confused. It is the gravitational lensing of
>>> Einsein's theory that provides the tool we use to
>>> investigate dark matter. Lensing of more distant
>>> objects allows us the map the distribution of the
>>> dark matter.
>>
>> How can a fact of nature be taken aside and labeled "Einstein's
>> theory" ?
> What I labelled "Einstein's theory" gives us the maths
> that describes that aspect of Nature.
>> Such lensing was obviously going to be present long
>> before Einstein came along. It _is_ a fact of nature you know.
> Of course.
>> Anyway, what makes you think the lensing is causes by dark
>> matter?
> Dark matter just means something that has mass but
> doesn't interact with light, it is a 'catch all'
> generic term and deliberately vague.
>> Why not something that nature predicts, like a black
>> hole(s)?
> Because microlensing surveys should detect them.
> The find some events but not enough.
How do you differentiate between dark matter and black holes?
-----
Max Keon
George Dishman
Max Keon wrote:
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message news:a4Sdnblx9c-...@pipex.net...
> > Max Keon wrote:
> >> George Dishman wrote:
> >>> Max Keon wrote:
>
> >>>> How can "every source" possibly say anything relating to a
> >>>> gravity anisotropy when a gravity anisotropy has never been
> >>>> represented in mathematics?
> >>>
> >>> Because you have expressed that anisotropy as an
> >>> acceleration and the relationship between acceleration,
> >>> velocity and location are fixed by their definitions.
> >>>
> >>>> You alone have chosen the maths to suit the outcome you want.
> >>>
> >>> There is no possible choce to make Max, acceleration
> >>> is DEFINED and the rate of change of velocity
> >>
> >> Well why do you have such a problem understanding why you are
> >> wrongly applying the anisotropy?
>
> > I am applying as your equation dictates - I have
> > no choice.
>
> You profess to know all about the consequences of a gravity
> anisotropy when you obviously can't.
I have no such need, _you_ have provided the equation
that supposedly describes the anisotropy, all _I_ need
to know is how to integrate that. It is simple maths that
I learnt in secondary school about forty years ago. You
should know it too but apparently you haven't done that.
> You have never had reason
> to address such a thing in the past, and the course you've chosen
> is the one that gives the best result for your purpose. But your
> method of applying the anisotropic acceleration is totally wrong.
I'm sorry Max, there is only one method permitted
by the definition of acceleration. If you don't like the
results, the only thing you can do is change the
equation you have given me.
> You are adding it to the naturally flowing acceleration in a
> naturally occurring eccentric orbit. Which is of course nothing
> more than a circular orbit that has been knocked off center.
>
> Can you not see that?
Your statement is factually untrue, the minor axis
of an ellipse is smaller than the major axis.
> One thing that you have never given a satisfactory explanation
> for is why Mercury's fall to its previous perihelion radius is
> prematurely halted as a consequence of a gravity anisotropy.
> Perhaps if you try demonstrating that mathematically, it will
> help you to understand why you are wrong.
I have told you over and over again why that happens,
and we discussed it in detail two months ago, see
message number 29 in this thread on Google.
> You will come to
> realize that Mercury's orbital speed cannot be fast enough to
> generate the required centrifugal force to prematurely halt its
> fall and whiz it back out toward the aphelion because the
> anisotropy has caused it to be drawn more slowly to the Sun
> throughout the inward journey, so by the time Mercury reaches
> the point of last perihelion, it has obviously fallen less
> distance than normal and is traveling at a lesser speed than
> normal. So how on earth does it turn around and go back out
> again.
>
> You will open up a whole new universe for me if you can prove
> that it does, where nothing is impossible, or predictable.
It is fully predicaable Max, just integrate the acceleration
as the maths requires. It may well open up a whole new
universe for you if you learn calculus and vectors.
> >> The rate of change of velocity
> >> in the direction along which the force is applied, being directly
> >> toward the Sun, _and only directly toward the Sun,_ is exactly
> >> what it should be. Your own _personal_ assumption that the force
> >> points in other directions as well is completely false.
>
> > I am applying it exactly towards the Sun. A long
> > time ago I spent several weeks trying to get you
> > to clarify the direction and eventually I gathered
> > that was what you meant though you were never
> > entirely clear on the point.
> >
> > The program calculates the _magnitude_ of the
> > anisotropy using (v_r/c) times the Newtonian value
> > and assumes the direction is the same as the
> > Newtonian force, i.e. directly towards the Sun.
>
> Yes, and that's probably why you are confused. Your program is
> designed _only_ to plot a natural orbit path, _even circular_.
Not true, the program integrates your equation for the
acceleration wherever that may lead.
> The Newtonian acceleration is no doubt pointing directly at the
> Sun throughout the entire orbit, but directly adding the
> anisotropy in the way you have done is still wrong.
The Newtonian acceleration points at the Sun, we
both know that. I have asked you many times what
the direction of the anisotropy is and yo never gave
a clear answer but my understanding is that it also
points along the line betwen the un and the planet
but towards the Sun on the outward leg and away
from it on the inward leg. Please either confirm that
or correct it.
The rules of vector addition in cartesian coordinates
say we must add the two x components to get the
x component of the sum and similarly for y. Since
both vectors point along the same Sun-Mercury line
those rules mean we get the same answer if we add
the signed magnitudes and the result points in the
same direction as the Newtonian force which is slightly
easier for coding so that's what the program does.
> My method may not yet be precise, ..
Your method is fundamentally wrong. An alternative
which would be similar to what you are trying to do
would be to work in polar coordinates but it is much
more complex and you need to accomodate coriolis
effects. That's not the real reason your results are
wrong thugh, you are making a few assumptions
which are incorrect. An ellipse is _not_ an offset
circle, the speed in an elliptical orbit is _not_ the
same as a cicular orbit and the path is _not_
perpendicular to the Sun-Mercury line so you cannot
use Pythagoras.
> but you are millions of meters
> away from your claim of precision within 1 meter.
When you learn how to do the maths, you will get the
same result as me.
> >>> All I will suggest is that you break your program at the
> >>> one quarter and three quarter orbit points and check
> >>> for yourself whether the anisotropy is increasing or
> >>> decreasing the Newtonian acceleration. I think you
> >>> will find it is the same in both cases when they should
> >>> differ. Don't take my word for it, check.
> >>
> >> There's no doubt about it George.
>
> > Then do the test I suggest and find out.
>
> I recently made the mistake of not doing such a test before
> jumping to conclusions and I'm not about to do it again just
> yet. But thanks anyway.
? Don't make the same mistake, do the test and
find out which way the anisotropy is pointing. If
you get the sign right you should at least see that
the path doesn't repeat but there are several other
errors listed above that will also make your result
somewhat inaccurate.
> >> The physical sign manipulation
> >> is essential because the required equations always give a
> >> positive result even when the anisotropy becomes negative.
> >>
> >> Just in case you've forgotten;
> >>
> >> dt = 1
> >> ana = 1
> >> # = (ana^2 * dt)^.5 is always 1.
>
> > This is just another example of your problems with
> > simple maths. You are again taking the root of a
> > square
> >
> > # = (ana^2 * dt)^.5
> >
> > is the same as
> >
> > # = ana * sqrt(dt)
>
> (ana^2 * dt)^.5 is only part of the equation. The proper
> equation is derived from a^2 + b^2 = c^2. It becomes
> s = (v^2 + ana^2)^.5 if dt is removed (s is the updated orbital
> speed).
That's quite different, but v is a speed while ana is an
acceleration so you cannot add them. You could correct
that error using
s = (v^2 + (ana*dt)^2)^.5
but as I said before, v and (ana*dt) are not perpendicular
so you cannot use Pythagoras. Instead you might try
breaking v into x and y components and likewise (ana*dt)
keeping both signed. Then add the components
s_x = v_x + dt * ana_x
s_y = v_y + dt * ana_y
then you could write:
s = sqrt(s_x^2 + s_y^2)
but you don't need that since you already have the x and y
components that you use for the change of location.
> > But why are you calculating that in the first place?
>
> I'm trying to determine the orbital speed changes according to
> the path taken when the anisotropy is included as compared with
> the unaffected path. I've used Pythagoras to do that.
OK, see above for how to do that properly, Pythagoras
does not apply since v and ana are not perpendicular.
> Previous orbital speed
> ______________________
> - _ l Anomalous
> New orbital speed - l acceleration
>
>
> I don't need you to tell me that I'm wrong either, only that
> it's not the way you would do it. But we already know that.
You have to follow the rules of maths, Pythagoras only
applies when the adjacent and opposite are perfectly
perpendicular.
> I've included the program that was designed to demonstrate the
> true effect of an anomalous change in gravity, and it does so
> exceptionally well.
You need to fix the problems listed above before it
will be worth looking at any code. The bottom line
is that my code is written such that it follows the
only valid method _assuming_ you really mean
that the anisotropic acceleration points directly
towards or away from the Sun depending on which
leg is being calculated. The results are accurate
enough for our needs as I have demonstrated.
> It demonstrates that the orbiting mass
> behaves exactly as it should according to the forces acting on
> it, with centrifugal force rising to twice the anomalous force
> before the falling mass can be halted and sent back out again.
>
> You will notice that I've treated the "previous orbital speed"
> as if it was tangential to the gravity source, but that is of
> virtually no consequence.
Sorry Max, it is critical. Nobody will treat your results
as anything other than worthless until you correct that
and the other errors.
> This program justifies the method I'm now using to include the
> anisotropy in your program.
The problem is that you have always expected a
particular outcome and you are writing the code
to meet your expectations. I had a rough idea what
would happen but I have always been prepared to
be surprised by what the maths produced. The
speed with which the eccentricity decays is such
a surprise, I thought it would take longer, but the
maths has shown me that it would be quite rapid.
> I've added comments within the program. Feel free to reply to
> them.
I'll skip it until you remove the use of Pythagoras,
deal with the x and y components separately and
account for the varying orbital speed.
<snip code
> >>> Dark matter is non-baryonic so new physics would not
> >>> be surprising, it is an exciting prospect indeed. The best
> >>> handle we have so far seems to be the Bullet Cluster
> >>> where the two clumps of dark matter associatated with
> >>> the galaxies have passed through each other.
> >>
> >> And the latest evidence doesn't comply with that.
>
> > Cite the paper please.
>
> http://www.eurekalert.org/pub_releases/2007-08/cxc-dmm081607.php
> seems to indicate that the Abell 520 system "train wreck" is not
> as previously noted, as in the Bullet Cluster where the "dark
> matter" and galaxies have stayed together.
You have misunderstood the problem what I said
remains true but the galaxies have been displaced
as well as the gas so there is an additional mystery.
Dark Matter is called 'dark' not just because it doesn't
interact with EM but slightly tongue in cheek because
we are 'in the dark' about its true nature.
> > Dark matter just means something that has mass but
> > doesn't interact with light, it is a 'catch all'
> > generic term and deliberately vague.
>
> >> Why not something that nature predicts, like a black
> >> hole(s)?
>
> > Because microlensing surveys should detect them.
> > The find some events but not enough.
>
> How do you differentiate between dark matter and black holes?
Black holes have a mass greater than the Sun in a very
small volume while a background of basic particles is
thin and spread out. The dark matter spread round a
galaxy will magnify background objects and the effect
will stay the same for centuries, black holes passing
in front of a more distant star produce lensing events
that may only last a few minutes and then be gone.
George
Max Keon
> Max Keon wrote:
>> George Dishman wrote:
>>> I am applying as your equation dictates - I have
>>> no choice.
>>
>> You profess to know all about the consequences of a gravity
>> anisotropy when you obviously can't.
> I have no such need, _you_ have provided the equation
> that supposedly describes the anisotropy, all _I_ need
> to know is how to integrate that. It is simple maths that
> I learnt in secondary school about forty years ago.
That's where the problem apparently lies George. You are trying
to apply a very simple logic that was never intended to describe
the consequences of a gravity anisotropy. The anisotropic
acceleration cannot be simply added to the Newtonian component
of an elliptical orbit, as you have done. It doesn't work.
>> You have never had reason
>> to address such a thing in the past, and the course you've chosen
>> is the one that gives the best result for your purpose. But your
>> method of applying the anisotropic acceleration is totally wrong.
> I'm sorry Max, there is only one method permitted
> by the definition of acceleration. If you don't like the
> results, the only thing you can do is change the
> equation you have given me.
>> You are adding it to the naturally flowing acceleration in a
>> naturally occurring eccentric orbit. Which is of course nothing
>> more than a circular orbit that has been knocked off center.
>>
>> Can you not see that?
> Your statement is factually untrue, the minor axis
> of an ellipse is smaller than the major axis.
What are you trying to say? Are you suggesting that a circular
orbit that has been deflected off course won't fall into a
natural eccentric orbit, and have a minor axis that's smaller
than the major axis? Or what?
>> One thing that you have never given a satisfactory explanation
>> for is why Mercury's fall to its previous perihelion radius is
>> prematurely halted as a consequence of a gravity anisotropy.
>> Perhaps if you try demonstrating that mathematically, it will
>> help you to understand why you are wrong.
> I have told you over and over again why that happens,
> and we discussed it in detail two months ago, see
> message number 29 in this thread on Google.
This is how you explained it.
_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.
You have described the difference between a circular and an
elliptical orbit. I've been trying to tell you all along that
they are identical, that an eccentric orbit is only a circular
orbit that has been deflected off course.
I've also been trying to tell you all along that your program
is only capable of doing what it was designed to do, and that is
of course to plot a natural orbit path, whether it be circular
or elliptical. Adding the anisotropy directly to Newtonian
gravity certainly causes the perihelion radius to increase and
the aphelion radius to reduce, but the only reason for that is
that your program sets the perihelion and aphelion at the points
where the y axis crosses zero. There can never be a perihelion
advance using your method.
Mercury has been drawn more slowly than normal to the Sun on the
fall to perihelion and will be at a greater radius from the Sun
when the y axis crosses through zero. But gravity conditions have
now returned to normal and Mercury is now drawn to the Sun as
normal, so it's orbital speed is now too slow to halt the inward
fall. _It is not going to stop there and turn around._
Include the anisotropy correctly and your program is fine.
http://members.optusnet.com.au/maxkeon/proven2.html
>> You will come to
>> realize that Mercury's orbital speed cannot be fast enough to
>> generate the required centrifugal force to prematurely halt its
>> fall and whiz it back out toward the aphelion because the
>> anisotropy has caused it to be drawn more slowly to the Sun
>> throughout the inward journey, so by the time Mercury reaches
>> the point of last perihelion, it has obviously fallen less
>> distance than normal and is traveling at a lesser speed than
>> normal. So how on earth does it turn around and go back out
>> again.
>>
>> You will open up a whole new universe for me if you can prove
>> that it does, where nothing is impossible, or predictable.
> It is fully predicaable Max, just integrate the acceleration
> as the maths requires. It may well open up a whole new
> universe for you if you learn calculus and vectors.
A gravity anisotropy is yet another inconvenient truth that you
are just going to have to get used to.
---
>> The Newtonian acceleration is no doubt pointing directly at the
>> Sun throughout the entire orbit, but directly adding the
>> anisotropy in the way you have done is still wrong.
> The Newtonian acceleration points at the Sun, we
> both know that. I have asked you many times what
> the direction of the anisotropy is and yo never gave
> a clear answer but my understanding is that it also
> points along the line betwen the un and the planet
> but towards the Sun on the outward leg and away
> from it on the inward leg. Please either confirm that
> or correct it.
The pull of gravity is reduced for motion toward a gravity
source, and is increased for outward motion. It can't get much
clearer than that.
---
>>> This is just another example of your problems with
>>> simple maths. You are again taking the root of a
>>> square
>>>
>>> # = (ana^2 * dt)^.5
>>>
>>> is the same as
>>>
>>> # = ana * sqrt(dt)
>>
>> (ana^2 * dt)^.5 is only part of the equation. The proper
>> equation is derived from a^2 + b^2 = c^2. It becomes
>> s = (v^2 + ana^2)^.5 if dt is removed (s is the updated orbital
>> speed).
> That's quite different, but v is a speed while ana is an
> acceleration so you cannot add them.
That is ridiculous. If the distance added in 1 second of
acceleration is 1 meter, then the distance is 1 meter. What do
you think it would be. The acceleration rate at the Earth's
surface adds an additional 9.8 meter fall in ever second. That's
a very specific quantity you know. How can that be a problem to
you?
> You could correct
> that error using
>
> s = (v^2 + (ana*dt)^2)^.5
The real test of dt is to run the program with different dt
values and note the results. If they are not all the same as when
dt = 1 then it's wrongly applied. Your modification does not
work. My method does work by the way.
> but as I said before, v and (ana*dt) are not perpendicular
> so you cannot use Pythagoras. Instead you might try
> breaking v into x and y components and likewise (ana*dt)
> keeping both signed. Then add the components
>
> s_x = v_x + dt * ana_x
> s_y = v_y + dt * ana_y
>
> then you could write:
>
> s = sqrt(s_x^2 + s_y^2)
>
> but you don't need that since you already have the x and y
> components that you use for the change of location.
I don't need to do any of that because it's all wrong.
>>> But why are you calculating that in the first place?
>>
>> I'm trying to determine the orbital speed changes according to
>> the path taken when the anisotropy is included as compared with
>> the unaffected path. I've used Pythagoras to do that.
> OK, see above for how to do that properly, Pythagoras
> does not apply since v and ana are not perpendicular.
>> Previous orbital speed
>> ______________________
>> - _ l Anomalous
>> New orbital speed - l acceleration
>>
>>
>> I don't need you to tell me that I'm wrong either, only that
>> it's not the way you would do it. But we already know that.
> You have to follow the rules of maths, Pythagoras only
> applies when the adjacent and opposite are perfectly
> perpendicular.
If I choose to use Pythagoras I automatically define those
conditions whether they be true or not. Since the degree of error
was of little consequence in demonstrating my point in the case
of the circular orbit described in my previous post, I have done
no wrong at all. I'm certainly not breaking any laws of
mathematics by tolerating an acceptable error.
-----
Max Keon
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:1188287226.3...@r34g2000hsd.googlegroups.com...
>> Max Keon wrote:
>>> George Dishman wrote:
>
>>>> I am applying as your equation dictates - I have
>>>> no choice.
>>>
>>> You profess to know all about the consequences of a gravity
>>> anisotropy when you obviously can't.
>
>> I have no such need, _you_ have provided the equation
>> that supposedly describes the anisotropy, all _I_ need
>> to know is how to integrate that. It is simple maths that
>> I learnt in secondary school about forty years ago.
>
> That's where the problem apparently lies George. You are trying
> to apply a very simple logic that was never intended to describe
> the consequences of a gravity anisotropy.
Maths is universal whatever it is used to describe.
> The anisotropic
> acceleration cannot be simply added to the Newtonian component
> of an elliptical orbit, as you have done. It doesn't work.
In that case you equation is invalid because what you
have given me is nothing more than a way to calculate
the amount of acceleration that I have to add to the
Newtonian acceleration.
>>> You have never had reason
>>> to address such a thing in the past, and the course you've chosen
>>> is the one that gives the best result for your purpose. But your
>>> method of applying the anisotropic acceleration is totally wrong.
>
>> I'm sorry Max, there is only one method permitted
>> by the definition of acceleration. If you don't like the
>> results, the only thing you can do is change the
>> equation you have given me.
>
>>> You are adding it to the naturally flowing acceleration in a
>>> naturally occurring eccentric orbit. Which is of course nothing
>>> more than a circular orbit that has been knocked off center.
>>>
>>> Can you not see that?
>
>> Your statement is factually untrue, the minor axis
>> of an ellipse is smaller than the major axis.
>
> What are you trying to say? Are you suggesting that a circular
> orbit that has been deflected off course won't fall into a
> natural eccentric orbit, and have a minor axis that's smaller
> than the major axis? Or what?
To put it in crude terms, I am saying that an ellipse is
longer than it is wide, a statement that is not true of
an off-centre circle. Look at the red path here:
http://en.wikipedia.org/wiki/Image:Sommerfeld_ellipses.svg
It is obviously not a circle.
>>> One thing that you have never given a satisfactory explanation
>>> for is why Mercury's fall to its previous perihelion radius is
>>> prematurely halted as a consequence of a gravity anisotropy.
>>> Perhaps if you try demonstrating that mathematically, it will
>>> help you to understand why you are wrong.
>
>> I have told you over and over again why that happens,
>> and we discussed it in detail two months ago, see
>> message number 29 in this thread on Google.
>
> This is how you explained it.
> _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.
Yes, so far that is OK.
> You have described the difference between a circular and an
> elliptical orbit. I've been trying to tell you all along that
> they are identical, that an eccentric orbit is only a circular
> orbit that has been deflected off course.
That is NOT true, think of a cometary orbit and it
is obvious that an ellipse can be long and narrow
such as the red path in the earlier diagram.
> I've also been trying to tell you all along that your program
> is only capable of doing what it was designed to do, and that is
> of course to plot a natural orbit path, whether it be circular
> or elliptical.
Again that is not true, it integrates the acceleration
and will plot any possible path, it is not restricted
to orbits at all.
> Adding the anisotropy directly to Newtonian
> gravity certainly causes the perihelion radius to increase and
> the aphelion radius to reduce, but the only reason for that is
> that your program sets the perihelion and aphelion at the points
> where the y axis crosses zero. There can never be a perihelion
> advance using your method.
Untrue again, the program determines the perihelion
when the radius stops decreasing and starts to increase
and vice versa for aphelion. It inserts a short cross
line at both points and you can see they are advanced.
> Mercury has been drawn more slowly than normal to the Sun on the
> fall to perihelion and will be at a greater radius from the Sun
> when the y axis crosses through zero. But gravity conditions have
> now returned to normal and Mercury is now drawn to the Sun as
> normal, so it's orbital speed is now too slow to halt the inward
> fall. _It is not going to stop there and turn around._
>
> Include the anisotropy correctly and your program is fine.
> http://members.optusnet.com.au/maxkeon/proven2.html
The anisotropy is included as your equation demands. Change
your equation and I will change the program to match.
>>> You will come to
>>> realize that Mercury's orbital speed cannot be fast enough to
>>> generate the required centrifugal force to prematurely halt its
>>> fall and whiz it back out toward the aphelion because the
>>> anisotropy has caused it to be drawn more slowly to the Sun
>>> throughout the inward journey, so by the time Mercury reaches
>>> the point of last perihelion, it has obviously fallen less
>>> distance than normal and is traveling at a lesser speed than
>>> normal. So how on earth does it turn around and go back out
>>> again.
>>>
>>> You will open up a whole new universe for me if you can prove
>>> that it does, where nothing is impossible, or predictable.
>
>> It is fully predicaable Max, just integrate the acceleration
>> as the maths requires. It may well open up a whole new
>> universe for you if you learn calculus and vectors.
>
> A gravity anisotropy is yet another inconvenient truth that you
> are just going to have to get used to.
Not at the level of your equation. There ARE effects
similar to what you describe in GR which matches what
really happens but your equation gives an effect that
is far too large.
>>> The Newtonian acceleration is no doubt pointing directly at the
>>> Sun throughout the entire orbit, but directly adding the
>>> anisotropy in the way you have done is still wrong.
>
>> The Newtonian acceleration points at the Sun, we
>> both know that. I have asked you many times what
>> the direction of the anisotropy is and yo never gave
>> a clear answer but my understanding is that it also
>> points along the line betwen the un and the planet
>> but towards the Sun on the outward leg and away
>> from it on the inward leg. Please either confirm that
>> or correct it.
>
> The pull of gravity is reduced for motion toward a gravity
> source, and is increased for outward motion. It can't get much
> clearer than that.
OK, that's what I have been working on. Now stop
your program at the 1/4 and 3/4 orbit points and
test if it does that. I think you'll find it doesn't.
>>>> This is just another example of your problems with
>>>> simple maths. You are again taking the root of a
>>>> square
>>>>
>>>> # = (ana^2 * dt)^.5
>>>>
>>>> is the same as
>>>>
>>>> # = ana * sqrt(dt)
>>>
>>> (ana^2 * dt)^.5 is only part of the equation. The proper
>>> equation is derived from a^2 + b^2 = c^2. It becomes
>>> s = (v^2 + ana^2)^.5 if dt is removed (s is the updated orbital
>>> speed).
>
>> That's quite different, but v is a speed while ana is an
>> acceleration so you cannot add them.
>
> That is ridiculous. If the distance added in 1 second of
> acceleration is 1 meter, then the distance is 1 meter. What do
> you think it would be. The acceleration rate at the Earth's
> surface adds an additional 9.8 meter fall in ever second.
Wrong, the acceleration adds 9.8 m/s to the speed in
every second, so in 2 seconds it adds 19.6m/s and
in dt seconds it adds (9.8 * dt) m/s to the speed.
> That's
> a very specific quantity you know. How can that be a problem to
> you?
You got it wrong again. If it was always in the same
direction (which ist isn't) it would add 4.9 m to
the distance in the first second, 14.7 m to the distance
in the next second and so on.
>> You could correct
>> that error using
>>
>> s = (v^2 + (ana*dt)^2)^.5
>
> The real test of dt is to run the program with different dt
> values and note the results. If they are not all the same as when
> dt = 1 then it's wrongly applied. Your modification does not
> work. My method does work by the way.
Sorry, yours is clearly wrong.
>> but as I said before, v and (ana*dt) are not perpendicular
>> so you cannot use Pythagoras. Instead you might try
>> breaking v into x and y components and likewise (ana*dt)
>> keeping both signed. Then add the components
>>
>> s_x = v_x + dt * ana_x
>> s_y = v_y + dt * ana_y
>>
>> then you could write:
>>
>> s = sqrt(s_x^2 + s_y^2)
>>
>> but you don't need that since you already have the x and y
>> components that you use for the change of location.
>
> I don't need to do any of that because it's all wrong.
Get a textbook Max, learn some schoolboy maths.
>>>> But why are you calculating that in the first place?
>>>
>>> I'm trying to determine the orbital speed changes according to
>>> the path taken when the anisotropy is included as compared with
>>> the unaffected path. I've used Pythagoras to do that.
>
>> OK, see above for how to do that properly, Pythagoras
>> does not apply since v and ana are not perpendicular.
>
>>> Previous orbital speed
>>> ______________________
>>> - _ l Anomalous
>>> New orbital speed - l acceleration
>>>
>>>
>>> I don't need you to tell me that I'm wrong either, only that
>>> it's not the way you would do it. But we already know that.
>
>> You have to follow the rules of maths, Pythagoras only
>> applies when the adjacent and opposite are perfectly
>> perpendicular.
>
> If I choose to use Pythagoras I automatically define those
> conditions whether they be true or not.
You automatically _assume_ those conditions and
since they do NOT apply, your result is wrong.
> Since the degree of error
> was of little consequence in demonstrating my point in the case
> of the circular orbit described in my previous post, I have done
> no wrong at all. I'm certainly not breaking any laws of
> mathematics by tolerating an acceptable error.
Learn some basic maths Max, there are plenty of
K12 resources on the web that will teach you how
to do this. I've shown you how to do it correctly,
the rest is up to you.
George
Max Keon
> Max Keon wrote:
>> George Dishman wrote:
>>> Max Keon wrote:
>>>> George Dishman wrote:
>> I've also been trying to tell you all along that your program
>> is only capable of doing what it was designed to do, and that is
>> of course to plot a natural orbit path, whether it be circular
>> or elliptical.
> Again that is not true, it integrates the acceleration
> and will plot any possible path, it is not restricted
> to orbits at all.
It's certainly not restricted to orbits because it doesn't work
in that application.
This is obvious.
If a constant force is suddenly applied perpendicular to a mass
traveling a straight line path, the mass will immediately shift
course to follow a constant curve that will eventually form a
complete circle. If the force is suddenly removed, the mass will
immediately take off along a straight line trajectory again.
However, if a force is suddenly applied to a mass in a circular
orbit around i.e. the Sun, the mass will initially be directed
to follow a tighter radius trajectory that would also eventually
form a smaller complete circle. But the accelerating force
increases as the mass is drawn inward, thus increasing orbital
speed, and since centrifugal force increases at a squaring rate
per velocity increase, the fall will be rapidly halted.
Centripetal force is initially increased by the added force, and
that rises at a linear rate as the fall progresses, but
centrifugal forces quickly rise to counter the fall.
The fall is halted and the mass is turned back outward when
centrifugal force has increased to twice the initial force
increase, as is demonstrated in the first program listed at the
link provided later in the post. Study it properly because that
scenario applies for every orbiting mass in the universe.
I've added this introduction to the web page as well.
-------------
The trajectory of a circular orbit is a naturally flowing
transition between the two dimensions of its orbit plane. The
orbit trajectory of an eccentric orbit is also a naturally
flowing transition between those two dimensions. All sustainable
orbits are therefore exactly the same.
An anomalous gravity change cannot be treated as part of that
natural transition. It has nothing to do with it. Any change to
that totally balanced system is equivalent to a force acting to
shift an object from a position where zero forces are being
applied. Any anomalous force is going to be subject to the rules
that apply if the orbiting mass is stationary. THE ANOMALOUS
FORCE CANNOT BE ADDED DIRECTLY TO THE EXISTING FORCES.
-------------
>> Adding the anisotropy directly to Newtonian
>> gravity certainly causes the perihelion radius to increase and
>> the aphelion radius to reduce, but the only reason for that is
>> that your program sets the perihelion and aphelion at the points
>> where the y axis crosses zero. There can never be a perihelion
>> advance using your method.
> Untrue again, the program determines the perihelion
> when the radius stops decreasing and starts to increase
> and vice versa for aphelion. It inserts a short cross
> line at both points and you can see they are advanced.
I can see that the orbit eccentricity decays, but I don't see
any perihelion advance.
These sets of figures were generated in accordance with the rules
of your program for the initial fall to perihelion, with the
anisotropy added directly to Newtonian gravity, as you require.
Notice that Mercury's position on the y axis has shifted by
around 41 million meters, which according to the orbit rotation
is in the retarded direction, and that occurs with or without
the anisotropy. So the basic cause is only software.
Excluding anisotropy.
41025996.52243679 current position on the y axis.
45961145477.91186 radius.
3797180.400002688 1 seconds steps.
59017.39331765785 orbital speed.
Including anisotropy.
41030998.40955561 current position on the y axis.
45963158216.10093 radius.
3797291.400001362 1 second steps.
59014.80893124959 orbital speed.
Mercury has shifted from the normal by 5002 meters on the y axis
at turnaround, which is less than the .1 seconds increments
within which the perihelion position was being detected. So the
turnaround point is much the same with or without the anisotropy.
It's actually not in the direction of advance either, it's
further retarded, in this case.
---
>>> You could correct
>>> that error using
>>>
>>> s = (v^2 + (ana*dt)^2)^.5
>>
>> The real test of dt is to run the program with different dt
>> values and note the results. If they are not all the same as when
>> dt = 1 then it's wrongly applied. Your modification does not
>> work. My method does work by the way.
> Sorry, yours is clearly wrong.
Apart from the relatively inconsequential orbital speed error,
which I later address, the first of the "wrongs" was in the
program line "radius = radius + anb". That should read
"radius = radius + ana". I was adding the total compounding
change to the radius in each second. ana holds the updated
current fall distance for the current second, and that's what
should have been added to the radius.
"Wrong 2" was in this equation "cf = vz^2# / vv^2# * newton",
which now reads "cf = vz^2# / vv^2# * newt". "newt" now
represents the Newtonian gravity value applicable to a compare
orbital speed "vv" which was established as the speed required
to balance the centripetal and centrifugal forces for the initial
orbit radius from the Sun for a circular orbit at that radius.
"vv = (G * M / x) ^ .5" and then "vz = vv" . vz becomes the
variable. That combination gives the correct balance for all
orbital speed per radius scenarios.
The consequences of the anisotropy are now barely noticeable.
http://members.optusnet.com.au/maxkeon/proven2.html
But dt is functioning perfectly, isn't it.
---
>>>>> But why are you calculating that in the first place?
>>>>
>>>> I'm trying to determine the orbital speed changes according to
>>>> the path taken when the anisotropy is included as compared with
>>>> the unaffected path. I've used Pythagoras to do that.
>>>
>>> OK, see above for how to do that properly, Pythagoras
>>> does not apply since v and ana are not perpendicular.
>>>
>>>> Previous orbital speed
>>>> ______________________
>>>> - _ l Anomalous
>>>> New orbital speed - l acceleration
>>>>
>>>>
>>>> I don't need you to tell me that I'm wrong either, only that
>>>> it's not the way you would do it. But we already know that.
>>>
>>> You have to follow the rules of maths, Pythagoras only
>>> applies when the adjacent and opposite are perfectly
>>> perpendicular.
>>
>> If I choose to use Pythagoras I automatically define those
>> conditions whether they be true or not.
> You automatically _assume_ those conditions and
> since they do NOT apply, your result is wrong.
The dotted line in the first diagram is tangential to a force
applied from the bottom of the page, and it's assumed to be the
same length as the first of the tilted lines. The added fall
distance during 1 second of acceleration is 1 meter.
sqr(48000^2 + 1^2) = 48000.00001042 is the hypotenuse length of
the triangle. The orbital speed increase during that second is
48000.00001042 - 48000 = .00001042 m/sec.
-. . . _ . . . . 48000 m/sec . . . . . . . .
- _ - _
- _ - l ----
- _ l 1 meter
-l ____
The correct way to address the problem is of course to first
establish a true length for the tangential leg.
If the tilt angle of the orbit trajectory is 10 degrees and the
orbital speed is 48000 m/sec, sin10 * 48000 = 8335 meters for
the opposite leg. So the triangle so far is, hypotenuse = 48000
and opposite = 8335.
sqr(48000^2 - 8335^2) = 47270.79 meters is then the true
tangential speed for the triangle adjacent.
Now that wasn't so hard was it.
The orbital speed increase is now according to this diagram.
47270.79 m/sec
(b)---_----------------------------------l
- _ l 1 m/sec
- _ l
47270.790010577 m/sec
47270.790010577 - 47270.79 = .000010577 meter orbital speed
increase.
Comparing that with the previous result of .00001042 meter
increase, .000010577 - .00001042 = 0.000000157 meter error.
I can't see that being a problem just yet. My point can be
demonstrated without further cluttering the program by adding
the extra step.
It's really no problem to add it though.
-----
Max Keon
George Dishman
I was going to redo my code to interpolate between
steps for the perihelion advance but it will take
some effort and it is pointless if you don't accept
the path is valid anyway so I'll just correct this:
> I've added this introduction to the web page as well.
...
> THE ANOMALOUS
> FORCE CANNOT BE ADDED DIRECTLY TO THE EXISTING FORCES.
If an object moves 3m and then another 5m in the
same direction, it has moved 8m in that direction.
We call that displacement. Displacements add.
Velocity is the rate at which displacement happens,
it is just the displacement divided by the time
taken so velocities add.
Acceleration is the rate at which velocity changes,
it is just the change of velocity divided by the
time taken so accelerations add.
Displacement, velocity and acceleration are all
vectors
http://www.physchem.co.za/Vectors/Addition.htm
The method used in my code uses x and y components:
http://www.physchem.co.za/Vectors/Addition.htm#Rectangular
Learn the basics Max, this is trivial schoolboy maths.
George
Max Keon
> "Max Keon" <max...@optusnet.com.au> wrote in message
> news:46f32fd8$0$844$afc3...@news.optusnet.com.au...
> I was going to redo my code to interpolate between
> steps for the perihelion advance but it will take
> some effort and it is pointless if you don't accept
> the path is valid anyway
Your program plots the coordinates of a natural eccentric orbit
with great precision, but that's where it ends. It cannot
accommodate a gravity anisotropy the way you are trying to do
it.
The graphs shown on this web page
http://members.optusnet.com.au/maxkeon/proven2.html
were generated using the wrong initial orbital speed, which
didn't matter at the time, but now it does. I've updated the web
page for the correct initial speed. Nothing has really changed
much though.
This program requires the correct orbital speed to demonstrate
my point. It does exactly as is stated below.
'-----------------
' The program is designed to demonstrate that orbital speed can
' also be determined using Pythagoras. It provides an extremely
' fluid method of depicting how a mass in orbit would behave when
' it has been deflected off course by any minor collision. That's
' where part (2) of this program fails to deliver.
' The oscillations that are generated about the mean path have
' been initiated at the start and they continue to resonate
' throughout the orbit, oscillating back and forth within the
' confines of the centripital-centrifugal force imbalance, in
' the same manner as demonstrated on the web page linked below,
' and depending on where the trajectory may be pointing at
' aphelion and perihelion turnaround the oscillation distance
' can be increased or reduced. That's the realm of the gravity
' anisotropy and it can't be treated as part of the natural flow
' of an eccentric orbit.
DEFDBL A-Z
SCREEN 12: COLOR 7
CLS
GOSUB ab
c = 299792458#
G = .0000000000667#
M = 1.99D+30
multi = .000000002#
' Multiplier for the graphics.
x = 69820000000#: vy = 38850#
' Aphelion start.
yx = 57890570000#
vv = vy
' Corrected initial orbital speed.
newt = G * M / x ^ 2
' Centrifugal force is established for
' all cases from this result.
vz = vv
lastradius = x
rad = 45961140000#
dt = 200
lasty = 41073216#
' This is roughly the initial negative advance that's generated
' as a consequence of the aphelion start. And that occurs with
' or without the anisotropy.
aa: ' -------- Part (1) ----------------------------------
' This section is as described in program (1) at
' http://members.optusnet.com.au/maxkeon/proven2.html
' Something that has become very obvious is that radial velocity
' has nothing whatever to do with generating centrifugal force.
' It's the tangential speed alone that generates the force, even
' though the force varies according to radius. The point is, a
' radius change most certainly cannot generate centrifugal force.
' Pythagoras is therefore a valid tool for determining orbital
' speed change caused by a fall or rise from a gravity source.
' The tangent leg of the triangle is always at 90 degrees to the
' force direction, or opposite leg of the triangle. The
' hypotenuse carries the orbital speed change. The true orbital
' speed is derived from that result.
ana = ana + dt * cfx
' ana stores the current fall distance.
anb = anb + ana
' anb stores the total fall distance.
IF anc >= anb THEN s = (vz ^ 2# - ((ana) ^ 2 * dt)) ^ .5#
IF anc < anb THEN s = (vz ^ 2# + (ana ^ 2 * dt)) ^ .5#
anc = anb
' anc determines which of the two equations is active.
vz = s
' vz carries the current tangential speed.
vzvr = SQR(vz ^ 2 + vr ^ 2)
' vzvr is the true orbital speed.
' vr is extracted from part (2) of the program which plots the
' natural transition of the orbiting body between the two planes
' of its orbit. That has nothing to do with anomalous changes.
LOCATE 8, 45: PRINT INT(vzvr)
' Orbital speed for part (1).
CIRCLE (10 + inc, -180 + vzvr / 100), 0, 9
cf = vz ^ 2# / vv ^ 2# * newt
' (Current speed^2 / original speed^2) gives the centrifugal
' force change ratio. Multiplied by the original centrifugal
' force gives the actual force.
cfx = newton + anisotropy - cf
' cfx holds the true fall rate, which is the difference
' between centripetal and centrifugal forces.
'---------------------------------------------------
' Part (2) -----------------
ryx = x * x + y * y
radius = SQR(ryx)
' radius = radius + ana
' The anisotropy is excluded so that, apart from calculating
' radial velocity, there is no link whatever between the two
' methods for determining orbital speed.
vr = (radius - lastradius) / dt
lastradius = radius
newton = G * M / ryx
anisotropy = vr / c * -newton
acceleration = -newton
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
vx = vx + dt * ax
vy = vy + dt * ay
x = x + dt * vx
y = y + dt * vy
v = (vx ^ 2# + vy ^ 2#) ^ .5#
' Orbital speed for part (2).
LOCATE 9, 45: PRINT INT(v)
CIRCLE (10 + inc, -180 + v / 100), 0, 12
inc = inc + .015
ft = ft + 1
IF ft * dt > 7603200 THEN GOSUB ab
GOTO aa
ab:
IF cycles = 5 THEN END
inc = 0: ft = 0: CLS
COLOR 9: LOCATE 8, 17: PRINT "Orbital speed per Pythagoras"
COLOR 12: LOCATE 9, 19: PRINT "Orbital speed per Part (2)"
COLOR 7
LOCATE 13, 18: PRINT "Aphelion"
LOCATE 27, 18: PRINT "Perihelion"
cycles = cycles + 1
LOCATE 21, 8: PRINT "cycle"; cycles
RETURN
'-----------------
> so I'll just correct this:
>> I've added this introduction to the web page as well.
> ...
>> THE ANOMALOUS
>> FORCE CANNOT BE ADDED DIRECTLY TO THE EXISTING FORCES.
> If an object moves 3m and then another 5m in the
> same direction, it has moved 8m in that direction.
> We call that displacement. Displacements add.
>
> Velocity is the rate at which displacement happens,
> it is just the displacement divided by the time
> taken so velocities add.
>
> Acceleration is the rate at which velocity changes,
> it is just the change of velocity divided by the
> time taken so accelerations add.
>
> Displacement, velocity and acceleration are all
> vectors
>
> http://www.physchem.co.za/Vectors/Addition.htm
>
> The method used in my code uses x and y components:
>
> http://www.physchem.co.za/Vectors/Addition.htm#Rectangular
>
> Learn the basics Max, this is trivial schoolboy maths.
Even if the anisotropy is inelastic the orbit eccentricity will
only decay by around 41 meters per cycle. And it only requires
less than .1 meters of that amount to be elastic to explain
Mercury's perihelion advance.
Even if I wasn't aware of the basics, my errors would be trivial,
while yours are absolutely enormous.
George, get used to the idea that I will only ever be proven
wrong if I have misinterpreted the consequences of the zero
origin universe. To the best of my knowledge, I base my
arguments on the truth as defined by the zero origin concept
http://members.optusnet.com.au/maxkeon/the1-1a.html
That universe is akin to an infinitely faceted Rubix "Cube",
where the very first twist sets the ball rolling, and the more
you twist it the worse it gets. It can never be put back the
way it was.
-----
Max Keon
George Dishman
>
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:PuydnSGQdN26Epra...@pipex.net...
>> "Max Keon" <max...@optusnet.com.au> wrote in message
>> news:46f32fd8$0$844$afc3...@news.optusnet.com.au...
>
>> I was going to redo my code to interpolate between
>> steps for the perihelion advance but it will take
>> some effort and it is pointless if you don't accept
>> the path is valid anyway
>
> Your program plots the coordinates of a natural eccentric orbit
> with great precision, but that's where it ends. It cannot
> accommodate a gravity anisotropy the way you are trying to do
> it.
You have provided me with an equation for the extra
acceleration which is to be added to take account of
the anisotropy. Acceleration is a vector and I have
added it in the correct manner for adding vectors, so
what I have done is the _only_ valid method that can
make use of what you have provided.
...
>>> I've added this introduction to the web page as well.
>> ...
>>> THE ANOMALOUS
>>> FORCE CANNOT BE ADDED DIRECTLY TO THE EXISTING FORCES.
...
>> Displacement, velocity and acceleration are all
>> vectors
>>
>> http://www.physchem.co.za/Vectors/Addition.htm
>>
>> The method used in my code uses x and y components:
>>
>> http://www.physchem.co.za/Vectors/Addition.htm#Rectangular
>>
>> Learn the basics Max, this is trivial schoolboy maths.
>
> Even if the anisotropy is inelastic the orbit eccentricity will
> only decay by around 41 meters per cycle. ...
Sorry Max, it is thousands of km per orbit at the
start, my code gives you the correct numbers, your
calculations are flawed.
> Even if I wasn't aware of the basics, my errors would be trivial,
You are not aware of basics and as a result you have
written code that gives you what you expected but not
what the anisotropy would actually produce.
> while yours are absolutely enormous.
There are no errors in my method, and I have shown
you the errors that result from the numerical
integrations, you simply need to learn schoolboy
maths. Study the two web site links above and start
again once you have mastered their content, or read
through my code and study how I have done it and
compare that with the reference pages. When you
understand what a vector is, you will find that my
code is correct. I'm not going to waste any more
time teaching you stuff you should have learned as
a teenager Max, it is time for you to do some work
for yourself.
George
Max Keon
> Max Keon wrote:
>> George Dishman wrote:
>>>
>>> steps for the perihelion advance but it will take
>>> some effort and it is pointless if you don't accept
>>> the path is valid anyway
>>
>> Your program plots the coordinates of a natural eccentric orbit
>> with great precision, but that's where it ends. It cannot
>> accommodate a gravity anisotropy the way you are trying to do
>> it.
> You have provided me with an equation for the extra
> acceleration which is to be added to take account of
> the anisotropy. Acceleration is a vector and I have
> added it in the correct manner for adding vectors, so
> what I have done is the _only_ valid method that can
> make use of what you have provided.
You are still missing the point completely here George.
A circular orbit is equivalent to a straight line through the
two dimensions in the plane of the orbit. Likewise is a stable
eccentric orbit. It's the line where all forces are in balance.
In the diagram, a force is applied for the duration of 1 second
and it deflects "@" to travel a different straight line
trajectory, where it will continue to point if no other forces
are applied.
(1) on off
\/ ^
@-------------> _1 sec
- _
- _
A force is now applied to @'s trajectory when it's traveling a
circular or elliptical orbit path.
(2) on off
\/
@-------------> _ ^
---------------
Do you now see the difference?
Your program does not account for the centripetal-centrifugal
force imbalance. It assumes that the trajectory is affected by
the anisotropy as in diagram (1).
---
>> Even if the anisotropy is inelastic the orbit eccentricity will
>> only decay by around 41 meters per cycle. ...
> Sorry Max, it is thousands of km per orbit at the
> start, my code gives you the correct numbers, your
> calculations are flawed.
Try studying this page properly.
http://members.optusnet.com.au/maxkeon/proven2.html
Now that your mission has failed, perhaps you should put some
effort into understanding the zero origin universe, the universe
we actaully live in.
http://members.optusnet.com.au/maxkeon/the1-1a.html
-----
Max Keon
George Dishman
>
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:L_SdnW5c775q4JLa...@pipex.net...
>> Max Keon wrote:
>>> George Dishman wrote:
>>>>
>>>> I was going to redo my code to interpolate between
>>>> steps for the perihelion advance but it will take
>>>> some effort and it is pointless if you don't accept
>>>> the path is valid anyway
>>>
>>> Your program plots the coordinates of a natural eccentric orbit
>>> with great precision, but that's where it ends. It cannot
>>> accommodate a gravity anisotropy the way you are trying to do
>>> it.
>
>> You have provided me with an equation for the extra
>> acceleration which is to be added to take account of
>> the anisotropy. Acceleration is a vector and I have
>> added it in the correct manner for adding vectors, so
>> what I have done is the _only_ valid method that can
>> make use of what you have provided.
>
> You are still missing the point completely here George.
The point Max is that the maths I have explained to
you is the _only_ valid method for incorporating your
equation. You have told me the acceleration and I have
used it. If you don't like the answer, tell me a
different equation, one which _can_ be added in the
manner my program applies.
> A circular orbit is equivalent to a straight line through the
> two dimensions in the plane of the orbit. Likewise is a stable
> eccentric orbit. It's the line where all forces are in balance.
The forces are not balanced, the only force acting is
Newtonian gravity which is why the planet doesn't move
in a straight line but instead travels in a circle. If
you work in polar coordinates, there is a centrifugal
"pseudo-force" which appears to balance gravity and
keep the radius constant but we weren't using polar
coordinates.
> In the diagram, a force is applied for the duration of 1 second
> and it deflects "@" to travel a different straight line
> trajectory, where it will continue to point if no other forces
> are applied.
>
> (1) on off
> \/ ^
> @-------------> _1 sec
> - _
> - _
>
> A force is now applied to @'s trajectory when it's traveling a
> circular or elliptical orbit path.
>
> (2) on off
> \/
> @-------------> _ ^
> ---------------
>
> Do you now see the difference?
Yes, the first is correct, the second is wrong. You
have shown an instantaneous change of the velocity
when the force goes off which of course cannot happen.
What has happened in the first case is that the planet
has been pushed off its circular orbit. The segment
after the 1s application of the transverse force is
now part of an elliptical orbit. One orbit later the
planet will return on a course that arrives a little
above the left hand section, pass through the "off"
point and then retrace the part to the lower right.
If the force is exactly perpendicular to the motion
throughout the 1s, then the energy of the orbit
remains the same but the eccentricity has changed.
> Your program does not account for the centripetal-centrifugal
> force imbalance. It assumes that the trajectory is affected by
> the anisotropy as in diagram (1).
(1) is correct, your second diagram is wrong. In an
elliptical orbit the "force imbalance" you mention is
what causes the variation of the radius. In an
elliptical orbit, in polar coordinates, generally the
gravitational and centrifugal forces are _not_ balanced
whereas they are for a circular orbit.
The bottom line here Max is that the maths I use is
correct, it predicts the elliptical orbit correctly
when there is no anisotropy so you know that it is
correctly modelling the continually changing force
imbalance that creates the path, and incorporating
your extra acceleration is done in the correct manner
so the results are accurately what your speculation
would produce. The orbital eccentricity would decay
to near zero over a few thousand orbits and your idea
is unquestionably wrong.
If you decreased the value significantly, something
like using (v/c)^3 instead of (v/c), then you would
get close to the correct values but your equation as
it stands produces far too much effect.
George
Max Keon
> "Max Keon" <max...@optusnet.com.au> wrote in message
> news:47172249$0$6925$afc3...@news.optusnet.com.au...
>> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
>> news:L_SdnW5c775q4JLa...@pipex.net...
>>> Max Keon wrote:
>>>>
>>>> Your program plots the coordinates of a natural eccentric orbit
>>>> with great precision, but that's where it ends. It cannot
>>>> accommodate a gravity anisotropy the way you are trying to do
>>>> it.
>>>
>>> You have provided me with an equation for the extra
>>> acceleration which is to be added to take account of
>>> the anisotropy. Acceleration is a vector and I have
>>> added it in the correct manner for adding vectors, so
>>> what I have done is the _only_ valid method that can
>>> make use of what you have provided.
>>
>> You are still missing the point completely here George.
> The point Max is that the maths I have explained to
> you is the _only_ valid method for incorporating your
> equation. You have told me the acceleration and I have
> used it. If you don't like the answer, tell me a
> different equation, one which _can_ be added in the
> manner my program applies.
Put your books away for a while and think about this, you are
still missing the point.
>> A circular orbit is equivalent to a straight line through the
>> two dimensions in the plane of the orbit. Likewise is a stable
>> eccentric orbit. It's the line where all forces are in balance.
> The forces are not balanced, the only force acting is
> Newtonian gravity which is why the planet doesn't move
> in a straight line but instead travels in a circle. If
> you work in polar coordinates, there is a centrifugal
> "pseudo-force" which appears to balance gravity and
> keep the radius constant but we weren't using polar
> coordinates.
You know as well as I do that the trajectory of a mass in an
eccentric orbit is determined by a balance between centripetal
force, centrifugal force (however you wish to define that) and
momentum. It's as though it were oscillating back and forth once
per orbit cycle in the middle of an invisible spring.
What would you expect it to do?
A straight line trajectory, a circular orbit, and an eccentric
orbit all follow a path where the forces are in balance. _All_
stable orbits are identical. In all cases, an anomalous force is
required to change the trajectory from what is a very precise
path for the circumstances. And an eccentric orbit trajectory is
as precise as a straight line trajectory.
This is how it works for an eccentric orbit.
'----------------------------------------
' Control/Break halts the program at any time.
' The program stops after 1 cycle.
DEFDBL A-Z
SCREEN 12: COLOR 7
CLS
LOCATE 1, 1: PRINT "Sustainable circular orbit speed"
LOCATE 2, 1: PRINT "Actual orbital speed"
LOCATE 4, 1: PRINT "Centripetal acceleration"
LOCATE 5, 1: PRINT "Centrifugal acceleration"
CIRCLE (250, 250), 4, 14 ' Sun.
c = 299792458#
G = .0000000000667#
M = 1.99D+30
multi = .000000002#
' Multiplier for the graphics.
colr = 3
' sets the initial graphics color.
LOCATE 12, 1
x = 69820000000#: vy = 38850#
' Aphelion start.
xx = 58000000000#
' Average orbit radius.
newt = G * M / x ^ 2
' Centripetal force at the start point.
os = (G * M / xx) ^ .5
' Orbital speed where centripetal and centrifugal
' forces are equal.
lastradius = x
dt = 200
aa:
ryx = x * x + y * y
radius = SQR(ryx)
vr = (radius - lastradius) / dt
lastradius = radius
newton = G * M / ryx
acceleration = -newton
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
vx = vx + dt * ax
vy = vy + dt * ay
x = x + dt * vx
y = y + dt * vy
v = (vx ^ 2# + vy ^ 2#) ^ .5#
' Orbital speed.
LOCATE 1, 33: PRINT SQR(radius * newton)
' Orbital speed for a sustainable circular orbit
' at the current radius.
LOCATE 2, 33: PRINT v
' Orbital speed.
LOCATE 4, 26: PRINT newton; " "
LOCATE 5, 26: PRINT v ^ 2 / os ^ 2 * newton; " "
' Centrifugal force is equal to centripetal force (newton) for a
' sustainable circular orbit at each radius along the way, and
' that is adjusted according to the orbital speed difference
' between the eccentric and circular orbits. It's all relative
' to the point where centripetal and centrifugal forces are
' equal for the two orbits (os).
CIRCLE (250 + x * multi, 250 - y * multi), 0, colr
ft = ft + dt
IF ft > 7603200 THEN END
GOTO aa
'---------------------------------------
If the pull of gravity is permanently altered, a new perfectly
balanced orbit will form. But when an anomalous force that
changes sign at aphelion and perihelion is added, the orbit is
completely out of whack. The smoothly flowing changes have been
disrupted.
Your program gives a one way trajectory change for the entire
journey from aphelion to perihelion, which is wrong. Up to the
midway point on the fall from aphelion to perihelion the
(now negative) anisotropy increasingly reduces the pull of
gravity, so Mercury falls further from the Sun than normal.
Beyond that point, the anisotropy is reducing, so the trajectory
must begin to point back toward the Sun. That's where your
program fails.
The same thing happens on the journey to aphelion. According to
how you include the anisotropy in your program, the anisotropy
is bending the trajectory more to the Sun for the entire journey.
>> In the diagram, a force is applied for the duration of 1 second
>> and it deflects "@" to travel a different straight line
>> trajectory, where it will continue to point if no other forces
>> are applied.
>>
>> (1) on off
>> \/ ^
>> @-------------> _1 sec
>> - _
>> - _
>>
>> A force is now applied to @'s trajectory when it's traveling a
>> circular or elliptical orbit path.
>>
>> (2) on off
>> \/
>> @-------------> _ ^
>> ---------------
>>
>> Do you now see the difference?
> Yes, the first is correct, the second is wrong. You
> have shown an instantaneous change of the velocity
> when the force goes off which of course cannot happen.
No, I've shown an instantaneous change of _direction_ and that
does happen the moment the force is varied, but the change is
not to the extent shown of course.
> What has happened in the first case is that the planet
> has been pushed off its circular orbit. The segment
> after the 1s application of the transverse force is
> now part of an elliptical orbit. One orbit later the
> planet will return on a course that arrives a little
> above the left hand section, pass through the "off"
> point and then retrace the part to the lower right.
> If the force is exactly perpendicular to the motion
> throughout the 1s, then the energy of the orbit
> remains the same but the eccentricity has changed.
Even if it has, the change is only around 41 meters per orbit.
http://members.optusnet.com.au/maxkeon/proven2.html
>> Your program does not account for the centripetal-centrifugal
>> force imbalance. It assumes that the trajectory is affected by
>> the anisotropy as in diagram (1).
> (1) is correct, your second diagram is wrong. In an
> elliptical orbit the "force imbalance" you mention is
> what causes the variation of the radius. In an
> elliptical orbit, in polar coordinates, generally the
> gravitational and centrifugal forces are _not_ balanced
> whereas they are for a circular orbit.
But all forces are balanced George. A trajectory is exactly
defined by that balance. There are no multiple choices available
for one set of circumstances you know.
-----
Max Keon
George Dishman
No Max, you are. Accelerations add. Your job
in providing me with an equation is to give
one that tells me the amount TO BE ADDED. If
it doesn't do that job, the equation is wrong
in that it tells me something that is not what
you theory predicts.
>>> A circular orbit is equivalent to a straight line through the
>>> two dimensions in the plane of the orbit. Likewise is a stable
>>> eccentric orbit. It's the line where all forces are in balance.
>
>> The forces are not balanced, the only force acting is
>> Newtonian gravity which is why the planet doesn't move
>> in a straight line but instead travels in a circle. If
>> you work in polar coordinates, there is a centrifugal
>> "pseudo-force" which appears to balance gravity and
>> keep the radius constant but we weren't using polar
>> coordinates.
>
> You know as well as I do that the trajectory of a mass in an
> eccentric orbit is determined by a balance between centripetal
> force, centrifugal force (however you wish to define that) and
> momentum.
No, the deviation from a straight line in the form
of an acceleration is determined by the imbalance
of the forces divided by the mass.
> It's as though it were oscillating back and forth once
> per orbit cycle in the middle of an invisible spring.
Sorry Max, that is wrong, it also speeds up and
slows down along the path.
> What would you expect it to do?
>
> A straight line trajectory, a circular orbit, and an eccentric
> orbit all follow a path where the forces are in balance.
No, a straight line results if the forces are balanced,
the others are produced by the imbalance. In my program,
if you remove the anisotropy, there is ONLY gravity with
nothing to balance it and as you know it correctly
produces the elliptical orbit.
> _All_
> stable orbits are identical.
Complete rubbish, and the anisotropy makes the orbit
unstable anyway.
That is for a circular orbit of course and
is where the acceleration towards the Sun
due to the unbalanced gravitational force
is exactly that needed to curve the path
at the right rate.
Sorry, you have failed to realise that there is
no sudden change, as the speed goes smoothly from
negative to positive through zero, so the path
changes smoothly too.
> Your program gives a one way trajectory change for the entire
> journey from aphelion to perihelion, which is wrong. Up to the
> midway point on the fall from aphelion to perihelion the
> (now negative) anisotropy increasingly reduces the pull of
> gravity, so Mercury falls further from the Sun than normal.
> Beyond that point, the anisotropy is reducing, so the trajectory
> must begin to point back toward the Sun. That's where your
> program fails.
The program implements your equation accurately so
if the output is wrong, it is your equation that is
wrong, not the program.
> The same thing happens on the journey to aphelion. According to
> how you include the anisotropy in your program, the anisotropy
> is bending the trajectory more to the Sun for the entire journey.
No, it bends it away on the inward leg, the perihelion
is _increased_, not decreased.
>>> In the diagram, a force is applied for the duration of 1 second
>>> and it deflects "@" to travel a different straight line
>>> trajectory, where it will continue to point if no other forces
>>> are applied.
>>>
>>> (1) on off
>>> \/ ^
>>> @-------------> _1 sec
>>> - _
>>> - _
>>>
>>> A force is now applied to @'s trajectory when it's traveling a
>>> circular or elliptical orbit path.
>>>
>>> (2) on off
>>> \/
>>> @-------------> _ ^
>>> ---------------
>>>
>>> Do you now see the difference?
>
>> Yes, the first is correct, the second is wrong. You
>> have shown an instantaneous change of the velocity
>> when the force goes off which of course cannot happen.
>
> No, I've shown an instantaneous change of _direction_ and that
> does happen the moment the force is varied,
No it doesn't, that is your mistake, the direction
immediately _starts_ to change if an different
acceleration is applied, but you have shown a change
when the acceleratioion is switched _off_. In that
case the planet is simply left moving in whatever
direction resulted from the application while it was
on, there is no change at all at the instant it goes
off, and your first diagram is correct.
> but the change is
> not to the extent shown of course.
No problem, you have exagerrated to make it visible
which is fine.
>> What has happened in the first case is that the planet
>> has been pushed off its circular orbit. The segment
>> after the 1s application of the transverse force is
>> now part of an elliptical orbit. One orbit later the
>> planet will return on a course that arrives a little
>> above the left hand section, pass through the "off"
>> point and then retrace the part to the lower right.
>> If the force is exactly perpendicular to the motion
>> throughout the 1s, then the energy of the orbit
>> remains the same but the eccentricity has changed.
>
> Even if it has, the change is only around 41 meters per orbit.
The perihelion is increased by 2010939m on the
first orbit alone, your maths is hopelessly wrong.
> http://members.optusnet.com.au/maxkeon/proven2.html
>
>>> Your program does not account for the centripetal-centrifugal
>>> force imbalance. It assumes that the trajectory is affected by
>>> the anisotropy as in diagram (1).
>
>> (1) is correct, your second diagram is wrong. In an
>> elliptical orbit the "force imbalance" you mention is
>> what causes the variation of the radius. In an
>> elliptical orbit, in polar coordinates, generally the
>> gravitational and centrifugal forces are _not_ balanced
>> whereas they are for a circular orbit.
>
> But all forces are balanced George.
No Max, they are only balanced for a circular
orbit using polar coordinates and psuedo-forces
and they _never_ balance in an elliptical orbit.
Polar coordinates are too advanced for you, stick
to the simpler Cartesian system where there are
no psuedo-forces and gravity is the only force,
then just add your anisotropy.
> A trajectory is exactly
> defined by that balance. There are no multiple choices available
> for one set of circumstances you know.
Your anisotropy makes the orbit unstable, it decays.
You need to forget about your ideas for a while and
go and learn the basic high school maths that you are
trying to use, you are wasting time continually
repeating the same error instead of getting out a text
book and learning what you need to know.
George
Max Keon
> Max Keon wrote:
>> George Dishman wrote:
>>>> You are still missing the point completely here George.
>>>
>>> The point Max is that the maths I have explained to
>>> you is the _only_ valid method for incorporating your
>>> equation. You have told me the acceleration and I have
>>> used it. If you don't like the answer, tell me a
>>> different equation, one which _can_ be added in the
>>> manner my program applies.
>>
>> Put your books away for a while and think about this, you are
>> still missing the point.
> No Max, you are. Accelerations add.
Then why don't you add _all_ accelerations.
>> A straight line trajectory, a circular orbit, and an eccentric
>> orbit all follow a path where the forces are in balance.
> No, a straight line results if the forces are balanced,
> the others are produced by the imbalance. In my program,
> if you remove the anisotropy, there is ONLY gravity with
> nothing to balance it and as you know it correctly
> produces the elliptical orbit.
The balance, or imbalance if you wish, involves centripetal
force, centrifugal force and momentum, regardless of the orbit
shape.
---
>> xx = 58000000000#
>> ' Average orbit radius.
>>
>> newt = G * M / x ^ 2
>> ' Centripetal force at the start point.
>>
>> os = (G * M / xx) ^ .5
>> ' Orbital speed where centripetal and centrifugal
>> ' forces are equal.
> That is for a circular orbit of course and
> is where the acceleration towards the Sun
> due to the unbalanced gravitational force
> is exactly that needed to curve the path
> at the right rate.
That's true, centripetal and centrifugal forces are not really
equal. They are assumed to be equal about the orbit path at that
point which is determined by your part of the program. The
actual curve is thus maintained.
>> aa:
>> ryx = x * x + y * y
>> radius = SQR(ryx)
>>
>> vr = (radius - lastradius) / dt
>> lastradius = radius
>>
>> newton = G * M / ryx
>> acceleration = -newton
>>
>> ax = acceleration * (x / radius)
>> ay = acceleration * (y / radius)
>>
>> vx = vx + dt * ax
>> vy = vy + dt * ay
>>
>> x = x + dt * vx
>> y = y + dt * vy
---
>> The same thing happens on the journey to aphelion. According to
>> how you include the anisotropy in your program, the anisotropy
>> is bending the trajectory more to the Sun for the entire journey.
> No, it bends it away on the inward leg, the perihelion
> is _increased_, not decreased.
I obviously meant "the entire journey" from perihelion to
aphelion.
---
>>> What has happened in the first case is that the planet
>>> has been pushed off its circular orbit. The segment
>>> after the 1s application of the transverse force is
>>> now part of an elliptical orbit. One orbit later the
>>> planet will return on a course that arrives a little
>>> above the left hand section, pass through the "off"
>>> point and then retrace the part to the lower right.
>>> If the force is exactly perpendicular to the motion
>>> throughout the 1s, then the energy of the orbit
>>> remains the same but the eccentricity has changed.
>>
>> Even if it has, the change is only around 41 meters per orbit.
> The perihelion is increased by 2010939m on the
> first orbit alone, your maths is hopelessly wrong.
http://members.optusnet.com.au/maxkeon/profa.jpg
shows the true consequences of correctly adding the anisotropy
to your program for the first fall from aphelion to perihelion.
The 41 meter figure I gave above was wrong because the
equation that gave the anomalous acceleration rate toward
the Sun was wrong. My original equation in the program
"radius = radius + anb" was in fact correct.
http://members.optusnet.com.au/maxkeon/proven2.html
has been updated accordingly.
An anomalous gravity change acts _directly_ toward the gravity
source, _nowhere else_, so it _must_ be added directly to the
radius between the gravity source and the orbiting body. And all
consequent forces also need to be included.
During the first second after an abrupt gravity change is
applied, if the anomalous change is, i.e. 8e-7m/sec^2 and orbital
speed is 48000 m/sec, the trajectory will shift from the normal
by 9.549e-10 degrees. But the trajectory has now changed from
what was the path of a perfectly balanced transition through the
two dimensional planes of the orbit, regardless of the orbit
shape. The centripetal-centrifugal force balance is thrown off
the natural balance, and that will increasingly affect the newly
established orbit path.
The problem with your program is that the trajectory change has
no consequence.
> Your anisotropy makes the orbit unstable, it decays.
> You need to forget about your ideas for a while and
> go and learn the basic high school maths that you are
> trying to use, you are wasting time continually
> repeating the same error instead of getting out a text
> book and learning what you need to know.
I've put a lot of thought into this George and I can only conclude
that I am right and you are wrong. I'll be only too happy to be
_proven_ wrong, but nothing you have put forward goes any way
toward doing that. I can't delude myself into believing something
that is clearly based on flawed maths.
So far you have provided nothing which rejects a gravity
anisotropy, _or the theory that predicts it_.
George Dishman
> "George Dishman" <geo...@briar.demon.co.uk> wrote in message
> news:YtOdnasL8b6AZ4Ha...@pipex.net...
> > Max Keon wrote:
> >> George Dishman wrote:
> >>> Max Keon wrote:
> >>>> You are still missing the point completely here George.
>
> >>> The point Max is that the maths I have explained to
> >>> you is the _only_ valid method for incorporating your
> >>> equation. You have told me the acceleration and I have
> >>> used it. If you don't like the answer, tell me a
> >>> different equation, one which _can_ be added in the
> >>> manner my program applies.
>
> >> Put your books away for a while and think about this, you are
> >> still missing the point.
> > No Max, you are. Accelerations add.
>
> Then why don't you add _all_ accelerations.
You _DO_. If more than one effect applies an acceleration
to an object then you add the vector accelerations to get
the total effect.
> >> A straight line trajectory, a circular orbit, and an eccentric
> >> orbit all follow a path where the forces are in balance.
> > No, a straight line results if the forces are balanced,
> > the others are produced by the imbalance. In my program,
> > if you remove the anisotropy, there is ONLY gravity with
> > nothing to balance it and as you know it correctly
> > produces the elliptical orbit.
>
> The balance, or imbalance if you wish, involves centripetal
> force, centrifugal force and momentum, regardless of the orbit
> shape.
"Centripetal" and "centrifugal force" are terms
that apply in polar coordinates and are called
"psuedo-forces". In the cartesian coordinates
(X and Y) we are using, they do not exist.
Instead centrifugal force refers to the inertia
of the planet which causes it to move in a
straight line in the absence of any applied force
while "centripetal force" refers to the combination
of the other forces, in this case gravity and your
anisotropic force.
The imbalance is what causes the path to deviate
from a straight line.
> >> xx = 58000000000#
> >> ' Average orbit radius.
>
> >> newt = G * M / x ^ 2
> >> ' Centripetal force at the start point.
>
> >> os = (G * M / xx) ^ .5
> >> ' Orbital speed where centripetal and centrifugal
> >> ' forces are equal.
> > That is for a circular orbit of course and
> > is where the acceleration towards the Sun
> > due to the unbalanced gravitational force
> > is exactly that needed to curve the path
> > at the right rate.
>
> That's true, centripetal and centrifugal forces are not really
> equal.
Good, at least you follow that.
> They are assumed to be equal about the orbit path at that
> point which is determined by your part of the program. The
> actual curve is thus maintained.
No, they are not assumed to be anything of the
kind. You cannot make any assumptions because
the effect of the anisotropy might change any
of the usual expectations. What you need to do,
and what my program does, is calculate the motion
based purely on your acceleration equation (plus
Newtonian gravity of course) from first principles
without making any assumptions whatsoever.
> >> aa:
> >> ryx = x * x + y * y
> >> radius = SQR(ryx)
>
> >> vr = (radius - lastradius) / dt
> >> lastradius = radius
>
> >> newton = G * M / ryx
> >> acceleration = -newton
>
> >> ax = acceleration * (x / radius)
> >> ay = acceleration * (y / radius)
>
> >> vx = vx + dt * ax
> >> vy = vy + dt * ay
>
> >> x = x + dt * vx
> >> y = y + dt * vy
>
> ---
>
> >> The same thing happens on the journey to aphelion. According to
^^^^^^^^^^^^^^^^^^^
> >> how you include the anisotropy in your program, the anisotropy
> >> is bending the trajectory more to the Sun for the entire journey.
> > No, it bends it away on the inward leg, the perihelion
> > is _increased_, not decreased.
>
> I obviously meant "the entire journey" from perihelion to
> aphelion.
You said "the journey TO aphelion" which is the inward
leg, from perihelion to aphelion is the outward leg.
> >>> What has happened in the first case is that the planet
> >>> has been pushed off its circular orbit. The segment
> >>> after the 1s application of the transverse force is
> >>> now part of an elliptical orbit. One orbit later the
> >>> planet will return on a course that arrives a little
> >>> above the left hand section, pass through the "off"
> >>> point and then retrace the part to the lower right.
> >>> If the force is exactly perpendicular to the motion
> >>> throughout the 1s, then the energy of the orbit
> >>> remains the same but the eccentricity has changed.
>
> >> Even if it has, the change is only around 41 meters per orbit.
> > The perihelion is increased by 2010939m on the
> > first orbit alone, your maths is hopelessly wrong.
>
> http://members.optusnet.com.au/maxkeon/profa.jpg
> shows the true consequences of correctly adding the anisotropy
> to your program for the first fall from aphelion to perihelion.
Complete rubbish, what on earth have you done?
> The 41 meter figure I gave above was wrong because the
> equation that gave the anomalous acceleration rate toward
> the Sun was wrong. My original equation in the program
> "radius = radius + anb" was in fact correct.
> http://members.optusnet.com.au/maxkeon/proven2.html
> has been updated accordingly.
>
> An anomalous gravity change acts _directly_ toward the gravity
> source, _nowhere else_, ...
Yes, that's what my program does.
> so it _must_ be added directly to the
> radius between the gravity source and the orbiting body. And all
> consequent forces also need to be included.
No Max, you do not add an acceleration to a radius,
you add the acceleration due to the anisotropy to
the acceleration due to Newtonian gravity and then
integrate twice to find the path.
> During the first second after an abrupt gravity change is
> applied, if the anomalous change is, i.e. 8e-7m/sec^2 and orbital
> speed is 48000 m/sec, the trajectory will shift from the normal
> by 9.549e-10 degrees. But the trajectory has now changed from
> what was the path of a perfectly balanced transition through the
> two dimensional planes of the orbit, regardless of the orbit
> shape. The centripetal-centrifugal force balance is thrown off
> the natural balance, and that will increasingly affect the newly
> established orbit path.
>
> The problem with your program is that the trajectory change has
> no consequence.
Sorry Max, you clearly cannot read the code. The change
of the path you describe affects the vx and vy values
which changes the radius at the end of the second and
that in turn modifies the gravitational acceleration.
What you say i correct and my code does exactly what
you say it should.
> > Your anisotropy makes the orbit unstable, it decays.
> > You need to forget about your ideas for a while and
> > go and learn the basic high school maths that you are
> > trying to use, you are wasting time continually
> > repeating the same error instead of getting out a text
> > book and learning what you need to know.
>
> I've put a lot of thought into this George and I can only conclude
> that I am right and you are wrong. I'll be only too happy to be
> _proven_ wrong, but nothing you have put forward goes any way
> toward doing that. I can't delude myself into believing something
> that is clearly based on flawed maths.
Max, my maths is correct. You need to learn how to
add vectors and how to integrate acceleration once
to get velocity and a second time to get location.
I have repeatedly given you links to K12 sites
where these basic schoolboy topics are covered and
you can easily find lots more.
> So far you have provided nothing which rejects a gravity
> anisotropy, _or the theory that predicts it_.
Yes I have, Mercury's orbit would become circular
within a few thousand orbits, your theory is
unquestionably ruled out. Your problem is that you
haven't learned basic maths that you should have
mastered when you were about 13 years old and you
won't make any progress with this question until
you do. I can only advise that you lay aside all
considerations of gravity and go and learn the
maths first. We have been going over your errors
for months and while we have corrected a lot of
secondary misunderstandings, you haven't addressed
the fundamental problem at all.
George
Max Keon
> Max Keon wrote:
>> George Dishman wrote:
>>> Max Keon wrote:
>>>> Put your books away for a while and think about this, you are
>>>> still missing the point.
>>>
>>> No Max, you are. Accelerations add.
>>
>> Then why don't you add _all_ accelerations.
> You _DO_. If more than one effect applies an acceleration
> to an object then you add the vector accelerations to get
> the total effect.
You're still wrong George. Your application of the anomalous
acceleration chooses a trajectory that's not affected by what
you later call "pseudo forces". You just brush those forces
aside as though they don't exist. But those forces are always
very much an integral part of an orbit.
>>>> A straight line trajectory, a circular orbit, and an eccentric
>>>> orbit all follow a path where the forces are in balance.
>>>
>>> No, a straight line results if the forces are balanced,
>>> the others are produced by the imbalance. In my program,
>>> if you remove the anisotropy, there is ONLY gravity with
>>> nothing to balance it and as you know it correctly
>>> produces the elliptical orbit.
>>
>> The balance, or imbalance if you wish, involves centripetal
>> force, centrifugal force and momentum, regardless of the orbit
>> shape.
> "Centripetal" and "centrifugal force" are terms
> that apply in polar coordinates and are called
> "psuedo-forces". In the cartesian coordinates
> (X and Y) we are using, they do not exist.
> Instead centrifugal force refers to the inertia
> of the planet which causes it to move in a
> straight line in the absence of any applied force
> while "centripetal force" refers to the combination
> of the other forces, in this case gravity and your
> anisotropic force.
You know as well as I do that a change in gravity has an
immediate consequence. An anomalous gravity increase is always
pointing directly at the gravity source and acceleration will
begin immediately in that direction. The ONLY possible trajectory
shift is determined by the fall rate directed at the gravity
source and the distance covered in that time. Subtracting the
fall from the radius is the ONLY possible option.
Your trajectory shift is millions of meters wrong.
> The imbalance is what causes the path to deviate
> from a straight line.
There is no centrifugal force acting on a straight line trajectory.
And if a force is maintained until a circular orbit is formed,
centripetal force is then equal to centrifugal force. Otherwise
the orbiting body continues to fall inward.
---
>> That's true, centripetal and centrifugal forces are not really
>> equal.
> Good, at least you follow that.
They are momentarily equal at two points in an elliptical orbit.
Don't forget that.
>> They are assumed to be equal about the orbit path at that
>> point which is determined by your part of the program. The
>> actual curve is thus maintained.
> No, they are not assumed to be anything of the
> kind. You cannot make any assumptions because
> the effect of the anisotropy might change any
> of the usual expectations. What you need to do,
> and what my program does, is calculate the motion
> based purely on your acceleration equation (plus
> Newtonian gravity of course) from first principles
> without making any assumptions whatsoever.
As I keep on trying to tell you, your program is great for
plotting the natural transition through the two planes of an
orbit, but it's incapable of accommodating an anomalous force
occurring anywhere during that transition.
---
>> http://members.optusnet.com.au/maxkeon/profa.jpg
>> shows the true consequences of correctly adding the anisotropy
>> to your program for the first fall from aphelion to perihelion.
> Complete rubbish, what on earth have you done?
That graph is a plot of the initial fall from aphelion to
perihelion. It shows the radius change from the normal as defined
by your program, with the anisotropy correctly applied. Meaning
that it's added to the radius. It was generated using the value
stored in "anb", so I wouldn't get too excited about it because
it's wrong.
A planet's inertia is of no consequence in the realm of gravity.
If gravity was to suddenly increase anomalously, an orbiting mass
would immediately accelerate from its current trajectory at the
rate of the anomalous increase, DIRECTLY TOWARD THE GRAVITY
SOURCE.
You can't change the laws of nature on a whim.
The following program is designed to demonstrate that a planet's
inertia sets its trajectory only when the trajectory aligns with
the requirements of centripetal and centrifugal forces. Inertia
can't be considered outside that balance.
If you run it, notice the point where the two forces swap signs.
There's no anisotropy included by the way.
'-------------
' This program demonstrates that ALL orbits are identical. Every
' orbit is equivalent to a circular orbit, and vise versa.
'
' "cf = v^2 / radius" gives the centrifugal acceleration rate.
'
' Notice how Mercury just rocks and up and down in the same way
' as a mass that's suspended on a spring. The spring force builds
' on the down cycle until the fall is halted, and reduces on the
' up cycle until the rise is halted.
'
' The current setup is for Mercury's orbit.
SCREEN 12: CLS : COLOR 7
CLS
CIRCLE (250, 250), 4, 14 ' Sun.
c = 299792458#
G = .0000000000667#
M = 1.99D+30
multi = .000000002# ' Multiplier for the graphics.
colr = 3 ' sets the initial graphics color.
x = 69820000000#: vy = 38850# ' Aphelion start.
' Swap the ' switch.
' x = 69820000000#: vy = (G*M/x)^.5 ' for a circular orbit.
' (supposed to be)
lastradius = x
dt = 400
aa:
ryx = x * x + y * y
radius = SQR(ryx)
vr = (radius - lastradius) / dt
lastradius = radius
newton = G * M / ryx
acceleration = -newton
ax = acceleration * (x / radius)
ay = acceleration * (y / radius)
vx = vx + dt * ax
vy = vy + dt * ay
x = x + dt * vx
y = y + dt * vy
v = (vx ^ 2# + vy ^ 2#) ^ .5# ' Orbital speed.
cf = v ^ 2 / radius ' cf is centrifugal force.
LOCATE 2, 1: PRINT cf; "centrifugal force. "
PRINT newton; "centripetal force (newton). "
PRINT cf - newton; "centrifugal force advantage. "
CIRCLE (250 + x * multi, 250 - y * multi), 0, colr
f = f + dt
IF f > 7603200 THEN END
GOTO aa
'--------------
>> The 41 meter figure I gave above was wrong because the
>> equation that gave the anomalous acceleration rate toward
>> the Sun was wrong. My original equation in the program
>> "radius = radius + anb" was in fact correct.
That's not right either. The value stored in "ana" was the
current compounding fall rate and that was added directly to the
radius for each time unit. So that was in fact correct for the
purpose of the program, which was to adapt the first program
listed at this link to an elliptical orbit. I need to do that
all again I think.
>> http://members.optusnet.com.au/maxkeon/proven2.html
>> has been updated accordingly.
>>
>> An anomalous gravity change acts _directly_ toward the gravity
>> source, _nowhere else_, ...
> Yes, that's what my program does.
Yes, but only while it's plotting a natural orbit. Beyond that,
it fails. An anomalous change can only be added directly to the
radius and ALL consequences of that change MUST be included.
---
>> During the first second after an abrupt gravity change is
>> applied, if the anomalous change is, i.e. 8e-7m/sec^2 and orbital
>> speed is 48000 m/sec, the trajectory will shift from the normal
>> by 9.549e-10 degrees. But the trajectory has now changed from
>> what was the path of a perfectly balanced transition through the
>> two dimensional planes of the orbit, regardless of the orbit
>> shape. The centripetal-centrifugal force balance is thrown off
>> the natural balance, and that will increasingly affect the newly
>> established orbit path.
>>
>> The problem with your program is that the trajectory change has
>> no consequence.
> Sorry Max, you clearly cannot read the code. The change
> of the path you describe affects the vx and vy values
> which changes the radius at the end of the second and
> that in turn modifies the gravitational acceleration.
> What you say i correct and my code does exactly what
> you say it should.
Only until an anomalous gravity change is introduced.
You seem to have a mental block here George. I've addressed the
problem by adding the anisotropy correctly, to the radius.
http://members.optusnet.com.au/maxkeon/the1-1a.html
You will no doubt have a problem comprehending the zero origin
universe, but I can help you with that too.
-----
Max Keon