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.
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.
Astronomy Engine used to use USNO historical and predictive tables,
along with linear interpolation, to calculate Delta-T values.
The problem with the USNO tables is, they did not work well outside
a few centuries around present day.
Later I replaced with Espenak & Meeus piecewise polynomials
that work over a much larger time span (thousands of years).
I just discovered there were still comments in the code referring
to the USNO models. I updated the ones I could find to reflect
the current truth about how the code works today.
This is technically a breaking change, but only for clients
that use the cartesian coordinates in an ecliptic coordinate
return type. Before now, the coordinates were just separate
floating-point members ex, ey, ez. Now they are a standard
vector type.
The purpose is to allow seamless interfacing with vector
rotation functions, and to be consistent with the equatorial
coordinate types.
Instead of declaring all the "body" parameters in the
TypeScript/JavaScript code to be strings, I created a
string-valued enumerated type called Body.
The same string values can still be passed in from JavaScript
code, or callers can use syntax like Astronomy.Body.Moon.
This improves the type checking inside the TypeScript source,
plus it adds better documentation for each of the parameters.
In the generated Markdown documentation, the user can click
on the Body type and see all the supported bodies.
The other three supported languages (C, C#, Python)
already use enumerated types for bodies, so this
brings the JavaScript version more in sync with them.
Now that equatorial coordinates include both angles
and cartesian coordinates, there is no need for the
VectorFromEquator function. It has been removed
from all four supported languages.
The expression "VectorFromEquator(equ, time)" can be
replaced with "equ.vec" in any calling code.
This caused me to discover I had forgotten to finish
making the necessary changes to astronomy.ts for saving
the cartesian vector inside the EquatorialCoordinates class.
I also realized I had made a mistake in the documentation
for the y-coordinate of the vector: it is the June solstice;
there is no such thing as a September solstice!
Also fixed some mistakes in demo tests: if something failed,
I was printing out the wrong filename (camera.c instead of camera.cs).
Added a C# demo program camera.cs that works the same way
as the C demo program camera.c.
I realized I can speed up the C# demo tests by directly
running the executables after I build them, instead of using 'dotnet'.
Added 'vec' field to Equatorial class. I just realized I no longer need
the function VectorFromEquator(), because the vector is now available
as 'vec'. I will get rid of it in another commit.
Created new rotation matrix functions for the C# version.
IdentityMatrix creates a new instance of the 3x3 identity matrix
1 0 0
0 1 0
0 0 1
Pivot transforms a rotation matrix by pivoting it about
one of its coordinate axes by a specified angle.
Still need to port the C version of the "camera" demo.
Exercise rotation around all three axes for the C function Astronomy_Pivot,
and verify that the actual rotation on a non-unit vector (1, 2, 3)
is as expected.
Added C function Astronomy_Pivot to transform a rotation matrix
by rotating it around one of its coordinate axes by a given angle.
Added C function Astronomy_IdentityMatrix that just returns
an identity matrix that can be used as the starting point in
a series of transforms.
C function Astronomy_Equator now also returns the topocentric
equatorial location in the form of a cartesian vector.
This is in a new member of the astro_equatorial_t struct
called 'vec'.
The unit test in ctest.c "Rotation_Pivot()" could be improved
with more and better tests.
Created a demo program camera.c that illustrates using
Astronomy_Pivot() to help calculate the tilt of the sunlit
side of the Moon, as seen by a camera pointing right at it.
The resulting tilt angle is not yet verified.
I need to have some confirmation that it is correct before
porting to the other languages.
I had a bug back in May 2020 that turned out to be in
generate.c unit tests, not in published Astronomy Engine code.
I have long since fixed these bugs, but I still had fossil
test code sitting around that doesn't work any more and
isn't needed. Deleted it.
I'm about to start working on adding a new output
from the Horizon functions. It was a good time to better
document the ideas behind these calculations, before
adding anything new. These are internal comments only
and do not affect generated documentation.
While I was in there, I noticed extra code that was
checking for impossible return values from atan2().
I eliminated these.
This script was a hack used to make the JavaScript code
work on both Node.js and in browsers. Now we build separate
versions of the code for both environments, so we no longer
need this script.
Updated the Windows batch file makedoc.bat to reflect
recent changes to the build process in Linux.
Using npm packages and build process to transpile
TypeScript to JavaScript, and to minify that JavaScript.
Generating separate js files for Node and the browser.
The only quirk is the file website\src\assets\documentation.json
does not exactly match.
In the TypeScript/JavaScript code, the functions MakeObserver and MakeSpherical
are no longer needed, because the classes Observer and Spherical are now exported,
along with their constructors. I deleted those functions and reworked callers
to use the equivalent constructors instead.
Also fixed a few breakages in the html/browser examples that crept in recently.
Although it looks less pretty in the generated Markdown,
I think it makes more sense to consistently use @brief in
the jsdoc comments for functions and classes, so that the generated
documentation.json might be more useful some day.
Added @brief comments for places it was missing.
Fixed obsolete remarks in the documentation for AstroTime:
this type, and its constructor, are both exported now.
Fixed broken link to EclipseEvent function.
The JSDOC type declaration for the Search function's 'func'
parameter was 'ContinuousFunction', which is nowhere defined.
Replaced that with an inline declaration of the function type.
Unfortunately, it shows up in the Markdown code as 'function',
but at least I explain the function's parameter and return type
in the accompanying text.
Use FlexibleDateTime consistently in the JSDOC parameter types.
Expanded the documentation for FlexibleDateTime.
Because we now export the AstroTime constructor, allow it to accept
FlexibleDateTime as a parameter. This means adding the ability to
clone another AstroTime if passed in as the parameter.
Where appropriate, use the more concise TypeScript constructor syntax
that declares members and parameters at the same time.
Use @ignore in JSDOC comments for things I want to document
internally, but are not exported. This way they do not appear
in the generated Markdown files.
Added @ignored documentation for ShadowInfo and body_grav_calc_t,
because these are complicated calculations.
It looks like parentheses are not needed in JSDOC parameter
types, even when there are multiple types separated by vertical bars.
Normalize {(a|b|c)} to {a | b | c} for improved readability.
Created a TypeScript SearchOptions interface for the Search function,
instead of the inline object-shape definition.
Now that we generate separate JavaScript code for Node.js and the browser,
the unit test should use the minified Node version.
It's interesting that the test works equally well with either file.
Perhaps we should consider exercising both in the unit tests?
Also moved the NPM commands to the package.json
so the makedoc scripts execute them in a central place.
Installed a jsdoc theme to improve the html output.
The npm dependencies required are now
installed locally inside the generate folder.
Cleaned up the Astronomy object closure for TS
and kept it for the Browser bundle.
We will have some usage examples in the website.
