I noticed on a freshly-cloned Astronomy Engine on Windows,
I started getting JavaScript test failures. The problem was the
script generate/test.js had an inconsistent way of reading text
from files and splitting it into lines. Some of the tests
did not account for \r\n line endings in Windows text files.
So I created a unified approach: a new function ReadLines
that works correctly for Linux and Windows, regardless
of the variant line endings.
This may not work on Mac OS, but I don't have an easy
way of testing that myself. But at least now I can fix
issues like that in one place.
The reason SSB vector errors were larger than other bodies
is because the Sun/Barycenter relationship does not have
position and velocity vectors of a "typical" size.
The distance of a planet from the SSB is fairly constant,
and the speed a planet travels is fairly constant.
Therefore, comparing errors by dividing by the magnitude
of the correct vector usually makes sense for scaling.
But for the barycentric Sun (or the heliocentric SSB),
the magnitude of the vectors can become arbitrarily small,
nearly zero in fact, resulting in surprisingly large ratios.
I compensated for this in all the tests by adding a new rule.
When the error thresholds r_thresh and v_thresh are negative,
it is a flag that indicates they are absolute, not relative.
In other words, r_thresh < 0 indicates that abs(r_thresh) is
the maximum number of astronomical units allowed in position
errors, and v_thresh < 0 specifies maximum AU/day.
This results in more consistent numbers that give confidence
the errors are indeed very small and not worth worrying about.
In the C unit test for barystate, heliostate, and topostate,
I had switched from checking absolute differences to relative
differences. I forgot to do that in the other 3 languages
until now. They are all working consistently in how they
measure calculation errors.
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.
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.
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.
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.
Before making these changes, I had the following discrepancies
between the calculations made by the different programming
language implementations of Astronomy Engine:
C vs C#: 5.55112e-17, worst line number = 6
C vs JS: 2.78533e-12, worst line number = 196936
C vs PY: 1.52767e-12, worst line number = 159834
Now the results are:
Diffing calculations: C vs C#
ctest(Diff): Maximum numeric difference = 5.55112e-17, worst line number = 5
Diffing calculations: C vs JS
ctest(Diff): Maximum numeric difference = 1.02318e-12, worst line number = 133677
Diffing calculations: C vs PY
ctest(Diff): Maximum numeric difference = 5.68434e-14, worst line number = 49066
Diffing calculations: JS vs PY
ctest(Diff): Maximum numeric difference = 1.02318e-12, worst line number = 133677
Here is how I did this:
1. Use new constants HOUR2RAD, RAD2HOUR that directly convert between radians and sidereal hours.
This reduces tiny roundoff errors in the conversions.
2. In VSOP longitude calculations, keep clamping the angular sum to
the range [-2pi, +2pi], to prevent it from accumulating thousands
of radians. This reduces the accumulated error in the final result
before it is fed into trig functions.
The remaining discrepancies are largely because of an "azimuth amplification" effect:
When converting equatorial coordinates to horizontal coordinates, an object near
the zenith (or nadir) has an azimuth that is highly sensitive to the input
equatorial coordinates. A tiny change in right ascension (RA) can cause a much
larger change in azimuth.
I tracked down the RA discrepancy, and it is due to a different behavior
of the atan2 function in C and JavaScript. There are cases where the least
significant decimal digit is off by 1, as if due to a difference of opinion
about rounding policy.
My best thought is to go back and have a more nuanced diffcalc that
applies less strict tests for azimuth values than the other calculated values.
It seems like every other computed quantity is less sensitive, because solar
system bodies tend to stay away from "poles" of other angular coordinate
systems: their ecliptic latitudes and equatorial declinations are usually
reasonably close to zero. Therefore, right ascensions and ecliptic longitudes
are usually insensitive to changes in the cartesian coordinates they
are calculated from.
Now callers can create time objects from either UT (UT1/UTC civil time)
or ephemeris/dynamical Terrestrial Time (TT). The new TT functions
numerically solve to find the UT that produces the given TT based
on the Delta-T value at that UT. This is always a very fast
numerical convergence, because TT and UT are almost perfectly
linear over brief time windows.
I increased the error tolerance slightly for the Jupiter moons model.
This shrank the model tables significantly, giving me some more
breathing room to stay under 100K download size.
Also made time parameters to rotation matrix functions be of
type FlexibleDateTime, and internally convert them to AstroTime.
This should be the policy of all exposed functions in the
JavaScript version of Astronomy Engine.
Exposed KM_PER_AU to outside callers.
This is technically a breaking change, but only for clients
that use the cartesian coordinates in an ecliptic coordinate
return type. Before now, the coordinates were just separate
floating-point members ex, ey, ez. Now they are a standard
vector type.
The purpose is to allow seamless interfacing with vector
rotation functions, and to be consistent with the equatorial
coordinate types.
Instead of declaring all the "body" parameters in the
TypeScript/JavaScript code to be strings, I created a
string-valued enumerated type called Body.
The same string values can still be passed in from JavaScript
code, or callers can use syntax like Astronomy.Body.Moon.
This improves the type checking inside the TypeScript source,
plus it adds better documentation for each of the parameters.
In the generated Markdown documentation, the user can click
on the Body type and see all the supported bodies.
The other three supported languages (C, C#, Python)
already use enumerated types for bodies, so this
brings the JavaScript version more in sync with them.
Now that equatorial coordinates include both angles
and cartesian coordinates, there is no need for the
VectorFromEquator function. It has been removed
from all four supported languages.
The expression "VectorFromEquator(equ, time)" can be
replaced with "equ.vec" in any calling code.
In the TypeScript/JavaScript code, the functions MakeObserver and MakeSpherical
are no longer needed, because the classes Observer and Spherical are now exported,
along with their constructors. I deleted those functions and reworked callers
to use the equivalent constructors instead.
Also fixed a few breakages in the html/browser examples that crept in recently.
Now that we generate separate JavaScript code for Node.js and the browser,
the unit test should use the minified Node version.
It's interesting that the test works equally well with either file.
Perhaps we should consider exercising both in the unit tests?
The npm dependencies required are now
installed locally inside the generate folder.
Cleaned up the Astronomy object closure for TS
and kept it for the Browser bundle.
We will have some usage examples in the website.
In all four versions of Astronomy Engine (C, C#, JavaScript, and Python),
starting a search for a full moon near December 19, 2020 would fail.
I added a unit test to all four languages and it failed consistently
across them all.
The root cause: I was too optimistic about how narrow I could make
the window around the approximate moon phase time in the
SearchMoonPhase functions. Finding the exact moon phase time failed
because it was outside this excessively small window around the approximate
time. I increased the window from 1.8 days to 3.0 days.
This should handle all cases with minimal impact on performance.
Now all four of the new unit tests pass.
In order to verify that the minified code is valid, the
JavaScript unit tests should use it rather than the original
code. I must have changed back to using the normal code while
I was debugging something and forgot to change it back.
In the JavaScript version, check throughout for valid
finite numeric/boolean values as needed.
This should make debugging a lot easier for everybody.
In the unit tests for all languages, also check for infinite
results, not just NaN.
I discovered that JS Astronomy.NextLocalSolarEclipse() was broken:
It was trying to call a nonexistent function.
Fixed it, and added unit test that would have caught the breakage.
Fixed mistakes in JS documentation for the field names of the
Observer class.
I was irked by how a seemingly passing unit test was not actually
doing anything because something of the form
if (diff > threshold) ...
was never firing when 'diff' was NaN. This made me paranoid
that other things could be broken. Added strategic checks
that values that are supposed to be numbers are indeed numbers.
From now on, it will be simpler to add new JavaScript unit tests.
In most cases, it should no longer be necessary to update the
bash script unit_test_js or the batch file run.bat when new
JavaScript tests are added.
