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

    
    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 

    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