cosinekitty / astronomy Goto Github PK

Max angular error is reaching 1.17 arcminutes. Get this down below 1.0 arcminutes. (Start by fixing light travel time and aberration.)

JPL Horizons does not seem to calculate refraction for negative altitude angles the same way NOVAS C 3.1 does. This forced me to skip horizontal coordinate checking for tests cases of objects below the horizon. I would like to reverse engineer the JPL Horizons refraction angle formula by comparing data sets with refraction disabled (airless) and enabled. The NOVAS formula seems unpleasant to work with because it looks like there is a step discontinuity once the zenith angle goes above 91 degrees. It would be nice to see if Horizons has smooth behavior, and if so, I would like to emulate it, both for more complete unit testing and for being able to create Chebyshev approximations of objects like the Moon to have efficient rise/set/culm calculations.

It would be nice to find authoritative values for Saturn's visual magnitude to use as test data. The following paper has formulas for Saturn (and the other planets), but no test data.

https://arxiv.org/ftp/arxiv/papers/1808/1808.01973.pdf

The source code here goes with the paper, and it might be possible to adapt it to create test data:

https://sourceforge.net/projects/planetary-magnitudes/files/

This was a real surprise:

CheckTestOutput: Verified 382306 lines of file temp/js_check.txt : max error = 0.727661 arcmin
CheckTestOutput: Verified 382306 lines of file temp/c_check.txt  : max error = 0.445261 arcmin

This makes me think there is some unnecessary error in the JS output (maybe just need more decimal places in the print statements?)

After fixing this, tighten up the error tolerances.

I was trying to use GitHub Pages just so I could host live demos of the JavaScript browser examples. It worked, but at the cost of having two different versions of this project with different Markdown renderers. I have turned off GitHub Pages. Now I need to create my own static website just for hosting the demos. Also need to automate the process of publishing there every time I hit a stable release.

Embed JavaScript code to demo the Astronomy code right on the GitHub project page. I looked online and apparently Markdown files are a superset of HTML, thus allowing script tags, etc. Could show the location of all the planets, the Moon's phase, stuff like that.

Create a document that explains astronomy terminology. Alphabetically sorted glossary. Allow deep linking from other documents.

• Observers
  • Heliocentric
  • Geocentric
  • Topocentric
• Coordinate systems
  • Equatorial
  • Ecliptic
  • Horizontal
• Different time scales (UT, TT).
  • UTC/UT1
  • Terrestrial Time
• Barycenters: SSB, EMB.
• Apsides: pericenter and apocenter.
• Equinox has two meanings:
  • A location on the Earth's orbit.
  • A time at which the Earth reaches the equinox point.
• (Search through documentation for all astronomy jargon.)

I found a case where there is a sudden jump from a negative Sun altitude to a positive, then back to negative, all over a span of 3 seconds:

1750-11-21 00:46:08.384, peak_altitude = -4.178
1750-11-21 00:46:09.384, peak_altitude = +6.752
1750-11-21 00:46:10.384, peak_altitude = -4.86

This is for the Sun with an observer at latitude +15, longitude +75, height = 0 meters.

Port all the target code to Python 3.

Calculate the visual magnitude of the Sun, Moon, and all planets as seen from the Earth. Geocentric calculation is fine; does not need to be micro-adjusted for a topocentric observer. Because this entails calculating distance and phase angle, include those data in the calculated results. (No phase angle for the Sun because it emits light instead of reflecting it!) Also include ring angle for Saturn in returned results.

Create an npm package for the JavaScript version of the Astronomy library.

Mainly this will affect the Chebyshev model for Pluto. All the VSOP stuff should work fine as-is.

The "elongation" in the name SearchMaxElongation is inconsistent with the function Elongation, which calculates an ecliptic longitude difference. It is really related to AngleFromSun.

Likewise, the type ElongationEvent is confusing. Rename whatever is needed to get consistent terminology throughout the library.

Provide ability to find the next major moon phase, given a start search date: new, first quarter, full moon, third quarter.

Line 145936 in c_check.txt and js_check.txt have a small discrepancy:

ctest(Diff): Maximum numeric difference = 1.81899e-12, worst line number = 145936

js_check.txt

s Venus -39864.1907954055495793 -39864.1907264927140204 17.3098151195010921 -28.0371006234166060 0.3456613889446833 34.5081734386010766 -88.6913704437932324

c_check.txt

s Venus -39864.1907954055495793 -39864.1907264927140204 17.3098151195010921 -28.0371006234166096 0.3456613889446833 34.5081734385992576 -88.6913704437932608

See if this can be improved or eliminated.

Calculate when the inferior planets have maximum angular separation from the Sun as seen from the center of the Earth. Report the angular separation in degrees along with the date/time of the event. Distinguish between morning sky visibility and evening sky visibility.

Find date/time of when Venus appears brightest in the sky. Also report the maximum magnitude value at this time. Depends on #18.

Use relative longitude between Sun and other objects to determine the times of planet conjunctions and oppositions. For Mercury and Venus, distinguish between inferior and superior conjunctions.

Offer a database of the brighter stars (mag <= 4.0)? This will be a separate add-on module in the JavaScript version.

Mercury and Mars have high orbital eccentricities. This causes SearchRelativeLongitude to take a long time to converge, especially for Mercury. Improve the algorithm so that it converges faster. The other planets converge within 4 or 5 iterations, but Mercury takes somewhere between 20 and 100.

Do profiling to figure out what's going on here. Seems much slower than it should be, compared to JavaScript and C versions.

Tables in documentation looks correct at:
https://cosinekitty.github.io/astronomy/source/c/

But is all messed up in:
https://github.com/cosinekitty/astronomy/tree/master/source/c/

Why don't the tables work there?

Provide functions in JavaScript code to find the next rise, set, culm times for any object between a given pair of times. There may not be any (e.g. Moon never rises on some days, and some objects are circumpolar for a while at latitudes far from the equator).

Consider creating generic search functions that can find other events such as full moon, conjunctions, etc.

This is happening every now and then in the Travis CI build. Need to set a longer timeout and/or retry after errors.

$ cd generate && ./run && ./verify_clean
Ephemeris file not found: lnxp1600p2200.405
Trying to download for you from:
https://github.com/cosinekitty/ephemeris/raw/master/lnxp1600p2200.405
--2019-05-10 00:05:39--  https://github.com/cosinekitty/ephemeris/raw/master/lnxp1600p2200.405
Resolving github.com (github.com)... 192.30.253.113
Connecting to github.com (github.com)|192.30.253.113|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/cosinekitty/ephemeris/master/lnxp1600p2200.405 [following]
--2019-05-10 00:05:39--  https://raw.githubusercontent.com/cosinekitty/ephemeris/master/lnxp1600p2200.405
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.0.133, 151.101.64.133, 151.101.128.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.0.133|:443... connected.
HTTP request sent, awaiting response... 503 first byte timeout
2019-05-10 00:06:40 ERROR 503: first byte timeout.
ERROR(./run): Could not download using wget: https://github.com/cosinekitty/ephemeris/raw/master/lnxp1600p2200.405
The command "cd generate && ./run && ./verify_clean" exited with 1.

When correcting the position of an object for light travel time, because the position is expressed in heliocentric coordinates, there is no need to correct the Sun's position because it is always at (0, 0, 0).

Create hand-crafted data file with test cases from JPL Horizons: (RA,DEC), (az,alt). Test every body from a variety of times and geographic locations. This is mainly as a sanity check that I'm not calling NOVAS functions wrong.

I'm not sure this is just a quirk of Python floating point, or if there is a subtle bug somewhere. But there is a discrepancy between the numbers calculated by Python and those calculated by C and JavaScript:

don@spearmint:~/github/astronomy/generate $ ./ctest diff temp/{py,js}_check.txt
ctest(Diff): Maximum numeric difference = 8.90736e-11, worst line number = 33246
ERROR: Excessive error comparing files temp/py_check.txt and temp/js_check.txt
ctest exiting with 1
don@spearmint:~/github/astronomy/generate $ ./ctest diff temp/{c,js}_check.txt
ctest(Diff): Maximum numeric difference = 1.81899e-12, worst line number = 145936
ctest exiting with 0

Add support to build C unit tests on Windows, and run them. Can create a Visual Studio solution to build the code written by generate.c. This way developers can work on Windows just as well as Linux.

Currently the makedoc Linux bash script knows how to translate doxygen xml files to markdown format, but it uses xsltproc to do so. Need to add support for generating the same documentation in Windows: running doxygen and translating the resulting xml.

Astronomy_SearchRelativeLongitude finds relative longitude as measured from the Sun's point of view. But astro_elongation_t::relative_longitude indicates relative longitude from the Earth's point of view. This is likely to confuse people. Consider renaming one or both of these.

Document why this project was created. Tell the story of how I started out trying to translate NOVAS directly to JavaScript and discovered it requires large ephemeris files.

Document project goals:

• Reliable and well-tested.
• Easier for programmers who are not professional astronomers to understand and use.
• Small and efficient code within 1 arcminute precision.
• Focused on use in amateur astronomy, calendars, etc.

Given (RA,DEC) in J2000 coordinates, calculate 1875 coordinates and look up the correct constellation name. Because many users won't care about constellations, this will be an optional add-on module in the JavaScript.

Include aberration in the calculation of (RA,DEC). Lack of this calculation contributes up to 1/3 of an arcminute of error.

Use a tool like Travis CI to run unit tests when commits and/or pull requests are submitted. This will help flag problems quickly so they can't slip through the cracks.

I don't like how the Search() function does a dumb binary search for the zero crossing. Something like Newton's method or quadratic interpolation could be a lot more efficient. I don't want to sacrifice accuracy though. And there should be some empirical evidence that things are really faster with such a change: like actually timing unit tests that exercise Search.

Given a location (longitude, latitude, elevation), a date and time, and equatorial coordinates (RA, DEC), calculate horizontal coordinates (azimuth, altitude) for an object. Must include refraction calculations so that rise/set times (to be implemented later) are accurate.

Change the lingering vague names of the project to "Astronomy Engine" throughout all code and documentation.

I encountered a problem where doxygen running on my Windows laptop causes the generated C documentation README.md to be messed up. The cause turned out to be trailing whitespace in astronomy.c. Once I cleaned that up, the markdown generated by Windows is the same as on Linux.

Plus, trailing whitespace is just annoying. I want to automatically strip trailing whitespace from all source code before generating documentation.

Provided a minified version of the generated JavaScript library. Use Google Closure compiler?

Calculate when any of the planets is closest to the Sun or farthest from the Sun, along with distance in AU. Will need to obtain authoritative test data: date & time of a series of apsides for every planet.

I can use the following to test apsides of Earth. Not sure how to do this for other planets; perhaps could use JPL Horizons to plot heliocentric distances of each planet with respect to time.

http://astropixels.com/ephemeris/perap2001.html

This just popped up for the first time.

novas.c(2306): warning C4701: potentially uninitialized local variable 'obl' used

Especially focus on .NET Core.

It may be better to use direct empirical data for delta-t values instead of calculating leap seconds.

See: https://www.usno.navy.mil/USNO/earth-orientation/eo-products/long-term

Data files:
http://maia.usno.navy.mil/ser7/historic_deltat.data
http://maia.usno.navy.mil/ser7/deltat.data
http://maia.usno.navy.mil/ser7/deltat.input
http://maia.usno.navy.mil/ser7/deltat.preds

The Chebyshev coefficients generated in the Javascript code are slightly different for Pluto, when generated by Windows versus Linux. I suspect the real issue is that I'm running different versions of node:
Windows: v10.15.3
Linux: v8.15.1

Find when moon is closest, furthest from the Earth's center. Report distance (center to center?) in kilometers.

Port all the code to C with a C++ friendly wrapper.

Find next solstice or equinox.

Julian Dates reduce precision by consuming so many mantissa bits. Rework to use days since 2000 (or 1900, or MJD=1857-11-17?), which is closer to the center of my eventual range of supported years (1600..2200).

On Travis CI only, confirm that generated code exactly matches what was checked in by the committer. Otherwise we are not publishing the same code that the generator creates!

Add support for the Go programming language.