While trying to convert ecliptic coordinates from mean
equinox of date to true equinox of date, I ran into excessive
overhead from the IAU2000B nutation model. The fact that it
uses 77 trigonometric terms made the calculations a lot slower.
https://apps.dtic.mil/sti/pdfs/AD1112517.pdf
Page 4 in the above document mentions a shorter series
“NOD version 2” that has 13 terms instead of 77 as used in IAU2000B.
I had not noticed NOD2 before, because it appears only in
the FORTRAN version of NOVAS 3.x, not the C version.
After reading the FORTRAN code, I realized NOD2 is the same
as IAU2000B, only it keeps the first 13 of 77 terms.
The terms are already arranged in descending order of
significance, so it is easy to truncate the series.
Based on this discovery, I realized I could achieve all of
the required accuracy needed for Astronomy Engine by
keeping only the first 5 terms of the nutation series.
This tremendously speeds up nutation calculations while
sacrificing only a couple of arcseconds of accuracy.
It also makes the minified JavaScript code smaller:
Before: 119500 bytes.
After: 116653 bytes.
So that's what I did here. Most of the work was updating
unit tests for accepting slightly different calculation
results.
The nutation formula change did trigger detection of a
lurking bug in the inverse_terra functions, which convert
a geocentric vector into latitude, longitude, and elevation
(i.e. an Observer object). The Newton's Method loop in
this function was not always converging, resulting in
an infinite loop. I fixed that by increasing the
convergence threshold and throwing an exception
if the loop iterates more than 10 times.
I also fixed a couple of bugs in the `demotest` scripts.
Modified the code generator and source templates to allow
using fewer than 77 terms from the IAU2000B nutation model.
The number of terms causes calculations to be far slower than
I would like, plus most of these terms provide far less than
one arcsecond of difference in the output.
I want to experiment with truncated versions of the series.
https://apps.dtic.mil/sti/pdfs/AD1112517.pdf
Page 4 in the above document references a shorter series
"NOD version 2" that has only 13 terms instead of 77 as used in IAU2000B.
I found that code and confirmed the 13 terms are the first 13
consecutive terms from the original 77.
This commit does not change the number of terms calculated;
it only enables doing so by changing a single #define in
generate/codegen.c.
Once I change the nutation model, I'm sure there will be multiple
tweaks to unit tests to get everything working again.
The documentation for SearchRiseSet and SearchAltitude needed
clarification about refraction and the part of the body solved
for (center versus limb). The JavaScript version was especially
lacking compared to documentation for the other languages.
Also documented SearchAltitude's limitations; it does not
work at or near maximum/minimum altitude.
Mention that user-defined stars are allowed for
SearchRiseSet, SearchAltitude, and SearchHourAngle.
Fixed a couple places where the Kotlin documentation had
broken links to other functions.
I had a copy-n-paste typo in the `dec` parameters
for all of the DefineStar functions. Fixed it.
The TypeScript version of HelioState did not handle
user-defined stars. Added support there.
Because we instantly know the heliocentric
distance of a user-defined star, there is no
need to convert it into a vector and then take
the length of the vector.
All of the HelioDistance functions now return
the distance directly, as an optimization.
Also, I decided it didn't make sense to have a
default definition for user-defined stars.
If the caller doesn't define a star, it should
be treated as an invalid body.
Added Python support for user-defined stars.
Defined new StateVector methods: Position and Velocity.
Defined division operator: Vector / float.
Bumped version number to 2.1.12.
Made sure all the altitude search functions
verify that the geographic latitude and target altitude
are valid numbers in the range [-90, +90].
Reworked the C version of the code to be clearer:
eliminated goofy ALTDIFF macro, split out max
altitude derivative into its own function MaxAltitudeSlope,
just like the other language implementations do.
Minor rewording of comments in MaxAltitudeSlope functions.
Python InvalidBodyError now includes the invalid body
in the diagnostic message.
The C# version of the altitude searches now work correctly
near the Earth's poles. This is a port of the C version.
Cleaned up a little code in the C version.
This is a whole new algorithm that efficiently finds
all rise/set events, even near the poles.
It uses a recursive bisection search that limits
recursion depth by knowing the maximum possible
|da/dt| = change in altitude with respect to time.
This is my second attempt to release eclipse obscuration.
I discovered there was a missing unit test for obscuration
for lunar eclipses in the Kotlin library. It has been added.
I ported the NOVAS C 3.1 functions julian_date and cal_date to Python,
and removed the dependence on the standard datetime class for calculating UT.
Now we can create Time objects for a much wider range of year values.
Simplified the julian_date formula in C and C#.
In the Python version, I had to account for a difference
in the way integer division works for negative numbers.
In Python, integer division always rounds down, not toward
zero like it does in C/C#. So I reworked the formulas to
avoid dividing a negative integer (month-14), dividing the
positive quantity (14-month) instead and toggling addition
of the term with subtraction of the term.
I use the reworked (14-month) version in C and C# for consistency.
Also, the formatting of the formula was wacky and didn't make sense,
so now it easier to read and understand.
The Python regex for parsing dates has been expanded to allow
years before 0 and after 9999.
Allow converting Python Time to string for years before 0 and after 9999.
The .NET type System.DateTime is limited to the years 0000..9999.
The Astronomy Engine type AstroTime was using System.DateTime to
convert a (year, month, day, hour, minute, second) tuple into a
fractional day value. This caused an exception for years outside
the supported range 0000..9999.
I ported the NOVAS C 3.1 functions julian_date and cal_date to C#,
and removed the dependence on System.DateTime.
Now we can create AstroTime for a much wider range of year values.
Allow converting AstroTime to string for years before 0 and after 9999.
The following Python functions now support searching
in forward or reverse chronological order:
SearchRiseSet
SearchAltitude
SearchHourAngle
Made some minor performance improvements to the
other implementations: return sooner if we
go past time window.
The following C# functions now support searching
in forward or reverse chronological order:
Astronomy.SearchRiseSet
Astronomy.SearchAltitude
Astronomy.SearchHourAngle
Also fixed places where I forgot to update documentation
for the corresponding changes to the C code.
Enhanced the C# function Astronomy.SearchMoonPhase
to allow searching forward in time when the `limitDays`
argument is positive, or backward in time when `limitDays`
is negative.
Added unit test "moon_reverse" to verify this new feature.
It turns out that "sed" does not work on Mac OS,
and I wasn't even trying to patch the version
numbers on Windows. I decided to write a Python
program for this task, so it will work identically
on all 3 operating systems.
Provide shield.io badges for pypi, npm, and nuget packages.
On the main README page, moved the badges into the supported
languages grid.
Added link and badge on each language documentation page.
Now that I have retargeted astronomy.csproj from
net5.0 to netstandard2.0, there are a couple of
other little improvements that are now possible:
1. In my manual Framework 4 test project, instead
of directly pulling in the source file astronomy.cs,
add astronomy.csproj as a project reference.
This demonstrates that the same binary astronomy.dll
works in both Framework and Core.
2. Now there is no need/use for conditional compilation
directives in the Astronomy.CubeRoot function.
Instead, always use my own implementation since the
Math.Cbrt function is never available.
From a testing standpoint, this was probably
the better option all along.
https://www.nuget.org/packages/CosineKitty.AstronomyEngine/2.1.2
This is my first attempt at publishing a NuGet package.
I have never done this before, so I'm not sure it is going to work.
Changed astronomy.csproj to target netstandard2.0, which still
works fine with all my net6.0 unit tests.
The csdown utility was not generating the correct ID
string that matched the C# compiler's XML output file
when a parameter was of a generic type.
Because the GravitySimulator constructor has a bodyStates
parameter of type IEnumerable<StateVector>, we were not
generating the correct method ID string:
CosineKitty.GravitySimulator.#ctor(CosineKitty.Body,CosineKitty.AstroTime,System.Collections.Generic.IEnumerable{CosineKitty.StateVector})
This caused the constructor to not show up in the markdown docs.
I fixed this and now the constructor is documented.
Corrected a mistake in the explanation of the
C function Astronomy_GravSimInit: the `bodyStates`
parameter is NOT barycentric -- it is relative to the
originBody parameter.
Python had improperly formatted documentation for
Time.FromTerrestrialTime parameter `tt`.
The Python markdown generator `pydown` did not
correctly handle links to compound symbols like
`#GravitySimulator.Update`. It also was trying
to link to `StateVector[]` instead of `StateVector`.
Removed unnecessary and unhelpful documentation
for C# internal class constructors. They do not appear
in the generated markdown documentation anyway.
Other minor wording revisions in the documentation.
The C# markdown generator (csdown) was not generating
documentation about constructors. This was especially
needed for the new GravitySimulator class.
Also added markdown for properties like
GravitySimulator.NumSmallBodies
GravitySimulator.Time
Made several constructors internal so they don't
need to be listed in the markdown docs.
