Star Chart Verification: An Independent Review
The goal of this website is to investigate underlying beauty and order. To check our accuracy, we engaged an astronomer to review our work. He was asked to validate our methodology, then to take a set of representative chart outputs and compare them against independent references: NASA JPL Horizons and Stellarium Web.
Dr. Juan Manuel Salerno of the Instituto de Astronomรญa Teรณrica y Experimental reviewed the star, planet, and Moon positions and the Moon’s phase and illuminated fraction. His signed statement is below, in full and unedited, along with his verification reports. He signed as an individual astronomer. The institute is named to identify him, not to endorse us.
What he reviewed
Along with our declared methodology and representative outputs, he was given a written account of how the engine works, including what it deliberately leaves out, and an extensive set of computed positions to check.
Dr. Salerno’s signed methodology review statement. The full documents are available at the foot of this page.
Read Dr. Salerno’s statement as text
May 10, 2026
Astronomical Methodology Review Statement
GoRhyme Personalized Star Chart Product
I reviewed the declared astronomical methodology and representative verification outputs for the GoRhyme personalized star chart product. The reviewed results show that the star, planet, and Moon positions are consistent with established astronomical reference tools within tolerances appropriate for fine art print reproduction. The verification also supports the consistency of the Moon phase and illuminated fraction for the intended visual use of the product.
Signature: [signed]
Dr. Juan Manuel Salerno
Instituto de Astronomรญa Teรณrica y Experimental
What we tested before we sent it out
Our engine computes positions from the HYG 4.2 star catalog and Astronomy Engine 2.1.19, accounting for proper motion, precession, nutation, and atmospheric refraction, then projects them with a zenithal stereographic projection.
Before we sent anything out, we ran our own verification: 28 star cases and 15 planet and Moon cases, grouped so that each group tests a specific way a star chart can go wrong. Many of the cases test the edges. In the southern hemisphere, an engine that fails to flip the sky draws Sydney’s view upside down. We tested latitudes above 60 degrees north and below 60 degrees south, out to Alert, Canada, at 82.5 degrees and McMurdo Station at 77.8 degrees south. At the equator, both celestial poles sit on the horizon at once, and a careless calculation divides by zero. We also tested the date line, midnight at the exact epoch boundary, and a catalog index check for a phantom star at coordinates zero, zero.
Dates run from 2 BCE through to the present, including Tycho’s supernova night in 1572, the evening Pluto was discovered in 1930, and the 2003 Mars opposition.
Some of those cases are checks on the drawing, not the numbers. A planet below the horizon has to be absent from the rendered chart, not merely negative in a table. The Moon’s lit limb has to face west on a waxing crescent and east on a waning one. Seen from Sydney, the whole Moon has to turn over.
Every case passed but one. Case 24 puts Vega over Bethlehem in 2 BCE, and the precession model we use is not validated that far back. We marked it DOCUMENT instead of PASS in our own grid, before any outside review, because we could not verify it and did not want to record it as verified.
Why we asked anyway
Our verification compared our engine’s output against PyEphem. Both libraries implement the same underlying planetary theory, VSOP87, which is why the two agreed to four decimal places on most cases. That agreement shows the implementation is sound, but a check between two descendants of one theory cannot tell you whether the theory was applied wrong for your particular observer.
So we sent the whole set to Dr. Salerno. He rebuilt the calculation independently in R and recomputed every case. Then, where the tools allowed, he checked both results by hand against NASA JPL Horizons and Stellarium Web. He could not confirm five of the star cases we had recorded as passing.
How the star cases came out
We ran 28 star cases. One of them, Polaris over Quito, had been failing on our own grid, and the outside check traced it to an elevation handling error in our verification code, not to any disagreement about the sky. It was repaired and it passes now, but because the case was rewritten during the review, we have withdrawn it from the count. That leaves 27 cases evaluated. Twenty-two came in inside the 0.1 degree tolerance, and five did not.
In the 22 that passed, the average angular separation between our positions and Dr. Salerno’s was about 0.000954 degrees, roughly 3.4 arcseconds. The worst passing case was about 20 arcseconds. For scale, the full Moon is about 1,800 arcseconds across, so the typical disagreement is a small fraction of the width of the Moon as you see it.
The five that did not confirm
Cases 8, 21, 24, 25, and 26 did not confirm. Their average angular separation was about 0.423 degrees, and the largest was 0.584 degrees. The full case notes are in the manual results report below.
In three of them, case 8, Polaris over Sydney, case 21, Canopus over Singapore, and case 25, Canopus over Samoa, the hand check in Stellarium Web landed closer to Dr. Salerno’s recalculation than to our value. His report concludes that the discrepancy is probably in our expected value, not in his calculation. We are treating our altitude as the error.
Case 24 is the Bethlehem case we had already set aside. Stellarium Web would not accept the negative year either, so it is now unverified from both directions and stays that way until we find a tool that handles BCE dates properly.
Case 26, Canopus over Tonga, is not a clean test. The coordinates entered into Stellarium Web did not match the coordinates in our case, because Stellarium Web accepts city names, not exact coordinates. A shifted observer moves a low star’s altitude on its own, so that case stays open.
What that means for a chart you order
The largest of the five, 0.584 degrees, is a little over the width of the full Moon as you see it in the sky. On a printed chart, the full Moon at this scale is .5 millimeters across (depending on chart size selected), and a star is a dot considerably smaller than that. Half a degree of altitude error moves a star by roughly the width of the Moon and no further, and it moves it only in the vertical, so no constellation changes shape. Three of the five are also concentrated in one situation, a bright star very low over a southern hemisphere horizon, which is exactly where refraction is hardest to model and where the smallest error in observer elevation shows up most.
What the planet and Moon cases show
The fifteen planet and Moon cases cover the Moon, Mercury, Venus, Mars, Jupiter, and Saturn. Three things decide whether a chart like this is right: where an object sits, how much of the Moon is lit, and what phase it is showing. A wrong Moon is the one error a viewer will catch without instruments.
Variable Largest disagreement Tolerance Result
Azimuth 0.0054ยฐ 0.5ยฐ Pass
Altitude 0.4191ยฐ 0.5ยฐ Pass
Illuminated fraction 0.0458% 1% Pass
Phase angle 0.1344ยฐ 1ยฐ Pass
Apparent magnitude (not a position, see below) 0.42 mag 0.1 mag Fail, 9 of 15 cases
Worst case across all fifteen planet and Moon cases, compared against the tolerance for each variable. The first four are what place an object on the chart and draw the Moon’s phase. The fifth is brightness, which is discussed below.
Dr. Salerno’s own recalculation sat extremely close to Horizons, averaging about 0.00078 degrees in azimuth and 0.00056 degrees in altitude. Our values averaged about 0.086 degrees from Horizons in altitude. That is larger than his by a wide factor and still well inside the tolerance for the product.
Apparent magnitude, and why it sits outside the review
Nine of the fifteen planet and Moon cases are marked FAIL. Every one failed on apparent magnitude alone, with position, illumination, and phase inside tolerance.
Apparent magnitude is not a position. It is a photometric estimate, and it depends on how a given library models the way a planet’s disc reflects sunlight at a given phase angle. Saturn is especially sensitive because of the rings, and Mercury and Venus swing with phase angle. Two tools can put a planet in exactly the same place and still disagree about how bright it is.
We did not ask Dr. Salerno to focus on magnitude, because it does not change any positions, and his analysis sets it aside for the same reason. Our renderer sizes a planet’s drawn disc from computed magnitude, so even the largest disagreement, 0.42 magnitude, changes only the diameter of one dot on a chart carrying hundreds of them. The conclusion the review supports is about position, illumination, and phase, which is what a printed chart is judged on.
What the engine does not do
The declared methodology that was reviewed includes what we leave out.
We do not draw the Sun. We do not apply aberration to star positions. We do not model daylight or atmospheric extinction, so the chart shows the sky as though it were dark and clear, whatever the real conditions were. We draw constellation lines for 39 constellations, not all 88. This was a deliberate choice, and the reasoning is on our star chart calculation page.
The documents
All four are reproduced in full. Nothing edited, summarized, or excerpted. The figures Dr. Salerno produced, comparing results against Horizons and Stellarium Web case by case, are inside them.
Endorsement (image) Astronomical methodology review statement. Dr. Salernoโs signed statement on the methodology and the verification outputs.
Read Dr. Salerno’s statement as text
May 10, 2026
Astronomical Methodology Review Statement
GoRhyme Personalized Star Chart Product
I reviewed the declared astronomical methodology and representative verification outputs for the GoRhyme personalized star chart product. The reviewed results show that the star, planet, and Moon positions are consistent with established astronomical reference tools within tolerances appropriate for fine art print reproduction. The verification also supports the consistency of the Moon phase and illuminated fraction for the intended visual use of the product.
Signature: [signed]
Dr. Juan Manuel Salerno
Instituto de Astronomรญa Teรณrica y Experimental
Star verification (PDF) Star verification manual results report. All 28 star cases checked by hand in Stellarium Web, case by case, including the five that did not confirm and the reasoning on each.
Read the Star Verification Manual Results Report as text
Star Verification Manual Results Report
DIFFERENCE CALCULATION
To compare the results, angular differences were used between three sources: the expected Excel/JPL-Stellarium values, the values calculated by the script, and the values checked manually in Stellarium Web.
The altitude difference is calculated as a simple absolute difference:
abs(compared_altitude - reference_altitude)
The azimuth difference is also treated as an angular difference, but taking into account that azimuth is circular and runs from 0ยฐ to 360ยฐ. This avoids artificial errors when one value is close to 0ยฐ and the other is close to 360ยฐ. Conceptually, the formula used is:
abs(((compared_azimuth - reference_azimuth + 180) %% 360) - 180)
The differences are mainly expressed in arcseconds. To convert them to degrees, they are divided by 3600. The tolerance used by the star script is 0.1ยฐ, equivalent to 360 arcseconds. Therefore, differences of 10″, 30″, or even 100″ are still within tolerance. A difference greater than 360″ exceeds the 0.1ยฐ tolerance.
SUMMARY OF MANUAL RESULTS
The manual review with Stellarium Web confirms that most of the star cases are consistent with the Excel/JPL-Stellarium values and with the script. In the passing cases, the differences are usually well below 0.1ยฐ. In several examples, the differences are only a few arcseconds in azimuth and between 5″ and 40″ in altitude, which is acceptable for the defined tolerance.
Cases 1 to 7 show good agreement. Sirius, Polaris, Vega, and Canopus remain within tolerance with small differences. In case 6, Vega in Chicago, two slightly different times were tested in Stellarium Web. The first time is closer to both the Excel and the script; the second is farther away in azimuth, but still remains within the 0.1ยฐ tolerance. This shows that small differences of a few seconds in the entered time can noticeably shift the azimuth, especially for high-altitude stars.
Case 8, Polaris in Sydney, confirms a real failure against the Excel. Stellarium Web is very close to the script, but far from the expected Excel value in altitude. The difference against the Excel is approximately 0.413ยฐ in altitude, while the difference against the script is much smaller. This indicates that the problem is probably in the Excel reference value, not in the script calculation.
Cases 9 to 18, except for specific notes, pass correctly. Canopus, Achernar, Sigma Octantis, Polaris, Vega, and Pollux show differences compatible with the defined tolerance. At high latitudes, such as Reykjavik, Tromsรธ, Fairbanks, and Alert Canada, the differences remain within the acceptable margin. This is important because those scenarios are more sensitive due to the observing geometry near the celestial pole.
Case 19, Sigma Octantis in McMurdo, cannot be evaluated as a direct astronomical discrepancy because the coordinates used in Stellarium Web do not match the coordinates in the Excel file. The Excel uses latitude -77.85 and longitude 166.72, while Stellarium was configured with latitude -77.52665 and longitude 164.98549. The latitude difference is approximately 0.323ยฐ, and the observed altitude error is approximately 0.338ยฐ. That correspondence indicates that the difference is mainly explained by the different location, not by an error in the script.
Case 20, Polaris in Quito, initially appeared as a failure, but after correcting the elevation handling in the calculation, it became PASS/PASS2. The manual comparison shows that Stellarium is close to both the Excel and the script. The previous failure came from how Quitoโs elevation was being applied in astrolibR, not from an underlying astronomical discrepancy.
Case 21, Canopus in Singapore, confirms another relevant failure in the Excel or expected reference value. Stellarium Web is much closer to the script than to the Excel: against the Excel, the altitude difference is approximately 1369″, while against the script the difference drops to about 42″. This supports the script calculation and suggests that the expected Excel value does not match an external reference.
Cases 22 and 23 pass. In Greenwich for 1572 and Flagstaff for 1930, the differences with Stellarium Web remain below the 0.1ยฐ tolerance. The historical Greenwich case shows an azimuth difference of about 36″, which is still acceptable.
Case 24, Vega in Bethlehem with a negative year, could not be manually verified in Stellarium Web because the system did not allow the BCE year to be entered correctly. Therefore, there is no valid manual comparison for that case. The script keeps it as FAIL/FAIL2 against the Excel, but the external manual validation remains pending or requires another tool that correctly handles BCE years.
Cases 25 and 26 show relevant issues. In case 25, Canopus in Samoa, Stellarium Web is much closer to the script than to the Excel in altitude, although there is still a noticeable difference. Against the Excel, the altitude difference is approximately 1704.5″, while against the script it drops to about 140.3″. This suggests that the Excel/expected reference may be offset. In case 26, Canopus in Tonga, there is also an important difference between the case coordinates and the coordinates used in Stellarium Web. For that reason, the comparison should not be interpreted as a clean test until the exact location is confirmed.
Case 27, Sirius in New York City, passes. The manual comparison is close to the expected value and within tolerance.
GENERAL CONCLUSION
The manual verification supports most of the results from the star script. In the PASS cases, the differences with Stellarium Web are small and well below the 0.1ยฐ tolerance. In several failed cases, Stellarium Web aligns better with the script than with the Excel, especially in cases 8, 21, and 25. This suggests that some FAIL results do not necessarily come from the script calculation, but from expected Excel values or configuration differences in Stellarium Web.
In addition, there are two FAIL cases whose differences can be explained by limited precision in the coordinate configuration in Stellarium Web, since it only accepts city names and not exact coordinate entry.
Astronomical analysis (PDF) Dr. Salernoโs own analysis, including his reasoning on numerical difference against visual impact, and his general conclusion.
Read the Astronomical Output Analysis as text
Astronomical Output Analysis for the GoRhyme Product
Dr. Juan Manuel Salerno
The analysis focused on evaluating the astronomical consistency of the verification data provided for the GoRhyme Star Chart product. To do this, three levels of information were compared: the values included in the Excel files sent by Kelly, the results recalculated by our scripts, and, when possible, independent external references obtained manually with Stellarium Web and NASA JPL Horizons.
The comparison was not framed as a search for perfect numerical agreement, but as an assessment of accuracy applied to the actual use of the product. GoRhyme Star Chart does not deliver tables to the final user: it generates a printed star chart from a date, a time, and a location. Therefore, the important point is to determine whether the detected differences could visibly or significantly affect the position of stars, planets, and the Moon within the chart, or whether they remain within a reasonable margin for an art product with an astronomical basis.
For this reason, two levels of interpretation must be separated. First, the numerical difference: how far the script is from the Excel file or from an external reference. Second, the visual impact: whether that difference would perceptibly change the position of a star, a planet, or the Moon in the final chart.
Difference Calculation
For stars, azimuth and altitude were compared. Altitude was calculated using a simple absolute difference:
ฮh = |hcal โ href|
For azimuth, a circular angular difference was used because azimuth runs from 0ยฐ to 360ยฐ. This avoids artificial errors when one value is near 359ยฐ and the other is near 0ยฐ:
ฮA = |((Acal โ Aref + 180ยฐ) mod 360ยฐ) โ 180ยฐ|
Angular separation was also calculated, combining azimuth and altitude into a single geometric measure. This measure is useful because it summarizes the real distance between two positions in the sky:
ฮฮธ = cosโ1 [sin(hcal) sin(href) + cos(hcal) cos(href) cos(Acal โ Aref)]
This equation gives the angular separation between the calculated position and the reference position on the celestial sphere. Here, h is altitude and A is azimuth. The subscripts cal and ref refer to the calculated value and the reference value. The result, ฮฮธ, is a single angular error that combines both azimuth and altitude differences into one geometric measure.
For planets and the Moon, the same azimuth and altitude differences were used, together with absolute differences for illuminated percentage, phase angle, and apparent magnitude. The current tolerances are: 0.5ยฐ for azimuth and altitude, 1% for illumination, 1ยฐ for phase, and 0.1 magnitudes for apparent magnitude.
Star Results
For stars, the automatic analysis worked with 28 cases. Of these, 27 correspond to evaluable stars and 1 corresponds to a special catalog case, HIP 0, which does not represent a real star and is therefore documented separately.
Of the 27 evaluable cases, 22 passed the automatic validation and 5 were marked as FAIL. The passing cases show very solid results: the average angular separation was approximately 0.000954ยฐ, equivalent to about 3.4 arcseconds. The worst approved case had an angular separation of approximately 0.005549ยฐ, about 20 arcseconds. These values are far below the defined tolerance of 0.1ยฐ.
This means that, for most of the verified stars, the script not only remains within tolerance, but does so with a wide margin. For a printed star chart, differences of this size should not be visually relevant.
The cases marked as FAIL are cases 8, 21, 24, 25, and 26. In these cases, the average angular separation is approximately 0.423ยฐ, and the maximum reaches 0.584ยฐ. These values exceed the 0.1ยฐ tolerance, which is why they appear as automatic failures.
However, the manual review with Stellarium Web changes the interpretation of several of these FAIL cases. In case 8, Polaris in Sydney, Stellarium Web is much closer to the script than to the Excel file. The main difference is in the expected altitude from the Excel file. This suggests that the issue is probably in the expected reference value, not in the script calculation. It should also be mentioned that Stellarium Web does not allow entering latitude and longitude directly, only a city name.
Something similar occurs in case 21, Canopus in Singapore. Stellarium Web is close to the script and far from the Excel file in altitude. This again indicates that the expected Excel value may be shifted or calculated under a different configuration.
In case 25, Canopus in Samoa, Stellarium Web is also much closer to the script than to the Excel file. The difference relative to the Excel file is large, while the difference relative to the script decreases substantially. This again points to a discrepancy in the reference or in the original configuration.
Case 24, Vega in Bethlehem with a negative year, remains pending for stronger external validation because Stellarium Web did not allow the BCE year to be loaded correctly. This case should not be used as final evidence against the script without checking it with a tool that correctly handles BCE dates.
Case 26, Canopus in Tonga, also requires caution because the manual comparison with Stellarium Web did not use exactly the same coordinates as the Excel file. When coordinates change, especially for low stars or for sensitive areas of the sky, altitude can change substantially. Therefore, this case should not be interpreted as a clean comparison until the exact location is confirmed.
Interpretation for Stars
The Excel results for stars are mostly consistent with the verifications performed. Most cases remain well within the defined tolerance, indicating that the azimuth and altitude positions included in the Excel file are adequate for the objective of the product. In the cases marked as FAIL, the differences appear to be concentrated in specific situations: some cases depend strongly on the exact observer location, and Stellarium Web does not always allow precise coordinates to be entered, but may instead use a city or approximate location. This can shift the observed altitude, especially for stars close to the celestial pole or objects low above the horizon. In addition, in some cases Stellarium Web is closer to the values calculated by the script than to the values in the Excel file, suggesting that these discrepancies do not necessarily indicate a problem with the Excel file.
Planet and Moon Results
For planets and the Moon, the Excel file Planet and Moon Chart.xlsx was used. It contains 15 cases with several numerical properties per case. At this stage, the analysis focuses on the variables relevant to the current product: azimuth, altitude, illuminated percentage, and phase angle. Since the product does not currently focus on apparent magnitude, that variable is excluded from the main interpretation.
No case exceeds the defined tolerance in azimuth, altitude, illuminated percentage, or phase angle. The maximum errors against the Excel file were approximately 0.0054ยฐ in azimuth, 0.4191ยฐ in altitude, 0.0458% in illumination, and 0.1344ยฐ in phase. All these values remain within the tolerances used for planets and the Moon: 0.5ยฐ for position, 1% for illumination, and 1ยฐ for phase.
This means that, according to the Excel file and the current criterion, the planets and the Moon are correctly positioned. Illumination and lunar phase also remain within tolerance, which is important because the Moon phase has a direct visual impact on the chart. The observed differences do not appear large enough to compromise the artistic representation of position or phase.
The manual comparison with NASA JPL Horizons reinforces this interpretation. Against Horizons, the script shows very small average errors: approximately 0.00078ยฐ in azimuth, 0.00056ยฐ in altitude, 0.0057% in illumination, and 0.0645ยฐ in phase. These values indicate very strong agreement with an independent external reference for topocentric position and phase.
In some cases, the Excel file is farther from Horizons than the script, especially in altitude. The average ExcelโHorizons altitude error is approximately 0.086ยฐ, while the average scriptโHorizons altitude error is approximately 0.00056ยฐ. Even so, those Excel differences remain within the tolerance defined for the product, so they do not represent an important visual problem for a printed star chart.
The general reading is that the planet and Moon data are adequate for the objective of the product when the variables that matter at this stage are evaluated: position, illumination, and phase. Apparent magnitude can be reviewed later if the final design decides to use it to control the relative size or brightness of the planets, but it should not affect the main conclusion about astronomical position and lunar phase.
General Conclusion
Overall, the verification results support the astronomical consistency of the data reviewed for the GoRhyme product. The variables that are most important for the visual output of the chart, namely azimuth, altitude, lunar illumination, and lunar phase, remain within the defined tolerances in the great majority of the evaluated cases.
For the star data, most cases show very small angular separations, far below the tolerance of 0.1ยฐ. These differences are not expected to be visually meaningful in a printed chart. The few cases marked as FAIL appear to be concentrated in specific situations involving reference values, approximate locations in Stellarium Web, BCE date handling, or coordinate sensitivity. They should be reviewed individually, but they do not indicate a general failure of the verification data.
For the planet and Moon data, all evaluated cases remain within tolerance for the variables used in the current analysis: azimuth, altitude, illuminated percentage, and phase angle. The comparison with NASA JPL Horizons also supports the accuracy of the topocentric positions and phase-related values. This is especially relevant because the Moon phase and the placement of visible planets directly affect the visual credibility of the final chart.
Based on these results, the data reviewed are suitable for supporting the astronomical accuracy of the product in its current intended use. The product can be considered well positioned for an artistically accurate printed star chart, provided that the few flagged cases are treated as specific review points rather than as evidence of a broader problem.
Planet and moon verification (PDF) The fifteen-case planet and Moon set, with calculated values, differences, tolerances, and pass or fail status for each. The nine cases marked FAIL are the magnitude cases described above.
Read the Planet and Moon Verification Report as text
Planet and Moon Verification Report
The script verify_planet_moon_astronomy.R is currently configured to read the first Excel file, Planet and Moon Chart.xlsx, sheet Planet & Moon Verification. This file contains 15 cases and includes more variables per case than the newer Excel file.
SCRIPT SUMMARY
The script reads the following main data from the Excel file: case number, group, location, latitude, longitude, UTC date, UTC time, local time as text, astronomical body, Engine Azยฐ, Engine Altยฐ, Illuminated %, Phase Angleยฐ, App. Mag., PyEphem values, result, and notes.
It then recalculates each case with astronomyengine. For each planet or the Moon, it obtains calculated azimuth, calculated altitude, visibility, illuminated percentage, phase angle, apparent magnitude, RA, Dec, and distance. These calculated values are saved in planet_moon_calculated.dat.
The script then compares the calculated values against the Excel values and writes planet_moon_verification_results.dat. That output contains the Excel data, the script-calculated data, the differences, and the final PASS or FAIL status.
The main functions are: normalize_time_text(), which normalizes times such as 02:00 to 02:00:00; derive_phase_angle_deg(), which calculates phase angle from illuminated fraction; read_planet_moon_workbook(), which reads the Excel file; clean_planet_moon_cases(), which cleans and converts the data; validate_planet_moon_cases(), which checks dates, coordinates, and duplicates; calculate_single_planet_moon_position(), which performs the astronomical calculation; calculate_planet_moon_positions(), which applies the calculation to all cases; compare_with_references(), which calculates errors and assigns PASS/FAIL; and write_planet_moon_outputs(), which writes the two final output files.
DIFFERENCE CALCULATION
For azimuth, the script uses a circular formula because azimuth wraps from 0ยฐ to 360ยฐ: abs(((calc_az_deg – engine_az_deg + 180) %% 360) – 180). For the other variables, it uses a simple absolute difference: abs(calc_alt_deg – engine_alt_deg), abs(calc_illuminated_pct – reference_illuminated_pct), abs(calc_phase_angle_deg – reference_phase_angle_deg), and abs(calc_app_mag – reference_app_mag).
The current PASS criterion requires all of the following tolerances to be met: azimuth <= 0.5ยฐ, altitude <= 0.5ยฐ, illumination <= 1%, phase angle <= 1ยฐ, and apparent magnitude <= 0.1. Under this criterion, the script currently returns 6 PASS and 9 FAIL. The FAIL cases are caused by apparent magnitude; position, illumination, and phase are within tolerance in all of those cases.
MANUAL RESULTS WITH HORIZONS
The manual comparison with NASA JPL Horizons allows three sources to be compared: the Excel values, the script-calculated values, and an independent external astronomical reference. This review was performed on the 15 cases from the first planet and Moon Excel file, which is the file with the most detailed numerical data because it includes azimuth, altitude, illuminated percentage, phase angle, and apparent magnitude.
In general terms, Horizons confirms that the script is highly consistent in the main astronomical variables: azimuth, altitude, illuminated percentage, and phase angle. In most cases, the differences between the script and Horizons are very small, especially in altitude, illumination, and phase. This indicates that the geometric calculation of position and phase is working correctly.
The automatic comparison between the script and the Excel file gives 6 PASS and 9 FAIL when all five available variables are evaluated. However, when the errors are reviewed by variable, the failed cases do not show a general problem with astronomical position. Almost all of them comfortably pass the tolerances for azimuth, altitude, illuminated percentage, and phase angle. The main reason for the FAIL results is the difference in apparent magnitude.
Cases 3, 4, 5, 6, 8, 10, 11, 14, and 15 fail mainly because of App. Mag. In those same cases, the manual comparison with Horizons shows that the script is often as close as, or closer than, the Excel file in position, illumination, and phase. Some examples are especially clear: in case 6, Mercury, the Excel altitude differs from Horizons by approximately 0.419ยฐ, while the script differs by only 0.00019ยฐ; in case 14, Jupiter, the Excel magnitude differs from Horizons by approximately 0.154, while the script differs by only 0.0049; and in case 15, the script is very close to Horizons in all main variables.
INTERPRETATION OF THE DIFFERENCES
The differences in apparent magnitude should be interpreted carefully. Unlike azimuth or altitude, apparent magnitude is not a direct geometric coordinate, but a photometric estimate. It depends on the model used for each planet, the Sun-planet-observer distances, the phase angle, body-specific corrections, and library-specific conventions. Saturn can be especially sensitive because of how the rings are handled; Mercury and Venus can also show variation because of their strong dependence on phase angle.
The Excel positions are acceptable for a printed star chart. In the reviewed cases, the Excel agrees well with Horizons in azimuth, altitude, illumination, and phase angle, within reasonable tolerances for an artistic printed product. The most visible differences are in apparent magnitude, especially for some planets. These differences do not affect the placement of the object in the chart, but they could affect relative size or brightness if the rendering uses apparent magnitude directly to draw the planets.