The Orrery Models of Astronomical Systems

*********************************************************************************************************
Number 37, December, 2000
*********************************************************************************************************
Subscription
Expirey Check!
Jack and the Equation of Time
by Greg Neill
20
10
0
10
20
Year 2000
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
M
i
n
u
t
e
s
Fig 1. The equation of time
for the year 2000.
Long time readers of The Orrery may recall the adventures of Jack, the moon without a home. Jack wanders
about, getting himself into all sorts of situations with other stellar performers. We keep vicarious tabs on Jack by
simulating his peregrinations and encounters on our computers. The last time we visited Jack he was nosing
about a system with two large Suns, where as the insignificant third party he experienced first hand the restricted
three body problem known as the "Copenhagen Problem" (See The Orrery issue #10).
As we catch up with Jack this time he's decided to try his luck in a more sedate neighborhood, as a lone planet
orbiting a single Sun. All was well until Jack realized that he didn't quite get his parameters perfect. Instead of a
circular orbit he finds himself with a slight eccentricity. Worse still, he finds that his own rotation axis is inclined
to that of his orbit. Now, since Jack likes to check his watch against local noon he has a bit of a problem, since
he now finds that local noon tends to wander about a bit during his year when compared to his smooth running
watch. Can we help Jack quantify the problem?
Here on Earth we have a similar problem. The Earth's orbit is not circular, but is slightly elliptical. The Earth's
eccentricity is currently about 0.0167. Furthermore, the Earth's polar axis is inclined at about 23.45 degrees. If
we ignore for the moment that these values can change slowly over time (due to the effects of other Solar System
bodies including the Moon), we can consider what effects these two facts have on the timing of local noon.
As the Earth spins on its axis once per day, local noon occurs when the Sun appears on the local meridian. In
the time it takes the Earth to rotate once on its axis (according to the "fixed" stars), the Earth will have progressed
some distance along its orbit about the Sun and so to an observer on the Earth the Sun appears to have moved
ahead slightly, which means that the Earth has to rotate just a little bit more in order to line up the meridian with
Continued on next page...
*********************************************************************************************************
In This Issue: Articles:
Jack and the Equation of Time - G. Neill
Calculating the Equation of Time - G. Neill
Potential Problems - Galactic Orbits - G. Neill
Orbits With Excel - G. Neill
Jack returns in a timely fashion, we explore the wild
world of star orbits in a galactic gravity well -- they're not
your usual trajectories, and we find that an Excel
spreadsheet can integrate orbits.
*********************************************************************************************************
1 The Orrery #37, September 2000
The perihelion velocity v
p
h
r
p
=
The specific angular momentum h p =
The semi-latus-rectum p a 1 e
2

( )
=
The perihelion distance r
p
a 1 e ( ) =
Since the simulation requires the perihelion distance and velocity as starting conditions, I looked in my bag of
tricks to find some equations relating these values to the known ones and came up with:
100 =
I also knew the gravitational parameter, , for the system since it is simply the gravitational constant times the
mass of the central sun. In our canonical units Newton's G is 1, so
e 0.0167 = a 100 =
First I set down what I already knew about the desired orbit, namely the semimajor axis and the eccentricity:
I decided that I wanted to simulate a fairly good approximation of the case of the Earth, incorporating the relevant
orbit eccentricity and axis inclination. But I didn't want to use the full set of orbital parameters, like the actual
semimajor axis in kilometers, or the gravitational constant with all its digits and units to convert. It would be more
practical to take our "usual" scale and units and fine tune the starting conditions to achieve the same effect. You
may recall that if we set the central sun to 100 mass units, then a planet with insignificant mass starting at 100
distance units on the X-axis, with a 1 unit Y-direction velocity and zero X-direction velocity will describe a circular
orbit. How can these initial conditions be adjusted the way we want? Canonical units and a few orbit related
equations do the trick.
We can simulate the complications of this situation using our old standby, the Leapfrog integrator. In the program
ETIME1, I've adapted the original program THREE from issue #1 to handle the orbit of the planet and calculate the
equation of time. Modifications include adding a "mean sun" which progresses at a constant angular velocity, a
correction for the inclination of the planet/sun plane with respect to the plane of the mean sun (the obliquity of the
ecliptic), and the calculation and plotting of the equation of time itself from the angular separation of the two
"suns". For the plot of the orbits the perspective is from the planet, so the suns appear to orbit about the planet.
The calculations of the orbit of the planet is still carried out in the sun-centric frame, of course. Here's how I
proceeded.
there is a foreshortening effect. The true Sun and the mean sun will have the same values of right ascension only
where the ecliptic and celestial equator meet (at the equinoxes) and where the true Sun is moving parallel to the
celestial equator (at the solstices). At these points the foreshortening effect is zero.
The second effect is due to the inclination of the polar axis with respect to the plane of the Earth's orbit (the
ecliptic). This is usually referred to as the obliquity of the ecliptic. In an ideal world we would like to keep time by
a sun in a circular orbit around a stationary Earth, where this mean sun is orbiting along the celestial equator
which coincides with the projection of the Earth's equator on the celestial sphere. Such a sun, having a circular
orbit, would always move uniformly around its obit, never speeding up nor slowing down. This is the kind of time
that clocks measure. The actual sun, as viewed from the Earth, appears to follow a trajectory which is inclined by
some twenty three and a half degrees to the celestial equator -- sometimes it is above the equatorial plane,
sometimes below. When we measure local noon by such a sun, by means of a sundial for example, what we are
really doing is projecting the shadow of the Sun onto the plane of the Earth's equator, effectively measuring the
right ascension of the Sun in this plane. Since the plane of the Sun's orbit is inclined with respect to this plane,
the Sun. If the Earth's orbit were perfectly circular, the pace of the Earth around the Sun would be constant and
each day would require the same small extra bit of rotation to line things up, an average of about 3 minutes and 56
seconds of extra time per rotation out of the 24 hour total. But due to the eccentricity of its elliptical orbit, the Earth
does not maintain a constant speed along its trajectory. Instead, it is faster near perihelion and slower near
aphelion, varying gradually in between.
2 The Orrery #37, September 2000
F
un
d
am
en
ta
l P
la
ne
R
o
t
a
t
e
d

P
la
n
e Y-Axis
X-Axis
Z-Axis
The perihelion distance falls out first from the first
equation. The perihelion velocity required the
calculation of a couple of intermediate values, but
still, quite simple to do. The resulting values are:
r
p
98.33 = and v
p
1.0168418 =
You can see these values plugged into the
program as starting values in line 150.
The unit of time in this canonical unit system is not
the second, yet I wanted to know how
approximately how many time steps in our
simulator would make up one full orbit. The
formula that follows from Kepler is appropriate
here, and we have:
TP
2

a
3
2
|

\
|
|
.
= or TP 628.319 = Fig 2. A rotation about the Y-axis tips an orbit lying in
the fundamental plane into the plane of the celestial
equator.
If I keep track of the time by adding up each time step DT, then I'll know to stop the simulation when the total
exceeds this value. In practice, rounding error and simulation granularity will effect the sum of the DTs that make
up a full orbit, so this serves as a close starting approximation. What I did was start with this value and then
made a slight adjustment by observing from the results of a couple of runs that the orbit just "closed". The
adjusted value can be seen as the variable TS at line 270 of the program.
Next it was time to add the mean sun. Rather than add a third body to the integration steps, and since I knew
that the motion of this fictitious entity was a perfectly regular circle, I resorted to direct calculation of its position
from the current simulation time. That's the purpose of lines 410 through 430. One might argue that what I've
really done is add a second planet in a perfectly circular orbit, and viewed from that planet the true sun appears as
the mean sun (since to such a planet, without a rotational axis inclination, the true sun and mean sun are one and
the same thing).
To view the "suns" from the perspective of the planet, I simply reversed the signs of the coordinates in the point
plotting lines. This has the effect of viewing the "radius vectors" from the sun to the planet from the other end, so
to speak.
To achieve the effect of the inclination of the rotational axis of the planet took a bit of thought, but in the end had a
rather simple solution. I wanted to avoid resorting to a 3-D simulation, adding Z components to the integration
steps, since this would slow things down. It would also mean that I would still have to deal with projecting the 3-D
vectors onto the X-Y plane for the angular calculations of the positions of the suns. It finally struck me that what I
was looking at was a rotation of the coordinate axes around the Y-axis. You see, the ellipse of the planet orbit
keeps the Sun at one focus. That focus coincides with the origin of our coordinate system. Furthermore, for our
simulated planet the line of nodes (where the plane of the orbit crosses the X-Y plane of the coordinate system, in
this case the celestial equator) lies along the Y-axis, and is coincident with the semi-latus-rectum. In other words,
viewed from the planet and with a coordinate system that has the celestial equator as its fundamental plane and
with its X-axis oriented to the perihelion direction, the plane of the true sun's orbit is just that X-Y plane tipped with
the Y-axis as the pivot.
It should be noted that in real life the Earth's perihelion does not actually lie along the X-axis of our chosen
coordinate system. That is why the time of perihelion does not coincide with the winter solstice. Right now the
solstice occurs around December 21, while the perihelion occurs around January 4th -- a difference of about ten
days. Another way to look at this is that the inclination of the Earth's rotation axis is not achieved by a simple
rotation about the Y-axis alone. More about this a bit later. For now, it is enough to realize that we will at least
achieve the correct shape and scale of the resulting equation of time curve.
3 The Orrery #37, September 2000
To accomplish this rotation for our planet's coordinates (or equivalently, for the Sun as viewed from the planet), it is
only a matter of multiplying the X-coordinate by the cosine of the angle of the rotation. That's the purpose of the
term cosB in the calculation of the apparent position angle of the Sun in line 440, and in the position for plotting in
line 380.
I should also mention that I wrote a function ATAN2 to calculate the angle of the sun from its coordinates. It takes
care of assigning the correct quadrant to the angle. The size of the mean sun orbit was chosen for clear display,
and does not enter into any calculations.
Assuming that our planet's year is divided into 365.25 days as is the Earth's, the calculation of the equation of
time proceeds in a similar manner, that is, it is simply the difference in the longitude of the true sun and the mean
sun in degrees, multiplied by 4 (thus converting degrees to minutes of time).
So how did we do? In figure 3 I've plotted the data collected from the program. I just added some print statements
to place the values into a text file, pulled them into MathCad, and plotted them.
20
10
0
10
20
Simulated Equation of Time
M
i
n
u
t
e
s
Fig 3. The Equation of Time as produced
from the simulation. The general shape of
the curve closely approximates that of the
true Equation of Time shown in fig 1.
It can be seen that the general shape of the curve, as well as the magnitudes of its excursions conforms pretty
well to that of the "real" equation of time for the year 2000 given in figure 1. The peak-to-peak excursion for the
simulation amounts to some 30.9 minutes, while the similar value for the real thing is about 30.75 minutes, a
difference of only 0.15 minutes, or about nine seconds. Not too shabby.
Notice that the simulated curve begins with an ET value of 0, while the actual ET begins its journey at a slightly
negative vale of about -2.6 minutes. As mentioned before, this artifact is due to the Solstice not occurring at the
same time as perihelion in the real world. If we were to perform a "left shift" of the simulated curve by about ten
days, the correspondence would be much closer. To do even better we would need to take into account some of
the finer points regarding the Earth's orbit, and in particular the things that effect the position of the Sun as viewed
from the Earth such as perturbations caused by the Moon and so forth.
(Program listing begins on next page)
4 The Orrery #37, September 2000
10 REM PROGRAM ETIME1
20 KEY OFF
30 DEFDBL A-Z
40 'Original program "THREE" by Caxton Foster, The Orrery, Issue #1
50 'Modified by G. Neill, September 27, 1998.
60 'Modified by G. Neill, October 25, 2000.
70 'Simulates Equation of Time
80 DT = .005 'Time step size.
90 SR = 5 / 7 'Screen aspect ratio
100 C(1) = 3: C(2) = 4: C(3) = 5
110 X0 = 420
120 Y0 = 175
130 CLS
140 M(1) = 100: X(1) = 0: VY(1) = 0 'The Sun
150 M(2) = 0: X(2) = 98.33 : VY(2) = 1.0168418 'The planet
160 VX(1) = 0: Y(1) = 0 'Sun never moves
170 VX(2) = 0: Y(2) = 0 'Planet starts at perihelion
180 SCREEN 9
190 CLS
200 PRINT "Body", "Mass", "X", "Vy"
210 FOR I = 1 TO 2
220 PRINT USING "## #### ###.## ###.##### ";I, M(I), X(I), VY(I)
230 NEXT I
240 LINE (0, Y0)-(600, Y0)
250 ' Place planet at center of universe
260 circle (X0,Y0),3
270 TS = 628.319986 'Time period for one orbit
280 pi2 = 6.283185307 : DEG = pi2/360
290 X(3) = 0 : Y(3) = 0 'Initial position of Mean Sun
300 cosB = cos(23.45*DEG) 'Obliquity of the ecliptic
310 '
320 T = 0 'Initialize time counter
330 sw1 = 0 'Software switch for detecting end time
340 MainLoop:
350 'Start of main loop.
360 if inkey$ = "Q" then end
370 REM Place a True Sun and Mean Sun point on screen
380 PSET (X0 - X(2)*cosB, Y0 + Y(2) * SR), C(2)
390 PSET (X0 - X(3), Y0 + Y(3) * SR), C(3)
400 'FInd mean sun position and calculate Eq. of Time
410 AMS = T*pi2/TS
420 X(3) = 115*cos(AMS)
430 Y(3) = 115*sin(AMS)
440 AP = ATAN2(Y(2),X(2)*cosB)
450 ET = (AMS - AP)/DEG*4
460 'Plot equation of time
470 PSET (30 + T/5, Y0 - ET*10*SR), C(1)
480 'Do the orbit calc
490 REM r1 is distance from 1 to 2 cubed
500 R1 = ((X(1) - X(2)) ^ 2 + (Y(1) - Y(2)) ^ 2) ^ 1.5
580 REM do the velocities
590 'Save some divisions by combining DT with R's
600 DTR1 = DT / R1
630 VX(2) = VX(2) - (X(2) - X(1)) * DTR1 * M(1)
640 VY(2) = VY(2) - (Y(2) - Y(1)) * DTR1 * M(1)
680 X(2) = X(2) + VX(2) * DT
690 Y(2) = Y(2) + VY(2) * DT
700 'Book keeping for time of run
710 T = T + DT 'Tick of the 'clock'
720 if sw1 = 0 then 'If still in first half of orbit
730 if Y(2) < 0 then sw1 = 1 'Just crossed X-axis (descending)
740 else
750 if Y(2) >= 0 then 'Just crossed X-axis (ascending)
760 locate 23,10
770 print using "Total Time = ####.####";T
780 end 'Halt to admire the view!
790 end if
800 end if
810 GOTO MainLoop
FUNCTION ATAN2(Y,X)
pi = 3.1415926535
if X = 0 then
if Y >= 0 then
ATAN2 = pi/2
else
ATAN2 = 3*pi/2
end if
else
a = ATN(Y/X)
if X > 0 then
if Y >= 0 then
ATAN2 = a
else
ATAN2 =2*pi + a
end if
else
if Y > 0 then
ATAN2 = a + pi
else
ATAN2 = a + pi
end if
end if
end if
END FUNCTION
5 The Orrery #37, September 2000
Where T is in Julian centuries (rather than millenia) from J2000.0.
M 357.52910 35999.05030 T + 0.0001559 T
2
0.00000048 T
3
=
e 0.016708617 0.000042037 T 0.0000001236 T
2
=
23
26
60
+ 21.448 46.8150 T 0.00059 T
2
0.001813 T
3
+
( )
1
3600
+ =
We have an expression for L
0
, so all we need is similar ones for , e, and M. Meeus provides the following:
is the Sun's mean anomaly M
is the eccentricity of the Earth's orbit e
is the Sun's mean longitude as given above L
0
being the obliquity of the ecliptic y tan

2
|

\
|
|
.
2
=
Where:
E y sin 2L
0
( ) 2 e sin M ( ) 4 e y sin M ( ) cos 2L
0
( ) +
1
2
y
2
sin 4L
0
( )
5
4
e
2
sin 2M ( ) =
The somewhat less accurate method that Meeus gives uses the following formula:
The value of is the apparent right ascention of the Sun, and a full treatment should take into account the effects
of aberration and nutation. is nutation in longitude, and the obliquity of the ecliptic.
Where is the time in Julian millenia (365250 ephemeris days) from J2000.0
L
0
280.4664567 360007.6982779 + 0.03032028
2
+

3
49931
+

4
15299

5
1988000
=
Here E is given in degrees, which is easily converted into minutes by multiplying it by four. In the formula, L
0
is
the Sun's mean longitude. This could be calculated using the full VSOP87 Theory (and its several hundred series
terms), or more reasonably for our purposes, by way of a truncated series that'll do just fine. This series is:
calculating each of the terms to high accuracy is not a simple matter.
E L
0
0.0057183 cos ( ) + =
The Equation of Time (ET) depends upon several factors that vary as the Earth's orbit varies over time. Meeus
provides several approaches to calculating the Equation of Time by way of series approximations, that is, formulae
based upon time-series approximations of the various factors that contribute to the ET. I selected a method that
was "somewhat less accurate" than the enormously tedious and complex method that does a detailed job of
calculating each contribution at length, for although a single formula serves to express how these factors combine
to give the ET:
While tinkering with the Equation of Time for the article "Jack and the Equation of Time", I wanted to have a
reference curve to with which to judge the simulated results. I turned to the book "Astronomical Algorithms" by
Jean Meeus to put together a BASIC program to provide the needed values. Since this program might be of intrest
to some readers (especially Dialers, i.e. makers of sundials), I present it here. As a bonus, the program also
includes a function that returns the Julian day for a given calendar date.
Calculation of the Equation of Time
by Greg Neill
6 The Orrery #37, September 2000
One thing to make sure of is that L
0
and M are both reduced to positive values less than 360 degrees by adding or
subtracting a convenient multiple of 360 degrees. I accomplish this with the BASIC MOD function and a test for
the sign of the result.
The full program, called EQTIME, is given at the end of the article. The program asks for a date in calendar format
(Day,Month,Year) and then spits out the corresponding Julian Day and the value of the Equation of Time in
minutes and seconds. The nasty part of the calculations are contained in the function EQT which returns the
Equation of Time for a given Julian Day. The Julian Day is provided by function JD. Here are a few test values to
try if you're inclined to miss decimal points and leading zeros (like I do) when you type in the code:
Date Julian Day
July 30, -3000 625518.5 +4' 23.4''
December 25, 1600 2305806.5 -1' 1.4''
March 9, 1957 2435906.5 -11' 13.8''
November 3, 2000 2451851.5 +16' 28.2''
August 5, 2200 2524809.5 -7' 34.1''
Eq. Of Time
With these functions in hand, it's a simple matter to create a loop to march through the Julian days for a given
year and produce a graph of the Equation of Time for that year. Below are a few examples that I produced in this
fashion. Meeus notes that in the year A.D. 1246, when the Sun's perigee coincided with the winter solstice, the
curve was exactly symmetrical with repect to the zero-line; the minimum of February was exactly as deep as the
height of the November maximum, and the smaller May maximum was exactly as high as the value of the July
minimum. This graph is included below. Because of the truncated series used in the calculation of the terms of
the results, I wouldn't put too much faith in the exact values given for dates more than + or - 1000 years from the
present.
20
10
0
10
20
Year 2000
Month (1 to 12)
E
T
(
M
i
n
u
t
r
e
s
)
20
10
0
10
20
Year -1000
Month (1 to 12)
E
T
(
M
i
n
u
t
r
e
s
)
20
10
0
10
20
Year 1000
Month (1 to 12)
E
T
(
M
i
n
u
t
r
e
s
)
20
10
0
10
20
Year 1246
Month (1 to 12)
E
T
(
M
i
n
u
t
r
e
s
)
20
10
0
10
20
Year 3000
Month (1 to 12)
E
T
(
M
i
n
u
t
r
e
s
)
20
10
0
10
20
Year 4000
Month (1 to 12)
E
T
(
M
i
n
u
t
r
e
s
)
7 The Orrery #37, September 2000
' Program EQTIME
' Author: G. Neill November 2000
' Calculates the Equation of Time given a calendar date.
DEFDBL A-Z
Input "Enter the Date (D,M,Y)";D,M,Y
J = JD(D,M,Y) 'Calculate the Julian Day
ET = EQT(J) 'Calculate the Equation of Time
MM = int(ET) 'Minutes
S = (ET - MM)*60 'Seconds
print using "Equation of Time for JD #######.# +##' ##.#''";J,MM,S
END
Function EQT(JDE)
' Returns the Equation of Time in Minutes for a given Julian Day
' Based upon Chapter 27 of "Astronomical Algorithms" by Jean Meeus
Deg = 3.1415926535/180
T1 = (JDE - 2451545.0)/36525 'Julian Centuries from J2000.0
T2 = T1/10
'Calculate Sun's mean longitude
L0 = 280.4664567 + 360007.6982779*T2 + 0.03032028*T2^2
L0 = L0 + T2^3/49931 - T2^4/15299 - T2^5/1988000
L0 = L0 mod 360 : if L0 < 0 then L0 = L0 + 360
'Calculate the Obliquity of the Ecliptic
E0 = 23 + 26/60 + (21.448 - 46.8150*T1 - 0.00059*T1^2 + 0.001813*T1^3)/3600
'Calculate the Eccentricity of the Earth's Orbit
E = 0.016708617 - 0.000042037*T1 - 0.0000001236*T1^2
'Calculate the Sun's Mean Anomaly
M = 357.52910 + 35999.05030*T1 - 0.0001559*T1^2 - 0.00000048*T1^3
M = M mod 360 : if M < 0 then M = M + 360
y = TAN(E0*Deg/2)^2
S = y*SIN(2*L0*Deg) - 2*E*SIN(M*Deg)
S = S + 4*E*y*SIN(M*Deg)*COS(2*L0*Deg)
S = S - y^2*SIN(4*L0*Deg)/2 - E^2*SIN(2*M*Deg)*5/4
EQT = S/Deg*4
End Function
Function JD(D,M,Y)
' Returns the Julian Day for a given Day Month Year.
' Checks for illegal dates
'
' First validate the date
Disc = 10000*Y + 100*M + D
if (Disc > 15821004 and Disc < 15821015) or Y = 0 then
print "** JD - Error - Illegal Date supplied **"
end
end if
if M < 3 then Y = Y-1 : M = M+12
if Disc > 15821014 then
A = int(Y/100) : B = 2 - A + int(A/4)
else
B = 0
end if
JD = int(365.25*(Y+4716)) + int(30.6001*(M+1)) + D + B - 1524.5
End function
8 The Orrery #37, September 2000
or, combining the denominators,
V
x
V
x
M
1
x
2
y
2
+
DT
x
x
2
y
2
+
=
where we recognize the term M
1
/R
12
2
as the acceleration caused by body 1 on body 2. The term (X
2
- X
1
)/R
12

extracts the component of the acceleration in the X-direction, and DT is the time step size. With a slight change
in terminology, we write x for (X
2
- X
1
) and y for (Y
2
- Y
1
), and expand R
12
accordingly to get:
...(4) V
x
V
x
M
1
R
12
2
DT
X
2
X
1
( )
R
12
=
In practice we apply the above steps to the X and Y components of the velocity and position separately. These
two formulas are pretty straightforward, and the acceleration that we feed into the first one comes from the
derivation above. What we get for the velocity calculation for the X component is:
Relating the new position to the old position and the velocity over the
timestep.
s
i 1 +
s
i
v t + = and
Relating the new velocity to the old velocity and the acceleration over the
timestep t.
v
i 1 +
v
i
a t + =
In the Leapfrog algorithm, at each timestep we calculate the new positions by first determining the velocity from
the current velocity, the acceleration, and the size of the timestep. This is based upon some standard equations
of motion:
That gives us the magnitude of the acceleration. The direction is obviously along the line connecting the centers of
the masses and will be towards the attracting mass, in this case M
1
.
...(3) A
12
M
1
R
12
2
= Setting G = 1 gives: A
12
G
M
1
R
12
2
=
and since F=MA, the acceleration experienced by M
2
due to M
1
is:
F G
M
1
M
2

R
12
2
=
...(2)
The resulting gravitational force between them is:
R
12
X
2
X
1
( )
2
Y
2
Y
1
( )
2
+ =
...(1)
We can recap the process for the two body case. Assume we have two masses M
1
and M
2
at locations [X
1
,Y
1
]
and [X
2
,Y
2
]. The distance between the two masses is given by the Pythagorean distance formula:
When we set out to simulate orbits with our simple Leapfrog algorithm we have typically started with the basic
Newtonian form of gravitational attraction between point masses and then applied a couple of Newton's laws based
formulas to find the acceleration and velocity during a time step to update the position of each mass. By repeating
this over and over for sufficiently small time steps, the motion of all the mass points can be "integrated" and their
trajectories approximated.
Potential Problems - Galactic Orbits
by Greg Neill
9 The Orrery #37, September 2000
We can immediately recognize these as the acceleration terms that we use in the Leapfrog algorithm. So, given
the potential function of a field, we're in a position to calculate the acceleration due to that field at any point.
...(7)
a
y
y

\
|
|
.
=

x
2
y
2
+
( )
1.5
y = a
x
x

\
|
|
.
=

x
2
y
2
+
( )
1.5
x =
Applying the operator, which is really just a pair of partial derivatives in rectangular coordinates, one with respect
to x and one with respect to y, we have:
...(6) assuming that the mass is located at the origin.

x
2
y
2
+
=
Converting to our usual rectangular components we have:
where ( ) is mathematical shorthand for the operation
x

,
|

\
|
|
.
.
a = -( )
The acceleration is extracted from the potential by applying the DEL operator from calculus, usually written as a
large, bold, upside down Greek Delta. That is,

r
=
where is the gravitational parameter, GM, and r is the distance as usual. We usually
choose G = 1 to simplify things, so will be numerically equal to the mass of the
attracting body.
Introducing the Potential Function
We can look at this in terms of a potential function, , which describes the gravitational potential filling the
surrounding space by the gravitating mass. For the point mass case the potential function is:
The whole enterprise of the simulation rests on being able to find the net acceleration on a given body at each
timestep. Is there another way to arrive at the acceleration without resorting to an examination of N-1 bodies at
each iteration? You bet.
Fig 1. The "business" part of the Leapfrog algorithm that
pushes the particles around. In this instance, a two-body
system is being modeled. The distance R1 is calculated
first and is cubed in preparation for use in the next step,
which is the velocity determination via the acceleration
over a small time interval DT. Finally, the position is
updated using this velocity.
480 'Do the orbit calc
490 REM r1 is distance from 1 to 2 cubed
500 R1 = ((X(1) - X(2)) ^ 2 + (Y(1) - Y(2)) ^ 2) ^ 1.5
580 REM do the velocities
590 'Save some divisions by combining DT with R's
600 DTR1 = DT / R1
630 VX(2) = VX(2) - (X(2) - X(1)) * DTR1 * M(1)
640 VY(2) = VY(2) - (Y(2) - Y(1)) * DTR1 * M(1)
680 X(2) = X(2) + VX(2) * DT
690 Y(2) = Y(2) + VY(2) * DT
This is the form that we usually see it in the BASIC routine. You can spot them as lines 630 and 640 in figure 1,
and the update of the positions in lines 680 and 690.
...(5b) V
y
V
y
M
1
x
2
y
2
+
( )
1.5
y DT =
The equivalent expression for the Y component of the velocity is:
...(5a)
V
x
V
x
M
1
x
2
y
2
+
( )
1.5
y DT =
10 The Orrery #37, September 2000
Some models are built from the ground up by layering shells of varying densities. These shells can take on
spherical shape, or be oblate in some fashion (fig. 2). The triaxial generalization of a thin spherical shell is called
a homoeoid. Each homoeoid is a shell of constant density, and if the geometry of the shells is chosen
In terms of the mass distributions that these models represent, the Plummer density profile exhibits a finite
density core and falls off as r
-5
at large radii. This is a steeper falloff than is generally seen in real galaxies. The
Hernquist and Jaffe models on the other hand decline as r
-4
at large radii. This power law has justification from
sound theoretical arguments, so these models are often seen in the literature.
r ( )
G M
a
ln
a
r a +
|

\
|
|
.
= Jaffe potential:
r ( )
G M
r a +
= Hernquist potential:
Plummer potential:
r ( )
G M
r
2
a
2
+
=
r
c
is the radius of a central 'core',
q is a 'flattening' factor for the potential in the
Y-axis direction. q 1.
x y , ( )
1
2
v
0
2
ln r
c
2
x
2
+
y
q
|

\
|
|
.
2
+

(
(

= Log potential:
where:
is the mass density M
3
4 a
3

= r ( ) 2 G a
2 r
2
3

\
|
|
.
r a < if
G
M
r
r a > if
= Uniform Sphere
of mass M and radius a:
For galaxy and star cluster investigations there are lots of different potential function models to be found in the
literature. Some are simple, some are complex. Some lend themselves to simple calculation, or embody
particularly subtle properties. Each has certain strengths and weaknesses, and allow different sorts of mass
distributions to be investigated. What is interesting about them is that any potential that models a reasonably
'lifelike' stellar system turns up the same general categories of orbits for bodies let loose in them. They go by
names like Box Orbits, Tube Orbits, Fish Orbits, and Line Orbits. We should be able to generate examples of all
of them with a little patience. Here are some examples of potential functions:
By making the assumption that the overall distribution of mass is on average static, that is, as the stars move in
their orbits the average density of any given region remains the same (as many stars enter as leave), the whole lot
can be modeled as a continuous distribution of mass that does not change with time. In other words, the overall
shape of the galaxy is presumed to be constant. In this event, a potential function can be concocted to mimic the
mass distribution. Once we have a potential function defined, calculation of the acceleration on a test mass at any
point becomes a matter of evaluating an expression or two, rather than hundreds of thousands of contributions by
individual masses.
Of course, going through these gyrations for each mass in an small N-body simulation would seem to be a waste
of time and effort, particularly as the potential function for each mass would have to be corrected for its location in
space. It's easier just to recognize the Newtonian acceleration and write it down directly in the program, which is
what we've done up to now. Where the method comes into its own is when you want to look at trajectories of a
test mass in a really large collection of masses, say in a galaxy or star cluster. N-body simulations really start to
bog down as the number of particles goes up, but if you can represent the overall collection with a single potential
function the problem becomes tractable even on a small desktop computer.
11 The Orrery #37, September 2000
X
Y
Z
Fig. 2. A mass concentration modeled as a
series of nested oblate shells.
appropriately, then Newton's third theorem applies. You may not be familiar with his third theorem (as opposed to
his third law of motion). It states that a mass that is inside a homoeoid experiences no net gravitational force from
the homoeoid. The familiar case of spherical shells of uniform density is just a special case of this.
Getting Started With Galactic Orbits
To begin tinkering with galactic orbits I took the log potential and applied the DEL operator on it to extract the
equations for the acceleration. I decided to stick to 2-D investigations to keep things simple for now. The
resulting formulae are:
Ax
x
r
c
2
x
2
+
y
2
q
2
+
|

\
|
|
|
.
= Ay
y
q
2
r
c
2
x
2
+
y
2
q
2
+
|

\
|
|
|
.

= ...(6)
where I've set the v
o
parameter in the potential to 1 for convenience. The term in brackets in the denominator is
common to both expressions, so a single calculation of it per iteration will save some simulation time.
I took our venerable Leapfrog algorithm program and modified it to handle the new approach and set about playing
with the parameters until I began to get the sort of results that are worth writing about. In hindsight, I could have
just consulted 'the manual' for a good starting point, Galactic Dynamics by Binney and Tremaine, but sometimes
doing is more instructive than just looking it up. In the end I settled for rc = 0.1 and q = 0.5. I found that a whole
range of orbit morphologies could then be generated by choosing various starting values for position and velocity.
The program is set up to run a 'hard coded' sample orbit which is described at line 190. If you'd rather go
interactive, comment out this line and line 150. Then the program will ask the user to enter the model parameters
and the initial position and velocity of the 'star' to be tracked. You will note that I've also included, in
commented-out form, a few other starting points that I found interesting.
I should point out that our simulation method is not too accurate over a great many iterations for some trajectories.
Some of the orbits exhibit a great range of speeds and sharp curves along their trajectories, and since our
simulator employs a fixed timestep the inaccuracies eventually creep in. As a result, some orbits which should be
closed and exactly repeating will eventually begin to thicken or spread out after several cycles. To some extent
these effects can be mitigated by decreasing the size of the timestep at the cost of increased simulation time.
But even so, there are limits to what can be done with this simple tool.
I ran the same parameter sets using a variable stepsize fourth order Runge-Kutta routine (built into MathCad --
yes, I am incredibly spoiled) which handles the more pathological curves somewhat better, and I present the
results below. These results do not differ significantly from what you will see with the BASIC program. The more
ambitious should find it relatively easy to modify the program described by James Foster in his article,
Applications of the Runge-Kutta Method to Orbit Calculation, in issue #21 of The Orrery.
12 The Orrery #37, September 2000
Y
0
10 = Vy
0
1 =
r
c
0.1 = q 0.5 =
20 0 20
10
0
10
20
Tube Orbit
X-axis
Y
-
a
x
i
s
Parameters: This tube orbit also oscillates only part way
around the galaxy, but incorporates some
interesting loops in the process. Let it go
long enough and it'll fill a U-shaped region
with square "ends"!
X
0
10 = Vx
0
0.2 =
Y
0
10 = Vy
0
0.3 =
r
c
0.1 = q 0.5 =
1 0 1
0.3
0
0.3
Bowtie Box Orbit
X-axis
Y
-
a
x
i
s
Parameters: What can I say? It just looks like a bowtie!
This is an example of a Box Orbit. Let it run
long enough and it will completely fill in the
bowtie shape.
X
0
1 = Vx
0
0 =
Y
0
0 = Vy
0
0.5 =
r
c
0.1 = q 0.5 =
10 0 10
10
0
10
"Fish" Orbit
X-axis
Y
-
a
x
i
s
Parameters: This is an example of a line orbit whose
profile resembles that of a fish. The star
traces the same path endlessly. X
0
10 = Vx
0
0 =
Y
0
0 = Vy
0
1.15 =
r
c
0.1 = q 0.5 =
20 10 0 10 20
5
0
5
Loop Orbit
X-Axis
Y
-
A
x
i
s
Parameters: Again, the path traced is closed with the same
loops being repeated endlessly.
X
0
10 = Vx
0
0 =
Y
0
0 = Vy
0
0.5 =
r
c
0.1 = q 0.5 =
50 0 50
40
20
0
20
Line Orbit 1
X-axis
Y
-
a
x
i
s
An example of a line orbit that oscillates only
part way around the galaxy. It really does
head out to the two extremes and then retrace
its path back to the loop.
Parameters:
X
0
10 = Vx
0
1 =
13 The Orrery #37, September 2000
10 REM PROGRAM POTENT1
20 KEY OFF
30 DEFDBL A-Z
40 'Original program by G. Neill October 2000
50 'Simulates orbits in a logarithmic potential field
60 SR = 5 / 7 'Screen aspect ratio
70 X0 = 320 'X-axis origin
80 Y0 = 175 'Y-axis origin
90 'PRINT "Orbits in the Logarithmic Potential"
100'INPUT "Core radius: ";RC
110'INPUT "Flattening parameter (<=1): ";Q
120'INPUT "X0,VX0: ";X,VX
130'INPUT "Y0,VY0: ";Y,VY
140'INPUT "DT,Scale: ";DT,SC
150 RC = 0.1 : Q = 0.5
160 'X = 10 : Y = 0 : VX = 0: VY = 1.15 : SC= 10 : DT = .0005 ' Fish Orbit
170 'X = 10 : Y = 0 : VX = 0: VY = 0.5 : SC = 15 : DT = .0005 ' Loop Orbit
180 'X = 10 : Y = 10 : VX = -1 : VY = 1 : SC = 5 : DT = .0005 ' Line Orbit 1
190 'X = 1: Y = 0 : VX = 0 : VY = 0.5 : SC = 200 : DT = .00005 ' Bowtie Orbit
200 X = 10:Y = 10:VX = -0.2:VY = -0.3 : SC = 10 : DT = .0005 ' Tube Orbit
210 RC2 = RC*RC : Q2 = Q*Q ' Precalculate these to save time
220 SCREEN 9
230 CLS
240 PRINT "Galactic Orbits in a Logarithmic Potential"
250 PRINT USING "Rc = ##.## q = ##.##"; RC,Q
260 PRINT USING "X0 = ###.## VX0 = ###.##"; X,VX
270 PRINT USING "Y0 = ###.## VY0 = ###.##"; Y,VY
280 PRINT USING "DT = #.##### Image Scale = ####"; DT,SC
290 LOCATE 25,1 : PRINT "Press 'Q' to stop!"
300 LINE (0, Y0)-(600, Y0)
310 LINE (X0,Y0+150)-(X0,Y0-150)
320
330 MainLoop:
340 'Start of main loop.
350 if inkey$ = "Q" then end
360 REM Place a point on the trajectory
370 PSET (X0 + X*SC, Y0 - Y * SC*SR), 2
380 'Do the orbit calc
390 D = RC2 + X*X + Y*Y/Q2
400 Ax = -X/D : Ay = -Y/D/Q2
410 REM do the velocities
420 VX = VX + Ax*DT
430 VY = VY + Ay*DT
440 REM do the positions
450 X = X + VX * DT
460 Y = Y + VY * DT
470 GOTO MainLoop
480 END
Note: To enter parameters interactively,
comment out lines 150 through 200 and
un-comment lines 90 through 140. To
explore the sample trajectories provided,
either enter their parameters interactively or
choose one of the selections in lines 160
through 200.
*********************************************************************************************************
Orbits With Excel
By Greg Neill
The other day at work I was tinkering with an Excel spreadsheet for generating expense reports. I had recently
returned from yet another business trip to parts foreign (well, Dallas is foreign to me) and after many years of doing
these reports by hand, I finally decided to have a go at using a spreadsheet that one of my coworkers had put
together for the purpose. The first thing I noticed was that it didn't handle foreign currency conversions in the
manner to which I had become accustomed, and further, it could handle just one currency conversion at a time.
Since my trips often involve stops in two or three different countries, this automated method would prove
bothersome. No problem, I thought, I'll just add a few columns for currency flags, enter a table of conversion rates,
and adjust the summation formulae at the column bottoms accordingly. Ha! Not so simple, it turned out. The
built-in functions and summation routines were just not up to handling multiple conditions in any straightforward
way that I could work out with my rather limited knowledge of the product. I'd have to 'code around' the problem.
14 The Orrery #37, September 2000
Turning to the Big Fat Excel manual [ref. 1], I discovered the wonderful world of Excel Macros. To my delight I
found that the language which Excel implements its macros is a dialect of BASIC, VBScript (or VBA), a subset of
Visual Basic to be precise. Not only that, but the user can write these macros directly with the built-in
development environment that comes bundled with Excel. As I set about writing the required routines, the thought
struck me that it should be possible to do something nifty for The Orrery with this newfound knowledge. After all,
readers who don't have a copy of QuickBASIC or PowerBASIC on their machines might just have Microsoft's Excel
installed. It also brought to mind the article in the March 2000 issue of Sky & Telescope which suggested turning
to Java or ECMAScript languages which are bundled in WEB browsers.
As a trial effort, I decided to try our venerable Leapfrog algorithm for orbit simulation. To keep things manageable,
not to mention presentable, I used the Excel spreadsheet only for setup of the initial conditions and for display of
the results, all the orbit calculations are handled by the VB macro Integrate_Orbit (see the code at the end of
this article). This routine plucks the initial conditions out of the cells in Sheet1 of the Excel Workbook, and writes
the integrated orbit positions to Sheet2 where they can be admired as numbers, or if you're like me, used to
generate a graphical summary which is even more pleasing to the eye.
There are a few tricky bits to get through to make the whole thing happen. First, there's getting the VB
environment going in Excel. This can be done by selecting Tools/Macro/Visual Basic Editor from the tool bar, or
by pressing Alt+F11. Then you need to create a code module for the VBAProject that the VB editor application
shows you. A really easy way to go about this is to have Excel generate a macro for you to "prime the pump" so
to speak. Just use the "record macro" feature from the Excel toolbar to record a few manipulations. A simple cut
and paste of a cell will suffice. Once done, you should note that module1 has appeared in the VB application
project list. Click on it and the resulting code for macro1 will appear as a VB subroutine, i.e., Sub Macro1().
You can leave macro1 alone and add a new subroutine, or rename it and gut its interior to make way for your own
code. This is just a matter of editing.
The parts of macro code that may be unfamiliar to us traditional BASIC programmers are the bits that access the
Excel spreadsheets. We need a way to read the contents of cells from the spreadsheets and write results back.
I've chosen to use the "Range" and "Cells" constructs that the language provides for this. Range is handy
because you can assign names to specific cells in your spreadsheet and then reference them by these names
from the macro using Range. If you tinker with the spreadsheet layout, the names will follow the moved cells so
that you don't have to go back and modify the macro code. The Cells method writes to absolute cell locations,
which I found adequate for writing back the results to a second spreadsheet, "Sheets(2)". This keeps the data
entry spreadsheet clean, and leaves room for the graphical output. I assigned a keyboard shortcut (<ctrl><shift>I)
to the macro so that a single keyboard operation could invoke the orbit integration after changing the inputs. This
was done from the Tools/Macros/Macros.../Options menu.
I did put one calculation on sheet1. From the Steps and Stride entries, I calculate the Points value, which is the
number of data points that the macro will return. The graphical chart which plots the results uses the value of
Points to determine how many of the data points to display. After performing the orbit integration, you can tinker
with the value of Steps. By selecting a value of Steps less than that used for the integration, you can change the
amount of the available data that is displayed in the plot. This can be handy if the full set of data is complicated to
view due to overlaps. There's no need repeat the integration to view a shorter "run".
One of the nice things about using Excel as a front end to drive the simulation is that it gives you access to all of
the power of its built-in graphing capabilities. No more working with screen coordinates, result scaling, or aspect
ratios! Instead, you have deal with showing the Excel Chart routines where the data is. The bundled Chart Wizard
can help, but getting it to update the results automatically with changing amounts of result data is another matter.
The chart type I selected was "XY Scatter with data points connected by smoothed lines without markers",
available as a standard selection from the Chart wizard. There are quite a few chart types to choose from,
including surface plots (which might come in handy in the future), but the scatter plot fit the bill nicely.
15 The Orrery #37, September 2000
Body Mass X0 Y0 VX0 VY0
1 100.00 0.00 0.00 0.00 0.00
2 10.00 100.00 0.00 0.00 1.00
DT 0.01 Time step size
Steps 45000 Number of time steps
Stride 250 Report every Stride 'th point
Points 180 Number of points returned
Note: Press <ctrl><shift>I to invoke simulation
Initial Conditions
A Simulated Two-Body Orbit
-100
-50
0
50
100
-100 -50 0 50 100
X-Position
Y
-
P
o
s
i
t
i
o
n
Body 1
Body 2
Figure 1. The Excel Spreadsheet "front end" with the initial condition entries and the plot of the results. Note that only a partial
orbit of the system is displayed. Initially, some 60000 steps were integrated, giving more than a complete orbital cycle. The value
of "Steps" was then reduced to 45000 as shown to display the partial orbit.
Getting the chart to automatically adjust for varying amounts of data involved two steps. First, I created four Excel
name definitions to define the data Series expressions for the chart's XY source data fields. One each for the X
and Y data fields of the two plot lines. These expressions were:
X1dat =OFFSET(Sheet2!$A$1,0,0,Points+1,1)
X2dat =OFFSET(Sheet2!$C$1,0,0,Points+1,1)
Y1dat =OFFSET(Sheet2!$B$1,0,0,Points+1,1)
Y2dat =OFFSET(Sheet2!$D$1,0,0,Points+1,1)
They are entered using the Insert/Name/Define mechanism available from the Excel toolbar. I also used the
same toolbar to create the names for the initial condition data cells that the macro picks up. Note that these
expressions refer to the Points value. That's how the automatic adjustment for the amount of data happens. In
the Chart's source data Series fields, I used these names in place of absolute cell references. The names need to
be qualified by the file they're in (in this case I called my Excel program "[Link]"), so the entries look like:
16 The Orrery #37, September 2000
[Link]!X2dat
[Link]!X1dat
[Link]!Y1dat
[Link]!Y2dat
It took me quite a bit of tinkering until I finally resorted to the Fat Manual to uncover this trick. The resulting
flexibility was worth the effort.
Despite being an interpreted version of BASIC, I found that the simulation runs fairly quickly. The 60,000 iterations
to produce a more than complete orbit at a timestep size of 0.01 took under two seconds on my machine (233
MHZ Pentium II).
I would like to hear from readers who think that this approach (using Excel for coding programs for The Orrery) is
worthwhile. Do more people have Excel than a stand-alone version of BASIC?
References:
[1] Microsoft Excel 2000 Bible by John Walkenbach, IDG Books Worldwide, Inc. ISBN 0-7645-3449-1
Sub Integrate_Orbit()
' Implements a simple Leapfrog algorithm to integrate
' the orbits of a two-body system.
' Original: G. Neill November 2000
'
'Declare our variables
Dim DT As Single ' The timestep size
Dim Steps As Long ' The number of integration steps
Dim R As Long ' A Row number for output
Dim Stride As Integer ' Report every stride steps
Dim M1 As Double ' Mass of first body
Dim M2 As Double ' Mass of second body
Dim X1 As Double ' X-Position of first body
Dim X2 As Double ' X-Position of second body
Dim Y1 As Double ' Y-Position of first body
Dim Y2 As Double ' Y-Position of second body
Dim VX1 As Double ' X-Velocity of first body
Dim VX2 As Double ' X-Velocity of second body
Dim VY1 As Double ' Y-Velocity of first body
Dim VY2 As Double ' Y-Velocity of second body
Dim RP As Double ' Distance ^ 3/2
Dim DTRP As Double ' DT/RP to save time
Dim TX As Double ' X-Velocity of C.O.M.
Dim TY As Double ' Y-Velocity of C.O.M.
Dim Mtotal As Double ' Total mass of system
Dim i As Long, k1 As Integer
'
' Extract the required data from the Excel sheet
DT = Range("DT")
Steps = Range("Steps")
Stride = Range("Stride")
M1 = Range("Mass1")
M2 = Range("Mass2")
X1 = Range("PX1"): Y1 = Range("PY1")
X2 = Range("PX2"): Y2 = Range("PY2")
VX1 = Range("VX1"): VY1 = Range("VY1")
VX2 = Range("VX2"): VY2 = Range("VY2")
'
' Fix Center of Mass
Mtotal = M1 + M2
TX = (M1 * VX1 + M2 * VX2) / Mtotal
TY = (M1 * VY1 + M2 * VY2) / Mtotal
VX1 = VX1 - TX: VY1 = VY1 - TY
VX2 = VX2 - TX: VY2 = VY2 - TY
DX = (M1 * X1 + M2 * X2) / Mtotal
DY = (M1 * Y1 + M2 * Y2) / Mtotal
X1 = X1 - DX: Y1 = Y1 - DY
X2 = X2 - DX: Y2 = Y2 - DY
'
' Clear the result area, place initial values
Sheets(2).[Link]
R = 1 ' First row of output
Call LineOut(R, X1, Y1, X2, Y2)
'
' Integrate the Orbit.
k1 = Stride
For i = 1 To Steps
DX = (X2 - X1): DY = (Y2 - Y1)
RP = (DX * DX + DY * DY) ^ 1.5
' Calculate New Velocities
DTRP = DT / RP
VX1 = VX1 + M2 * DX * DTRP
VY1 = VY1 + M2 * DY * DTRP
VX2 = VX2 - M1 * DX * DTRP
VY2 = VY2 - M1 * DY * DTRP
' Calculate New Positions
X1 = X1 + VX1 * DT: Y1 = Y1 + VY1 * DT
X2 = X2 + VX2 * DT: Y2 = Y2 + VY2 * DT
' See if we should return a point
k1 = k1 - 1 ' Stride countdown
If k1 <= 0 Then
R = R + 1 ' Next output row
Call LineOut(R, X1, Y1, X2, Y2)
k1 = Stride ' Reset the stride count
End If
Next i
End Sub
Sub LineOut(R, X1, Y1, X2, Y2)
' Places a line of result values (X,Y positions of the
' orbing bodies)on Sheet 2 of the Excel workbook.
' Original: G. Neill November 2000
'
' Entry: R = The row number to write (assumes
' a starting row of 1)
' X1,Y1 = The XY coordinates of body 1
' X2,Y2 = The XY coordinates of body 2
'
' Places the results on line R, columns 1 to 4
'
Sheets(2).Cells(R, 1) = X1
Sheets(2).Cells(R, 2) = Y1
Sheets(2).Cells(R, 3) = X2
Sheets(2).Cells(R, 4) = Y2
End Sub
Note: I will e-mail a copy of the Excel speadsheet to
anyone who requests it.
17 The Orrery #37, September 2000
Corrections:
On page 16 of issue #36, in the article Tools of the Trade - Integration by Simpson's Rule, I inadvertently made an
error in the integration of the example. The correct sequence of equations should be:
f x ( ) x
3
7 + =
a
b
x f x ( )
(
(
]
d
1
4
b
4
7 b
1
4
a
4
7 a +
********************************************************************************************************
Time to Renew?
You'll find a number next to your name on the mailing label that got this issue to your abode. This number
represents your last paid issue. I've also placed a small checkbox in the newsletter banner on the first page. If
this box contains a check mark, you're subscription is perilously close to expiring. If you wish to see that more
issues find their way to you, you may wish to visit the section below....
********************************************************************************************************
Subscriptions:
The Orrery is published approximately six times a year. The cost, in Canadian dollars, is $15 per year in North
America and $27 overseas. (U.S. Subscribers: I will accept U.S. dollar cheques in the amount of $10 U.S.)
Please make cheques payable to Greg Neill. Send your subscription request and payment to:
Greg Neill / 4541 Anderson / Pierrefonds, Quebec / Canada H9A 2W6
*********************************************************************************************************
[Your Name Here!]
I am on the lookout for articles, programs, letters, questions, book reviews, or anything else that might be of
interest to readers of The Orrery. If you have such a beast or even an idea for one that needs fleshing out, drop
me a line. Naturally, I cannot promise to publish everything that's sent in. The three general guidelines that will
continue to apply are: I have to be able to understand it, it should be of interest to our readership, and it should
bear some relation to astronomy. This has worked in the past, and there's no reason to change it now.
Submission via e-mail is encouraged, but not mandatory by any means; if your article is scribbled on a napkin it
won't necessarily be turned away... but please use clean napkins.

Send submissions to:
Greg Neill / 4541 Anderson / Pierrefonds, Quebec / Canada H9A 2W6
e-mail: gneill@[Link]
18 The Orrery #37, September 2000