Implemented half of the GravitySimulator unit tests.
Fixed a bug in the GravitySimulator constructor.
Did some refactoring of test.js:
- Wrote Debug() function as shortcut for conditional output.
- Created generic JPL Horizons state file reader.
Starting the C# version of class GravitySimulator.
There are no unit tests for it yet.
Added a fix to the C# markdown generator `csdown`
to show `void` as a function return type.
This is the first time I have had any function
in the C# version of Astronomy Engine that has
a void return type!
Fixed and improved documentation in the Kotlin version
of the gravity simulator. Fixed some comments too.
Added the following functions:
GravSimTime
GravSimNumBodies
GravSimOrigin
GravSimSwap
The GravSimSwap function allows an instantaneous "undo"
of a simulation step, which required refactoring the internal
data structures of the simulator. I did this because I realized
I needed a way to undo exploration of time steps near a fixed
current time. This will make it easier to implement a
light travel time solver.
I was using a UT calculation where I should have used TT.
All of the JPL Horizons state vector input files are
expressed in TT. I found I was a few microseconds off,
which has no measurable effect, but I thought I would
do the time calculations the absolutely correct way.
I have decided the ability to select different
collections of gravitating bodies causes far
more complexity in the code than it is worth.
So now the gravity simulator always calculates
the Sun and all planets except Pluto.
This greatly simplifies the core code, gets
a good balance between efficiency and accuracy,
and makes the test matrix much simpler.
The GravSimOriginState function was doing too
much work for bodies that weren't already calculated
and cached. Instead of always calling Astronomy_BaryState,
it is possible to do a lot less work for most bodies
by recycling the SSB calculation that has already
been done.
Other minor code cleanup -- mostly stuff that makes
the code easier to read and understand.
Now testing all 4 major asteroids:
Ceres, Pallas, Vesta, Juno.
Test all 3 simulation options.
Interestingly, it doesn't seem to matter much
whether I include the 4 inner planets or not.
I guess they are too small and too far away
from the asteroid belt.
Asteroids are probably difficult to calculate accurately
over long time spans, so I generated replacement
test data from JPL Horizons. Instead of trying to
cover the years 1800..2200, I cover the much smaller
range 2020..2040.
C GravSimFile(0 : barystate/Ceres.txt ): PASS (max_rdiff = 4.347e-04, max_vdiff = 1.733e-06)
C GravSimFile(0 : barystate/Pallas.txt): PASS (max_rdiff = 2.826e-04, max_vdiff = 1.263e-06)
C GravSimFile(0 : barystate/Vesta.txt ): PASS (max_rdiff = 5.201e-04, max_vdiff = 2.703e-06)
C GravSimFile(0 : barystate/Juno.txt ): PASS (max_rdiff = 2.162e-04, max_vdiff = 1.063e-06)
C GravSimFile(1 : barystate/Ceres.txt ): PASS (max_rdiff = 4.347e-04, max_vdiff = 1.733e-06)
C GravSimFile(1 : barystate/Pallas.txt): PASS (max_rdiff = 2.826e-04, max_vdiff = 1.263e-06)
C GravSimFile(1 : barystate/Vesta.txt ): PASS (max_rdiff = 5.201e-04, max_vdiff = 2.703e-06)
C GravSimFile(1 : barystate/Juno.txt ): PASS (max_rdiff = 2.162e-04, max_vdiff = 1.063e-06)
C GravSimFile(2 : barystate/Ceres.txt ): PASS (max_rdiff = 4.347e-04, max_vdiff = 1.733e-06)
C GravSimFile(2 : barystate/Pallas.txt): PASS (max_rdiff = 2.826e-04, max_vdiff = 1.263e-06)
C GravSimFile(2 : barystate/Vesta.txt ): PASS (max_rdiff = 5.201e-04, max_vdiff = 2.703e-06)
C GravSimFile(2 : barystate/Juno.txt ): PASS (max_rdiff = 2.162e-04, max_vdiff = 1.063e-06)
C GravitySimulatorTest: PASS
Starting implementation of a generalized gravity simulator.
Already calculating the movement of Ceres, but with less
accuracy than I had hoped. I don't know if the lack of modeling
pull of the other asteroids has a larger effect than I expected,
or there is just something wrong with the implementation.
I'm preparing to create a generalized gravity simulator
for small bodies moving through the Solar System
under the influence of the Sun and planets.
Adding JPL Horizons data for 1 comet and 5 asteroids:
Comet 1P/Halley
Ceres
Juno
Pallas
Vesta
101955 Bennu
Halley was chosen as an object with a highly eccentric orbit.
Bennu was chosen as a member of the inner solar system, where
Earth and Mars are likely to have strong effects.
The remaining 4 major asteroids were chosen as typical members
of the asteroid belt between Mars and Jupiter.
Added the following iterator functions that wrap
search/next pairs of functions:
GlobalSolarEclipsesAfter
LocalSolarEclipsesAfter
LunarApsidesAfter
LunarEclipsesAfter
MoonNodesAfter
MoonQuartersAfter
PlanetApsidesAfter
TransitsAfter
I updated the following C# demos:
moonphase.cs ==> MoonQuartersAfter
lunar_eclipse.cs ==> LunarEclipsesAfter
Fixed an issue in the C# Markdown generator
so that it can now handle generic types like
`IEnumerable<MoonQuarterInfo>`.
Added the following iterator functions that wrap
search/next pairs of functions:
globalSolarEclipsesAfter
localSolarEclipsesAfter
lunarApsidesAfter
lunarEclipsesAfter
moonNodesAfter
moonQuartersAfter
planetApsidesAfter
transitsAfter
I updated the following Kotlin demos:
MoonPhase.kt ==> moonQuartersAfter
LunarEclipse.kt ==> lunarEclipsesAfter
However, I have not yet figured out how to use these
functions in the corresponding Java demos.
It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
Also added operator overloads for adding and
subtracting StateVector, just like we already had
for Vector.
It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
Added Kotlin and Java demos for calculating Jupiter's moons.
Illustrates correcting for light travel time.
I added named getters for the 4 moons in `JupiterMoonsInfo`,
because in Java it was really ugly to write
`jm.getMoon()[0]`, etc.
I had to add a new method `Vector.withTime` to work around
the error checking that throws an exception if vectors
from different times are added.
Also made Kotlin constants public:
MINUTES_PER_DAY
SECONDS_PER_DAY
MILLISECONDS_PER_DAY
Deleted the do-nothing placeholders for installing
the Kotlin Native compiler. We are not going to support
Kotlin Native for now.
Removed redundant installation of pylint from the
Windows commit_hook.bat.
Other batch file cleanup, now that I know "||" works in Windows.
I refactored the unit tests for all the demo programs
to follow a different pattern that makes it simpler
to add more demo tests in the future.
The main thing is that correct output and generated
output are now in separate directories `correct` and `test`.
I have moved the test scripts from `test/test` to `./demotest`
in all the langauge demo directories.
This makes it simpler to clean up any stale generated
files before each test run by `rm -f test/*.txt`.
I stumbled across this while making the Java demo tests,
and it was a better solution, so now all the other languages
are consistent with the Java demo tests.
In the C demo tests, I also decided to compile all the
binary executables into a subdirectory `bin` that can
be cleaned out before each run, to make sure there are
no stale executables from an earlier run.
Direct use of arrayOf can be a bit more efficient than calling map and toTypedArray.
It could be faster if JupiterMoonsInfo was holding a list but better to use direct
typed array initializer for more efficiency.
Used IntelliJ IDEA's linter to perform code cleanup.
There were unused variables, `var` that could be replaced with `val`,
and other minor code style issues.
While doing this, I also discovered that a lot of documentation
links were broken. The fix is to stop intenting the text after
a `@param`.
