moved kdeaccessibility kdeaddons kdeadmin kdeartwork kdebindings kdeedu kdegames...
[kdeedu.git] / kstars / README.planetmath
blob5fd8f6f7b1f20094abc0973efb5ed38a11dd9702
1 README.planetmath:  Understanding Planetary Positions in KStars.
2 copyright 2002 by Jason Harris and the KStars team.
3 This document is licensed under the terms of the GNU Free Documentation License
4 -------------------------------------------------------------------------------
7 0. Introduction: Why are the calculations so complicated?
9 We all learned in school that planets orbit the Sun on simple, beautiful 
10 elliptical orbits.  It turns out this is only true to first order.  It 
11 would be precisely true only if there was only one planet in the Solar System, 
12 and if both the Planet and the Sun were perfect point masses.  In reality, 
13 each planet's orbit is constantly perturbed by the gravity of the other planets
14 and moons.  Since the distances to these other bodies change in a complex way,
15 the orbital perturbations are also complex.  In fact, any time you have more 
16 than two masses interacting through mutual gravitational attraction, it is 
17 *not possible* to find a general analytic solution to their orbital motion.  
18 The best you can do is come up with a numerical model that predicts the orbits 
19 pretty well, but imperfectly.  
22 1. The Theory, Briefly
24 We use the VSOP ("Variations Seculaires des Orbites Planetaires") theory of 
25 planet positions, as outlined in "Astronomical Algorithms", by Jean Meeus.  
26 The theory is essentially a Fourier-like expansion of the coordinates for 
27 a planet as a function of time.  That is, for each planet, the Ecliptic 
28 Longitude, Ecliptic Latitude, and Distance can each be approximated as a sum:
30   Long/Lat/Dist = s(0) + s(1)*T + s(2)*T^2 + s(3)*T^3 + s(4)*T^4 + s(5)*T^5
32 where T is the number of Julian Centuries since J2000.  The s(N) parameters
33 are each themselves a sum:
35   s(N) = SUM_i[ A(N)_i * Cos( B(N)_i + C(N)_i*T ) ]
37 Again, T is the Julian Centuries since J2000.  The A(N)_i, B(N)_i and C(N)_i
38 values are constants, and are unique for each planet.  An s(N) sum can
39 have hundreds of terms, but typically, higher N sums have fewer terms.
40 The A/B/C values are stored for each planet in the files
41 <planetname>.<L/B/R><N>.vsop.  For example, the terms for the s(3) sum
42 that describes the T^3 term for the Longitude of Mars are stored in
43 "mars.L3.vsop".
45 Pluto is a bit different.  In this case, the positional sums describe the
46 Cartesian X, Y, Z coordinates of Pluto (where the Sun is at X,Y,Z=0,0,0).
47 The structure of the sums is a bit different as well.  See KSPluto.cpp
48 (or Astronomical Algorithms) for details.
50 The Moon is also unique, but the general structure, where the coordinates
51 are described by a sum of several sinusoidal series expansions, remains
52 the same.
55 2. The Implementation.
57 The KSplanet class contains a static OrbitDataManager member.  The
58 OrbitDataManager provides for loading and storing the A/B/C constants
59 for each planet.  In KstarsData::slotInitialize(), we simply call
60 loadData() for each planet.  KSPlanet::loadData() calls
61 OrbitDataManager::loadData(QString n), where n is the name of the planet.
63 The A/B/C constants are stored hierarchically:
64  + The A,B,C values for a single term in an s(N) sum are stored in an
65    OrbitData object.
66  + The list of OrbitData objects that compose a single s(N) sum is
67    stored in a QVector (recall, this can have up to hundreds of elements).
68  + The six s(N) sums (s(0) through s(5)) are collected as an array of
69    these QVectors ( typedef QVector<OrbitData> OBArray[6] ).
70  + The OBArrays for the Longitude, Latitude, and Distance are collected
71    in a class called OrbitDataColl.  Thus, OrbitDataColl stores all the
72    numbers needed to describe the position of any planet, given the
73    Julian Day.
74  + The OrbitDataColl objects for each planet are stored in a QDict object
75    called OrbitDataManager.  Since OrbitDataManager is static, each planet can
76    access this single storage location for their positional information.
77    (A QDict is basically a QArray indexed by a string instead of an integer.
78    In this case, the OrbitDataColl elements are indexed by the name of the
79    planets.)
81 Tree view of this hierarchy:
83 OrbitDataManager[QDict]: Stores 9 OrbitDataColl objects, one per planet.
85 +--OrbitDataColl: Contains all three OBArrays (for 
86    Longitude/Latitude/Distance) for a single planet.
87    |
88    +--OBArray[array of 6 QVectors]: the collection of s(N) sums for 
89       the Latitude, Longitude, or Distance.
90       |
91       +--QVector: Each s(N) sum is a QVector of OrbitData objects
92          |
93          +--OrbitData: a single triplet of the constants A/B/C for 
94             one term in an s(N) sum.
96 To determine the instantaneous position of a planet, the planet calls its
97 findPosition() function.  This first calls calcEcliptic(double T), which
98 does the calculation outlined above: it computes the s(N) sums to determine
99 the Heliocentric Ecliptic Longitude, Ecliptic Latitude, and Distance to the
100 planet.  findPosition() then transforms from heliocentric to geocentric
101 coordinates, using a KSPlanet object passed as an argument representing the
102 Earth.  Then the ecliptic coordinates are transformed to equatorial
103 coordinates (RA,Dec).  Finally, the coordinates are corrected for the
104 effects of nutation, aberration, and figure-of-the-Earth.  Figure-of-the-Earth 
105 just means correcting for the fact that the observer is not at the center of 
106 the Earth, rather they are on some point on the Earth's surface, some 6000 km
107 from the center.  This results in a small parallactic displacement of the 
108 planet's coordinates compared to its geocentric position.  In most cases, 
109 the planets are far enough away that this correction is negligible; however, 
110 it is particularly important for the Moon, which is only 385 Mm (i.e., 
111 385,000 km) away.