Conference hydra::amiga_v1

    Fundamental Formulas of Physics or something in paper from dover
    in
    2 volumes has a chapter on orbital mechanicals.  It's not trivial.
    I think you should use fields and energy, not forces and velocities; otherwise
    it will be too hard.  10 to 1 the program exists already.
    Tom

    Yes, it does.  One of my Professors at Northeastern has a program
    very similar to what you are looking for, but I'll be damned if
    I can remember his name.  8^(
    
    As I recall, he gave us a procedure that had a small error that
    took him months to find.  It was an extra credit problem for us.
    The Error turned out to be something to the effect of "a piece of
    data updated every microsecond, was being used before it should
    have, and should have been updated once more, before being used."
    or something like that, so
    
    Yes it has been done.
    
    Steve O

    I wrote such a program in 1975 for the Sanders/500.  It isn't very
    difficult if you use the forces approach (Newtonian mechanics):
    compute the force on each object as the sum of the forces due to
    each other object.  The force due to one other object depends on
    the square root of the distance to the object, and its mass (Newton).
    The object's new velocity is the old velocity plus the force divided
    by the step size.  The object's new position is the old position
    plus the velocity divided by the step size.  The smaller the step
    size the smaller the error, and the slower the simulation.
    
    It gets trickey if you try to take into account the increase in
    mass due to velocity, so you can watch what happens near a black
    hole.  To get good results you need a variable step size, inversely
    proportional to the velocity of the fastest object.
        John Sauter

>    < Note 1974.3 by SAUTER::SAUTER "John Sauter" >
>                   -< not difficult, and can be interesting >-
>    The object's new velocity is the old velocity plus the force divided
>    by the step size.  The object's new position is the old position
>    plus the velocity divided by the step size. 

    I don't understand.  you say v'=v + F/step.  That's
    meters/second = meters/second + kilogram*meter/(second*second)*(1/step)
    
    Is the step in kilograms /second?  What unit is that?
    
    for position:
    s' = s + v/step or
    
    meters = meters + meters/second * (1/step), so step would be in
    nothing per second.  What unit is that? Otherwise the units don't
    work out.

    Tom

    re: .4
    
    I wasn't thinking very clearly when I wrote .3.  Let's see if I
    can do better.  Force = mass * acceleration (Newton).  Using SI
    units, mass is measured in grams, and acceleration in centimeters
    per second squared, so force is measured in gm-cm/sec�.
    
    You compute the force due to each other object from Newton's equation
    for gravity (which I won't embarass myself further by trying to
    remember) and sum the forces to get the net force on the object.
    
    The acceleration of the object is the net force divided by its mass.
    (I must have forgotten about the object's mass in .3).
    
    Acceleration causes a change in velocity based on the amount of
    time it is applied, so the new velocity must be the old velocity
    plus (acceleration _times_ step size), not divided by step size
    as I stated in .3.  With longer step sizes each computed acceleration
    is applied over a longer time, and therefore contributes more to
    each velocity.  Similarly, the new position is the old position
    plus (velocity _times_ step size).
    
    Step size is measured in seconds, by the way.  If you want smooth
    animation, set the step size to 0.3 or thereabouts.  The computational
    complexity increases as the square of the number of objects, so
    you will not get real time operation if you have lots of objects.
    
    When doing orbit visualizaton you may want to go faster than real
    time.  A real-time simulation of the solar system wouldn't be too
    exciting after the first few hours.
    
    Sorry about the bad mathematical advice; my only excuse is that
    I did this work a long time ago, and I've forgotten more than I
    realized.  Consult a good physics book if you want a more reliable
    source.
        John Sauter

I was thinking on doing just what John said - use the forces under Newton.
Except the new location will be a function of the impulse given to it
by the resulting gravatational forces taken over delta t - The step time.

One thing I didn't see John accounting for is the Centripital Force generated
when the new position is not tangent to it's previous velocity vector. I could
maintain N number of previous spacial points to provide for calculation
of a psuedo-radius of curvature, thereby allowing calculation of the
centripital force. This force then gets added, for each "Quantum" , to
the above resultant force (due to the gravity of all other objects).

The relevant equations:

	         M1M2
	Fg =  G ------		Vectoral sum of all objects/per object
                  R�

	       MV�
	Fc =  -----		Centripital force. r is radius of curve
                r

	F  = Fg + Fc		Vectoral sum of gravatational and centripital F

	(Ft = MV)		Impulse due to F above
	Vi = Ft/M		Velocity due to the Impulse

	V' = V + Vi		New velocity Vector (is this right???)
 
	S' = S + V't		New position (in direction of V vector)


Whats missing???  Whats Wrong!?!


John

    
    In the magazine "Astronomy" about a year or so ago there was a BASIC
    program designed to illustrate the gravitational/orbital effect
    on a star cluster, it must contain all the formulae you need. I'll
    dig it out and let you know the issue number.
    
    				Alan T.

    re: .6
    
    If I remember my physics lectures correctly (this was even longer
    ago than 1975) centripital force isn't real.  It's actually a function
    of being tethered to the center of motion; if you cut loose the
    rope, the "force" disappears.  For example, a small body in orbit
    around the Earth feels no net force, even though it is constantly
    turning!
    
    Thus, I don't think you need to worry about radius of curvature.
        John Sauter 

    
>    If I remember my physics lectures correctly (this was even longer
>    ago than 1975) centripital force isn't real.  It's actually a function
>    of being tethered to the center of motion; if you cut loose the
>    rope, the "force" disappears.  For example, a small body in orbit
>    around the Earth feels no net force, even though it is constantly
>    turning!

Huh?  If you cut the "rope" it's true the force dissappears. But so does the 
curved motion. The object then flies off on the tangent in a strait line.

The force I was trying to account for is due to the change in direction 
of the mass, which is an acceleration (centripital acceleration). When the
net force of all other bodies changes the direction of the mass in question,
it feels a force 90� to the tangent of the curve. This force is due to it's
inertia and the tendancy for it to travel in a strait line.

The velocity of the moon's mass around the earth creates a centrifugal force
which, if it weren't for the gravational attraction between earth-moon, would
cause the moon to fly off into space on a strait line.

Centripital Force is the measurable quantity that is required to exactly
counteract the centrifugal force resulting from a mass travelling an a curved
path (i.e. the tension in the rope) and is directed towards the center of the
curvature. 

In orbital motion, Fc = Fg. In other words, the force of gravitational
attraction is equal to the force tending to send the moon off into space,
hence orbit.


Am I missing something here??


John

    re: .9
    
    I think you've got it backwards.  Change in direction of motion 
    is due to force, the force isn't caused by the change in direction.  
    If you compute the net force on a planet due to gravitation, you can
    predict the path of the planet (Newton, Kepler).
    
    In the example you give of the Moon flying off in a straight line,
    I claim that if the Earth, Sun, etc were to disappear the Moon would
    indeed fly off in a straight line, but flying in a straight line
    requires no force!
        John Sauter

Now that kinda makes sense, doesn't it?  It  makes it a bit easier too.

Come to think of it, I bet I would have calculated a centripital
force EQUAL (and opposite) to the force that was curving the motion!!
Then adding the 2 would have produced F=0, or no curve at all!! (BORING!)

John

Yes, John is correct- motion continues at constant velocity (speed AND
direction) until acted on by outside force. First law of motion.

I believe the following procedure will work. It's rather roundabout,
but that's what orbits are, :^)  - and computers don't mind the work.
--------------------------------------------------------------------------
First, calculate the force acting on pairs of bodies. (Must do this for each 
set of pairs):

	M1 + M2
F = --------------- * G
	D squared

Where M1 and M2 are the masses, D the distance between their gravitational
centers, and G the gravitational constant, 6.67E-11. This is "gravity",
or "centripetal force". Units are kilograms and meters.

Next, apply the force to each mass of the pair to get acceleration along
the force vector. The force vector is a line drawn between the two
masses. Acceleration is force/mass, so A for M1 = F/M1, A for M2 = F/M2.
Note that a big mass is accelerated little, a small one a lot, which
is why the earth orbits the sun, not vice versa.

Now select a time interval and calculate average velocity along the
acceleration vector. Since acceleration = distince/time/time, and
velocity is distance/time, then the average velocity is A/t. The time
interval is arbitrary, but little ones cause lots of calculations,
and big ones cause poor resolution. I'd suggest 10 "real" minutes
to replot every 1/10 second. This would mean one moon orbit around
earth in 403 computer seconds, about 7 minutes. To go faster, select
a longer "real" interval, or replot faster. AmigaBasic may not be
able to keep up with high plot rates.

At this point, you should probably do all the velocities along all the
acceleration vectors for all the masses involved, and save them. The next
step would be to perform vector addition of all the velocities of all
the masses. Resolve each vector into delta X and delta Y, and sum all the
deltas, obtaining a final velocity in two components, X and Y. Note that
the velocity obtained is used in the next round of calculations as one
of the velocity vectors to be summed. (Also there has to be a mechanism
for establishing the "initial" velocity vectors, or the bodies will
exhibit the boring behavior of falling straight towards each other until 
impact.)

Add the X and Y deltas to the current X and Y positions of the objects,
replot, and then repeat all of the above. Tedious, but the Ami doesn't
mind. To get accurate animation, be sure to use the timer.device to
refresh the plot, so there will be good correlation between "real" and
"computer" time interval.

    I have written such a program in AmigaBasic.  It plots the motion
    of up to 12 bodies in either an absolute or center-of-mass frame
    of reference.  It is iterative, and allows you to set the mass,
    initial position and initial velocity of each of the objects, and
    the time step size and gravitational constant.  It will also randomly
    assign values to parameters if you so wish.  It runs until all the
    objects are off the screen.
    
    It's not terribly fast, but for 4 or 5 bodies it runs fast enough
    that the display is interesting to watch.  It suffers badly from
    long term divergence; i.e., nominally stable orbits go haywire after
    a few orbits, but sometimes the results are interesting to watch
    anyway.  It is, of course, two dimensional only.  With appropriate
    initial conditions, I have been able to set up 3, 4, 5 and 6 body
    rosettes (i.e., symmetric "rings" of bodies orbiting their common center
    of mass) that are stable for several orbits. 
    
    I am surprised by the misunderstandings about Newtonian mechanics
    evinced by some of the discussion here.
    
    Centripetal force or acceleration does not enter into the simulation
    at all.  As already noted several times, for each iteration, you
    compute the force acting between each pair of bodies, sum the forces
    acting on each body, compute each body's current acceleration by
    dividing the force by the mass (being clever to use a consistent
    convention for direction), update the velocity by adding the
    acceleration times the time interval, update the position by adding
    the velocity times the time interval, plot the new position, and do
    it again.  The center of mass frame of reference requires a
    normalization step in the loop.
    
    This is a brute force approach and requires a relatively small time
    interval to avoid rapid divergence.  You can get by with larger
    time intervals by using fancier equations (i.e., using higher order
    difference equations).  None the less, it works quite well at
    demonstrating the basic principles involved.
    
    There are numerous things to watch out for, like overflow.
    
    I don't have a modem on my Amiga, but I could probably get a disk
    of this program to somebody who does, and they could make it available
    to the net.  I have a couple of other programs that might also be
    of interest (e.g., linear automata, diffusion limited aggregation
    simulation (better than the one discussed in Scientific American
    this month), Newton's method convergence maps).
    
    len.
     
    

    I'm not sure. But Starglider II seems to take into account orbital
    and gravitational kinematics. 
    
    ...Rich

    I went back and read the code this weekend.  The program's in pretty
    good shape, and I will be taking advantage of Wes Plouffe's offer
    to make it available on the net as soon as I can clean up a few
    minor things and get a few other programs into shape.
    
    The only tricky thing was sorting out the resolution of the force
    into its x and y components.  This required suitably adjusting the
    principle value returned by the ArcTangent function (used to compute the
    orientation of the vector between each pair of masses) depending
    on which quadrant the vector was located in.  And, of course, avoiding
    a divide by zero when the two objects have the same x position. 
    In retrospect, I ought to be able to avoid using any trig functions,
    simply resolving the force into its components by similar triangles.
    This will require an invocation of SquareRoot, but that's cheaper
    than invoking ArcTangent, Sine and Cosine.  Why didn't I think of
    that earlier?
    
    Anyway, the rest of the program is as described in .13.  I made
    no attempt to relate the passage of simulated time to real time,
    and I need to provide some guidance as to sensible values for the
    various input parameters.  The program will quite happily accept
    conventional units (mass in Kg, position in M, velocity in M/sec,
    etc.), but at risk of overflow.  An early 3-body version assumed
    specialized units (i.e., mass in arbitrary units ("emms"), position
    in pixels, velocity in pixels/iteration, G in compatible units, etc.),
    but I generalized both the number of bodies and the units during
    a rewrite to accommodate the center of mass frame of reference.
    
    len.
    

    You might want to check out GRAV.ARC which is probably on TAPE::
    amoung others.  This is a game where you have a number of planets
    and stars on the screen.  Two players attempt to fire missles at
    one another.   The missles get bent all over the place by gravitational
    effects.  I believe the effects were supposed to be fairly accurate.
    
    I only looked at this one time so I don't remember much about it.
    I'm sure it was PD so maybe the code is available.  Something sticks
    in my mind that it was written in Draco or compiled Basic but I
    could be wrong.
    
    - steve mcafee

Re: .8

>    If I remember my physics lectures correctly (this was even longer
>    ago than 1975) centripital force isn't real.

I think you may have inadvertently written a few notes using the word
"centripetal" when you meant "centrifugal".

Centripetal force is real.  In orbital mechanics, the centripetal force
is the force acting to pull the satellite down towards the object being
orbited.  It is the very real force gravity.

Centrifugal force is the fictitious force of your physics lectures.
Centrifugal force seems to be a force acting normal to the curve
of an orbit.  The centrifugal force seems to keep the water in the pail
being swung above the head or keep the satellite from falling.  This
force does not exist: it is the result of inertia and the centripetal
and tangential forces.

Consider a string with a rock at the end being swung in a plane
perpendicular to the ground.  The centripetal force is being supplied
by the string.  Their seems the be a centrifugal force pulling on the
rock keeping the string taut.  If the centrifugal force really existed,
letting go of the string would cause the rock to fly away normal to
the curve.  So if you wanted the rock to hit an object in front of
you, you would let go of the string as the rock passed the passed in
front of you.  You you tried the experiment, you would discover that
the rock would continue in a tangent to its orbit, and would hit the ground
at your feet.  To hit the object in front of you, you would want to 
let go of the string when the rock was at the top or bottom of its
orbit (depending on whether the orbit was clockwise or counter-clockwise).

I agree with the consensus that you do not need to consider the radius
of curvature.  The radius of curvature is determined by the forces acting
on the object and the object's current position, velocity, and mass.

Well, I'm real close to finishing my program (in C). It's fully "intuitionized"
(that's what took me all day sunday to learn!).


I've run into some strangness. When creating objects on the screen I call
ModifyIDCMP to add the MOUSEMOVE messages to my window. This way I can
display the current mouse position in the 2D "universe".  However,
when the mouse coordinates are between 10 and 100 (x or y), I don't get
a 1 pixel movement report resolution. Instead I get a report every 10 pixels
of movement! (...,7,8,9,10,11,22,33,44,55,66,77,88,99,100,101,102,103,...)
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^

What's going on here??

Also OnGadget() doesn't seem to work (completely). It reenables a previously
OffGadget()'ed gadget, but never fixes the "ghosting". I have resorted
to calling a "RePaint()" function which basically does a SetRPort() and then
refreshes the window graphics.  I wonder if I'm getting IDCMP refresh events
to "fix" my gadgets??? I tried RefreshGadgets() to no avail.


John

    Re: .16
    I saw the GRAV program run somewhere--it was fairly impressive.
     And I believe it was written in MODULA2.
    
    

*< Note 1974.19 by SANFAN::BARRETODE >
*                             -< RE:Gravity Wars >-

  
*  Re: .16
*    I saw the GRAV program run somewhere--it was fairly impressive.
*     And I believe it was written in MODULA2.
 
	Its on one of the fred fish  "Goldfish" disks, I believe #1.

    

	Reg