Based on a discovery made by someone helping me get
Astronomy Engine building on the Mac. In some versions
of g++ (aliased to clang), if you don't explicitly tell
the compiler to treat .c files as C++, it gives a warning
that escalates to an error due to -Werror.
So I added the same fix to the raytracer build:
pass in the option '-x c++'.
Pluto is so far away that is angular size seen from Earth
is very small. I had to tweak my internal scaling constants
so that the raytracer was able to resolve it.
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.
Refactored the Jupiter imager to be a generic planet imager.
Added support for drawing an image of Venus.
Verified that its extreme crescent phase looks correct
for the current date.
I will add radius constants to astronomy.h for each body I support.
The raytracer now includes the option -s (without a numeric
spin angle on the command line) to automatically calculate
the spin angle needed to bring the planet's north pole
exactly upward in the generated image.
Improved the way I create the rotation matrix that
aims the virtual camera at Jupiter. The camera still
aims exactly at Jupiter, but this time it defaults
to having the left/right pixel direction aligning
with the Earth's equator. By experiment, I can spin
the longitudinal camera axis by -10 degrees and get
a good fit with Jupiter's equatorial plane. I will
adjust this more exactly in a future commit.
Now the raytracer requires the user to pass in
both the pixel width and pixel height on the command line.
This allows for generating non-square images, which will
be necessary for the general case of imaging the moons
with respect to the planet.
Now that I have eliminated refraction and reflection
from the astronomy raytracer, there is no need for an
Optics class that represents matte, gloss, and index
of refraction.
I had lots of problems with using AU as my scale units.
By changing to 10000*km units, the vector equation solver
works correctly again, and I actually get an image of Jupiter
and its moons. However, it does not match the test photo:
Ganymede does not appear close to the planet, nor is there
a shadow of it on the planet. I will have to debug that
separately.
Starting to work through adaptation of existing
raytracer code to generate geometrically accurate
images of Jupiter and its moons. Not yet working,
but I believe I am at least aiming the camera in
the right direction.
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.
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.
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!
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.
