Backported fixes to the Seasons functions in
C, C#, Python, and JavaScript. They were failing
to find equinoxes and/or solstices for distant
year values.
Also brought over some other minor code cleanup.
While working on the Kotlin implementation, I have
found a few documentation mistakes in the other language
implementations. These have been accumulating in the
`kotlin` branch. I migrated these changes back into
the released code for now, because I don't want to wait
until Kotlin is ready.
The pip package was broken!
I violated ancient software development wisdom:
"If you haven't tested it, it doesn't work."
It is now working in:
https://pypi.org/project/astronomy-engine/2.0.15/
Version 2.0.15 of Astronomy Engine for Python (pip)
and Node.js (npm) add support for the new SiderealTime
function. This was previously an internal function,
but now it is exposed for outside callers.
There was already an internal function for calculating
Greenwich Apparent Sidereal Time (GAST). By request,
I have exposed this function for outside users.
Added a minimal unit test to verify the function is
callable and returns the correct result for one case.
This function is already exhaustively tested by unit
tests that verify other functions that already called
this function when it was internal, so minimal testing
is sufficient in this case.
The way I was publishing the Python package was annoying.
I found a better way to authenticate myself to pypi.org,
but I needed to test it. This required bumping the version
numbers of the packages. There is no difference between
2.0.12 and 2.0.13.
Added the following new functions to all 4 languages:
MassProduct: find the GM product for all Solar System bodies.
LagrangePoint: calculate L1..L5 state vectors for a pair of bodies.
LagrangePointFast: calculate L1..L5 state vectors given
state vectors and GM products of a pair of bodies.
In languages that support it, using hypot(x,y) is a little
easier to read than sqrt(x*x + y*y). Some documentation
(e.g. the man page for the C function) leads me to believe
hypot might also be better behaved than sqrt in some cases.
The JavaScript Math.hypot() is especially nice because it works
for any number of dimensions, so I can use it in 2D and 3D cases.
C only allows 2D usage, as does Python 3.7. Python 3.8 added
support for any number of dimensions, but I don't want to break
compatibility with Python 3.7 just yet. Therefore, in C and Python,
I am only using hypot for 2D cases.
C# does not appear to have any kind of hypot function,
so no changes were made to the C# code.
Thanks to https://github.com/ebraminio for this suggestion.
Python and npm package version: 2.0.11.
Finished implementing new functions across all
supported languages:
EclipticGeoMoon
Calculate the Moon's ecliptic geocentric position
in angular coordinates. The ecliptic longitude is
measured with respect to the mean equinox of date.
SearchMoonNode
NextMoonNode
A pair of functions to search for consecutive occurrences
of the Moon's center passing through the ecliptic plane.
Changed the documentation for the GeoMoon and GeoMoonState
functions to make it explicit that they calculate coordinates
oriented with respect to the Earth's J2000 equator (EQJ).
This is because I will soon add ecliptic (ECL) counterparts
for the GeoMoon function, to more directly search for ascending
and descending nodes of the Moon.
See this discussion:
https://github.com/cosinekitty/astronomy/issues/150
For the case of calculating a map, where each pixel
on the map represents a different location on the Earth,
it is more efficient to factor out expensive calculation
of sidereal times, assuming the entire map represents
some phenomenon at a single moment in time.
For example, to determine whether the Moon is visible
at different places on the Earth, the following
functions can be calculated across thousands of
different (lat, lon) geographic coordinates around
the world:
ObserverVector
Rotation_EQD_HOR
Before iterating over the map pixels, a program
can call GeoMoon, then convert EQJ coordinates to EQD.
Then by passing the same time value in a loop to
ObserverVector and Rotation_EQD_HOR, the program
can calculate a vector from the observer to the Moon
in EQD coordinates, then convert EQD to HOR.
The z-coordinate of the horizontal coordinates
determines whether the Moon is above or below the
observer's horizon at that point on the Earth.
This calculation pattern performed redundant
sidereal time calculations for each pixel on the map.
I changed the code for all 4 languages to cache
sidereal time so that it only needs to be calculated
once.
In the C version of Astronomy Engine, this resulted
in a speedup factor of about 2.3 in the above use case.
(See the function MapPerformanceTest in generate/ctest.c.)
The code generator was creating slightly different numeric
values for the Pluto state tables and the Jupiter rotation matrix.
I decreased the output precision by one decimal digit.
This should allow the code generator to produce identical
source code on both Linux and macOS.
Added documentation about the missing `date` parameter
to the `Elongation` function in the JavaScript version.
I reviewed all the other JavaScript functions to make sure there
were no other similar mistakes with parameters or return types.
Along the way, I discovered and fixed some other issues:
Fixed miscellaneous typos in the documentation.
Consistently refer to enumeration values like `Body.Earth`
instead of strings like `"Earth"`. I want to encourage
use of the enumerations because they make type-checking easier,
especially for TypeScript code.
Reworked `AstroTime` parameters to `FlexibleDateTime` parameters
in all exported functions. This is completely backward-compatible,
and allows callers more flexibility with passing `AstroTime`,
`Date`, or numeric day values.
I'm concerned that a first-time visitor to the Astronomy Engine
repo on GitHub will get lost. I made it more obvious where to
quickly find the source code needed for a given language.
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.
These security updates do not affect users of Astronomy Engine.
They were flagged by Dependabot on GitHub to the steps
I use for building the TypeScript/JavaScript versions of
Astronomy Engine. The resulting code does not have any
external dependencies that need to be maintained.
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 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.
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.
