The algorithm OGS15 (orbit-gravity-sim-15.exe) is a 3D evolutionary software-model that uses Newtonian-Planck gravity to depict the interacting movements of the 9 primary bodies of the solar system. The most essential detail of the source-code is free here:
How to Build N-body-gravity Algorithm

OGS13 is the 2D version. OGS14 is an easy-to-use 3D-n-body-gravity orrery depicting possible orbits around hypothetical binary stars. These virtual orrery applications can all be downloaded at this link:
Download Orrery Algorithm with N-Body-Gravity

You may wish to read the introduction to this chapter understand the purpose of this project. What follows is an in depth description of how the algorithms function.

Starting parameters for the planets are primarily from NASA's Horizon Ephemeris, but thereafter the process evolves purely according to the Newtonian law: g=GmM/r^2. With M to m being a sequence of the 9 major bodies with the resultant 72 interactions between them.

When the software is running, you can [Stop] and move the planets around manually and arbitrarily - in order to check that this is an evolutionary algorithm - and also just for the sake of curiosity. It maybe better to begin with OGS13 in 2D if you just want to play around with the solar system. It has substantial visual features, and is only less accurate than the 3D version by a small amount - this is purely due to its missing Z-axis.

Use OGS14 if you want to have a look at n-body gravity orbits around multiple stars in 3D. OGS14 (orbit-gravity-sim-14.exe) is the 3D version of OG8 (orbit-game-8.exe). These are both easy to use and some fun to play with. They do not have specified scales for time and distance. These are recommended for younger scholars, but also the curious speculator.

Whereas OGS15 was designed primarily to examine precisely the Newtonian effect on the Perihelion Precession of the planets in our solar system. Its not much fun to look at because it suppresses the visible evolution of the parameters in order to more optimally evolve the raw data. For these reasons it is more accurate than the others. For serious researchers only.

After you have downloaded these apps, when the software is running, hover the mouse over each function to pop up more tips and help for that function. Most of the help detail is available this way.

When you first run OGS13 or OGS15, you need to select one of the Scenarios to evolve. Each Scenario focuses on a particular planet's orbit data. This especially details the Perihelion Precession in angular terms as well as for distance. This is expressed individually per orbit and as an average. (The version with accurate measurements of aphelion OGS15.2 has not been published online - if you want a copy of it, contact me). Also inherent is the temporal duration of each orbit as it fluctuates, as well as the average.

The prime purpose is to see if Newtonian gravity can completely account for the changes to the perihelion and aphelion of the planets. OGS13 is also compared to OGS15 to ascertain how important the Z-axis (3rd dimension) is in affecting Perihelion Precession. The Z-axis plays a substantially larger role than the claims of Relativity, but it was omitted in all historical analyses that I have found. This is an astonishing discovery, but not entirely unexpected if you have read my previous articles.

After running the algorithm, OGS15 may appear slow (depending on your computer), and may take some minutes or even hours, to compute a single orbit. Fiddle at your leisure with the distance and time-rate to see the scales involved - See option (D), below.

To check if the parameters are evolving you can also toggle the 'Turbo-time/detail' option (E). The 'detail' option slows down the rate of computation, whilst numerically demonstrating the evolution of the data. But the accuracy of the calculation stays the same. So set it back to 'Turbo-time' when you are satisfied at the evolution and want to speed up the process again.

Key to screenshot:
(A) Start the evolution of the solar system by selecting from the Scenarios.
(B) You can toggle the side-view and edge view.
(C) The switch here toggles the minimum and maximum distances to the sun. The first 8 orbits show on-screen, but full orbit details for all orbits are saved in the file 'data-drift.txt' which is located in the folder in which OGS13 or OGS15 is running.
(D) Time-scale can be altered by changing the size of each jump of virtual quantum time. Bigger jumps run faster, but less accurately. So the orbit may be calculated in jumps of 150 virtual seconds for the planet, or more, or less, depending on the accuracy required and patience of the user.
(E) The section 'elapsed-time' allows the user to change the rate of computer computation in real-time. This should be left at its optimum (turbo-time), but altering it can describe more detail on the screen. Be sure to appreciate the difference between (D) and (E). Option (E) simply suppresses the visual data to compute faster, but does not change the accuracy of the calculation.
(F) Changes in the angle of perihelion are described in detail here. This can be switched between that showing the average over numerous orbits, or the individual changes per orbit. You can select an individual 'marker perihelion' using the horizontal scrollbar (in gray). This highlights the various individual perihelion changes numerically. Details of each aphelion and perihelion change are recorded in the 'data-drift.txt' file, and also in a simpler 'orb.txt' file which is ideally used to generate the graphs.
(G) The graphic orbits of the planets as well as the graphic of the changing perihelion are in the center of the screen. The the lines radiating from the Sun to the orbit, color coded for each planet, show visually how the angle of the Perihelion Precession, or recession, changes for each orbit. In the screenshot above it should be easily visible how much Saturn's Perihelion has changed visually after 2769 years of evolution. In the image below, 824 years of Uranus' orbit evolved.

You may also run scenarios over numerous sessions. I found it useful to let OGS15 run for about 10 hours whilst I sleep each night. This way I could evolve a single detailed evolution over 3 months with extreme accuracy. OGS15 automatically saves evolution data every orbit.

When you exit, and re-enter later, it then gives you the option to reload the last completed orbit of the last scenario you executed. Then simply select [continue]. Bare in mind that all the intricate details on-screen may only be properly updated for the 2nd orbit after restarting. But all the essential data is identical with running it in one continuous session.

Should you wish to back-up specific scenarios and restart them later, the full data for each scenario is located in four essential txt documents:
data-drift.txt, orb.txt, orbit-pp.txt and orbit-save.txt

These should be the most recently updated files by date/time in the folder in which the OGS15 algorithm is located. The four files can be saved and presented if you plan to demonstrate them at the forum: cosmology.africamotion.net for discussion.

Of course the dynamic nature of the algorithm allows you to fiddle the parameters as much as you like. For instance I used Scenario [37] in two different sessions to assess the real effect that Neptune had on Uranus' orbit. Those details are presented in the section: Uranus

All I did there was to Start Scenario [37], then [stop] it quickly, and then turn [off] Neptune. You can thus get clear results as to what effect any one planet has on any other planet this way.

An interesting similar experiment I have not tried, is to determine what Saturn's orbit looks like without Neptune and Uranus. This could simulate a process whereby Uranus might have been predicted and discovered by unexpected fluctuations to Saturn's orbit.

So just start Scenario [26] or [36], then quickly [stop] the algorithm. Turn [off] Uranus and Neptune and then [continue] and let it run for a few complete orbits. Copy the four essential txt documents into a new folder. Then restart the scenario from scratch again, and compare the orbital duration, Perihelion Precession, as well as distances of perihelion and aphelion. Tell me about it at the forum! I really want to know but I just do not have time to run all such scenarios.

These two screen extracts show how to select a planet and turn it on/off.
Note: alter the positions and velocities of values: X, Y, Z and Xv, Yv, Zv.
[stop] any scenario to access these controls.

By turning off [Orbit-lines]
the process can be sped up significantly.
(see screen extract directly above this comment)

But then you won't see the orbits evolving. You can quickly turn [Orbit-lines] on and off to see where the planets are without effecting the evolution in any way directly. If you have any other questions please do not hesitate to contact me at the forum.

There are many other secondary sources of data cross-referenced beyond NASA's Horizon Ephemeris. But after each Scenario begins with historical data, the process then continues completely due to the evolution of Newtonian-Planck theory on gravity. The user can pause the Scenarios, move the planets around, change their velocity or even their mass. Restarting the Scenario will set it back to the proper parameters. This way you can observe that this is a model based entirely on theoretical physics, not historical data.

In OGS15, the start is 24 January 1940 for the first 20 Scenarios where Jupiter is at perihelion. Scenarios [41]-[45] give very detailed (and ever more slowly evolving) accounts of Mercury's orbit for the same time-frame. In all the Scenarios of OGS13 the starting parameters are from 24 January 1940 for comparison between the 2D and 3D processes.

In OGS15, Jupiter's perihelion of 1773 begins Scenarios [21] - [38].
Whereas Scenarios [49]-[58] begin with Earth's perihelion of 1900.

In most cases the order is numerical such that [11], [21], [31], etc - focus on Mercury with subsequent Scenario numbers ending in '2' for Venus, '3' for Earth, etc, etc. There are a few exceptions to this general principle for the extreme scenarios.

Scenarios [71], [72] & [78] are control tests with the Sun in relation to just Mercury alone, just Venus, and just Neptune respectively. Each Scenario has only the one planet and the Sun to check the extent to which the size of the time-quanta effects the error margins in the Perihelion Precession. This was particularly relevant for Neptune, as the algorithm OGS15.2 predicts a net average recession for Neptune's aphelion over multiples of 8 or more orbits.

Large time quanta do cause a recession to the major axis. But Scenario [78] which is unaffected by other planetary gravity, shows that this amount is substantially small. Thus when Scenario [28] of OGS15.2 detected recession to Neptune's aphelion of between -1 and -2 as/Ey, then that was certainly caused by n-body gravity.

Even the fastest computers cannot process information anywhere near the rate of quanta in Planck-time. These models have been constructed to accommodate a maximum rate of computation of 0.00015 seconds per quantum of virtual time. But it has been found that time-quanta of between 1.5 virtual seconds and 15000 virtual seconds produce acceptable error-margins in most Scenarios, depending on the planet and duration of the sample. The inner planets requiring a finer time margin, with Mercury optimal at 15 seconds per iteration.

Details of the nature of the error-margins are in the previous chapter. (Chapter 31, section 27: Using OGS12). OGS13 & OGS15 improve on the previous gravity simulators by speeding up the computation process when limiting some functions to allow faster computers to iterate the process as rapidly as they can manage. So OGS13 & OGS15 are not only about 5x faster than previous versions on my little computer, but as newer computers are constructed the algorithm should get faster, and compute with increasing speed and accuracy.

Even after building it, I cannot use many of the Scenarios myself at optimal effectiveness; yet. Unfortunately the newer 4-core machines have actually slowed this computation process by 10x. The Windows 10 crew have said they are working on how to allow these apps to access the full processing power of the 4-core processors.

Nevertheless, this algorithm computes 72 gravitational effects between the 9 major bodies for each quantum of time. This is a vast improvement on numerical mathematical models which are based on approximations that typically only take into account only 7 gravity interactions between the other planets and the selected body, ignoring the effects that all the other planets have on one another. See Introduction for details.

More bodies could easily be programmed, but this will paradoxically cause larger-error margins as they will slow down the process considerably for insignificant amounts of gravity.

Because 9 bodies yields 72 iterations, then 18 bodies would be 306 iterations. Double the bodies = about 4 times slower; and thus the error-margin is 4 times worse.
Err = (b^2) - b where b is bodies and Err is the error-margin proportionally.

Inaccuracy is likely to be the result of:
(1) A flat Z-axis in OGS13. Solved in OGS15.
(2) Quanta of time being too large. (Depends on the setting, and Scenario).
(3) Moons and minor planets not accounted for such as Pluto.
(4) Imperfect starting parameters and thus inaccuracies adding up to a butterfly effect.
(5) Rounding errors accumulating due to a maximum of 16 decimal places per variable. Often, a smaller time-quantum can thus produce an amassing of rounding errors such that smaller time-quanta can be paradoxically less accurate as they require more calculations per orbit and thus generate more rounding errors in total.

(6) In the extreme top-right of the screen you can alter G. This will change it across any scenarios you run until you reload the application or reset G. Of course you can alter G midway through a scenario as the interface is entirely interactive.

The estimates of mass, and G effectively cancel one another out, because we can increase either and decrease the other, with no effective change to the orbit. Change this at your leisure to test the effects this could have on the orbits. I have not tested all possible permutations, but spot-testing proved G most unlikely to be relevant to the aims of this study.

Default G= 6.67259 from Horizon Ephemeris. Although there is a contradiction from them as to what value they are using. This is discussed in detail in the section: Sorting Horizons.

Just note that the various Scenarios have exactly balanced velocities proportional to the masses. So if you switch off a planet or alter its mass, then the solar system will start to drift across the screen very slightly; because the planets should pull on the Sun with precise momentum proportional to their masses and velocities. The formulae for that is with the source-code in the section: How to Build N-body-gravity Algorithm

(7) The source data of Horizon Ephemeris is based on planet's positions. But their given velocity vectors have a huge 7%+ error. I discuss the full details and prove their error in the section on Uranus as an example. However, I was able to reverse engineer the correct velocities which are given together with the most vital aspect of the source-code in the section: How to Build N-body-gravity Algorithm

(8) Inaccuracy may also be the result of other Post-Newtonian theories on gravity. However it is the conclusion of this study that Newton's theory is perfectly intact, and that any variations against Newton are the result of inaccuracy in observation. The only sleight alteration to Newtonian theory is to use Plank's quantum time.

If you have any queries as regards these algorithms, please make them here:
cosmology.africamotion.net

The algorithm at the core is very simple, even if the computer code makes it seem more complex. Most of the computer code exists to yield good qualitative measurement of the core quantitative process. So really its just this: g=GMmmmmmmmm/r^2.

The adjustments for Einstein's Relativity are accounted for in the previous chapter, leaving no doubt as to their being blatantly incorrect for numerous reasons. Not only is Relativity illogical in terms of its internal geometrical claims; but the results allegedly yielded were historically badly estimated without due process in terms of evolutionary computational geometry.

This article/chapter proves against Einstein specifically as it includes the most accurate known detail of the empirical data of: Mercury' Perihelion Precession. The previous articles/chapters prove this categorically as regards internal analytical logic:

Chapter 29: www.flight-light-and-spin.com/LIGO/analysis-gw150914.htm
Chapter 30: www.flight-light-and-spin.com/simulator/relativity-orbit-solar-system.htm

<— Page Back — Start Page — Next Page —>