HomeUpSearchMail
NEW

Planetarium programs

Introduction

In archaeoastronomy a possible accuracy of 0.5° is expected for monuments build around 4000 BCE. On this web page I try to determine the accuracy achievable with computer programs that simulate the celestial events. The accuracy of these programs should at least be around one order better than the presumed accuracy of the monuments; so the accuracy must be much smaller than 30'.

This page will provide some insight on who to make a choice in planetarium computer programs. This will be done along the following lines:

The specification

A few features are important when looking at programs for archaeoastronomical work. The following features should be taken into account when deciding to use a program (in order of preference):
    1. celestial objects
    2. In any program (demo, share or free-ware) all planets, objects and stars which are visible with the naked eyed need to be available. Including an outline of the milky way and the horizon
    3. it should included all 'normal' theories of calculations
    4. Such as: position (VSOP87, DE405, etc.), aberration, perturbations, precession (Simon, J.L. [1994]), DT (Stephenson, etc.), nutation, change of obliquity, lunar motion (n-dot, ELP2000-85, etc.), proper motion (Hipparcos and Tycho catalogues), light travel time, refraction, horizon dip, etc. etc.
    5. has to have an accuracy of much smaller than 60' for azimuth and altitude between 4000 BCE and 2100 CE. This specification has to be relaxed perhaps for the moon.
    6. provide an inaccuracy range in every display, based on for instance Monte Carlo Analysis
    7. the possibility to step in time using different periods; like average solar periods (hours, days, sidereal day, tropical year, etc.) and average lunar periods (like draconic, synodic, nodal cycle, etc.).
    8. has to have an automatic date/time increase/decrease repeat.
    9. the possibility to define a sky window and determine when a celestial object passes along this window.
    10. information on and changing the actual DT used by the calculations.
    11. provide visibility (incl. e.g. extinction angle) of celestial objects in the sky (depending on twilight conditions).
    12. integrate it in a virtual world with whole sky display usable in VRML and QuickTime
    13. Beside the above mentioned analythical theories in bullet 2), it is important to know which numerical model has been used in the implementation. The numerical method must have been mapped a well as possible for the period 4000 BCE to 2100 CE (validity period).
I am using at this moment the following programs: If people know of other (better) programs for archaeoastronomy, let me know.

The theories and their accuracy

All topics discussed in the following sections don't look at implementations, it centres on the accuracies that can be obtained from these theories. I assume implementations (programs) exist that will implement these theories without errors/bugs. Benchmarking of programs should check this.
I have the following list on accuracies (see what inaccuracies means for local circumstances (like altitude/azimuth)):
Because the DT formula's have common basis of eclipse data, the above values in some way will flatten the inaccuracy prediction!
The accuracy of DT (DDT) is around 4000 BCE some ± 250 [min], around 3000 BCE: ± 150 [min] and around 480 CE: ± 10 [min]. This accuracy is determine by half the spread between min. and max. calculated values from above formula, which results into a somewhat higher value than the sigma of calculated values.
In some literature (Bretagnon [1986], page 5) the accuracy of DT (DDT) is quoted around 4000 BCE at some ± 120 [min] (interpolated this gives some 85 [min] in 3000 BCE and 10 [min] in 484 CE).
Uncertainty values of Stephenson and Houlden (1986) are also quoted here.
In my following evaluations, I take the maximum of these two methods; so I use the values of half the spread of calculated values. Comments to this choice? Let me know.
The Hipparcos- and Tycho catalogue have a location inaccuracy due to proper motion of resp. around 15" and 180" in declination (Dds) and RA (Das) for times at 4000 BCE (based on information from Michael Perryman, ESA, Pers. Comm.  [2002]). Be aware that this inaccuracy increases for fast-moving/close-by stars (sections 1.2, 1.5 and table 1.2.3).

Accuracy determination in azimuth and altitude

Using Napier's rules, VSOP82, Monte Carlo analysis (some 2100 runs), geographical latitude of 52° and without taking into account DT and refraction (in case of altitude).
Values in bold are not reaching the specified accuracy range of much smaller than 1800".

For planets

Ddx = arctan(cos(e+De)/tan(90-Dlx))
This gives the following Ddx for the Sun, Mercury, Mars and the Moon around 4000 BCE: 4", 12", 36" and 707"
Error on HA (Hour Angle):
Dax = asin(sin(e+De)*sin(Dlx))
(DHAx)2= (Dax)2+ (Dlsun)2
This gives the following DHAx for the Sun, Mercury, Mars and the Moon around 4000 BCE: 7", 7", 17" and 316"

Using this we determine Dazix and Daltx (Duffett-Smith [1988], page 36):

altx+Daltx=asin(sin(dx+Ddx+Press.+DPress.)*sin(f)+cos(dx+Ddx+Press.+DPress.)*cos(f)*cos(HAx+DHAx))
f = geographical latitude
azix + Dazix=acos((sin(dx+Ddx+Press.+DPress.)-sin(f)*sin(altx +Daltx))/cos(f)/cos(altx +Daltx))
The errors in azimuth and altitude vary of course due to actual values of declination (dx) and hour angle (HAx). When using Monte Carlo analysis, the maximum errors found in azimuth and altitude are around the same value as the Dlx.
So this gives the following Daltx and Dazix for the Sun, Mercury, Mars and the Moon around 4000 BCE: 10", 14", 40" and 800"

For stars

Dazis = (see above depending on ds, Dds, as, Das)
Dalts = (see above depending on ds, Dds, as, Das)
The errors in azimuth and altitude vary of course due to actual values of declination (ds) and hour angle (HAs). When using Monte Carlo analysis, the errors found in azimuth and altitude are some 2-3 times bigger than the Dds.
So this gives the following Dalts and Dazis for stars from Hypparcos and Tycos catelogue around 4000 BCE: 35" and 450" (the error can be bigger, like when AH=0 and the declination has the same value as the geographical latitude).

Accuracy's of occultation events

Accuracy for set/rise events

Important: In the below section the influence of DT is not included (DT has considerable influence on the time of the set/rise [not much on the azimuth], but this is left for another time, perhaps I can help you in a personal e-mail: let me know).

The error in the azimuth near the horizon is mainly determined by parallax and refraction uncertainties (assuming an accurate altitude of the horizon). The variation can be for parallax between 0.9 and 1.0° (Dpar) and for refraction a variation (1s) of 30% of nominal value is assumed (Schaefer [2000], page 126).
Other errors are the error (1s) in declination of the celestial object of 0.20° for The Moon and 0.001° for The Sun (Ddx). Taking latitude at 52°, horizon apparent altitude of 0° and around solstice/standstill limits this gives:
Dazim = 0.56° or Dazis = 0.29° (these values are calculated with Monte Carlo analysis, some 4500 runs)
Around the equinoxes the errors are around Dazim = 0.86° or Dazis = 0.22°

The azimuth error for the Moon and the Sun if the type of set/rise point is not know (top or bottom limb; thus an extra uncertainty (Dsize) between 0° and 0.52°), but no error in declination of celestial object (so actual observation) is:
Dazim = 0.46° or Dazis = 0.38° (these values are calculated with Monte Carlo analysis, some 4500 runs).
Around the equinoxes the errors are around Dazim = 0.82° or Dazis = 0.29°
For solar and lunar alignments, the found errors are of the same order as the 0.5° of Ruggles ([1999], page ix) or Schaefer ([2000], page 126).

Benchmark for archaeoastronomy software

A few things should be important for benchmarking:
  1. determine if a computer program supports the specifications mentioned,
  2. determine which theories are being used in the program,
  3. benchmarking them against a few known celestial events or accepted implemented standard(s) (like tried with JPL Ephemeris?).
At this moment several of these items are done (so looking at solar, lunar and deltaT related issues). Future work will develop this to more aspects of benchmarking (like for instance for star related issues).

Possible benchmarks

The proposed benchmarks are primarily for looking at the implementation of available formula/emphemeris into programming code (so is its more or less about debugging;-):

Total eclipse of January 14th484 CE.

Within the mailing list HASTRO-L (in 1996), software was discussed and some programs were checked against the eclipse of 14 January 484 CE near Athens (38° 0' latitude, 23° 44' longitude). According to literature this should be around that place and time.
Mr. Dearborn made an overview of the results and I (VR) have attached new information obtained since 1996.

A general question asked in any area of research is how dependable (accurate) are your sources (data). In archaeoastronomy, many students depend on commercial software for calculations of events and orientations in the distant past. Even when you are writing your own software, it is a fairly complex process to determine how uncertainties in the approximations of various quantities propagate through a calculation to the answers that you seek. In discussions on the History of Astronomy List server (HASTRO-L), Leigh Palmer, from San Francisco State University, proposed a test for such software. As a test of the long term accuracy; How well it represents the eclipse of 14 January 484 (Julian Calendar)?

A. Fletcher, in Schove's (1984, p. 81) "Chronology of Eclipses and Comets 1 - 1000 AD", quotes from Marinus' Life of the Athenian philosopher Proclus as follows:
"Portents occurred a year before his death, such as the solar eclipse, which was so considerable that night occurred in the daytime. For there was deep darkness and stars were seen. This happened in Capricorn near the rising point (of the Sun)."

Totality is clearly implicit in this, but nothing in what Fletcher actually cites identifies from where the observation of totality was made. Fletcher reports discussion by F.K. Ginzel (1899) and Neugebauer (1931) wherein they "argue respectively for totality at, and only near Athens". He also cites Stephenson and Clark (1978) as saying that "this is probably the most reliable of all solar eclipses reported in the Classics"

Before presenting the results, we wish to reiterate that these programs perform many functions, and that the accuracy of a program in representing a single eclipse is at best suggestive of its ability to represent other eclipses near that epoch. There are sensitive geometric effects for sunrise observers, and there are genuinely poorly known variables (like the correction between ephemeris time and universal time; DT).

Evaluation

In the following list, the reported results are summarized. Because individuals styles are not identical, and there is some variation in exactly what is reported. Robert Oliver, on the performance of Dance 2.71 and Total Eclipse 1.5. Cary James sent results from the DOS based programs, EZCosmos 3.0 and PEEP 1.02 (Planetary Event and Eclipse (Predictor). Richard Johnson sent output from EZCosmos 4.0 and Eclipse Complete 2.0. Jim Fuchs provided input on MyStars!. Peter Jones provided input on Cartes du Ciel. gillies macbain provided input for Voyager. Guus Gilein provided feedback on Guide and Redshift 5. Rob van Gent provided feebback on Redshift 3. Vladimir Pakhomov provided input on SkyChart III. David Herald provided input on winOccult. Sourav Maiti for SwissEph and Eclipse Finder. Victor Reijs composed the rest.

A nice presentation using Google maps can be seen on Espenak's webpage.

The below programs (in alphabetic order) have been tested. Bold printed program names have an eclipse moment of around 5:48 +/- 0:30 (3s) UTC on Jan 14th, 484 (using JPL Ephemeris and error in DT as reference; remember that the precise time is not known from historical accounts!).
A good link on planetarium programs is here (MacOS, MS Windows, DOS, X, Palm, OS/2 WARP).
Let me know if you tested one! Investigating the precision of a tool is fundamental to basic research, and no numerical simulation should be considered to be absolutely accurate. The ground track of eclipses, particularly near the limb of the earth, are sensitively dependent on the precise value of a number of difficult to determine variables. So, it is understandable how a program may do well on one eclipse and not so well on another of the same epoch.

The testing discussed here is a good beginning, but confidence should be based on more that one test. In addition, tests should be collected on events other than eclipses.

Acknowledgments

I would like to thank the following people for their help and constructive feedback: Dan Charrois, David Dearborn, Robert van Gent, Michael Gorodetsky, Steven Hope, Michael Perryman, Thomas Schmidt, Andrew Sinclair, Myles Standish and all the people who provided feedback on specific computer programs. Any remaining errors in methodology or results are my responsibility of course!!! If you want to provide constructive feedback, let me know.

Disclaimer and Copyright
HomeUpSearchMail

Last content related changes: Aug. 23, 2002