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!
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.
Allow this demo to use the current date and time by
default if the user does not specify one on the command
line. This required changing the order of the command line
parameters.
Given the right ascension and declination of a star,
expressed in J2000 coordinates, this demo converts those coordinates
to right ascension and declination expressed in the Earth's
equator at any given date and time. This example illustrates
how to use rotation matrices to convert one coordinate system
to another.
This example was prompted by the question at:
https://github.com/cosinekitty/astronomy/discussions/114
Just like the Python version, this program calculates
the best-fit intersection point for two lines of sight
as seen by two observers. It demonstrates converting
back and forth between geographic coordinates and
geocentric vectors.
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.
The program triangulate.py finds the point in space
where two vantage lines come closest to each other.
It is the midpoint between the closest points on both lines.
Now I print the distance between those two points also,
as a measure of how much uncertainty there is in the
estimation of the target object.
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.
