Got 'ctest pluto' error down to 5.675183e-05 AU.
I was adding vectors when I should have been subtracting,
to find heliocentric Pluto from barycentric Pluto.
When finalizing the position of Pluto, I need to convert
barycentric coordinates to heliocentric coordinates.
I do this by adding the barycentric location of the Sun
to the barycentric location of Pluto to obtain the
heliocentric location of Pluto. But I was using the Sun
coordinates from the simulation starting point, not
at the final time.
This decreases the AU error from 1.369e-02 to 1.347e-02.
I'm still looking for the rest of the error.
I wasn't initialzing the acceleration vector in the value returned
by GravSim(). I'm not sure how any of this ever worked!
Found it by using valgrind.
There is no apparent advantage to looping for convergence in GravSim().
Also, it looks like I can use a much larger dt = 10 days.
Added PlutoStateTable to C code generator.
This is a table of known correct [tt, pos, vel] tuples for Pluto,
calculated using TOP2013. These serve as seed points from which
to integrate Pluto's motion.
Added PlutoCheck() function to ctest, just to get going.
I have a lot more peformance work to do in order to make
the full blown unit test to finish in a reasonable amount of
time.
Changes in astronomy.c:
Added some generic "terse vector" support.
A terse vector contains 3 components and nothing else.
This is handy for implementing compact formulas for various
vector expressions.
Created enhanced VSOP87 calculations that provide
velocity vectors as well as position vectors for
the Sun, Jupiter, Saturn, Uranus, and Neptune.
These are the "major" bodies that have significant
effects on the motion of Pluto. Also used to convert
heliocentric coordinates to barycentric coordinates.
Implemented first version of the integrator logic.
It is not accurate enough yet, and it is far too slow.
I need to debug the accuracy first, then I will work on
making it faster.
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.
Fixed some build warnings that occur on various gcc
optimization levels, and only on this version of gcc.
For now, build ctest with fewer optimizations: -O1
instead of -O3. This is because -O3 and -O2 cause
excessive errors in 'ctest diff' of the order
1.0e-9, where I usually get 1.0e-12. I will have to
come back and figure out exactly which optimization(s)
are causing the problem and turn them off specifically.
This also means I need to document the dangerous optimizations
for people who are using the C version of Astronomy Engine.
When 'ctest diff' fails because of excessive numeric error,
print out the two lines of input text that had the worst
numeric error. This really helps on the Raspberry Pi
where memory is at a premium, and it's hard to open the
full output files using vi.
Added Astronomy_FormatTime to the topic index.
Reworded text to avoid "as explained above", because it turns
out the generated documentation does not always put things
in the same order they appear in the source code comments.
It's surprisingly tricky to print a time rounded to the
nearest millisecond, second, or minute using the C code.
I saw a case where positions.c printed '2020-07-09 04:29:60'.
Because printing a date/time is a basic need of an astronomy program,
I added the new function Astronomy_FormatTime to do this.
All the demo programs use this new function, which required
me to update the correct reference output for the unit tests.
Also corrected code generator to output term coefficients
in scientific notation. In the C code, it was dropping signficant
digits by outputting in fixed point notation.
The high-frequency wobble in the Pluto position function was bothering me.
Decreased the arcminute error threshold from 1.0 to 0.5, resulting
in a much larger model, but a lot less ripple:
547 [ 78 140 94 115 21 99]
The truncated TOP2013 series creates higher frequency
oscillations in the heliocentric distance of Pluto
that confused the apsides algorithm the same way Neptune did.
So I changed the special-case Neptune logic to work for both
Neptune and Pluto.
Now the C version of Astronomy Engine is using the TOP2013 model
of Pluto instead of resampled Chebyshev polynomials.
I added temporary hacks to ignore differences for Pluto between
C output and output from Python, JavaScript, and C#.
I will remove these after all four languages are using TOP2013.
See the variable ToleratePlutoErrors in ctest.c.
ctest.c DiffLine function now understands that longitude-like
angles (right ascension and azimuth) can wrap around, and to tolerate
very small angular differences that happen to straddle the wraparound
value. I should have done this a long time ago, but it never caused
problems before now.
C PlanetApsis has a serious problem with Pluto that I didn't expect.
I need to investigate and understand this before porting to other
languages. For now, I hack around it using ToleratePlutoErrors.
This is another way to explore possible solutions in a random order
so that we don't keep going in the same directions each time.
Found a better solution:
219 [ 27 63 61 58 6 4]
winner: 0.998305 arcmin : 228 [ 37 63 60 58 6 4]
This script keeps running the ray search followed by the nudge search.
If it finds a better solution that the existing one, it replaces it.
Found the above solution after about 30 minutes.
Relax apparent angular error threshold from 0.4 to 1.0 arcminutes.
No longer compare TOP2013 to NOVAS while optimizing.
Use worst-case distance between Earth and Pluto:
Pluto radius from Sun, minus Earth aphelion distance.
Sample 503 points intead of 293.
Measure 2 full orbits before J2000 and 2 full orbits after J2000.
Statistics for output/8.top :
OptimizeTop: 268 terms [ 34 57 72 90 9 6]
Use much tighter pruning to figure out when a transit might be
possible, based on a smaller angle between the planet and Sun
at the moment of inferior conjunction.
Including aberration makes little difference in the transit calculations,
so I turned that off to be a little more efficient.
To be consistent, when calculating the geocentric position of the Sun,
we do need to correct for light travel time just like we would for any
other object. This reduces the maximum time error for predicting transits
from 25 minutes to 11 minutes.
Also had to disable aberration when calculating moon phases
(longitude from Sun) in order to keep a good fit with test data.
Does not pass unit test yet.
I had to rework norm.py because I misunderstood the data format.
The date given is not for the beginning of the transit, but
for the peak. This means the normalized data files need to
keep the start time, peak date/time, and finish time.
The unit test needs to adjust start time and finish time
to make sense with respect to the peak time, by adding/subtracting
a day as needed.
Wrote stub C functions for finding transits.
Updated html files containing Espenak test data for Mercury, Venus.
Updated norm.py to convert the html files to easy-to-use text files.
Added global/local solar eclipse functions to topic indexes for
C#, JavaScript, and Python.
Revised wording "eclipse found may be" --> "eclipse may be".
Python:
- Added missing Attributes section in class GlobalSolarEclipseInfo.
- Added classes EclipseEvent, LocalSolarEclipseInfo.
- Added stub functions SearchLocalSolarEclipse, NextLocalSolarEclipse.
