onekiloparsec
Bug in Moon rise/set/transit
Using the code below, and comparing the output to three different sources, shows SwiftAA is off on the set by more than 60 minutes. No two sources agree completely, but, are 'close'.
import Foundation
import SwiftAA
var cleveland = GeographicCoordinates(positivelyWestwardLongitude: Degree(.plus, 81, 40, 52.6440),
latitude: Degree(.plus, 41, 30, 19.7748),
altitude: Meter(30))
let timeOffset = TimeInterval(TimeZone.current.secondsFromGMT())
let date = Date(timeIntervalSinceReferenceDate: 632667424.846199) // 2021-01-18 17:57:04 +0000
let earth = Earth(julianDay: JulianDay(date))
let moon = Moon(julianDay: JulianDay(date))
let times = moon.riseTransitSetTimes(for: cleveland)
let riseDate = times.riseTime?.date.addingTimeInterval(timeOffset)
let transitDate = times.transitTime?.date.addingTimeInterval(timeOffset)
let setDate = times.setTime?.date.addingTimeInterval(timeOffset)
print("====> date:\(date) timeOffset:\(timeOffset)")
print("====> rise:\(String(describing: riseDate))") // Should be around 11:09:44
print("====> trasnit:\(String(describing: transitDate))") // Should be around 17:10:09
print("====> set:\(String(describing: setDate))") // Should be around 11:19:45
SwiftAA shows:
====> date:2021-01-18 12:57:04 +0000 timeOffset:-18000.0
====> rise:Optional(2021-01-18 11:07:44 +0000)
====> trasnit:Optional(2021-01-18 17:07:14 +0000)
====> set:Optional(2021-01-17 22:15:14 +0000)
AstroApp 1 shows: 11:37/17:52/23:16
AstroApp2 shows: 11:33/---/23:22
Py library shows: 11:09/17:10/23:19
Some of these numbers are off due to the locational accuracy. But the set time being off so much is a defect.
I'm seeing similar results – comparing moonset/moonrise times to several online services results in times being off more than an hour.
Sorry for not coming back to you before that, I am pretty busy with the JavaScript version.
I've never feel satisfied with this riseSetTransit function and implementation. Sorry for that, it seems it gives wrong results (precision should be within a minute).
I'll try to find some time to investigate.
Hello
First of all, I would like to congratulate you for the big job you made. I’m very interested in all those matters and your programs are amazing. As for the rises, transits, sets, which is a particular problematic you told you haven’t had time to fix definitely, I have several observations (excuse my English ; I think you speak French too but it will be better for other readers) :
1° I think you don’t exactly call the AA+ function CAARiseTransitSet::Calculate in the appropriate way. No correction of julianday should be made (then not the one you put in line 68 in RiseTransitSet swiftAA file). There’s indeed a correction UTC to TT to make (I don’t know the exact reason but there’s indeed a deltaT mention in CAARiseTransitSet::CalculateTransitHelper function and similar ones) but it only consists in computing body1, body2 and body3 coordinates for the given date as if it was in TT. In a simpler way (and more precise finally), body1, body2 and body3 should be calculate at JD - deltaT… This last difference has a very very slight effect but I think it’s the correct way to do.
When applying that method, I find (compared to https://ssp.imcce.fr/forms/visibility datas, which seem to me accurate, remembering computes are made with only 36,6’ mean refraction, at the center of the body) very good rise/transit/set times for the sun (differences less than 2 seconds).
Furthermore, it’s not necessary to constraint JD to be at noon. CAARiseTransitSet::Calculate works with any time value. It just produces rise / transit / set times occurring after the given time and within the next 24 hours. It can be useful to use that possibility to get rise / transit / set times during a particular day in any place of the world and, possibly, to improve the accuracy of estimations (the result is all the more precise that rise / transit / set time occurs close to the given time).
Finally, you could perhaps take into account the altitude given in geographic coordinates. In one of its programs PJ Naughter explains h0 is to be adjusted by -CAACoordinateTransformation::RadiansToDegrees(acos(6371008 / (6371008 + height)))
2° Because of its velocity, moon estimates are a little less precise. When correcting the program as in 1° and use (for comparison) 36,6’ refraction and center of the body hypothesis, I get for Cleveland on 2021-01-18 : 11:10:05 / 17:08:24 / 22:15:12 (not far from the values given above by Treaves).
IMCCE gives : 11:09:49 / 17:08:27 / 23:16:24
But for the very reason I mentioned, in swiftAA output, moonset is given here for the 17th !! It’s well precised in Treaves output. If we compute for the right local day, we get with swiftAA a moonset at 23:16:08. All the precisions are less than 20 seconds. The best estimation is for the transit, because it occurs near the initial hour we gave to CAARiseTransitSet::Calculate (01 GMT)
3° I think it’s not necessary to improve rise / set time estimates for all bodies (especially since it depends on many local factors) except perhaps for the moon. If you should consider to do so, you should probably use AARiseTransitSet2.cpp programs. I think you noticed PJ Naughter implemented new methods and considered old ones deprecated.
I tried to call it and obtained (with default iterations number, though I initially considered fewer would be necessary…) : 11:09:48 / 17:08:25 / 23:16:21
This seems very good (I don’t know which is the best estimate compared to IMCCE, but I think it’s not very important so far).
Best regards
Hi. Thanks so much for this detailed report. I always had the feeling I was doing something wrong with riseTransitSet in some way. I will look at your report carefully.
Bonjour
Si je peux aider, n'hésite pas ;o)
----- Mail original ----- De: "Cédric Foellmi" @.> À: "onekiloparsec/SwiftAA" @.> Cc: "jbsdn" @.>, "Comment" @.> Envoyé: Dimanche 26 Mars 2023 09:44:44 Objet: Re: [onekiloparsec/SwiftAA] Bug in Moon rise/set/transit (#104)
Hi. Thanks so much for this detailed report. I always had the feeling I was doing something wrong with riseTransitSet in some way. I will look at your report carefully.
— Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you commented. Message ID: <onekiloparsec/SwiftAA/issues/104/1484022030 @ github . com>
Salut. Bon, le sujet étant compliqué, on va peut-être continuer en français pour être sûr de se comprendre.
J'ai bien lu ton commentaire, et... j'aurais préféré une PR comme ça on aurait pu commenter directement dans le code. En fait, je me trouve un peu coincé, sans savoir quoi faire vraiment. PLus précisément:
I think you don’t exactly call the AA+ function CAARiseTransitSet::Calculate in the appropriate way. [...] ... but I think it’s the correct way to do.
Ok, et donc, selon toi, je dois faire cette correction TT ou pas? Je ne suis pas sûr de comprendre. J'avoue que je n'ai que le bouquin de Jean Meeus, et pour plein de raisons, je n'utilise pas SwiftAA moi-même.
-
Merci pour le site du IMMCE, je ne connaissais pas.
Furthermore, it’s not necessary to constraint JD to be at noon.
Ok, mais encore une fois, je suis Jean Meeus. Je trouve ça utile que le calcul donne justement des résultats après le temps donné, dans une fenêtre de 24h. (J'ai la même question avec aa-js pour Arcsecond
- Pour la correction du
h0je veux bien, mais tu as une référence où il explique cette correction ?
Bref, je pense que tu vois un peu le sens de mes interrogations. Si je résume, on est dans le cas où un choix a été fait (mettre le JD à minuit) tel que suggéré par le bouquin. Mais le choix inverse est tout à fait pertinent aussi.
It appears that the calculation of new moon and full moon also has noticeable discrepancies with actual time.
Sorry guys, I know these rise, set and transit times are one of the most useful things to compute with SwiftAA, which would deserve more attention than I hace. I've been overwhelmed with daytime work.
As far as I understand, an update of the underlying aa+ lib would help, I need some rest then some time to make it happen.