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.
This is our first official release of Astronomy Engine
that includes support for Kotlin and Java for the JVM.
There are also a few minor enhancements and improvements
in the other supported languages.
Special thanks to: @ebraminio, who helped me get
the build environment set up, taught me lots of
cool stuff about the Kotlin language, and provided
numerous code reviews and extremely helpful feedback
the whole time. His help made this project much
faster and greatly improved the quality of the work.
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.
The help pages for the Java and Kotlin demos mention
a Windows batch file `rundemo.bat`, but they did not exist.
I created them, so now the documentation is correct.
Three of the lunar eclipse demos (Python, Java, Kotlin)
provided a less than ideal example of efficient computation.
They were wasting a lunar eclipse search by calculating it
but not printing it. Now after printing exactly 10 lunar
eclipses, stop running immediately.
Added Java demo to search for rise/set/culmination
of the Sun and Moon.
Also added the missing entry for the Kotlin
rise/set/culmination demo that I had forgotten.
