This reverts commit a7e747c100.
This broke the GitHub Actions automated tests, because they
are using gcc 11 (which does not support level 3 fortification),
and they already predefine another fortification level.
I realize this would also hinder other contributors who
are not using gcc 12. At least I tried it once on my own
system and didn't find any problems, which is nice.
The following build error occurred in Mac OS:
Compiling altazsearch.cpp
clang: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated]
Added options to explicitly perform mixed C/C++ programming.
See the following discussion for context:
https://github.com/cosinekitty/astronomy/discussions/308
Added a demo program that shows how to search for when
a body enters a window defined in terms of an observer's
horizontal frame of reference, given a range of altitudes
and a range of azimuths.
The camera demos all have a bug where I was calculating
the angle of the sunlit side of the Moon incorrectly.
The arguments to atan2 were backwards.
Added test data for Florida, New Zealand, and Canada
that are backed up by photographic evidence and
my first-hand observation.
Now the C function Astronomy_Ecliptic returns ecliptic
coordinates in true equinox of date instead of the
J2000 mean equinox. I'm doing this because it is a
better fit for physical phenomena that ecliptic
coordinates are often used for. For example, lunar nodes,
eclipses, phase angles, and oppositions make more sense
with true latitude and longitude of date.
I will port these changes to the other languages also.
While trying to convert ecliptic coordinates from mean
equinox of date to true equinox of date, I ran into excessive
overhead from the IAU2000B nutation model. The fact that it
uses 77 trigonometric terms made the calculations a lot slower.
https://apps.dtic.mil/sti/pdfs/AD1112517.pdf
Page 4 in the above document mentions a shorter series
“NOD version 2” that has 13 terms instead of 77 as used in IAU2000B.
I had not noticed NOD2 before, because it appears only in
the FORTRAN version of NOVAS 3.x, not the C version.
After reading the FORTRAN code, I realized NOD2 is the same
as IAU2000B, only it keeps the first 13 of 77 terms.
The terms are already arranged in descending order of
significance, so it is easy to truncate the series.
Based on this discovery, I realized I could achieve all of
the required accuracy needed for Astronomy Engine by
keeping only the first 5 terms of the nutation series.
This tremendously speeds up nutation calculations while
sacrificing only a couple of arcseconds of accuracy.
It also makes the minified JavaScript code smaller:
Before: 119500 bytes.
After: 116653 bytes.
So that's what I did here. Most of the work was updating
unit tests for accepting slightly different calculation
results.
The nutation formula change did trigger detection of a
lurking bug in the inverse_terra functions, which convert
a geocentric vector into latitude, longitude, and elevation
(i.e. an Observer object). The Newton's Method loop in
this function was not always converging, resulting in
an infinite loop. I fixed that by increasing the
convergence threshold and throwing an exception
if the loop iterates more than 10 times.
I also fixed a couple of bugs in the `demotest` scripts.
For consistency, I now calculate the Sun's apparent position
correcting for aberration, for lunar eclipses and transits.
This didn't make much difference for accuracy.
Before correcting for Sun aberration:
$ ./ctest transit
C TransitFile(eclipse/mercury.txt ): PASS - verified 94, max minutes = 10.709, max sep arcmin = 0.2120
C TransitFile(eclipse/venus.txt ): PASS - verified 30, max minutes = 9.108, max sep arcmin = 0.6772
$ ./ctest -v lunar_fraction
C LunarFractionCase(2010-06-26) fraction error = 0.00900991
C LunarFractionCase(2012-06-04) fraction error = 0.00491535
C LunarFractionCase(2013-04-25) fraction error = 0.00143039
C LunarFractionCase(2017-08-07) fraction error = 0.00682336
C LunarFractionCase(2019-07-16) fraction error = 0.00572727
C LunarFractionCase(2021-11-19) fraction error = 0.00350680
C LunarFractionCase(2023-10-28) fraction error = 0.00370518
C LunarFractionCase(2024-09-18) fraction error = 0.00429906
C LunarFractionCase(2026-08-28) fraction error = 0.00322697
C LunarFractionCase(2028-01-12) fraction error = 0.00405870
C LunarFractionCase(2028-07-06) fraction error = 0.00857840
C LunarFractionCase(2030-06-15) fraction error = 0.00557106
C LunarFractionTest: PASS
After correcting for Sun aberration:
$ ./ctest transit
C TransitFile(eclipse/mercury.txt ): PASS - verified 94, max minutes = 10.709, max sep arcmin = 0.2120
C TransitFile(eclipse/venus.txt ): PASS - verified 30, max minutes = 9.108, max sep arcmin = 0.6772
$ ./ctest -v lunar_fraction
C LunarFractionCase(2010-06-26) fraction error = 0.00762932
C LunarFractionCase(2012-06-04) fraction error = 0.00606322
C LunarFractionCase(2013-04-25) fraction error = 0.00111560
C LunarFractionCase(2017-08-07) fraction error = 0.00571542
C LunarFractionCase(2019-07-16) fraction error = 0.00713913
C LunarFractionCase(2021-11-19) fraction error = 0.00298979
C LunarFractionCase(2023-10-28) fraction error = 0.00448445
C LunarFractionCase(2024-09-18) fraction error = 0.00367044
C LunarFractionCase(2026-08-28) fraction error = 0.00405559
C LunarFractionCase(2028-01-12) fraction error = 0.00347340
C LunarFractionCase(2028-07-06) fraction error = 0.00729982
C LunarFractionCase(2030-06-15) fraction error = 0.00680776
C LunarFractionTest: PASS
The following C functions now support searching
in forward or reverse chronological order:
Astronomy_SearchRiseSet
Astronomy_SearchAltitude
Astronomy_SearchHourAngleEx
The function Astronomy_SearchHourAngleEx replaces
Astronomy_SearchHourAngle, adding a new `direction` parameter.
A #define for Astronomy_SearchHourAngle preserves backward
compatibility for older code.
Implementation notes:
Astronomy_SearchRiseSet and Astronomy_SearchAltitude used
to call a private function InternalSearchAltitude.
That function has been split into two functions:
BackwardSearchAltitude and ForwardSearchAltitude,
for searching both directions in time.
Fixed a bug where it was possible to report a successful
altitude event that went outside the time limit specified
by `limitDays`.
Simplified the Jupiter moon raytraced image demo
by using Astronomy_BackdatePosition to directly
calculate the vector while returning the backdated
time directly. This eliminates a redundant calculation
using the distance divided by the speed of light.
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.
I made the scripts for testing the demos for
C, C#, JavaScript, and Python follow the improved
pattern used for Java and Kotlin: much smaller
and easier to maintain thanks to bash functions.
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.
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.
The phrase "Moon phase" is ambiguous, because sometimes
it means relative ecliptic longitude, other times it means
illuminated fraction. The "moonphase" demos were only
calculating the relative ecliptic longitude, which was
confusing. Now they calculate both.
Reduce the number of redundant Earth nutation calculations
by passing astro_time_t values as pointers in more functions.
Nutation values can then be cached in the time parameter
and passed to other functions that can then avoid calculating
the same nutation again.
Nutation is an expensive calculation, so reducing this overhead
can dramatically speed up certain use cases.
This was only needed in C, because this is the only language
in which times are passed by value. In Python, C#, and JavaScript,
times are objects that are already passed by reference, and
they already benefit from this nutation recyling approach.
The following functions have had their parameters changed.
This is a breaking change, but in every case, the caller
usually just needs to change `time` to `&time`.
Astronomy_Rotation_EQD_EQJ
Astronomy_Rotation_EQD_ECL
Astronomy_Rotation_EQD_HOR
Astronomy_Rotation_EQJ_EQD
Astronomy_Rotation_EQJ_HOR
Astronomy_Rotation_ECL_EQD
Astronomy_Rotation_ECL_HOR
Astronomy_Rotation_HOR_EQD
Astronomy_Rotation_HOR_EQJ
Astronomy_Rotation_HOR_ECL
Astronomy_RotationAxis
Astronomy_VectorObserver
I found a mistake in the raytracer's Spheroid class,
thanks to a warning about an unused member variable.
I don't believe it had any effect on the currently
generated images, but it was important to fix it before
I ever do any set operations on Spheroids.
On macOS, there is no 'realpath' command by default.
So I eliminated some more attempts to use 'realpath'
in the demo test scripts.
Renamed the GitHub Actions tests to be consistent:
Astronomy-Engine-Linux
Astronomy-Engine-Macos
The demo tests on Mac OS failed because of very tiny
floating point discrepancies that don't matter.
Changed the output of the "Moon check" so that slight
differences in vector residue no longer fail the unit tests.
Based on a discovery made by someone helping me get
Astronomy Engine building on the Mac. In some versions
of g++ (aliased to clang), if you don't explicitly tell
the compiler to treat .c files as C++, it gives a warning
that escalates to an error due to -Werror.
So I added the same fix to the raytracer build:
pass in the option '-x c++'.
Pluto is so far away that is angular size seen from Earth
is very small. I had to tweak my internal scaling constants
so that the raytracer was able to resolve it.
Added radius data for the Sun, Moon, and remaining planets.
Test the raytracer for all other bodies except the Earth and Sun.
There is a problem with Pluto that I still need to figure out.
Fixed an issue in the doxygen-to-markdown translator I wrote
(hydrogen.js): it did not handle when one #define referred
to another #define. Created a more generic markdown expansion
that works in all cases, and creates embedded hyperlinks.
Refactored the Jupiter imager to be a generic planet imager.
Added support for drawing an image of Venus.
Verified that its extreme crescent phase looks correct
for the current date.
I will add radius constants to astronomy.h for each body I support.
The raytracer now includes the option -s (without a numeric
spin angle on the command line) to automatically calculate
the spin angle needed to bring the planet's north pole
exactly upward in the generated image.
Improved the way I create the rotation matrix that
aims the virtual camera at Jupiter. The camera still
aims exactly at Jupiter, but this time it defaults
to having the left/right pixel direction aligning
with the Earth's equator. By experiment, I can spin
the longitudinal camera axis by -10 degrees and get
a good fit with Jupiter's equatorial plane. I will
adjust this more exactly in a future commit.
Now the raytracer requires the user to pass in
both the pixel width and pixel height on the command line.
This allows for generating non-square images, which will
be necessary for the general case of imaging the moons
with respect to the planet.
Now that I have eliminated refraction and reflection
from the astronomy raytracer, there is no need for an
Optics class that represents matte, gloss, and index
of refraction.
