#!/usr/bin/perl -w use strict; my @syncfiles = qw( test_calc_reduce.c test_calc_reduce.h test_test_calc_reduce.c test_test_calc_reduce.h testgen.c testgen.h tcr.fix tests.cpp tests.hpp makefile ); foreach my $file (@syncfiles) { `ln -s ~/workspace/swepar/src/$file $file`; }... und hier ist der
Hier beschreibe ich mein wahnwitziges Refactoringvorhaben, an dessen Ziel eine parallelisierte Version der Swiss Ephemeris steht (http://www.astro.com/swisseph). GitHub (für die ältere Windows-Version): https://github.com/rplantiko/swepar Dropbox (Linuxversion)
Donnerstag, 26. Dezember 2013
Backup und kurzfristige Versionierung mit der Dropbox
Da ich dieses Projekt nicht im Team bearbeite, sondern solo, ist ein "richtiges" Repository ein bisschen mit Kanonen auf Spatzen schiessen. Eigentlich reicht vorerst die auf dreissig Tage befristete Versionierung, wie sie die Dropbox-Gratis-Accounts anbieten.
In Linux gibt es die schönen symbolischen Links. Ich habe einen Ordner angelegt, der symbolische Links auf die Dateien enthält, die von der SwissEphemeris-Distribution abweichen:
Der Mondknoten
Ich habe nun die Änderungen der letzten beiden Releases, soweit sie das Include sweph.c betrafen, in meine experimentelle Version test_calc_reduce hineingearbeitet.
Ein diff -uw mit der neuen Version förderte auch die folgende Modifikation an sweph.c zutage, die ich damals eigenmächtig vorgenommen hatte - und die nun die mysteriösen Differenzen produziert hatte!
@@ -783,8 +789,6 @@
if (!(iflag & SEFLG_SIDEREAL) && !(iflag & SEFLG_J2000)) {
ndp->xreturn[1] = 0.0; /* ecl. latitude */
ndp->xreturn[4] = 0.0; /* speed */
-/* For true node, radial speed can be ommitted too. RPL, 17.11.2011 */
- ndp->xreturn[5] = 0.0; /* radial speed */
ndp->xreturn[8] = 0.0; /* z coordinate */
ndp->xreturn[11] = 0.0; /* speed */
}
Damit hatte ich eine Änderung am Referenzalgorithmus (sweph.c) vorgenommen. Eine genauere Prüfung zeigt, dass dies meine einzige Änderung am Referenzcode ist.
Die Fixture neu generiert mit
testgen tcr.fix tcr.bin- und schon kommt das neue Output wie erwartet:
ruediger@herschel:~/workspace/swepar/src$ test_calc_reduce tcr.bin | grep OK Swiss Eph, geocentric positions: 250 OK Swiss Eph, helio/barycentric positions: 285 OK Swiss Eph, different coordinate systems: 4 OK Obliquity of ecliptic and nutation: 1 OK Moshier, geocentric positions: 140 OK Moshier, heliocentric positions: 100 OK Provoking a "file not found" error: 1 OK New mode: Barycentric, directly from file: 1 OK
Montag, 23. Dezember 2013
Präzessionsalgorithmen geändert
Die Erklärung der kleinen Abweichungen meiner Tests dürfte darin liegen, dass ich die neueste Version der Swiss Ephemeris für die Berechnung der Testerwartungen verwende. Die Release Notes sagen aber:
1.78 2-aug-2012 Precession calculation updated acc. to Vondrák et alii 2012Die Vondrák-Codeänderung in sweph.c ist in meinem vorläufigen Ersatzinclude test_calc_reduce.c für sweph.c noch nicht vorhanden. Es muss ge-merged werden.
LD_LIBRARY_PATH ist anders - in Ubuntu
Es gefiel den Entwicklern von Ubuntu, Änderungen der Variable LD_LIBRARY_PATH in der .profile-Datei nicht zuzulassen. Was für beliebige andere Variablen geht – z.B. auch für PATH – wird in Ubuntu für LD_LIBRARY_PATH stillschweigend ignoriert.
Hier die Erklärung - nebst zwei Workarounds, wie man es trotzdem hinbekommt (ich habe mich für den zweiten entschieden).
Alle Tests OK in Windoze
Habe es gerade einmal ausprobiert: Unter Windows werden alle Tests bestanden.
W:\swepar\src>test_calc_reduce tcr.bin Swiss Eph, geocentric positions: 250 OK Swiss Eph, helio/barycentric positions: 285 OK Swiss Eph, different coordinate systems: 4 OK Obliquity of ecliptic and nutation: 1 OK Moshier, geocentric positions: 140 OK Moshier, heliocentric positions: 100 OK Provoking a "file not found" error: 1 OK 2452545.00000 05: sepl_18.se1 New mode: Barycentric, directly from file: 1 OK... also ist die diff-Sitzung angesagt!
Einstellungen, Vorbereitungen, Genauigkeit
Schön, die Debugging-Perspektive von Eclipse CDT! Überhaupt fühlt sich diese IDE robust und zuverlässig an.
Den Fehler konnte ich als vom letzten Testfall herrührend identifizieren und habe ihn dann mit einer separaten Fixture tcr1.bin, die nur diesen einen Fall enthält, analysiert.
TESTCASE description:New mode: Barycentric, directly from file planets:0-9,12-16 flags:416048 # NEW_MODE + ICRS + BARYCTR + XYZ + TRUEPOS + J2000 dates:1.1.1000-31.12.2000,5,randomlyEs war dann relativ leicht zu finden. Mir fiel wieder ein, dass dieser letzte Testfall einen experimentellen Modus prüfen sollte, in dem ich, statt das ganze System allmählich umzubauen, den direkten Weg zur Planetenposition über das File gehe. Dabei hatte ich mich darauf focussiert, schnell zum Ziel des Experiments zu kommen und alles so zu bauen, dass es gerade durchläuft. Hierfür hatte ich den Ephemeridenpfad direkt angegeben, was nach der Portierung natürlich nicht mehr stimmte. Das Lesen des Files führte dann zu einem Abbruch. Hier die Korrektur:
// File name swi_gen_filename(tjd, ipl, fname); strcpy(qfname, "/usr/swisseph/ephe/"); // temporary strcat(qfname, fname); printf("%15.5f %.2d: %s\n",tjd,ipl,fname);"Temporary" natürlich, weil an dieser Stelle, wenn sich dieser Weg als gangbar erweist, die Auswertung des Umgebungsparameters stehen wird. Der Test läuft nun für die inneren Planeten mit OK, während die äusseren Planeten ein NOK bringen. Der Grund ist, wie ich mich dunkel erinnere, dass die äusseren Planeten mit einem anderen Verfahren im File gespeichert werden als die inneren. Das war damals noch offen geblieben. Die DOS-Zeilenvorschübe 0D0A wirkten sich beim Einlesen der Kommentarzeilen aus den Fixtures schädlich auf die Ausgabe aus: In der Konsole wirken sie wie "Wagenrücklauf ohne Zeilenvorschub", so dass die gerade ausgegebene Zeile mit dem nächsten String überschrieben wird. Habe sie daher im vi mit dem Kommando %s/^M//g (tippe "Ctrl+V,Ctrl+M") in die plattformgemäss richtige Form gebracht (nur 0A). In meinem .profile habe ich noch folgende Einstellungen eingetragen:
# Set dynamical load library path export LD_LIBRARY_PATH="/opt/lib:$LD_LIBRARY_PATH:." # Look also in current directory export PATH="$PATH:." export SE_EPHE_PATH=/usr/swisseph/epheWobei allerdings merkwürdigerweise der LD_LIBRARY_PATH-Export nicht funktioniert. Wenn ich eine neue Konsole öffne, ist der Pfad wieder initial. In den übrigen Testfällen "nach alt" gibt es für alle Planeten Abweichungen im Bereich von 10^-8. Woher diese stammen, wäre noch zu klären. Ich weiss auch nicht mehr, ob ich sie auch auf dem Windows-Rechner vor zwei Jahren noch hatte, vermute aber eher nicht. Mögliche Gründe:
- Änderungen, die ich vor zwei Jahren an den swe... Files gemacht und im neuen Projekt noch nicht nachgezogen habe. Hier wäre eine diff-Tour angebracht.
- Weiterentwicklungen der Swiss Ephemeris (denn ich habe das Projekt auf dem neuesten Stand der Swiss Ephemeris aufgesetzt).
Sonntag, 22. Dezember 2013
Jahre später... weiter auf Linux
Nach fast zwei Jahren komme ich nun auf dieses Projekt zurück.
Nun entwickle ich mit der Eclipse CDT auf einem Linux-Rechner (Ubuntu 12.04).
Der Plan ist nach wie vor, eine parallelisierbare ("thread-safe") Version der Swiss Ephemeris zu erstellen.
Nach Übernahme der Files und Anpassung des makefile gab es Abbrüche bei der Ausführung der Tests. Ich musst die binären Dateien mit den Testerwartungen (dem Output des Swiss-Ephemeris-Standard) mit testgen tcr.fix neu generieren, um weiterzukommen. Ich vermute, es lag daran, dass auf der neuen Plattform Gleitkommazahlen anders gespeichert werden, aber es lohnt sich in diesem Fall nicht, der Ursache nachzugehen.
Nun komme ich mit dem Programm test_calc_reduce, das den neuen Code testet, zwar weiter, als vorher, und es gibt auch eine ganze Reihe von erfolgreichen Tests... aber eben auch nicht erfolgreiche.
swepar/src$ cat tcr.log | grep OK Swiss Eph, geocentric positions: 245 OK 5 NOT OK Swiss Eph, helio/barycentric positions: 285 OK Swiss Eph, different coordinate systems: 4 OK Obliquity of ecliptic and nutation: 1 OK Moshier, geocentric positions: 20 OK 120 NOT OKZur Auffrischung: Die Tests wurden mit einem Fixture-File beschrieben. Hier ist die Fixture, die ich verwendet habe:
TESTCASE description:Swiss Eph, geocentric positions planets:0-13,15-20,21,22,40,43,47 flags:2,258 dates:1.1.1000-31.12.2000,5,randomly # 5 random dates for each object TESTCASE description:Swiss Eph, helio/barycentric positions planets:1-9,14-20,40,43,47 flags:10,266,16642 dates:1.1.1000-31.12.2000,5,randomly # 5 random dates for each object TESTCASE description:Swiss Eph, different coordinate systems planets:5 flags:96,64,4096,8192 jd:2424912.5 # 1.2.1927 TESTCASE description:Obliquity of ecliptic and nutation planets:-1 flags:0 jd:2424912.5 # 1.2.1927 TESTCASE description:Moshier, geocentric positions planets:0-13 flags:4,260 dates:1.1.500-31.12.1500,5,randomly # 5 random dates for each object TESTCASE description:Moshier, heliocentric positions planets:1-9,14 flags:12,268 dates:1.1.500-31.12.1500,5,randomly # 5 random dates for each object TESTCASE description:Provoking a "file not found" error planets:5 flags:2 # Force Swiss Ephemeris jd:0 # There will be no ephemeris file for JD 0 TESTCASE description:New mode: Barycentric, directly from file planets:5 flags:416048 # NEW_MODE + ICRS + BARYCTR + XYZ + TRUEPOS + J2000 jd:2452545.0Nach "Moshier, geocentric positions" wären also weitere Tests auszuführen gewesen. Das Programm ist in "Moshier, heliocentric positions" abgebrochen. Tatsächlich gab es einen Speicherzugriffsfehler. Dem wäre als nächstes nachzugehen...
Abonnieren
Posts (Atom)