-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rise/transit/set times calculation #140
Comments
Thanks for your bug report. I'm embarrassed to say, but indeed, I did not check the calculation carefully enough myself, since as you said, it looked good at first glance. So, thanks for doing a more careful check to uncover a real issue. :-) I did find a badly placed bracket, which seems to be the culprit. I checked the Sun with DE440s (calceph) after the fix, and the transit times now match USNO. The rise/set times also match for -0.833 deg elevation. Please check PR #141 yourself, and let me know if it looks good to you too, or if there is more to it still... I'm really glad you caught this bug in the development stage, before the 1.3 release. cheers, -- Attila |
PS. I also noticed that I made a mistake of using the refraction (degrees) with the wrong unit (arcseconds), which effectively meant that the refraction did not factor in much in the calculation. Also corrected in PR #141. Now the -0.8 degrees makes more sense also. The standard optical refraction is 0.585 deg on the horizon, and if you define 'rise' for the Sun when the first light from the disk (0.26 deg radius) becomes visible, then the center of the unrefracted Sun is actually 0.845 deg below horizon. After the fixes, you should therefore check for -0.26 deg elevation to compare with USNO if using the standard refraction or -0.845 degrees if not using refraction... |
The modified
And from USNO for same date and location:
I think this confirms both fixes (the misplaced bracket, and the poorly applied refraction)... |
Super, thank you! The same results for However, if you change the observation date slightly into the future,
the result is:
And from USNO for same date and location:
|
Also, if you change the body to the Moon and the location, it now fails to calculate some events when using
even though it theoretically should:
|
Yes, that's not good. I'll keep looking into it until we sort it out properly... |
All right. It looks like the iterative approach for Solar-system bodies was a bit misconstrued also. I think it's fixed in PR #142. For your date and location it gives:
vs USNO's:
|
* Fix iterative method for Solar-system rise/set/transit * Update CHANGELOG for fixed issue #140 * Edits to inline comments * Additional API doc notes for rise/set times
Hi @valeriy-sokoloff. I merged #142. Thanks again for your efforts. |
Hi! I'm trying to compute the Moon and Sun rise, transit, and set times for a given date and location: example-riseset.c
At first glance, the results look good. However, when I compared them with data from USNO and imcee.fr - used as "sources of trust" - I noticed a discrepancy:
The produced output appears to be about 5 minutes later than USNO/imcee.
I also tested different locations and dates, with and without built-in refraction calculations, using custom refraction calculations, and with dynamic elevation angle calculations. The discrepancy remains, up to +7 minutes.
It seems like there might be an underlying bug in supernovas.
Could you please check and confirm this, or let me know if I’m just missing something?
The text was updated successfully, but these errors were encountered: