The Mac OS tests failed because the Kotlin Native
compiler created an unexpected directory:
demo/kotlin/native/moonphase.kexe.dSYM/
I fixed this by adding *.dSYM to .gitignore.
Also, the GitHub Action `fwilhe2/setup-kotlin@main`
defaults to an older version of the compiler.
I added an option to specify using version 1.6.20.
Nothing very interesting yet.
Just building a very basic Kotlin Native app
to make sure build and execute work on GitHub Actions,
on Linux and Mac OS. I will worry about Windows later.
I found out in the Kotlin branch that GitHub Actions
only checks for error codes in the last step of the
Windows commands it executes. I moved all the command
line steps into a batch file generate\commit_hook.bat.
It does all the error checking itself.
A build error slipped through because both
ebraminio and I were making changes to the Kotlin
code at the same time. Just needed to reorder
the parameters to a call to `search`.
I just noticed a build problem in the Kotlin code
was detected by GitHub Actions in Linux and Mac OS,
but not in Windows. It marked the Windows test as
a success, even though the output clearly shows that
run.bat failed. I theorize that the steps inside
the file .github/workflows/astronomy-engine-tests.yml
are not being checked for errors after each step, but
only after all of them execute. So I have moved them
into a new batch file generate/commit_hook.bat, which
does check each step.
After pushing this change, all 3 builds should fail.
Once I get Windows to fail also, I will fix the failure.
Added functions:
searchGlobalSolarEclipse
nextGlobalSolarEclipse
These functions find a solar eclipse that is visible
somewhere on the Earth. They report the time of the
eclipse, what kind it is (partial, annular, total),
and if annular/total, the geographic location where
the eclipse is greatest.
Added functions:
searchLunarEclipse
nextLunarEclipse
These allow searching for a series of consecutive
lunar eclipses, including penumbral, partial,
and total eclipses.
Added a few extra functions that will be used soon
to search for solar eclipses (global and local) and
transits of Mercury and Venus.
I discovered that the build process on Windows
was still using Dokka to make html, not markdown.
Fixed this to maintain compatibility with the
build process for Linux and Mac OS.
Moved the step that creates the fatJar into
the main build process for Kotlin. This is
needed to run the Java demos, and it is good
to fail early if it cannot be built.
Renamed AstroTime to Time.
Renamed AstroVector to Vector.
For some reason this breaks the Java demo build.
I'm pushing the broken build anyway to see if
ebraminio can help me fix it.
Changed RotationMatrix.identity from a variable to a function.
I want to leave open the possibility of mutating matrices
in the future, for the sake of performance critical code.
That means it is a good idea to create a new matrix to avoid
unintended side effects.
Removed redundant function equatorFromVector.
It was the same as Vector.toEquatorial.
Moved nextMoonQuarter to be right after searchMoonQuarter.
Somehow other functions had ended up between them.
Simpler syntax for initializing SearchContextPeakAltitude.
Added `Observer.toStateVector` and `Observer.toVector` for converting
an observer's geographic location to position and velocity vectors
relative to the Earth's center.
Reworked the C unit test to output a text file that can be used
as reference, to make sure the Kotlin output matches.
I forgot that Mac OS does not have sha256sum
installed by default. This caused the worldmap
demo test to fail, trying to confirm that I got
the output PNG image I expected.
The demo worldmap.cpp now also prints out the
geographic locations where the Sun/Moon appear
to be straight up (at the zenith) for the given time.
This illustrates that Astronomy_VectorObserver can
turn a geocentric vector into a location on the
Earth that is in the same direction from the Earth's
center that a given celestial body lies.
The worldmap.cpp demo was calculating each pixel's
observer location twice. Now it does so only once.
Added verification that the output PNG file is
exactly as expected, using a sha256 checksum.
The new demo worldmap.cpp generates a PNG image of
a Mercator projection of the Earth, showing color-coded
intensity of sunlight (yellow) and moonlight (blue).
This sample program shows how to efficiently calculate
horizontal altitudes of the Sun and Moon across many
different geographic locations, for a given observation time.
Backported fixes to the Seasons functions in
C, C#, Python, and JavaScript. They were failing
to find equinoxes and/or solstices for distant
year values.
Also brought over some other minor code cleanup.
For years before 1582 or years after 3668, the Seasons functions
were unable to find many equinoxes and/or solstices.
The problem was that over time, the Earth's axis precesses
enough that the calendar dates of these events drifts outside
the fixed search ranges I had provided for them.
I expanded the search ranges so all season changes can be found
for a much wider range of years, as verified by unit tests:
C/C++: -2000..9999
C#: 1..9999
JavaScript: -2000..9999
Python: 1..9999
Kotlin: 1..9999
Note: C#, Python, and Kotlin currently do not allow
years values below +1. In fact, I discovered we were not
noticing when an invalid year was passed into the Kotlin code.
I updated that code to throw an exception when the year does
not match what was expected. It is disturbing that the
GregorianCalendar class silently ignores invalid years!
Constricted the search tolerance from 1 second to 0.01
seconds for the seasons search, to ensure more consistent
behavior.
Fixed a bug in the Kotlin search() function's
quadratic interpolation that was causing the convergence
to be slower than it should have been.
Added Astronomy.searchAltitude, which enables more generic
searches for altitude events. The most common use for these
are finding civil, nautical, and astronomical twilight times.
Implemented the following Kotlin functions:
Astronomy.searchHourAngle
Astronomy.searchRiseSet
The Kotlin code can now search for rise/set
times for a given Earthbound observer for the
Sun, Moon, or any planet.
It can also search for times when a given body
reaches a desired hour angle. This has its own
value (for example, culmination), but is also
used to assist finding time brackets that bound
rise/set events.
Added special case exception type:
EarthNotAllowedException.
This follows the pattern of the other languages,
and makes diagnosing a violation easier than
the more generic InvalidBodyException.
Minor simplifications to the C# function
Astronomy.InternalSearchAltitude.
Improved the comments for the C# unit test
function RiseSetTest. They make the algorithm
easier to understand.
Added the following Kotlin functions:
equatorialToEcliptic
pairLongitude
moonPhase
searchMoonPhase
searchMoonQuarter
nextMoonQuarter
Discovered I could tighten the tolerance for the moon phase
unit tests from 120 seconds to 90 seconds and they still pass.
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.
