Frage zu MeeusJS

Zitat von h_c_greier:
Aha, kommt da jetzt nix mehr?
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Doch, kam schon, schon Gestern, per PN!

nebenbei gefunden ;)
h_c_greier

'Mondposition - Coding Challenge'

Freunde der rechnenden Astronomie,

ich bin auf der Suche nach einem möglichst effizienten Script, das die Mondposition berechnen soll.

Die Vorgaben:
Sprache: prizipiell egal, Scripte von Webseiten, aus der üblichen Literatur, selbst geschriebene, ...
Geozentrische ekliptikale Koordinaten [L, B, R]
Ausgabe L, B in Grad, R in km
Genauigkeit L,B <= 2' (reicht für Auf-/Untergangsrechnung später)
Genauigkeit R <= 1000 km =ca. 0.25% mittlere Mondentfernung (384400 km)

Natürlich alles diskutabel.

Ziel:
Die Algorithmen sollen so einfach wie möglich sein. Hilfsfunktionen können 'ausgelagert'...
  • Like
 
*genervt* ... Was ich noch nicht mag und gerade daran verzweifle, sind Repos, die nur mit npm benutzbar, sowie in fast unendlich viele Dateien aufgeteilt sind, sodass erstens das Script mit hunderten Zeilen import beginnt (übertrieben dargestellt), sowie die Verwendung eines zweiten ebensolchen zu Konflikten führt und die Console nicht mehr aufhört zu meckern. Ganz zu schweigen von der Performance der Website und dem Server, die dann erstmal hunderte Requests erledigen müssen, bevor es überhaupt mal los geht. ... und dann meckert der Webhoster: hey, du hast zuviele Request, schieb mal mehr Geld rüber ...

Es soll zusätzlich ein Skript von 30 kB geladen werden, in dem über 4 Functions das erledigt wird, was diese eine Zeile erledigt:
Code: 
userProjection = 'EPSG:4326';
Das läuft vollkommen aus dem Ruder, diese neumodische Architektur. Das habe ich schon vor x Jahren kritisiert.

Das gesamte Repo hat 10 MB und ist in über 1.000 Dateien aufgeteilt. Wenn alle Funktionen genutzt werden wollen, müssen alle benötigten Dateien mittels import requested werden ... Die Server schreien vor Freude!
 
Zuletzt bearbeitet:
Du hast immer noch nicht gesagt, was genau du brauchst?
Geozentrische Mondposition?
---> Wie genau?
Nur mit "Hausmitteln" (autark)?
Phasenwinkel des Mondes?
Elongation des Mondes?
.......
....
..

cs,
harald

--
 
Es gibt da doch ein kleines Problemchen bei dem zu JavaScript umgeschriebenen PHP moonphase.php Skript.

und zwar bei/um Neumond, also dem Zurücksetzen des Phase-Werts von 1 zu 0, sowie ebenso dem Mondalter in Tage.

Im Original wird ein synodischer Mondmonat verwendet:
Javascript: 
var synmonth = 29.53058868; // Synodic month (new Moon to new Moon)
this.synmonth = synmonth;
this.agesyn = this.synmonth * this.phase; // Age of syn moon (days)
this.period = (this.phasequarter[4] - this.phasequarter[0]); // Length of moon month (milliseconds)
this.age = (this.period * this.phase); // Age of moon (milliseconds)
Das ergibt allerdings ungenaue Werte für das Mondalter in Tage.

Wenn ich jetzt die Länge des current Mondmonats verwende, der mittels dem letzten und nächsten Neumond - die beide auch berechnet werden - berechnet werden kann, sind beide Wechsel, also der der Phase und der des Mondalters in Tage, nicht synchron.
Code: 
this.age = ((this.phasequarter[4] - this.phasequarter[0]) * this.phase);    // Age of moon (days)
console.log((this.age / 1000) / 86400);
Es kommt zu einem Sprung. Aktuell, da der nächste Mondmonat kürzer ist, zu einem minimalen Zurücksetzen kurz vor Wechsel des Mondalters in Tage von 29.x zu 0. Exakt von
Code: 
0.999606928063949 // Phase
29.777283801518465 // Mondalter in Tage

0.9996284354763348 // Phase
29.74510295612426 // Mondalter in Tage
Also ein Zurücksetzen von 29.77x auf 29.74x. Das sind 1 Minute und 56 Sekunden.
Der Wechsel wird um 18 Sekunden verzögert.
Vermutlich, wenn der nächste Mondmonat länger als der vorherige ist, wird es einen Zeitsprung nach vorne geben.
 
Zuletzt bearbeitet:
... Zeitraum zum bearbeiten abgelaufen ...
---
Es gibt da doch ein kleines Problemchen bei dem zu JavaScript umgeschriebenen PHP moonphase.php Skript.

und zwar bei/um Neumond, also dem Zurücksetzen des Phase-Werts von 1 zu 0, sowie ebenso dem Mondalter in Tage.

Im Original wird ein synodischer Mondmonat verwendet (Zeile 3):
Javascript: 
var synmonth = 29.53058868; // Synodic month (new Moon to new Moon)
this.synmonth = synmonth;
this.agesyn = this.synmonth * this.phase; // Age of syn moon (days)
Das ergibt allerdings ungenaue Werte für das Mondalter in Tage.

Wenn ich jetzt die Länge des current Mondmonats verwende, der mittels dem letzten und nächsten Neumond - die beide auch berechnet werden - berechnet werden kann, sind beide Wechsel, also der der Phase und der des Mondalters in Tage, nicht synchron.
Javascript: 
this.period = (this.phasequarter[4] - this.phasequarter[0]); // Length of moon month (milliseconds)
this.age = (this.period * this.phase); // Age of moon (milliseconds)
console.log((this.period/ 1000) / 86400);
console.log((this.age / 1000) / 86400);[/CODE]
Es kommt zu einem Sprung. Aktuell, da der aktuelle Mondmonat kürzer ist als der letzte, zu einem minimalen Zurücksetzen kurz vor Wechsel des Mondalters in Tage von 29.78899301867732 zu 0. Exakt von
Code: 
0.999606928063949 // Phase
29.777283801518465 // Mondalter in Tage

0.9996284354763348 // Phase
29.74510295612426 // Mondalter in Tage
Also ein Zurücksetzen von 29.77x auf 29.74x. Das sind 1 Stunde und 56 Minuten.
Vermutlich, wenn der nächste Mondmonat länger als der vorherige ist, wird es einen Zeitsprung nach vorne geben.
Der Wechsel von max auf 0 ist logischerweise gleich wie der der Phase.
Das bedeutet, dass das Mondalter nicht sekundengenau, sondern maximal in Tage angezeigt werden kann, damit diese Ungenauigkeit somit kaschiert wird.
 
Zuletzt bearbeitet:
Zitat von slart:
Das ergibt allerdings ungenaue Werte für das Mondalter in Tage.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Und warum wundert dich das jetzt? Hier wird über eine mittelere Länge der Lunation von 29.530589 Tagen gerechnet. Lunationen, also die Zeiträume Neumond-Neumond, sind nunmal nicht gleich lang und können bis zu 7 Stunden vom Mittelwert abweichen.

Daher kann der Mond auch jeweils "verschieden alt" werden. In einer längeren Lunation wird der Mond dann "älter". Das Mondalter ist einfach JDE(jetzt) − JDE(letzer Neumond).

Auch die Zwischenphasen 1. Viertel, Vollmond und Letztes Viertel liegen innerhalb einer bestimmten Lunation nicht gleichmäßig verteilt, wie vielleicht das Ansteigen 0 - ¼ - ½ - ¾ - 1 des k-Werts suggeriert! Das sind Zeitpunkte in UT bzw. TD, denen komplizierte astronomische Berechnungen zugrunde liegen.

cs,
harald

--
 
Zuletzt bearbeitet:
Weiß ich doch. Seh ich doch an den Ergebnissen.

Selbst wenn der Wert des synodischen Mondmonats im Interval des Skripts durch den Wert von (aktueller-Neumond - letzter-Neumond) ersetzt wird, bleibt der Sprung. Das bedeutet, dass die Mondmonatslänge und also somit der aktuelle und der letzte Neumond nicht exakt bei Phase === 0 berechnet wird, sondern schon kurz vorher. Das kriegt man wahrscheinlich auch nicht weg. Bei einem anderen Projekt hatte ich das Problem auch. Aber kann micht nicht mehr erinnern, ob ich es gelöst hatte. Es ist verflixt komplex, weil das eine das andere ergibt. Wer keinen Interval und keine Slider verwendet, sondern immer einzelne Datumsangaben eingibt, der bemerkt das wahrscheinlich gar nicht, außer er erwischt mal eine kritische Datumsangabe.

Es gibt ein Problem mit der while Schleife bei der Berechnung der Quarter. Hier im original PHP-Skript:
github.com

php-moon-phase/src/MoonPhase.php at master · BitAndBlack/php-moon-phase

A PHP Class for calculating the phase of the moon, and other related variables. - BitAndBlack/php-moon-phase
github.com github.com
Die rennt manchmal ins Unendliche und dann stürzt der Browser ab. So wie ich das beobachten konnte, wird sie manchmal benötigt und macht dann 2 Durchläufe, wobei die Korrektur bereits beim ersten erreicht wird. Aber manchmal korrigiert sie gar nichts und die if mit break fängt es nicht ab, da die Werte immer gleich bleiben. So wie es aussieht, würde es genügen da eine for Schleife mit 2 Durchgängen anstatt der while zu verwenden. Keine Ahnung was da genau gemacht wird. Scheinbar wird, wenn meanphase() zu ungenau, nochmal mit truephase() berechnet.
 
Also sinngemäß würde ich das in etwa so machen:

1. Datumseingabe im UI durch den User (wie auch immer das geschehen mag, Stepper, Slider, Inputfelder, ...)
2. Auslesen der Zeitzone (ZZ) des Rechners bzw. Usereingabe
3. Umrechnung von [Jahr, Monat, Tag, Stunde - ZZ, Minute, Sekunde] in => JD
(Jemand, der bei solchen astronomischen Berechnungen mit UNIX Zeiten (1.1.1970) oder new Date() Objekten rechnet muss mal kurz an den Ohren gezogen werden ;))
4. Berechnung von ΔT = TD - UT für die aktuelle Eingabe.
5. JDE = JD + ΔT/86400
6. Berechnung der Mondphasen: Mittels dezimaler Jahreszahl = Jahr + Tag/365 (366) das Anfangs-k bestimmen, und T = (JDE - 2451545)/36525)
7. Das mittlere JDE0 der Neumondphase mit diesem k ermitteln
8. Prüfen, ob JDE0 < JDE ist, wenn ja => OK, ansonsten k = k - 1.
9. Gesamtes Mondphasen-Skript ablaufen, mit k, k+0.25, k+0.5, k+0.75, k+1. Damit jeweils alle Hilfswinkel und alle Korrekturterme berechnen => ergibt die JDE Daten für Neumond - 1.Viertel - Vollmond - Letztes Viertel - Neumond. Jetzt hast du die gesamte aktuelle Lunation rund um das eingegebene Datum herum.
10. Die ermittelten JDE Daten mittels JD = JDE - ΔT/86400 in => UT umrechnen (Algorithmus für JD => Kalenderdatum)
11. Die UT Daten mittels Zeitzone in lokale Zeiten/Ortszeit umrechnen.
12. Daten ausgeben.

cs,
harald

--
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben