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.