Fixed 3 of the language implementations where I forgot
to make GeoVector return the observation time, not the
backdated time. This is important to preserve existing
behavior.
Implemented two new C functions for generic correction
of light travel time:
1. Astronomy_CorrectLightTravel
This is a completely generic solver that is passed
a pointer to a function that returns a relative
position vector for a given time.
The generic solver keeps calling the function
whose address is passed, until the light travel
solution converges. This usually takes 3 or 4 iterations.
2. Astronomy_BackdatePosition
This is a more specific solver that uses Astronomy_CorrectLightTravel
to backdate the position of a target body as seen from an
observer body at a specified observation time.
It implements the aberration option needed by Astronomy_HelioVector.
Astronomy_HelioVector now uses Astronomy_BackdatePosition,
instead of having a redundant light travel solver,
so the code isn't much larger than it was before.
The csdown utility was not generating the correct ID
string that matched the C# compiler's XML output file
when a parameter was of a generic type.
Because the GravitySimulator constructor has a bodyStates
parameter of type IEnumerable<StateVector>, we were not
generating the correct method ID string:
CosineKitty.GravitySimulator.#ctor(CosineKitty.Body,CosineKitty.AstroTime,System.Collections.Generic.IEnumerable{CosineKitty.StateVector})
This caused the constructor to not show up in the markdown docs.
I fixed this and now the constructor is documented.
Corrected a mistake in the explanation of the
C function Astronomy_GravSimInit: the `bodyStates`
parameter is NOT barycentric -- it is relative to the
originBody parameter.
Python had improperly formatted documentation for
Time.FromTerrestrialTime parameter `tt`.
The Python markdown generator `pydown` did not
correctly handle links to compound symbols like
`#GravitySimulator.Update`. It also was trying
to link to `StateVector[]` instead of `StateVector`.
Removed unnecessary and unhelpful documentation
for C# internal class constructors. They do not appear
in the generated markdown documentation anyway.
Other minor wording revisions in the documentation.
The C# markdown generator (csdown) was not generating
documentation about constructors. This was especially
needed for the new GravitySimulator class.
Also added markdown for properties like
GravitySimulator.NumSmallBodies
GravitySimulator.Time
Made several constructors internal so they don't
need to be listed in the markdown docs.
C# builds for .NET Framework 4 were broken because
the Math.Cbrt function does not exist there.
.NET Core provides a standard cube root function,
but Framework doesn't. Added conditional compilation
to fall back to a less efficient substitute function
on Framework builds.
The Python version of the GravitySimulator class
is now passing all unit tests. This completes
the initial coding. I still need to review
documentation across all the language implementations.
Finished coding the Python version of the gravity simulator.
No unit tests have been written yet.
Cleaned up documentation in the other languages.
Made some functions static that did not need to be members.
Started implementation of the Python gravity simulator.
Updated the `pydown` markdown generator to include
class constructors `__init__` when they contain docstrings.
The JavaScript version of the gravity simulator is
now working. I had one bug in the acceleration formula.
Finished the unit tests and also streamlined them a little.
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 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.
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.
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.
