This is a thin wrapper function for the internal
function CalcMoon, which has already been extensively
validated. It will enable outside users to search
for ascending and descending nodes of the Moon,
or to calculate ecliptic spherical coordinates for the Moon
for any other useful purpose.
Changed the documentation for the GeoMoon and GeoMoonState
functions to make it explicit that they calculate coordinates
oriented with respect to the Earth's J2000 equator (EQJ).
This is because I will soon add ecliptic (ECL) counterparts
for the GeoMoon function, to more directly search for ascending
and descending nodes of the Moon.
Added data for testing Lagrange point calculations,
which has yet to be implemented. JPL Horizons
provides L1, L2, L4, and L5 (but *not* L3) calculations
for:
Sun / EMB
Earth / Moon
where EMB = Earth/Moon Barycenter.
See this discussion:
https://github.com/cosinekitty/astronomy/issues/150
For the case of calculating a map, where each pixel
on the map represents a different location on the Earth,
it is more efficient to factor out expensive calculation
of sidereal times, assuming the entire map represents
some phenomenon at a single moment in time.
For example, to determine whether the Moon is visible
at different places on the Earth, the following
functions can be calculated across thousands of
different (lat, lon) geographic coordinates around
the world:
ObserverVector
Rotation_EQD_HOR
Before iterating over the map pixels, a program
can call GeoMoon, then convert EQJ coordinates to EQD.
Then by passing the same time value in a loop to
ObserverVector and Rotation_EQD_HOR, the program
can calculate a vector from the observer to the Moon
in EQD coordinates, then convert EQD to HOR.
The z-coordinate of the horizontal coordinates
determines whether the Moon is above or below the
observer's horizon at that point on the Earth.
This calculation pattern performed redundant
sidereal time calculations for each pixel on the map.
I changed the code for all 4 languages to cache
sidereal time so that it only needs to be calculated
once.
In the C version of Astronomy Engine, this resulted
in a speedup factor of about 2.3 in the above use case.
(See the function MapPerformanceTest in generate/ctest.c.)
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
For developers wanting to contribute to Astronomy Engine,
the tooling instructions were vague about xsltproc.
I added some useful hints.
I also removed things that don't need to be manually
installed: jsdoc2md, graphviz, etc.
In Windows builds, I was checking for the existence
of md5sum.exe, and if present, I used it for verifying
downloaded files. However, this is not a standard
utility that comes built into Windows 10.
I found there is a standard utility certutil.exe
that can calculate md5, sha256, etc, checksums.
However, it does not verify files created by the
Linux utilities md5sum, sha256sum, etc.
So I created a batch file checksum.bat that invokes
certutil.exe to process one of those listing files.
Reworked run.bat to call checksum.bat instead of
using md5sum.exe.
Thanks to ebrominio, I was able to create a pip
package for Astronomy Engine. See:
https://pypi.org/project/astronomy-engine/1.0.1/
I will probably need to go back and keep the version
numbers in sync with the matching npm package.
From the GitHub Actions logs, it looks like verify_clean.bat
is not running after run.bat, like I intended. I'm guessing I
need to add "call" before both batch files to ensure that
control returns to the caller.
Weirdly, the python program for generating constellation
data did not seem to run, but that failure did not break
the build directly. I am adding an explicity 'py' command
to run each Python program. Also added a check for missing
output constellation test data.
The version of md5sum.exe that runs in GitHub Actions
gets confused when its input file ends with CRLF,
which is weird because this is supposed to be a Windows
environment. So I added a .gitattributes to force
these checksum files to have LF line endings.
In the GitHub Actions CI environment, the program md5sum.exe
resides in "C:\Program Files\Git\usr\bin\md5sum.exe".
Therefore, to execute it, I need quotes around the executable.
The 'windows' directory is mainly useful for
maintainers, not end users. So I moved it out of
the root to reduce distraction for a first-time
visitor.
While I was fixing up resulting breakage in
Visual Studio project files, I noticed I still had
some hard-coded absolute paths that would only work
on my own Windows laptop (e.g. "c:\don\github\astronomy").
I replaced those with relative paths that will work
regardless of what directory the repo is cloned into.
Safari does not work when you try to do this in JavaScript:
const date = new Date('2022-01-08 17:26:59');
Instead, it requires a 'T' between the date and the time:
const date = new Date('2022-01-08T17:26:59');
Fixed this issue in the moonradar.html and positions.html demos.
We still render the date/time as normal, with the space,
but parse it by replacing the space with 'T'.
Thanks to @ebraminio for reporting this!
The code generator was creating slightly different numeric
values for the Pluto state tables and the Jupiter rotation matrix.
I decreased the output precision by one decimal digit.
This should allow the code generator to produce identical
source code on both Linux and macOS.
More work getting MacOS build process to work.
Avoid excessive number of floating point digits of
output in the demo tests, so that insignificant
floating point variations don't cause unit test failures.
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.
Two different people are currently helping me get the
build process working on Mac OS. They both ran into different
amounts of comparison error in the calculations for different
langauges. I updated the 'diffcalc' bash script to have
slightly less strict tolerances, so the unit tests pass.
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++'.
When built using g++ as an alias for clang,
as reportedly happens on Mac OS, we need to explicitly
tell g++ (using option '-x c++') to compile astronomy.c
as C++. Otherwise, it will fail with a deprecation warning.
