The floating point constants emitted for the Pluto Chebyshev
model did not quite match between Linux and Windows.
I suspect the real problem is not the operating system
but that I'm using different versions of Node on both:
Windows: v10.15.3
Linux: v8.15.1
Now I print only 12 place after the decimal instead of 18.
This makes no difference in the unit test output,
and reduces the JS code size significantly.
Expanded the Chebyshev model for Pluto.
Resampled VSOP models to have required accuracy over wider date range.
Decreased astro_check.js sampling rate to allow tests to run faster.
Now the JavaScript code uses UT and TT values expressed
in days since 2000, instead of Julian Dates.
This makes the numeric values much smaller and thus
should yield less floating point error when time solvers
are added later.
Using historic, recent, and predicted values of TT-UT instead of
UTC leap seconds. With linear interpolation, there are no longer
discrete jumps in the calculated TT values. Hopefully, this will
make event solvers (rise, set, etc) more well-behaved.
Astronomy.GeoVector now corrects for light travel time from
the observed object. This reduced worst case angular error
from 1.16 arcmin to 0.89 arcmin (0.27 arcmin improvement).
I found some online resources that helped me track down the
formula for the refraction model used in the JPL Horizons
online tool. Now the JavaScript library allows 4 different
refraction options in Astronomy.Horizon():
false : no refraction
'novas' : use the NOVAS C 3.1 algorithm.
'jplhor' : JPL Horizons algorithm, clamped beyond 1 degree below horizon.
'sae' : same as 'jplhor', only without clamping.
Now passes the jplcheck unit test without filtering out objects below the horizon!
Always compile the C code when executing the script './run'.
Not quite right yet for some reason, but this is closer.
JavaScript function Astronomy.SkyPos() now returns both
J2000 (RA,DEC) and (RA,DEC) using true equator and equinox of date.
Use the latter to calculate horizontal coordinates.
This matches my call to NOVAS place() function, but there
are still errors larger than 2 degrees compared with JPL Horizons
and Heavens Above.
For example:
2019-04-11 19:47:00
variable test.html JPL Horizons error(arcmin)
Sun azimuth 245.455 246.585 -67.80
Sun altitude 50.858 51.261 -24.17
Jupiter azimuth 277.309 275.287 121.33
Jupiter altitude -63.751 -63.860 6.52
I have horizontal coordinates calculated, but they might
be wrong (both in how I call NOVAS functions and the JS code itself)
because I think I'm mixing up equinox of date coordinates with
J2000 coordinates for (RA,DEC).
Fixed bug that caused excessive estimate of angular error:
right ascension and azimuth are like longitudes -- they matter
less as an object approaches the poles. Scale such longitudinal
errors by the cosine of the latitudinal counterpart.
