The code generator was creating slightly different numeric
values for the Pluto state tables and the Jupiter rotation matrix.
I decreased the output precision by one decimal digit.
This should allow the code generator to produce identical
source code on both Linux and macOS.
More work getting MacOS build process to work.
Avoid excessive number of floating point digits of
output in the demo tests, so that insignificant
floating point variations don't cause unit test failures.
Two different people are currently helping me get the
build process working on Mac OS. They both ran into different
amounts of comparison error in the calculations for different
langauges. I updated the 'diffcalc' bash script to have
slightly less strict tolerances, so the unit tests pass.
When built using g++ as an alias for clang,
as reportedly happens on Mac OS, we need to explicitly
tell g++ (using option '-x c++') to compile astronomy.c
as C++. Otherwise, it will fail with a deprecation warning.
Added radius data for the Sun, Moon, and remaining planets.
Test the raytracer for all other bodies except the Earth and Sun.
There is a problem with Pluto that I still need to figure out.
Fixed an issue in the doxygen-to-markdown translator I wrote
(hydrogen.js): it did not handle when one #define referred
to another #define. Created a more generic markdown expansion
that works in all cases, and creates embedded hyperlinks.
The program 'realpath' does not come installed on Mac OS.
This caused the bash script 'makedoc' to fail on Mac.
The only place I used realpath was to convert relative
paths to absolute paths for filenames passed to
check_internal_links.py.
It turns out Python has a standard function os.path.realpath()
that does the same thing, so I moved the logic into the
Python script itself. Thus makedoc no longer needs the
realpath program, and the Python function will work on
all platforms.
There is a general lesson here: in the future I will
consider moving more of my scripting logic into Python.
It has proven to be more portable than a mixture
of bash scripts and Windows batch files.
There was one more place where novas.c calls abs()
that caused a warning when compiled on the Mac.
It was passing long int to abs(). To be abundantly
cautious, instead of using labs(), I just manually
check for negative values and toggle -- inline abs.
I received a report that there are compiler warnings
that break the build in novas.c when building on the Mac.
In two cases, long integers are passed to abs(), which expects
its argument to be int. The warnings broke the build
of the 'generate' program. I patched the code so these
warnings should no longer occur, though I do not have a
Mac to test. Will ask the correspondent to test for me.
The documentation for the Python function `SearchAltitude`
was missing a mention of the `altitude` parameter.
I searched for similar mistakes in Python, C#, and C,
having just completed the same exercise in the JavaScript code.
I also found several places where extraneous newlines
between the parameter documentation caused the Markdown
to be rendered incorrectly.
Added documentation about the missing `date` parameter
to the `Elongation` function in the JavaScript version.
I reviewed all the other JavaScript functions to make sure there
were no other similar mistakes with parameters or return types.
Along the way, I discovered and fixed some other issues:
Fixed miscellaneous typos in the documentation.
Consistently refer to enumeration values like `Body.Earth`
instead of strings like `"Earth"`. I want to encourage
use of the enumerations because they make type-checking easier,
especially for TypeScript code.
Reworked `AstroTime` parameters to `FlexibleDateTime` parameters
in all exported functions. This is completely backward-compatible,
and allows callers more flexibility with passing `AstroTime`,
`Date`, or numeric day values.
Now that Microsoft has officially released .NET 6,
I have upgraded the C# version of Astronomy Engine to use it.
No source code changes were needed. I just bumped the
version number in the project files, and targeted .NET 6
in the GitHub Actions continuous integration tests.
Fixed some obsolete wording in generate/README.md.
I used Cassini's Laws to derive an approximate solution
to the Moon's rotation axis. The error is on the order of
5 arcminutes. I still need to correct for physical libration.
I also need to find test data for the Moon's prime meridian
so that I can implement the spin angle calculation.
(I could use test data for all the planets' spins, for that matter.)
In Windows I am running Python 3.7.8.
For some reason, it fails to write Unicode Greek letters
I use in the Markdown documentation unless I explicitly
specify to use utf-8 encoding. I thought that was the default,
because it works fine in Linux running 3.9.2.
I'm not sure whether the issue is due to Windows or
to a change in the Python version. Regardless, I am
explicitly specifying the file encoding to make the
documentation translator I wrote (pydown.py) work.
This issue affected maintainers (mostly me) only.
Developers who are using Astronomy Engine do not need
to worry about this.
Running the source generator on Windows was broken because
I forgot to copy a step over from the Linux build that
prevents building tutorial pages in the master branch.
I didn't notice this until now because makedoc.bat also
had a bug where it detected an error but did not stop
execution... it just kept going and made it hard to
notice something was wrong.
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.
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?
