The C and C# Illumination functions now return
a `phase_fraction` result to complement `phase_angle`.
This makes them consistent with the Python and JavaScript
versions.
There is now a Libration function in all 4 supported languages.
The returned structure contains libration angles in
ecliptic latitude and ecliptic longitude, along with
the Moon's ecliptic position and distance.
Also included is the Moon's apparent angular diameter.
All 4 languages have added a `diam_deg` field to the
structure returned by the Libration function.
It is the apparent angular diameter of the Moon as
seen from the center of the Earth, expressed in degrees.
Because I have to perform the expensive calculation to find
the Moon's ecliptic coordinates, I might as well return them
to the caller. This could help reduce calculation overhead
for some uses, and doesn't add any significant cost.
I could not measure a significant difference in calculation
accuracy from doing the expensive earth-tilt step.
I removed it to significantly speed up the calculation.
I discovered that when I tried to build astronomy.c as C++ code,
I got several errors and warnings. So I fixed those issues and
added a C++ build-check to the unit tests.
I discovered that when I tried to build astronomy.c as C++ code,
I got several errors and warnings. So I fixed those issues and
added the C++ build-check to the unit tests.
The newer gcc generates warnings when a function
is declared to take a sized array parameter, but the caller
passes an array of smaller dimension. In these cases, the
intention was to pass arrays of variable size, so I deleted
the specific array sizes.
In JavaScript and Python, throw an exception if provided
an invalid refraction option. Especially in JavaScript,
it was too easy to pass in a value like 'true', which did
not calculate refraction as expected.
The current Raspbian uses an older version of pylint
that suffers from a recursion overflow. Hacked a deeper
recursion limit to work around this issue.
Also directly calling 'pylint' does not work in Raspbian.
Instead of trying to figure out why, I just use 'python3 -m'
to invoke pylint.
Refactored SearchRiseSet to create a new function
InternalSearchAltitude. SearchRiseSet calls InternalSearchAltitude,
and the new function SearchAltitude also cals InternalSearchAltitude.
This causes the code to be only a tiny big larger.
This is the beginning of adding support for calculating
civil, nautical, and astronomical twilight (dawn/dusk).
Just added the stubbed unit test without the call in place
for the new function that will be added: SearchAltitude.
I'm doing Astronomy Engine development from different
Debian versions (Buster and Bullseye). Buster installs
doxygen version 1.8.13, but Bullseye installs version 1.9.1.
These two versions of doxygen generate slightly different output
for function pointer typedefs: the older version adds an extra
space between the '*' and the defined type name.
I need the output to be exactly the same so that
the continuous integration tests don't see any changed
files in git after they finish running.
So I added an extra step in hydrogen.js (the code I wrote
that converts the doxygen output into markdown) to squash
multiple contiguous spaces into a single space in the
typedef output.
The unit tests for the calendar.ts demo program
assumed that the 'tsc' typescript compiler was
installed globally. Redirect it to the typescript
installed in the 'generate' folder.
I could have just made typescript a dependency,
but it seemed wasteful of disk space to have two
copies of the same thing (it is currently 54MB).
Worked around an issue where the npm package google-closure-compiler
assumes the current architecture is Intel x64.
This caused a broken install on the Raspberry Pi.
Detect non-Intel architecture and fall back to installing
only the Java version of the Closure compiler.
The following security issue was reported by
Dependabot for the code generator script:
https://github.com/advisories/GHSA-hj48-42vr-x3v9
The issue was that the npm package path-parse 1.0.6
had a regex denial-of-service attack.
I have updated to use path-parse 1.0.7.
The user-facing Astronomy Engine library has no external
dependencies, so there is no need for most users to
be concerned with this change. The only affected component
was the internal code generator used to produce the
distributed source files, which is only run on my own
machine and the GitHub CI hook when I push a new change.
I verified that this update has no effect on the generated code.
The formatting of the JS documentation for class
GlobalSolarEclipseInformation was messed up in the
generated Markdown file. Fixed that issue in the
JS comments.
Bumping npm version to 2.0.6, to include recent
barycentric state and Earth gravity calculations.
Implemented the C function Astronomy_ObserverGravity.
It implements the WGS 84 Ellipsoidal Gravity Formula,
yielding the effective observed gravitational acceleration
at a location on or above the Earth's surface.
Wrote a demo program that also serves as a unit test.
I verified a few of the calculations, so the file
demo/c/test/gravity_correct.txt also serves as correct
unit test output.
Added a web page that calculates the round trip time
of a radar pulse from an observer at a given location on
the surface of the Earth to bounce from the Moon and return
back to that observer.
The aberration unit test that relies on barycentric
velocity calculation for the Earth's geocenter
has been ported from C to JS and shows identical results.
Ported the C version of BaryState to JavaScript.
Fixed an issue in both the C and JS unit tests:
the JPL Horizons data is given in terms of TT, not UT.
I updated the C aberration unit test to use the barycentric
velocity of the Earth to adjust the apparent position of
a star. This brought the error compared to JPL Horizons
data down from 20.5+ arcseconds to less than 0.4 arcseconds.
Success!
