TDE educational programs
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

#### 5.6 KiB Raw Permalink Blame History

`README.planetmath:  Understanding Planetary Positions in KStars.copyright 2002 by Jason Harris and the KStars team.This document is licensed under the terms of the GNU Free Documentation License-------------------------------------------------------------------------------0. Introduction: Why are the calculations so complicated?We all learned in school that planets orbit the Sun on simple, beautiful elliptical orbits.  It turns out this is only true to first order.  It would be precisely true only if there was only one planet in the Solar System, and if both the Planet and the Sun were perfect point masses.  In reality, each planet's orbit is constantly perturbed by the gravity of the other planetsand moons.  Since the distances to these other bodies change in a complex way,the orbital perturbations are also complex.  In fact, any time you have more than two masses interacting through mutual gravitational attraction, it is *not possible* to find a general analytic solution to their orbital motion.  The best you can do is come up with a numerical model that predicts the orbits pretty well, but imperfectly.  1. The Theory, BrieflyWe use the VSOP ("Variations Seculaires des Orbites Planetaires") theory of planet positions, as outlined in "Astronomical Algorithms", by Jean Meeus.  The theory is essentially a Fourier-like expansion of the coordinates for a planet as a function of time.  That is, for each planet, the Ecliptic Longitude, Ecliptic Latitude, and Distance can each be approximated as a sum:  Long/Lat/Dist = s(0) + s(1)*T + s(2)*T^2 + s(3)*T^3 + s(4)*T^4 + s(5)*T^5where T is the number of Julian Centuries since J2000.  The s(N) parametersare each themselves a sum:  s(N) = SUM_i[ A(N)_i * Cos( B(N)_i + C(N)_i*T ) ]Again, T is the Julian Centuries since J2000.  The A(N)_i, B(N)_i and C(N)_ivalues are constants, and are unique for each planet.  An s(N) sum canhave hundreds of terms, but typically, higher N sums have fewer terms.The A/B/C values are stored for each planet in the files<planetname>.<L/B/R><N>.vsop.  For example, the terms for the s(3) sumthat describes the T^3 term for the Longitude of Mars are stored in"mars.L3.vsop".Pluto is a bit different.  In this case, the positional sums describe theCartesian X, Y, Z coordinates of Pluto (where the Sun is at X,Y,Z=0,0,0).The structure of the sums is a bit different as well.  See KSPluto.cpp(or Astronomical Algorithms) for details.The Moon is also unique, but the general structure, where the coordinatesare described by a sum of several sinusoidal series expansions, remainsthe same.2. The Implementation.The KSplanet class contains a static OrbitDataManager member.  TheOrbitDataManager provides for loading and storing the A/B/C constantsfor each planet.  In KstarsData::slotInitialize(), we simply callloadData() for each planet.  KSPlanet::loadData() callsOrbitDataManager::loadData(QString n), where n is the name of the planet.The A/B/C constants are stored hierarchically: + The A,B,C values for a single term in an s(N) sum are stored in an   OrbitData object. + The list of OrbitData objects that compose a single s(N) sum is   stored in a QPtrVector (recall, this can have up to hundreds of elements). + The six s(N) sums (s(0) through s(5)) are collected as an array of   these QVectors ( typedef QVector<OrbitData> OBArray ). + The OBArrays for the Longitude, Latitude, and Distance are collected   in a class called OrbitDataColl.  Thus, OrbitDataColl stores all the   numbers needed to describe the position of any planet, given the   Julian Day. + The OrbitDataColl objects for each planet are stored in a QDict object   called OrbitDataManager.  Since OrbitDataManager is static, each planet can   access this single storage location for their positional information.   (A QDict is basically a QArray indexed by a string instead of an integer.   In this case, the OrbitDataColl elements are indexed by the name of the   planets.)Tree view of this hierarchy:OrbitDataManager[QDict]: Stores 9 OrbitDataColl objects, one per planet.|+--OrbitDataColl: Contains all three OBArrays (for    Longitude/Latitude/Distance) for a single planet.   |   +--OBArray[array of 6 QVectors]: the collection of s(N) sums for       the Latitude, Longitude, or Distance.      |      +--QVector: Each s(N) sum is a QVector of OrbitData objects         |         +--OrbitData: a single triplet of the constants A/B/C for             one term in an s(N) sum.To determine the instantaneous position of a planet, the planet calls itsfindPosition() function.  This first calls calcEcliptic(double T), whichdoes the calculation outlined above: it computes the s(N) sums to determinethe Heliocentric Ecliptic Longitude, Ecliptic Latitude, and Distance to theplanet.  findPosition() then transforms from heliocentric to geocentriccoordinates, using a KSPlanet object passed as an argument representing theEarth.  Then the ecliptic coordinates are transformed to equatorialcoordinates (RA,Dec).  Finally, the coordinates are corrected for theeffects of nutation, aberration, and figure-of-the-Earth.  Figure-of-the-Earth just means correcting for the fact that the observer is not at the center of the Earth, rather they are on some point on the Earth's surface, some 6000 kmfrom the center.  This results in a small parallactic displacement of the planet's coordinates compared to its geocentric position.  In most cases, the planets are far enough away that this correction is negligible; however, it is particularly important for the Moon, which is only 385 Mm (i.e., 385,000 km) away.`