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.
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.
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!
Implemented the C function Astronomy_BaryState().
Used JPL Horizons to generate some test data.
Started work on the C unit test for BaryState,
but it is not yet finished. This is just a good
checkpoint for this work in progress.
I realize some use cases require adjustments for
stellar aberration. The existing aberration adjustments
are only supplied for calculating planet positions.
Some users will benefit from being able to add/subtract
aberration corrections to arbitrary vectors, including
for star positions.
I have added some JPL Horizons test data to help
validate the aberration functionality I'm about to add.
I created the beginning of a unit test in ctest.c,
but currently there is no aberration correction
implemented, so the test has no error threshold.
Instead of the hack call to Search(), the latitude
solver now uses Newton's Method directly. This
significantly speeds up the code, and is more elegant.
Added more exhaustive testing of VectorObserver.
I found a few cases where the height calculation
was off by more than 5 millimeters.
In the VectorObserver function, require the latitude solver
to keep iterating until the error is less than one billionth
of a degree. Now the height error is always within 1 mm.
I already had the function ObserverVector that converts geographic
coordinates (latitude, longitude, elevation) to an equatorial-of-date
(EQD) vector.
Now I'm in the process of adding the inverse function VectorObserver
that calculates geographic coordinates from an EQD vector.
This commit implements VectorObserver in Python.
The other languages will follow in future commits.
The motivation was from the following request:
https://github.com/cosinekitty/geocalc/issues/1
The goal is to find the near-intersection between two different lines
of sight from two different observers on the Earth's surface.
Added a demo program triangulate.py that solves this problem.
Ported conversion to/from galactic coordinates to Python.
Added unit test for new Python code.
Updated documentation for all 4 supported languages.
Fixed mistakes in JavaScript function documentation.
I added this test, but unfortunately I could not figure
out how to make JPL Horizons generate equatorial and galactic
coordinates using the same aberration model. This appears
to introduce an extra 22 arcseconds of error.
Added a sanity check in the unit tests that the functions
Astronomy_Rotation_EQJ_GAL and Astronomy_Rotation_GAL_EQJ
return matrices that really are inverses of each other.
Added the following C functions:
Astronomy_Rotation_EQJ_GAL
Astronomy_Rotation_GAL_EQJ
These return rotation matrices to convert between
the galactic and J2000 equatorial orientation systems.
I wrote a quick Python program based on an original reference
paper defining the galactic orientation system.
It generates a rotation matrix from first principles
that matches one inside the NOVAS function equ2gal(),
within the expected 2.3 arcsecond difference between
ICRS and EQJ.
NOVAS equ2gal matrix:
double ag[3][3] = {
{-0.0548755604, +0.4941094279, -0.8676661490},
{-0.8734370902, -0.4448296300, -0.1980763734},
{-0.4838350155, +0.7469822445, +0.4559837762}};
This program's generated matrix:
B1950 = 1949-12-31T22:09:21.346Z
-0.0548624779711344 0.4941095946388765 -0.8676668813529025
-0.8734572784246782 -0.4447938112296831 -0.1980677870294097
-0.4838000529948520 0.7470034631630423 0.4559861124470794
Also added some JPL Horizons test data to confirm
conversion back and forth between EQJ and GAL, which
I will use for future tests.
Starting work on support for galatic coordinates.
Generate a test data file using calculations made
by the NOVAS function equ2gal(). Later I will use
this data to verify the conversion functions I
write for Astronomy Engine.
Decreased the minified browser code from 94918 bytes to 94221 bytes.
Did this by using a more efficient encoding of the IAU2000B nutation model:
instead of making {nals:[_], cls:[_]} objects, make lists of lists [[_], [_]].
Ran 'npm audit fix' to resolve some security vulnerabilities
in the developer tools in the 'generate' directory.
None of the vulnerabilities affect the npm package
astronomy-engine, because it has no external dependencies.
The risk was only to developers who run the code generation
tools, not end users. Even then, the risk is minimal because
these tools run with well-defined inputs that are not subject
to external tampering.
Started work on a Python demo for finding when the moon
reaches relative longitudes with other solar system bodies
that are multiples of 30 degrees. It is not finished yet,
but getting close.
Added operator overloads for the Python Time class so
that times can be compared against each other.
This makes it easier to sort a list of times, for example.
