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.
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'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.
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.
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.
The JavaScript version of Astronomy.Search was sometimes being passed
an incorrect 'options' parameter. It should always be either omitted
or passed in an object with the correct shape.
Also, there were places where Search failures, indicated by it
returning null, should cause an immediate exception.
When built from a system with a European (or similar) culture setting
where a comma is used as a decimal marker instead of a period,
the C# unit tests and demos would fail.
Now explicitly specify InvariantCulture to resolve these problems.
Improved the type checking by using tsc --strict.
Nothing substatial changed in the generated JavaScript, and no
actual bugs were found, but I removed a lot of loose/sloppy
type signatures. This should make mistakes less likely
in the JavaScript code going forward.
The goal is to provide both TypeScript and JavaScript to developers.
Will also provide a type definition file once I figure that out.
This is just the first pass through the code.
It builds and passes all the unit tests, with some minor changes
to the generated README.md.
I forgot that my build process automatically updates
copyright years when the current year changes.
My Travis CI unit tests verify that there are no local
changes after running all the tests.
That test failed because the update_copyrights.py changed
all the "2019-2020" to "2019-2021".
In all four versions of Astronomy Engine (C, C#, JavaScript, and Python),
starting a search for a full moon near December 19, 2020 would fail.
I added a unit test to all four languages and it failed consistently
across them all.
The root cause: I was too optimistic about how narrow I could make
the window around the approximate moon phase time in the
SearchMoonPhase functions. Finding the exact moon phase time failed
because it was outside this excessively small window around the approximate
time. I increased the window from 1.8 days to 3.0 days.
This should handle all cases with minimal impact on performance.
Now all four of the new unit tests pass.
This new demo shows how to calculate rise and set times
of the Sun and Moon in local time, using Linux functions.
It also sorts the events in chronological order.
I believe this wraps up the Python integrator.
It now works in all 4 languages and passes all tests.
Fixed up demo tests to match new output.
Turned on Travis CI checking in this branch again.
I had to require('./astronomy.js') instead of require('astronomy.js')
to get the nodejs demos working, now that I maintain a redundant
copy of astronomy.js in the demo directories.
Windows does not support relative links in Git by default.
This broke the first-time experience for Windows users.
From now on I will maintain copies of the astronomy.js
and astronomy.py in the demo folders, so that the demos
will work on Windows immediately after cloning the repo.
Using Linux relative links to astronomy.py and astronomy.js
from the demo directories just doesn't work in Windows.
This creates a stumbling block for first-time users.
To make it easier for people to get started, I will just
make redundant copies in other directories as needed.
It is better to use a little extra disk space -- hard drives are cheap!
This is the first step: get rid of the links.
When I added support for pseudo-bodies like SSB
(Solar System Barycenter), it broke the positions.html demo.
Use an explicit list of the bodies to be calculated.
I should probably get rid of Astronomy.Bodies, because it
seems to invite bugs like this. I will think more about that.
Also, there was no way to manually edit the time.
Added a checkbox called "Automatic" that toggles whether
the time is updated automatically every second or
is entered by the user.
Persist the checkbox and edited time in the saved options.
Fixed some build warnings that occur on various gcc
optimization levels, and only on this version of gcc.
For now, build ctest with fewer optimizations: -O1
instead of -O3. This is because -O3 and -O2 cause
excessive errors in 'ctest diff' of the order
1.0e-9, where I usually get 1.0e-12. I will have to
come back and figure out exactly which optimization(s)
are causing the problem and turn them off specifically.
This also means I need to document the dangerous optimizations
for people who are using the C version of Astronomy Engine.
When 'ctest diff' fails because of excessive numeric error,
print out the two lines of input text that had the worst
numeric error. This really helps on the Raspberry Pi
where memory is at a premium, and it's hard to open the
full output files using vi.
It's surprisingly tricky to print a time rounded to the
nearest millisecond, second, or minute using the C code.
I saw a case where positions.c printed '2020-07-09 04:29:60'.
Because printing a date/time is a basic need of an astronomy program,
I added the new function Astronomy_FormatTime to do this.
All the demo programs use this new function, which required
me to update the correct reference output for the unit tests.
Also corrected code generator to output term coefficients
in scientific notation. In the C code, it was dropping signficant
digits by outputting in fixed point notation.
The high-frequency wobble in the Pluto position function was bothering me.
Decreased the arcminute error threshold from 1.0 to 0.5, resulting
in a much larger model, but a lot less ripple:
547 [ 78 140 94 115 21 99]
Now the C version of Astronomy Engine is using the TOP2013 model
of Pluto instead of resampled Chebyshev polynomials.
I added temporary hacks to ignore differences for Pluto between
C output and output from Python, JavaScript, and C#.
I will remove these after all four languages are using TOP2013.
See the variable ToleratePlutoErrors in ctest.c.
ctest.c DiffLine function now understands that longitude-like
angles (right ascension and azimuth) can wrap around, and to tolerate
very small angular differences that happen to straddle the wraparound
value. I should have done this a long time ago, but it never caused
problems before now.
C PlanetApsis has a serious problem with Pluto that I didn't expect.
I need to investigate and understand this before porting to other
languages. For now, I hack around it using ToleratePlutoErrors.
To be consistent, when calculating the geocentric position of the Sun,
we do need to correct for light travel time just like we would for any
other object. This reduces the maximum time error for predicting transits
from 25 minutes to 11 minutes.
Also had to disable aberration when calculating moon phases
(longitude from Sun) in order to keep a good fit with test data.
