Tonight as I was walking outside, I saw a fairly bright
star about half a degree away from the edge of the Moon.
I wondered what it was, so I decided to write a quick
program to find out.
This Python demo program scans the HYG Database
(https://github.com/astronexus/HYG-Database)
to find which bright stars are within a small angular
distance of the Moon, as seen at a given time, latitude, and longitude.
It turns out the star I saw was Nunki (Sigma Sagittarii).
It was handy to do vector subtraction to implement this program,
and it was trivial to do in the Python code's Vector class,
so I went ahead and added that.
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.
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.
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.
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).
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.
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 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 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.
When I merged from calendar2 branch into master branch,
I forgot to run the unit tests locally and commit the
code generation changes it caused. This has been fixed.
