I don't think it's a good idea to imply that the body constants
are always going to be consecutive, or that it makes sense to
iterate over them. The caller needs to understand the body enough
to know which operations are allowed and which aren't.
So I removed the constants MIN_BODY and MAX_BODY.
Calculate the vector that points in the direction
of the body's north pole.
The unit test now checks for excessive angle
between the expected north pole vector and the
calculated north pole vector.
I'm starting to implement formulas from the IAU 2015 report:
https://astropedia.astrogeology.usgs.gov/download/Docs/WGCCRE/WGCCRE2015reprint.pdf
This is a work in progress. The unit test is partially finished.
The C function Astronomy_RotationAxis() works only for the Sun and Mercury.
I want to also return a rotation matrix that reports the rotating
frame in a way more suited to graphics work. I will add this to
the type astro_axis_t later.
I am starting to work on calculation of the north pole
axes of various solar system bodies. Here I include a reference
source document, along with some test data, all described by
the README.md file.
Compare state vectors with the initial states used
to integrate the DE405 ephemeris.
This is just yet another confidence check that calculations
are correct.
When building Astronomy Engine for publication,
I was disabling generation of C documentation by default,
because I used to have issues getting deterministic output
in the CI tests (GitHub Actions). Now I have reason to believe
it will work reliably, so I am turning on C docs generation
by default.
If this fails the CI test, I will have to make the CI test
explicitly disable this step until I figure out how to fix it.
Otherwise (and preferably) the CI test will ensure that the
published C documentation is always up to date, and will fail
the build if there are any issues generating the docs.
I also had forgotten to enable installing dependencies for
my custom tool `hydrogen` in the Windows build. I added a fix
for that.
For now, I'm keeping beta/unfinished website and tutorial stuff
outside the master branch to reduce confusion for newcomers.
It will stay in the `tutorials` branch for any ongoing development.
If we finish it and make it ready for public use, then I will
bring it back into `master`.
Updated the `makedoc` script to gracefully skip steps
involving tutorials or website if they are absent.
Also, we were not installing packages needed for `hydrogen`
to generate C documentation. This broke document generation
on freshly-cloned repos.
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.
I'm trying to make it easier for first-time visitors to
this project to find the source code and documentation
to get started quickly. Moved directories that are only
used by contributors (mostly myself) out of the root
and into the 'generate' directory where they are less
distracting.
I'm concerned that a first-time visitor to the Astronomy Engine
repo on GitHub will get lost. I made it more obvious where to
quickly find the source code needed for a given language.
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.
Fixed a few lingering issues in the documentation of
the C# version of the ObserverState function.
This completes the implementation across all 4 languages.
ObserverState calculates the position vector of a point
on the surface of the Earth, and the velocity vector
of that point, both relative to the center of the Earth.
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.
Implemented the C# version of the ObserverState function.
This returns the geocentric position and velocity for
a point on the Earth's surface at a given time.
Made the internal data structure for the C version of barystate
use named fields in a struct for Sun...Neptune, instead of
an array. This makes the C code look more like the other 3
language implementations. I am going to experiment with adding
more bodies to see if it helps accuracy, and this makes the
code easier to modify for that experiment.
Instead of measuring absolute state vector position/velocity
errors, measure them relatively by dividing by the magnitude
of the scalar length of the correct vectors. This gives a better
feel for how much error each calculation contains.
In the process, I discovered that the barycentric Sun calculation
is off by more than 1 percent, which is surprising and deserves
more attention. I wonder if including the inner planets would
make it more accurate?
The unit test uses two JPL Horizons data sets: the center of
the Earth as seen from the surface of the Earth, and the
Earth/Moon Barycenter (EMB) as seen from the surface of the Earth.
Simplified the C unit tests for barystate and heliostate
so they use common code for parsing the JPL Horizons
data files. The only thing really different about them
is which function is called to compare against the state
vectors in the files. Pass in a pointer to a context.
Right now the context just contains a pointer to a function
to call, but later it may contain other parameters if needed.
I am starting to work on a function to find the position
and velocity vectors for an observer on the surface of the Earth.
I created the C function Astronomy_ObserverState(), but I don't
yet have a unit test for it.
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 function ParseArgs (used by many of the C demo programs)
now allows an alternative command line usage. If the '-e'
option is specified, it looks for the environment variable setting:
ASTRONOMY_ENGINE_OBSERVER='latitude longitude'
This form allows the demo programs to be configured for a given site.
Now the C 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).
Astronomy_BaryState() now supports body == BODY_EMB.
Added a new function Astronomy_GeoEmbState() to calculate
the geocentric state for the EMB.
Both have been verified using test data generated by JPL Horizons.
I wanted to test the geocentric Moon state vector I
calculate for the sake of the Moon state relative to
the Solar System Barycenter (SSB). Because the geocentric
portion has such a small magnitude, I decided to go ahead
and expose GeoMoonState as part of the API, and create
a test for it specifically. I used JPL Horizons to generate
the test file GeoMoon.txt.
The C function Astronomy_BaryState() now supports BODY_MOON.
Because of the complexity of the CalcMoon() function, I ended
up calculating two positions close together in time, and
using dr/dt to estimate the velocity vector.
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!
A slight difference (7.9e-17) in calculation now exists between
the C and C# horizontal angle calculations on Windows.
This is not surprising because the atan2() function is
known to return slightly different values on other
compilers/platforms. Adjusted the tolerance for this tiny
amount of roundoff discrepancy.
