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.
Reworked the Pluto gravity sim constants so they are defined
in one place: a new header file gravsim/pluto_gravsim.h.
Then the code generator writes the #defines to the C code, instead
of having two independent versions of the same constants.
I will continue down the road of having a single-source-of-truth
for these constants across all 4 supported languages.
Also, confusingly, I had one constant called PLUTO_DT in codegen.c
that was called PLUTO_TIME_STEP in astronomy.c. Also, astronomy.c
had a different constant PLUTO_DT that didn't mean the same thing.
I reworked the naming to be consistent in all places.
I already had a TopPosition() function that knows how to calculate
exact equatorial coordinates, so I eliminated the redundant logic
from gravsim_test.c
While I'm tinkering with Pluto gravsim algorithms in C,
I don't want to fail the unit tests that compare it against
the original gravsim algorithm in JavaScript, C#, and Python.
So I turned that part off for now. I will have to take this
back out when they are all unified again.
Significantly decreased the calculation error:
0.20 arcmin to 0.12 arcmin in my test metric.
However, the amount of extra work may not be
worth the accuracy, compared to just stepping more
increments between the segments, or simply making
more segments in the first place.
As they say in government-funded academia,
"more research is needed."
I have gravsim_test.c to the point where it calculates a
standard deviation of error between TOP2013 and Astronomy Engine
for calculating the position of Pluto over 10 worst-case samples.
My baseline is now 0.205303 arcminutes of heliocentric position error.
For Runge-Kutta (or some other method) to be an improvement, it
has to beat that score without incurring significant extra work
or larger memory consumption.
I updated gravsim_test.c to calculate the Pluto model
at every (exact) state table entry, and every halfway point.
I compare it against (exact) TOP2013 calculations.
As expected, the errors alternate between 0 and nonzero.
I'm interested in understanding drift error calculation
between the known-correct state waypoints for Pluto's orbit.
I'm trying to figure out whether there is some unintended
asymmetry between the forward calculation and the reverse
calculation. I will likely have to compare against TOP2013
data for the major planets, because I am using truncated
VSOP87, which also introduces position errors.
I should also validate TOP2013 versus VSOP87, both
untruncated, for Jupiter..Neptune, which they both cover.
I'm trying to get a better feel for the amount of error
in my gravity simulator calculations for the movement of Pluto.
Added conditionally-compiled code to log state vectors calculated
in the forward and reverse time directions, along with the
exact endpoints that frame the interpolated values.
Also log errors measured between both directions.
There is a curious asymmetry in the first case I tried
(roughly the years 2000..2100), where the forward calculation
seems less accurate than the reverse calculation.
For bodies other than the Sun, Moon, or Saturn, the
C function Astronomy_Illumination calls an internal function
VisualMagnitude. If VisualMagnitude is passed an invalid body,
it returns an error code. Astronomy_Illumination was not checking
for an error code. In the case of being passed a pseudo-body
like BODY_SSB (the Solar System Barycenter) or BODY_EMB
(the Earth/Moon Barycenter), VisualMagnitude is called and
returns the error ASTRO_INVALID_BODY. Astronomy_Illumination was
ignoring the error and returning ASTRO_SUCCESS to the caller,
even though the magnitude was NAN (the "not a number" value).
Note that other invalid bodies than EMB and SSB would not
cause this problem, because the earlier call to HelioVector
would fail and be noticed.
I added unit tests that confirmed this bug, then made fixes
to the code so that the unit tests pass.
I confirmed this same problem does NOT exist in the Python,
JavaScript, or C# versions of Astronomy Engine. In all
the other languages, this case causes VisualMagnitude to
throw an exception, so no error checking is needed in the
Illumination functions.
Tonight as I was walking outside, I saw a fairly bright
star about half a degree away from the edge of the Moon.
I wondered what it was, so I decided to write a quick
program to find out.
This Python demo program scans the HYG Database
(https://github.com/astronexus/HYG-Database)
to find which bright stars are within a small angular
distance of the Moon, as seen at a given time, latitude, and longitude.
It turns out the star I saw was Nunki (Sigma Sagittarii).
It was handy to do vector subtraction to implement this program,
and it was trivial to do in the Python code's Vector class,
so I went ahead and added that.
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.
The C and C# Illumination functions now return
a `phase_fraction` result to complement `phase_angle`.
This makes them consistent with the Python and JavaScript
versions.
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.
Because I have to perform the expensive calculation to find
the Moon's ecliptic coordinates, I might as well return them
to the caller. This could help reduce calculation overhead
for some uses, and doesn't add any significant cost.
I could not measure a significant difference in calculation
accuracy from doing the expensive earth-tilt step.
I removed it to significantly speed up the calculation.
I discovered that when I tried to build astronomy.c as C++ code,
I got several errors and warnings. So I fixed those issues and
added a C++ build-check to the unit tests.
I discovered that when I tried to build astronomy.c as C++ code,
I got several errors and warnings. So I fixed those issues and
added the C++ build-check to the unit tests.
The newer gcc generates warnings when a function
is declared to take a sized array parameter, but the caller
passes an array of smaller dimension. In these cases, the
intention was to pass arrays of variable size, so I deleted
the specific array sizes.
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.
The current Raspbian uses an older version of pylint
that suffers from a recursion overflow. Hacked a deeper
recursion limit to work around this issue.
Also directly calling 'pylint' does not work in Raspbian.
Instead of trying to figure out why, I just use 'python3 -m'
to invoke pylint.
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.
I'm doing Astronomy Engine development from different
Debian versions (Buster and Bullseye). Buster installs
doxygen version 1.8.13, but Bullseye installs version 1.9.1.
These two versions of doxygen generate slightly different output
for function pointer typedefs: the older version adds an extra
space between the '*' and the defined type name.
I need the output to be exactly the same so that
the continuous integration tests don't see any changed
files in git after they finish running.
So I added an extra step in hydrogen.js (the code I wrote
that converts the doxygen output into markdown) to squash
multiple contiguous spaces into a single space in the
typedef output.
The unit tests for the calendar.ts demo program
assumed that the 'tsc' typescript compiler was
installed globally. Redirect it to the typescript
installed in the 'generate' folder.
I could have just made typescript a dependency,
but it seemed wasteful of disk space to have two
copies of the same thing (it is currently 54MB).
