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:

#!/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

Link auf den Dropbox-Ordner

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   

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 2012

Die 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,randomly

Es 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/ephe

Wobei 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).

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 OK

Zur 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.0 

Nach "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...