Now the Python version of Astronomy Engine supports calculating
the Earth/Moon Barycenter (EMB) state vector (position and velocity)
relative to the Earth's center (geocentric) or relative
to the Solar System Barycenter (SSB).
This completes support for this feature across C, C#, JavaScript, and Python.
The BaryState function did not support Pluto before.
Refactored the code so that the internal CalcPluto function
returns both the position and velocity, and its caller
can select from heliocentric or barycentric coordinates.
HelioVector asks for heliocentric coordinates and keeps
only the position vector. BaryState asks for barycentric
coordinates and returns both position and velocity.
I added test data for Pluto generated by JPL Horizons.
It turns out the Pluto system barycenter is the best fit
for TOP2013, presumably because Charon causes Pluto to
wobble quite a bit.
I also generated JPL Horizons test data for the Moon
and the Earth/Moon barycenter, anticipating that I will
support calculating their barycentric state vectors soon.
I had to increase the enforced size limit for minified
JavaScript from 100000 bytes to 120000 bytes.
I guess this is like raising the "debt ceiling".
Fixed a bug in Python unit tests: if "-v" verbose option
was specified, it was printing a summary line for every
single line of input, instead of a single summary after
processing the whole file, as was intended. This is one
of those Python whitespace indentation bugs!
I'm getting much better accuracy sticking with my original
gravity simulator, just with smaller time increments, than
I was with the Runge-Kutta 4 method. The PlutoStateTable
gets a bit larger (51 state vectors instead of 41), but the
accuracy is so much higher.
Removed the Runge-Kutta code because I won't be going back to it.
The Pluto gravity simulator constants now come from
a single source: pluto_gravsim.h. This will allow me
to experiment with the Pluto state table to get a better
compromise between size and accuracy.
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.
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
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.
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.
The calendar enumerator demo now includes inferior and superior
conjunctions of the inner planets (Mercury and Venus), along
with the conjunctions and oppositions of the outer planets
(Mars ... Pluto).
Once a collator has been created, and a caller starts
enumerating events, it does not make sense to be able to add
another enumerator to the collator. So I removed EventCollator.Append().
It was just opening up the possibility of bugs for no good reason.
Client code should decide up front what kind of events it wants
to enumerate and provide a complete list of enumerators.
Then it may use FindFirst/FindNext as many times as it wants
and everything will just work.
Added MoonQuarterEnumerator, which finds new moon, first quarter,
full moon, and third quarter events.
Changed the calendar start date to May 2021, so it is
more relevant to the time I'm testing it.
This is an example of how multiple enumerators can be combined
into an EventCollator. The collator does the minimum amount
of work to keep searching for one event at a time, while always
emitting them in chronological order.
