There were a few more places where C# code called
Search() but did not check for a search failure.
Throw InternalError exceptions if these ever occur,
because these particular searches should always succeed.
Added an InternalError class to explicitly indicate
that an exception occurs due to an internal assertion
failure inside Astronomy Engine. Any InternalError
should be considered a bug in Astronomy Engine, not
a bug in calling code.
Upon reviewing the code for searching moon phases,
I discovered that there was inconsistent behavior
in SearchMoonPhase. It was sometimes returning null,
other times throwing an exception. Because the caller
passes in `limitDays`, it makes sense to simply
return `null` in any case where the search fails.
This is to support callers that intentionally want
to find whether or not a moon phase occurs in a given
small window of time.
Updated internal callers of SearchMoonPhase to throw
an InternalError when they know they should always
find an event.
Internal function FindSeasonChange did not check to
make sure SearchSunLongitude succeeded. There is no
known case where this failure happens, but if it did,
a null AstroTime would have been stored in SeasonsInfo.
It is better to fail early with an explicit InternalError.
Other miscellaneous C# code cleanup.
In the Python code, I found a couple of `raise Error`
that needed to be changed to `raise InternalError`.
Dokka preserves leading whitespace in the text after
`@return` comments. This causes these fields to render
as preformatted text. Removed the leading whitespace so
this text is rendered as normal markdown.
Implemented the following related functions in Kotlin:
sunPosition
searchSunLongitude
seasons
C#: fail Astronomy.Seasons with an exception if any of the
equinox/solstice searches fail. If this ever happens, it is
an internal error. It should not be the burden of the caller
to check for nulls! Fixed mistake in documentation for
searchSunLongitude.
Implemented the low-level search function that will be used
to implement all the special-purpose search functions to come.
Added missing documentation to class NodeEventInfo members.
Minor cleanup in the C# function `Astronomy.Search`:
- removed an unused output parameter.
- deleted confusing sentence in documentation.
While working on the Kotlin implementation, I have
found a few documentation mistakes in the other language
implementations. These have been accumulating in the
`kotlin` branch. I migrated these changes back into
the released code for now, because I don't want to wait
until Kotlin is ready.
Starting to add the functions that create rotation
matrices to convert from one orientation to another.
Here are the ones implemented in this commit:
rotationEqjEcl
rotationEclEqj
rotationEqjEqd
Also starting to add missing documentation to
resolve Dokka warnings.
Defined consistent __repr__ methods for
Astronomy Engine Python classes.
Each string representation is reversible:
eval(repr(x)) -> x
The main goal is to facilitate interactive
debugging and experimentation for developers
working directly in the Python interpreter.
Fixed documentation mistakes in the following classes:
IlluminationInfo
LunarEclipseInfo
The `horizon` function was taking the sine and cosine
of the right ascension, but treating it as degrees.
This was wrong because right ascension is in sidereal hours.
Fix: multiply hours by 15 to get degrees.
Keeping the unit test that confirmed this bug.
Added comparison of C and Kotlin output to `diffcalc`
and `diffcalc.bat`. This test now passes on Linux.
This is a big milestone!
The function getPlutoSegment had a bug simulating gravity
in the forward direction. It was creating an array `seg`
that was one item too long: 202 instead of 201 elements.
This caused states from inconsistent time steps to be mixed.
I discovered this via the `diffcalc` script.
I added a new unit test that quickly reproduced this issue.
This was helpful for debugging and finding the problem.
I'm keeping the new unit test, in case it helps detect
breakage in the future.
Implemented Kotlin functions and code generator
for calculating the state vectors of Jupiter's
largest 4 moons.
Added cautionary comments about needing to correct
Jupiter's moons for light travel time.
This is the first pass to get everything needed
for the AstroCheck tests. I tried comparing
C output to Kotlin output, and there are some
serious problems to debug:
$ ./ctest diff 2.8e-16 temp/{c,k}_check.txt
First file: temp/c_check.txt
Second file: temp/k_check.txt
Tolerance = 2.800e-16
lnum a_value b_value factor diff name
FAIL 137746 4.2937184148112564e+01 4.2944101081740065e+01 0.03364 2.327e-04 helio_x
FAIL 373510 1.4197190315274938e+01 1.4193716564905307e+01 0.03364 1.168e-04 helio_y
FAIL 137746 -6.5897675150466091e+00 -6.5929481589493522e+00 0.03364 1.070e-04 helio_z
FAIL 59150 1.8035183339348251e+01 1.8035909197904104e+01 0.01730 1.255e-05 sky_j2000_ra
FAIL 137747 -8.1222057639092533e+00 -8.1250990689970894e+00 0.00556 1.607e-05 sky_j2000_dec
FAIL 137747 4.8436159305823310e+01 4.8441487614058218e+01 0.03481 1.855e-04 sky_j2000_dist
FAIL 322846 8.7596368704201495e+01 2.6760770774700188e+02 0.00278 4.995e-01 sky_hor_az
FAIL 405828 -6.5075824596574279e+01 5.6922941329250996e+01 0.00556 6.778e-01 sky_hor_alt
OK 92717 4.1268347083494783e-03 4.1268347083494774e-03 223.21429 1.936e-16 jm_x
OK 45091 -8.0149190392649894e-03 -8.0149190392649929e-03 79.42812 2.756e-16 jm_y
OK 135377 1.5470777280065808e-03 1.5470777280065804e-03 223.21429 9.680e-17 jm_z
OK 216836 4.5725777238332412e-03 4.5725777238332394e-03 126.58228 2.196e-16 jm_vx
OK 351647 5.1351566793199944e-03 5.1351566793199962e-03 126.58228 2.196e-16 jm_vy
OK 351647 2.5217607180929289e-03 2.5217607180929298e-03 126.58228 1.098e-16 jm_vz
Score = 6.778e-01
ctest(Diff): EXCEEDED ERROR TOLERANCE.
So I'm checking this in as work-in-progress.
Implemented more of the core functions needed for
the AstroCheck tests. Most of AstroCheck is now implemented,
except for the JupiterMoons tests.
Code cleanup thanks to @ebraminio:
- Use `when { }` syntax.
- Renamed `IllumInfo` to `IlluminationInfo`.
- Other minor naming fixes.
Configured Dokka to warn about undocumented symbols.
We also configured Dokka to omit internal symbols, including
inside enums, but that does not work, despite this bug
being marked fixed in dokka:
https://github.com/Kotlin/dokka/issues/1802
We suspect they didn't really fix the bug, and that
there is a bug in their test.
Thanks to @ebraminio, I learned that Kotlin enum classes
allow the members to contain data properties. This greatly
simplifies code so that I no longer need such verbose
`when (body)` statements.
I also understand Kotlin enums better, and I realized
there is no need for `Body.Invalid`, because the compiler
simply does not allow invalid enum values to exist.
In any future hypothetical situation where I want to
represent an optional `Body` value, I can use the nullable type `Body?`.
Added Astronomy.geoMoonState and Astronomy.helioState functions.
These allow calculating the position and velocity of any
solar system body.
Added sanity checks for state vectors in the unit tests.
Added calculation of heliocentric and barycentric
state vectors for Pluto. This is done using
a gravity simulator that treats Pluto as a negligible
mass that is affected by the major masses of the
Solar System: Sun, Jupiter, Saturn, Uranus, Neptune.
Updated the code generator to write the Kotlin
version of the Pluto state table, a lookup table
of known-correct state vectors of Pluto at long
intervals, derived from the TOP2013 model.
The gravity simulator interpolates state vectors
of Pluto between these known-correct states.
Minor code style cleanup in the Kotlin source.
Fixed a possible thread-safety issue in the C# code.
Implemented the VSOP87 calculation functions for
heliocentric position vectors, heliocentric velocity vectors,
and heliocentric distances.
Implemented Astronomy.helioVector for everything except Pluto and SSB.
Corrected small errors in C# documentation.
Implemented the Montenbruck/Pfleger version of the NAO1954
geocentric Moon model in Kotlin.
In the process, code review helped simplify parts of the C# code.
I may want to go back and see if I can simplify the CalcMoon
code in the other languages too.
Added code generator for VSOP87 major planet models in Kotlin.
Added a lookup function for VSOP87 models to Kotlin template.
Moved IAU2000b delcaration outside class Astronomy.
Added the rotationAxis, which calculates dynamic orientation
of planet, Sun, and Moon rotation axes. Added the first
unit test that verifies against JPL Horizons data.
Eliminated more redundant time parameters in precession functions.
More cleanup of C# code: I realized the private function
vector2radec was redundant with the public function EquatorFromVector.
Deleted vector2radec.
Added functions for generating rotation matrices,
rotating position vectors, and rotating state vectors,
for the Earth's axial nutation.
Simplified gyration functions in C#:
it turns out the `time` parameters were redundant,
because time is included in the `t` field of the vector
passed in. I reworked the C# code to eliminate those time
parameters.
The Kotlin code follows suit.
Implemented the functions `terra` and `inverseTerra`.
`terra` converts geographic coordinates and time into
a geocentric state vector.
`inverseTerra` converts a position vector and time
into geographic coordinates.
I realized the C# function `inverse_terra` could be
simplified. It does not need to be passed a separate
time, because the sidereal time can be derived
from, or has already been stored inside, the vector's
time field `ovec.t`.
There were a couple of other minor cleanups to the C# code.
Implemented Astronomy.siderealTime() in Kotlin.
Updated all languages' unit tests for sidereal time
to verify exact conformity between them, rather than
to an externally derived value. I wanted to make
sure all languages, including Kotlin, are calculating
the exact same value.
I don't need an external authoritative test for
sidereal time, because it will be indirectly tested
through its involvement in thousands of other calculations
that depend on it. I just need a quick sanity check
before implementing those other things that depend on it.
Implemented the iau2000b nutation formula.
Implemented calculation of the precession
rotation matrix.
This is the very first use of a code generator
macro for the Kotlin code. I am going to try
keeping all these macros toward the bottom
of the source tepmlate, so that as I look at
line numbers for compiler errors, they will match
between the target code and the template code.
I may go back and rework the other languges to
do this also. I'm not sure why I didn't think
of this before!
Ported the following types to the Kotlin code:
GlobalSolarEclipseInfo
EclipseEvent
LocalSolarEclipseInfo
TransitInfo
ShadowInfo
IllumInfo
AxisInfo
NodeEventKind
NodeEventInfo
Made some wording fixes in the documentation for the
other languages.
Converting between radians and degrees.
Clamping angles to a desired range of degrees.
Converting between vector, spherical, horizontal.
Refraction and inverse refraction.
Implemented most of the RotationMatrix functions.
Added unit tests for combining rotation matrices, using a
rotation matrix to rotate a vector, and pivoting a rotation
matrix around its axes.
Replaced AstroVector operator '*' with infix function 'dot',
because it removes ambiguity between vector dot products
and vector cross products.
Later I will add a 'cross' infix function too.
Corrected minor typo in documentation for Python, C, C#, JavaScript.
"trasnform" -> "transform"
Moved Astronomy object to bottom of source file.
This object is going to end up with a lot of functions,
so it's best to keep outer classes above it.
Removed unnecessary empty {} after classes.
Replace Array<Array<Double>> with Array<DoubleArray>.
This is more efficient because Array<Double> boxes the numbers
inside it, whereas DoubleArray is unboxed.