Also moved the NPM commands to the package.json
so the makedoc scripts execute them in a central place.
Installed a jsdoc theme to improve the html output.
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.
The JavaScript version of Astronomy.Search was sometimes being passed
an incorrect 'options' parameter. It should always be either omitted
or passed in an object with the correct shape.
Also, there were places where Search failures, indicated by it
returning null, should cause an immediate exception.
When built from a system with a European (or similar) culture setting
where a comma is used as a decimal marker instead of a period,
the C# unit tests and demos would fail.
Now explicitly specify InvariantCulture to resolve these problems.
Improved the type checking by using tsc --strict.
Nothing substatial changed in the generated JavaScript, and no
actual bugs were found, but I removed a lot of loose/sloppy
type signatures. This should make mistakes less likely
in the JavaScript code going forward.
The goal is to provide both TypeScript and JavaScript to developers.
Will also provide a type definition file once I figure that out.
This is just the first pass through the code.
It builds and passes all the unit tests, with some minor changes
to the generated README.md.
I forgot that my build process automatically updates
copyright years when the current year changes.
My Travis CI unit tests verify that there are no local
changes after running all the tests.
That test failed because the update_copyrights.py changed
all the "2019-2020" to "2019-2021".
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.
This new demo shows how to calculate rise and set times
of the Sun and Moon in local time, using Linux functions.
It also sorts the events in chronological order.
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.
Now that I no longer need to generate Chebyshev models
or TOP2013 models for Pluto, I got rid of all the
code in generate.c that is no longer needed.
This whacked about 1000 lines of code.
The minimized code astronomy.min.js is now significantly smaller
because it uses a completely new algorithm for calculating
the position of Pluto. Instead of using TOP2013 formulas directly,
it simulates the gravitational forces on Pluto between 40
precalculated checkpoints spread over a 4000 year range.
I believe this wraps up the Python integrator.
It now works in all 4 languages and passes all tests.
Fixed up demo tests to match new output.
Turned on Travis CI checking in this branch again.
Ported Pluto integrator to C#.
Along the way, I noticed that I had VSOP87 latitude and longitude
swapped in such a way that they worked, but were labeled wrong.
This confused me quite a bit as I tried to implement functions
to calculate the derivatives of the VSOP87 spherical coordinates.
Fixed this in the code generator and the C and C# template files.
The vgtest script allows checking for memory errors in
Astronomy Engine using valgrind. This helped me find
a bug where I was using uninitialized memory.
The PlutoStateTable was slightly different when generated
in Linux and Windows, because there was so much precision
after the decimal point. Reduced precision until Linux
and Windows generated the exact same output.
Instead of remembering the most recent 3 segments of Pluto's orbits,
cache up to all 40 segments within the year span 0000..4000.
Use dynamic memory to allocate them instead of static memory.
Added Astronomy_Reset() to free memory before exit.
Also reduced stack usage by sharing bary[5] more.
Eliminated a redundant call to MajorBodyBary() when
calculating one-way outside the bounds of PlutoStateTable.
There were two places where I was searching for table entries.
I realized I can just directly calculate the same indexes.
This makes the code smaller and faster.
To make Pluto calculations have a low amortized time cost,
calculate up to 3 segments between adjacent pairs of
pre-calulcated states and recycle them. Do linear ramp
fade-mixing between them.
Currently, something is wrong with this because it fails
by inaccurately calculating horizontal coordinates of Pluto
in one test. I'm not sure what's going wrong there yet,
but likely related to multiple calls via search.
This is a happy compromise between speed and accuracy.
Solidified this as a #define PLUTO_DT, which will allow
me to do compile-time math to establish an array size for
an internal buffer of lazy-computed dt increments between
most recently requested segment endpoints.
Now we are getting somewhere!
Using the mean acceleration over the interval seems so much
better than the complicated calculus thing I did.
Now I am using a very large time step: 500 days,
with an error less than 0.2 arcminutes.
C PlutoCheck: dt = 500.000000
C PlutoCheck: 2049-12-19T12:00:00.000Z = 18250.000000 UT = 18250.001076 TT
C PlutoCheck: calc pos = [ 37.4373396436339121, -10.2445033319559062, -14.4764587025278448]
C PlutoCheck: ref pos = [ 37.4377303529113306, -10.2466292445590774, -14.4773101309873091]
C PlutoCheck: del pos = [ -0.0003907092774185, 0.0021259126031712, 0.0008514284594643]
C PlutoCheck: diff = 2.323163e-03 AU, 0.198 arcmin
Allow passing in the dt value as an environment variable PLUTO_DT:
$ PLUTO_DT=100 ./ctest pluto
C PlutoCheck: dt = 100.000000
C PlutoCheck: 2049-12-19T12:00:00.000Z = 18250.000000 UT = 18250.001076 TT
C PlutoCheck: calc pos = [ 37.4506659151144774, -10.2638146514621269, -14.4865003148403595]
C PlutoCheck: ref pos = [ 37.4377303529113306, -10.2466292445590774, -14.4773101309873091]
C PlutoCheck: del pos = [ 0.0129355622031468, -0.0171854069030495, -0.0091901838530504]
C PlutoCheck: error = 2.339073e-02 AU, 1.989 arcmin
Default to dt = 50 days.
I had a bug in the calculation of the Solar System Barycenter.
The position and velocity vectors were both backwards.
This caused the barycentric Sun to be in the wrong place.
C PlutoCheck: 2049-12-19T12:00:00.000Z = 18250.000000 UT = 18250.001076 TT
C PlutoCheck: calc pos = [ 37.4386594210222654, -10.2474739785185811, -14.4777836541558340]
C PlutoCheck: ref pos = [ 37.4377303529113306, -10.2466292445590774, -14.4773101309873091]
C PlutoCheck: del pos = [ 0.0009290681109348, -0.0008447339595037, -0.0004735231685249]
C PlutoCheck: error = 1.342001e-03
I didn't implement the math I had derived on paper exactly right.
There was one place where I meant to have (dt^3 / 6), but I had (dt^2 / 6).
This has only a tiny effect on the error. I know this can work better,
so I'm still searching for the real problem.
C PlutoCheck: 2049-12-19T12:00:00.000Z = 18250.000000 UT = 18250.001076 TT
C PlutoCheck: calc pos = [ 37.3682426267669996, -10.0216432448322834, -14.3724661626442582]
C PlutoCheck: ref pos = [ 37.4377303529113306, -10.2466292445590774, -14.4773101309873091]
C PlutoCheck: del pos = [ -0.0694877261443310, 0.2249859997267940, 0.1048439683430509]
C PlutoCheck: error = 2.577586e-01
I picked a worst-case starting time that is halfway between
two entries in the PlutoStateTable[]. This requires the most
iterations to calculate. Now I have a better metric for
position accuracy:
C PlutoCheck: 2049-12-19T12:00:00.000Z = 18250.000000 UT = 18250.001076 TT
C PlutoCheck: calc pos = [ 37.3682426469732860, -10.0216428456503461, -14.3724660445065933]
C PlutoCheck: ref pos = [ 37.4377303529113306, -10.2466292445590774, -14.4773101309873091]
C PlutoCheck: del pos = [ -0.0694877059380445, 0.2249863989087313, 0.1048440864807159]
C PlutoCheck: error = 2.577590e-01
Clearly I still have a lot of work to do!
