I increased the error tolerance slightly for the Jupiter moons model.
This shrank the model tables significantly, giving me some more
breathing room to stay under 100K download size.
I don't like how close I am to my 100K target size, now
that I'm calculating Jupiter's moons.
Simplified the spin() function so its minified code is smaller.
I will look for other things I can shrink too.
The optimizer makes the Jupiter moons series as short as
possible while keeping error within an acceptable limit.
This should help produce much smaller code, especially
for JavaScript where it really matters.
I want to experiment with truncating the L1.2 series to
sacrifice some accuracy for smaller generated code.
To that end, I implemented the ability to save the
Jupiter moons model after loading it. I added a 'jmopt'
command to the 'generate' program that will do this
optimization. For now, it just loads the model and
saves it back to a different file. Then the code generator
loads from the saved file instead of the original.
This commit verifies that everything is still working,
before I start truncating the series.
I want to make sure I have thorough coverage of exercising
the Jupiter moon calculations before I start tinkering
with truncating the L1.2 models; the eventual goal is
to decrease the code size, especially later for JavaScript.
Only 101 test cases seemed far too small. Now there are 5001.
Increased the time range to cover the years 1931..2068.
Decreased the time step from 100 days to 10 days.
Eliminated all but the geometric data, because I'm testing
code without any light-time or aberration correction.
Updated the README.txt instructions for generating the
JPL Horizons test data.
Output the Jupiter moon model data tables in a tidier format.
Format the amplitudes as fixed-point instead of exponential,
so that the JavaScript minifier will have an easier time
shrinking the data (later, when I get to the JavaScript version).
I translated the L1.2 FORTRAN code into C, and verified
that the calculations match the Stellarium code I modified
to produce EQJ coordinates. I still need to compare against
JPL Horizons data.
This is the beginning of a unit test for the new C function
Astronomy_JupiterMoons(). It reads the stellarium file and
can iteratively solve for the ut corresponding to a given tt.
The test "passes" because it doesn't actually check the value
returned by Astronomy_JupiterMoons() yet.
Instead of calculating ECL coordinates that I will later
have to convert to EQJ, I re-ran all the JPL Horizons test
data sets for EQJ, and updated the rotation matrix in the
Stellarium sample code to generate EQJ output. I'm still
getting reasonably good fit between the two: the max
error is about 1 part in 5000. I was hoping for better,
so I still wonder if I'm just a tiny bit off in some respect.
Stellarium uses the same L1.2 model for Jupiter's moons that
I am implementing. I wanted to confirm that I have valid test
data that matches something authoritative.
Work in progress.
Generating the data tables for Jupiter's moons, but not using them yet.
Created a stub function Astronomy_JupiterMoons(), but it just
returns invalid vectors. The formulas have not yet been implemented.
I found some FORTRAN code for calculating the positions of Jupiter's
moons. I recorded its origin in README.md. I'm going to experiment
with using it as a basis for doing these calculations in Astronomy Engine.
I am starting the process of implementing calculation
of Jupiter's four largest moons: Io, Europa, Ganymede, Callisto.
This commit just contains constant declarations for the
equatorial, polar, and volumetric mean radii of Jupiter.
The positions of the moons will be related to the center
of Jupiter and be expressed in Jupiter equatorial radius units,
so I felt it would be good to give users a way to convert to
kilometers, which can in turn be converted to AU.
Automatically update the front page README.md to include the current
byte size of astronomy.browser.min.js. Fail the build process if
this file ever grows to 100000 bytes or larger.
Python docstrings don't work for variables, so I hacked
a special comment format for helping pydown generate Markdown
text for the README.md for the exported constant KM_PER_AU,
or any other constants I may want to expose in the future.
Also made time parameters to rotation matrix functions be of
type FlexibleDateTime, and internally convert them to AstroTime.
This should be the policy of all exposed functions in the
JavaScript version of Astronomy Engine.
Exposed KM_PER_AU to outside callers.
Use a private enumerated type to select which direction
the precession and nutation is to be done:
- from date to J2000
- from J2000 to date
Normalize the order of parameters to be consistent
between precession() and nutation(), and across languages.
Pass in AstroTime instead of a pair of floating point TT
values (one of which had to be 0).
Added TypeScript version of ObserverVector(),
but it has not yet been documented or tested.
It always seemed a little odd to have to pass in two
time values to the precession() function, when one of
them always had to be 0. I think the logic is clearer
now that I pass in an enum value to select whether I
want a forward transform or a backward transform.
It is cleaner that now I can just pass in an AstroTime.
Ported the ObserverVector function to C#, but it is not tested yet.
While doing that, I realized I needed a way to document newly public
constants DEG2RAD, RAD2DEG, and KM_PER_AU. This led to work
on the 'csdown' project that converts C# XML documentation
into Markdown format.
Then I realized a lot of code would be more elegant if
AstroVector had operator overloads for addition, subtraction,
and dot products.
This in turn required these operators to know which time value
to store in the AstroVector, which led to realizing that I
was sloppy in a lot of places and passed in null times.
So this whole commit contains a variety of unrelated topics,
which is something I don't usually do, but it felt
justified here while I'm in a refactoring mood.
The C functions that took a parameter of a pointer type
'astro_time_t *' were causing incorrect Markdown to be generated.
Now my custom Markdown translator (hydrogen.js) handles this case.
Now exercise the new Astronomy_ObserverVector() function by
calling it with a variety of times, geographic coordinates,
and both supported equatorial systems (J2000, of-date).
Also check to make sure it returns the correct error code
when passed an invalid astro_equator_date_t value.
This function calculates the position of an observer on or
near the surface of the Earth (the geoid) in one of two
equatorial coordinate systems: J2000 or equator-of-date.
Moved the following constant definitions from astronomy.c
to astronomy.h, so external code can use them:
DEG2RAD
RAD2DEG
KM_PER_AU
My custom doxygen-to-markdown translator (hydrogen.js)
now emits markdown for the above constants.
Eliminated the obsolete constants MIN_YEAR and MAX_YEAR.
Astronomy Engine is no longer limited to calculating planets
within that range of years.
Fixed a couple of minor documentation issues in the C code.
Started work on a new function Astronomy_ObserverVector,
but it is just a stub for now.
