I have already mentioned in this blog, that I use an application named ‘Celestia‘, which basically anybody can download and ‘play with’. This is an Astronomy application, which displays to the user graphically, not only what the sky above the Earth would have looked like at some arbitrary point in time, but also what the sky – i.e. the star field – would look like, as seen from elsewhere in the near regions of space, such as anywhere from within our own solar system, or from the closest neighbors to our own sun.
In fact, I even uploaded a YouTube Video, which explains to anybody, the basic usage of this program.
This is another video which I uploaded at 1920×1080 resolution, but which the viewer may have to play with somewhat, even after he has made it full-screen, to switch its resolution to True HD.
(Edit 11/07/2017 :
When recording the above screen-cast, I nearly sidetracked the main subject – of how to navigate the program – with the question, of how to change the Field Of View, the ‘FOV’, indicated in the bottom-right-hand corner of the screen. I do know from experience, that when ‘in synchronous orbit around the Moon’, and looking back at the Earth, using the scroll-wheel of the mouse does not make the earth look any larger or smaller, because using the scroll-wheel will then only change the distance with which my camera-position is orbiting the Moon.
The way to adjust the FOV is finally, to hold down the <Shift> Key, and then to click-and-drag with the Left Mouse Button.
Also, the distinction is known to me, between how this program defines ‘a synchronous orbit’, and what a synchronous orbit would be, correct to Physics. A synchronous orbit needs to have one specific altitude, at which a stable, circular orbit has the same rotational period, as the body we’re orbiting. In the case of the moon, this may not even be achievable. Yet, the way ‘Celestia’ defines a synchronous orbit, is as my screen-cast shows. )
But if this program is to be used for anything aside from pure entertainment, the question should ultimately be asked, how accurate the model is, by which planets are animated, at whatever time-period the user is observing. Basically, a program would be possible, which simply extrapolates Kepler’s Laws about the movements of Planets, according to which their orbits are purely elliptical, and according to which the periods of each orbit stay perfectly the same, over the Eons.
The problem with Kepler’s Laws is, that they not only assume Newtonian Gravity, but They also assume that each orbit is only affected by the gravitational interaction of two bodies: A body assumed to be orbiting, and the body around which the first is assumed to be orbiting. The problem with this is the fact that in the real Universe, every body that causes gravitation, eventually exerts that gravitation on any other body – up to infinite distance. The fact that each and every person standing on the surface of the Earth, experiences the gravitation of the Earth, is a kind of proof of that. In theory, the gravitation of the Earth not only affects the orbit of the moon, but to a lesser extent, also the orbits of Mars and Venus – except for the fact that some people fail to know, that at the distance of Mars, for example, the gravitation of the Earth would be assumed negligible in strength. The effect of a car that passes the street in front of an Inhabitant of Earth, is in fact stronger, than the effect of the gravitation of Mars, on the same Inhabitant. And this is simply because, the strength of gravitation does decrease, as the reciprocal of distance squared.
But what this means is that over longer time-frames, the orbits of the planets become ‘perturbed.’ Mostly, this is due to the effects of the gravitation of Gas Giants, on the smaller planets of our solar system, but it really applies generally, wherever gravitation exists.
Well The programmers of Celestia took this into consideration, when they created that program. What they did, was to assume that Kepler’s laws generally apply, when they are fed a single parameter – time – and that they predict elliptical orbits, as a linear function of time. But, because real orbits are perturbed, it was at some point thought best, that time first be fed through a polynomial, to arrive at the parameters, which are then fed into Kepler’s Model, such as the one parameter that states, in what phase of its orbit a planet is, as orbiting our sun.
In reality, this method of applying a polynomial, does not reflect any physical realities, of ‘how the orbits work’. What it reflects is that Real Astronomers at some time in the past, used very powerful computers in order to compute gravitational interactions, and that the result of their simulation was a continuous sequence of planetary positions, which next needed to be stated somehow. The reader might think, that nothing but a series of numerical values would be needed, except that one problem with that idea would be, that effectively an infinite series of numerical values would be needed, because any time-interval can be magnified, and the motion of planets is supposed to remain continuous.
And so what Astronomers did, was to express the results of their simulation as a polynomial approximation, which consumers’ computers can next turn into real values, for what the position of a planet is supposed to be, at any precise point in time.
In other words, the use of a polynomial approximation served essentially, as a type of data-compression, and not as a physical model of gravity.
This approximation is also known as “vsop87“.
(Updated 11/08/2017 : )
Any polynomial approximation has as its main weakness, that while it stays accurate over a finite interval, outside the assigned interval, it goes off the rails – quickly. I think I recall reading somewhere, that Celestia Users were trying to emulate what our Solar System would have looked like, in the year 2000 B.C. – i.e., 4000 years ago. And those users were experiencing anomalies. To the best of my knowledge, ‘vsop87′ should still be accurate, near the year 1 A.D. – i.e. merely 2000 years ago, especially according to the article above.
I suppose that a second question could be asked, as to how faithfully Celestia applies ‘vsop87′. In theory, each of the parameters of an orbit, such as the radial distance of its perihelion and its aphelion, as well as the angle of inclination in the solar system, could be made polynomial functions of time. But what Celestia may have done instead, could have been to keep the geometry of each orbit constant, but to keep the phase of the planet’s motion within its orbit the required polynomial. Additionally, I believe that their model of the rate at which bodies spin, is a simple, constant function of time – which may again, not be completely accurate.
This type of simplification would actually ‘make sense’, for two practical reasons I can think of:
- It simplifies coding,
- If the user was to take the application Celestia outside the epoch within which ‘vsop87′ is deemed accurate, he will experience that the planets’ positions within their orbits are not correct anymore, but the user may not even be interested in this. And then, such a user would find that at least, the geometries of the orbits would still be correct – more or less – rather than to have each orbit assume ‘a wild geometry’, which it never had.
So according to the article which I just linked to above, ‘vsop87′ is accurate +/- 4000 years from the modern epoch, and if the other user was placing his time-pointer at the edge of the valid interval, the polynomial would indeed have started to become inaccurate – directly at the edge.
(Edit 11/06/2017 : )
I have some added observations, that eventually have implications about the accuracy, of the application, ‘Celestia’.
This application is scriptable. What this means, is that using the language ‘Lua’, any user can install an arbitrary 3D model, and can decide that this model is supposed to be orbiting the sun (‘Sol’) , the Earth, the Moon, or anything else. This type of addition to Celestia’s collection of known object does not require, that the user in question know how to apply polynomial approximations. According to his script, such objects can be made to have much simpler movement – i.e. completely linear parameters governing movement.
It was only to simulate our own Solar System, that the very-precise model was used, which is named ‘vsop87′, and that uses polynomial approximation.
Further, some time ago I found myself analyzing the question, of how many bits of precision should be used to evaluate the polynomial. And the conclusion that I reached at the time was, that the coefficient of x^1 needs to be more precise, than any other coefficients, including for x^0 , or, the constant term.
My reasoning for this result was rather straightforward. Floating-point numerals have been engineered in such a way, that they remain accurate over many multiplications. Hence, the term of x^8 can become hugely positive far-away from the modern epoch, but can then be multiplied by a 32-bit, floating-point number, which has a correspondingly negative order of magnitude, so that this coefficient can be as minuscule, as the term itself has become huge.
None of this would really change the fact, that we’d obtain a numerical result, which is still approximately 24-bits accurate overall, the way 32-bit floating-point numbers are stored.
But when it comes to the coefficient of x^1 , we find that in some way the equations can be set up, the part of the result which is to the left of the decimal-point may not interest us, because it simply expresses how many times a body has orbited the sun. When observing a body, this could not be seen. But the part of the result which is important, is the part that’s to the right of the decimal point, which expresses what fraction of an orbit a body has completed, which can in fact be observed.
Well if we simply add or subtract two 32-bit, floating-point numbers, the magnitudes of which are very different, one number can become much smaller, than the margin of error, of the fractional part of the other. Therefore, 32-bit floating-point numbers do not maintain their accuracy, for addition or subtraction, if their magnitudes are strongly different.
I.e., we could perform the following two series of additions, and obtain different results:
- 1.0e+00 + 1.0e-20 – 1.0e+00 ~= 0.0e+00 (?)
- 1.0e+00 – 1.0e+00 + 1.0e-20 ~= 1.0e-20
Now, there is an argument against the apparent, visual clarity of what I have written above:
- (1.0e+00) was not an exact value to begin with. It has an implicit margin of error, which is (1 / 2^24) times its magnitude, if that is a standard, single-precision floating-point number. Therefore, its margin of error may make the value of (1.0e-20) irrelevant.
This argument places an ultimate limit, on how accurately high-order polynomials can be evaluated at all, as soon as the error present in any one term, is larger than another term.
But when expressing the movement of a body within its orbit, what we’re most interested in, is the accuracy of the fractional component.
I’ve actually seen source code, due to which ‘Celestia’ performs certain crucial computations in a type of 128-bit, fixed-point format, that has been defined using object-oriented programming, but for which only basic computations, such as addition, subtraction, multiplication and division, have been defined. Other operations are computed within ‘Celestia’, using very mundane 32-bit or 64-bit floating-point Math, for which every conceivable function has been defined.
The custom, 128-bit numeral has been set up, as having 64 (largely-unused) bits to the left of the decimal, plus 64 bits to the right of the decimal. And certain member-functions will extract either of the two fields, or set either of the two fields, using native data-types.
We can ask ourselves whether the coefficient of x^0 needs to be more-precise, that 24-bits. The answer would be, ‘Only if we want the phase of the position of a planet, within its orbit, to be more-precise than 24-bits behind the decimal-point.’ (Edit 11/08/2017 : In other words, ‘Not if we only want to display an entire orbit, on a 1920×1080 display.’ )
What remains important however, is that the fractional part of this term needs to be preserved, when added to the higher-order parts of the polynomial, even if the non-fractional parts of that polynomial are numbers in the thousands – i.e. even if the planet has orbited thousands of times.
Giving the first-order term this kind of 128-bit, fixed-point precision, ‘makes sense’, then.
But what about the higher terms? How precise does the coefficient of x^2 , x^3 , … x^8 need to be? And how precise can they be? The answer that I find is, that Those terms can only ever be as precise, as the number of bits of precision, which their coefficients have been written in. They are not responsible for the fact that on average, the Earth orbits once per year, only for the more-subtle perturbations to that orbit, which the Earth has undergone over the range of ( -4000 … +4000 ) years or orbits.
Assuming that the magnitude of the actual perturbations is not huge, and that these coefficients are not written as having a huge number of digits, they can be computed most-efficiently, as a series of multiplications. I.e.,
x^3 == x*x*x
x^8 == x*x*x*x*x*x*x*x
Hence, unless we include a type of numeral, which has (24 * 8) bits of precision, which would actually be 192 bits of precision, we have no way to make those terms more precise, than their stated coefficients would be. And because the exaggeratedly-long numbers need to be in fixed-position format, it would actually make sense to have (192 + 192 == 384) bits then (code for which is not evident).
So simply due to practical limitations, we’d get the idea only to compute the x^1 term in the especially-long format, and to compute all the other terms using
either 32-bit or 64-bit floating-point numbers, but also to pay attention to the order with which we apply computations.
Also, when evaluating the polynomial in question, we would find that the lower terms start earlier to become very large, but that the highest terms only start to become significant, at the outer limits of the interval over which the polynomial is deemed valid. Eventually these terms need to oppose each other when added, to result in an overall result that’s to be accurate.
This last observation seems to suggest that the term x^2 should be computed, before the term x^3 is computed, as well as that the term x^7 should be computed, before the term x^8 is computed, and that the result from each term can be added to a cumulative value, which will eventually start out as having matchingly large positive and negative values, to lead to matching, correspondingly smaller values.
It would make most sense, for this cumulative value – the result of additions – to be stored in the custom, 128-bit format. But in fact, ‘Celestia’ might not use this format here.
The fact is trivially possible, that a constant, average rate of orbit is indicated by the x^1 term, but that deviations in the orbital position from this value, exceed 1 orbit. If thousands of years have gone by, the deviations of the orbital phase due to perturbation, may reach 10 orbits, and for academic completeness, a deviation of up to 100 orbits should be planned for.
Effectively, this would reduce the precision by 1 or 2 further decimals, i.e., powers of ten, with respect to what each term was computed to, assuming that we’re still only interested in the fractional part, of the final result. Hence, if it was a valid standard that the x^0 term only needed to be as accurate as single-precision floating-point Math, then by same token, double-precision Math for the higher terms would seem appropriate.
(Edit 11/07/2017 : )
I’ve observed that even though the source code defines a custom-data-type, which corresponds to a 128-bit numeral, the same source-code fails to apply it, when computing polynomials.
A curious reader might ask, ‘In what situation, then, did the developers think it appropriate to apply this type of numeral?’
AFAICT, They applied it, when an object orbits another object, which orbits another object.
In other words, for example, the moons of Jupiter could be an orbital system, which needs to be scaled, before it gets added to the position of Jupiter. This entails a multiplication, followed by an addition.
And yet, a user may eventually want to know, whether as seen from Earth, Ganymede transits Neptune, which is of course another planet that orbits the Sun, potentially transiting at one point in time. In order for the program to reveal an answer to this question, the position of Ganymede within our solar system, needs to be as precise, as the orbit of Neptune, as well as the orbit of Earth. And yet, the position of Ganymede has been scaled and transformed…