Das stimmt so, weil sich sonst Pluto selbst beschleunigen würde.
TheiaSim
- Ersteller SRMeister
- Erstellt am
SRMeister
Registriertes Mitglied
Also das mit den klären hat sich dann wohl erledigt?
Ich hatte die Änderungen nicht ohne Grund vorgenommen. Die Schnittstelle und damit die Windowsanwendung kann mit den TPs nichts anfangen.
Deswegen hatte ich Planeten und TPs von Body abgeleitet.
Jetzt ist es so: 2 Klassen von fast identischen Objekten, 2 Sätze von fast identischen Integratorfunktionen, 2 Listen die nicht kompatibel sind.
Jetzt müsste ich, damit das Windows Programm klarkommt, auch fast die komplette Schnittstelle verdoppeln und das Windows Programm auch noch ewig anpassen.
Die letzte Version von mir (rev30) hatte die Integratorfunktionen doppelt und es hat auch alles funktioniert, also ich verstehe wirklich nicht warum du jetzt den Schritt zurück gemacht hast. Den ersten Fehler in den TPs hätte man auch dort beheben können.
Die TPs sind immernoch nicht korrekt erstellt, dass wäre dir sicher aufgefallen, hättest du das im GUI in 1-Tages schritten mal verfolgt. Fehler: Die TPs müssen bei Erstellung auch die Geschwindigkeit der Erde(oder des Systems Erde-Mond) bekommen, denn dass ist ihr lokales Koordinatensystem. Sonst fallen sie einfach auf die Sonne. Edit ok doch das stimmt soweit, auch wenns etwas ungeschickt implementiert ist (siehe mein Hinweis oben zur Übergabe an den Konstruktor)
Zuletzt bearbeitet:
zu a) Schau Dir mal bitte die aktuelle Version an und prüfe, ob das nicht vielleicht schon so gemacht ist
.zu b) Gute Idee.
SRMeister
Registriertes Mitglied
Ja das ist jetzt so, aber du hast alle Änderungen rückgängig gemacht, insbesondere die CBody klasse ist verschwunden.
Jetzt funktioniert nurnoch die Konsolenanwendung, der Windowsteil ist jetzt komplett unbrauchbar.
Wie schon vorhin beschrieben, waren die Änderungen notwendig und auch sinnvoll, um Redundanzen zu verringern, die Übersichtlichkeit zu erhöhen, den Code objektorientierter zu gestalten und vorallem um die Schnittstelle funktionsfähig zu halten. Die Schnittstelle war von Anfang an seit rev1 vorhanden nur durch das "verdoppeln" aller möglichen Funktionen/ Klassen hast du die leider komplett unbrauchbar gemacht.
Ich weis garnicht mehr was ich jetzt machen soll... ?
Vielleicht wäre es praktikabler wenn man eben doch 2 unabhängige Varianten erstellt... keine Ahnung??
Hallo SRMeister,
ich werde dann mal versuchen ein eigenes svn-Projekt bei sourceforge.net aufzumachen. Langfristig sehe ich da momentan keine Alternative dazu.
Gruß
ralfkannenberg
Registriertes Mitglied
Hallo zusammen,
ich will mich ja nicht unnötig einmischen, aber ich würde diese Zahl robuster auslegen, auch wenn man nicht so genau weiss, warum. Bedenkt, dass sogar der grösste Zwergplanet eine Bahnneigung von fast 45° hat, was man eigentlich nicht erwartet hat.
Ist das denn sehr teuer (in Form von Rechenzeit), wenn man einen grösseren Wert verwendet ?
Freundliche Grüsse, Ralf
Hi Ralf,
ich finde das ist ein guter Tip, denn bei meiner Programmversion (ich bin jetzt mal ein wenig gemein) hat der Streuwinkelbereich keinen Einfluss auf die Rechenzeit.
Was mich momentan ebenfalls sehr interessiert, ist die Anzahl an Abstürzen der Trümmer auf den Planeten. Eine triviale, geschwindigkeitsunabhängige Absturzbedingung läßt sich recht schnell implementieren und ich will jetzt einfach mal wissen, wieviele Abstürze die Simulation bei beispielsweise 1000 Jahren berechnet und wo diese stattfinden.
Gruß
SRMeister
Registriertes Mitglied
ich versteh grad irgendwie nich, was eigentlich das Problem ist? Ich hatte selbst auch vorgeschlagen, wieder 2 Listen einzuführen. Ich habe auch angeboten das zu tun. Gut, du hast durch rückspielen einer alten Version dieses Problem gelöst aber die Zusammenarbeit beendet. Nur warum??? Da guck ich jetzt doof in die Röhre.
Okay, dann wird es eben keine Version kompatibel mit Konsole und GUI mehr geben...
Tolles Arbeiten...
Okay, dann wird es eben keine Version kompatibel mit Konsole und GUI mehr geben...
Tolles Arbeiten...
ralfkannenberg
Registriertes Mitglied
Hallo SRMeister,
aus der Praxis (Industrie, Banken, etc.) weiss man, dass zwischen dem Erstellen einer ersten korrekt lauffähigen Software und ihrer Eingliederung in die vorhandene Systemlandschaft mindestens ein Faktor (!!) 10 an zusätzlichem Aufwand erforderlich ist.
Also: bitte nicht frustiert sein - bei einer gemeinsamen Arbeit, bei der die Leute nicht am selben Schreibtisch sitzen, müsst Ihr mit ähnlichen Faktoren rechnen.
Von meiner Seite einfach nur ein riesiges Kompliment, ich kann mich nicht erinnern, dass man sich hier im astronews in den vergangenen 7 Jahren die Mühe für ein solches Projekt gemacht hat !
Freundliche Grüsse, Ralf
Ganz so einfach ist das leider doch nicht und zwar aus dem folgenden Grund. Der Vorteil des Bulirsch-Stoer-Algorithmus ist gerade die große Schrittweite (bei uns 1 Tag). Da aber auf triviale Weise (Abstand) ein Absturz nur nach jedem Simulationsschritt abgefragt werden kann, verliert man hier leider viele interessante Informationen.
Mit der aktuellen Konsolenversion kann man in akzeptabler Zeit (und nach auskommentieren der TimeStamp-Ausgabe am Ende) 1000 Jahre mit 10 Testkörpern bereits simulieren. Bei mir ergab sich dabei folgendes Ergebnis: Ein Testkörper hat das Sonnensystem komplett verlassen. Mehrere haben sich im Erdorbit angesammelt. Der Rest verteilte sich auf das innere Sonnensystem bis etwa 7 AE. Interessant finde ich solche Ergebnisse allemal, allerdings lief das aus Zeitgründen mit einer für mich übersichtlicheren Version ohne verlinkte Listen, dafür aber mit Arrays aus Objekten.
Bynaus
Registriertes Mitglied
Ich kann und will mich nicht in die Details eurer Diskussion bzw. eures Streits einmischen, aber ich glaube, es wäre absolut sinnlos, zwei verschiedene Simulationen zu dem einen Thema aufzubauen - dann machen wir die Arbeit doppelt, die Kontrolle bzw. das Review der Ergebnisse - und damit das zu erwartende Niveau - kann nur abnehmen. Ich kann euch nicht sagen, wie ihr dies lösen könnt, aber ich würde vorschlagen, mit einer klaren Rollenverteilung anzufangen.
Zurück zum eigentlichen Inhalt: Diese ersten Ergebnisse, Bernhard, klingen qualitativ schon mal ganz okay, dh, in etwa das, was man wohl erwarten würde. Die wichtigste Frage dazu muss lauten: können wir ihnen trauen? Dafür wird eine sehr sorgfältige Dokumentation nötig sein.
Ich würde mir das Programm (nicht unbedingt den Code, zu diesem Zeitpunkt) gerne mal auch selbst ansehen. Wie genau muss ich vorgehen?
Zurück zum eigentlichen Inhalt: Diese ersten Ergebnisse, Bernhard, klingen qualitativ schon mal ganz okay, dh, in etwa das, was man wohl erwarten würde. Die wichtigste Frage dazu muss lauten: können wir ihnen trauen? Dafür wird eine sehr sorgfältige Dokumentation nötig sein.
Ich würde mir das Programm (nicht unbedingt den Code, zu diesem Zeitpunkt) gerne mal auch selbst ansehen. Wie genau muss ich vorgehen?
Ich schließe mich Bynaus an und halte mich raus aus Eurer "Diskussion" Genauso sehe ich aber auch, dass Ihr das Kriegsbeil begraben müsst, weil das sonst nach hinten losgeht.
@Bernhard: Du sagtest, du hättest eine Konsolenversion. Ist die Linux-Geeignet oder ist das eher sowas wie DOS/Windows-Eingabeaufforderung?
Wenn die Linux-basiert ist, kann ich gerne simulieren, weil mich das auch interessiert, was rauskommt. Ich habe (unseren Cluster ausgenommen) 6 CPU zur Verfügung. Läuft das Programm parallel via MPI?Wie lange läuft eine Simulation im Schnitt?
Beste Grüße,
Basti
Genauso sehe ich aber auch, dass Ihr das Kriegsbeil begraben müsst, weil das sonst nach hinten losgeht.@Bernhard: Du sagtest, du hättest eine Konsolenversion. Ist die Linux-Geeignet oder ist das eher sowas wie DOS/Windows-Eingabeaufforderung?
Wenn die Linux-basiert ist, kann ich gerne simulieren, weil mich das auch interessiert, was rauskommt. Ich habe (unseren Cluster ausgenommen) 6 CPU zur Verfügung. Läuft das Programm parallel via MPI?Wie lange läuft eine Simulation im Schnitt?
Beste Grüße,
Basti
Hallo Basti,@Bernhard: Du sagtest, du hättest eine Konsolenversion. Ist die Linux-Geeignet oder ist das eher sowas wie DOS/Windows-Eingabeaufforderung?
Wenn die Linux-basiert ist, kann ich gerne simulieren, weil mich das auch interessiert, was rauskommt. Ich habe (unseren Cluster ausgenommen) 6 CPU zur Verfügung. Läuft das Programm parallel via MPI?Wie lange läuft eine Simulation im Schnitt?
die Konsolenversion enthält nur noch marginale Windows-, resp. Microsoft-Technik und genau so wollte ich das auch haben, weil die Rechenzeiten mit den erweiterten Anforderungen natürlich sofort nach oben gehen.
Deswegen schlage ich folgendes vor:
@SRMeister: Darf ich meine aktuelle Version auf Deinen svn-Space aufspielen? Bynaus und Basti könnten sich dann den Quelltext ansehen und ausgiebig testen. Das würde das Projekt sehr voranbringen und auf das GUI können wir dabei momentan ohne Probleme verzichten. So etwas hält halt momentan eher auf. Idealerweise sollte die Simulation also komplett ohne grafischen Overhead auf einem Linux-Cluster laufen. So etwas wäre auch für mich interessant. Man müsste nur prüfen mit welchem Zusatzaufwand das zu machen wäre.
Gruß
Hallo Bynaus,
schicke mir am besten eine PN mit Deiner eMail-Adresse. Ich schicke Dir den Code dann privat zu, weil der momentan nur auf meiner privaten Festplatte existiert.
SRMeister
Registriertes Mitglied
okay
Dass die Windowsversion das Programm langsamer machen würde, oder Overhead erzeugen würde, ist totaler quatsch. Die DLL wird genausoschnell ausgeführt, wie die .exe Datei. Das konnte ich mit dem Intel Profiler und dem eingebauten Benchmark beweisen.
stimmt natürlich. Ich will/kann auch keine eigenen Integratoren erstellen, deswegen werde ich vorhandene, in der wissenschaftlichen Umgebung gut dokumentierte Software einsetzen.
Ich bin momentan noch auf der Suche nach einem passenden Ansatz, aber es kristallisiert sich bereits heraus, dass es ein symplektischer Integrator werden wird. das SWIFT Paket sieht da sehr vielversprechend aus. Darauf bauen viele wissenschaftlichen Arbeiten zum Thema Sonnensystem, Oortsche Wolken usw. auf.
Mit der letzten lauffähigen GUI-Version und den letzten von Bernhard veröffentlichten Änderungen habe ich momentan eine lauffähige Version. Damit habe ich ein Video erstellt, wo 2500 Fragmente simuliert werden. Habe es bei YouTube hochgeladen.
www.youtube.com/watch?v=RUd06bwsPMw (Am besten mit 480p Auflösung ansehen)
Grüße
Zuletzt bearbeitet:
ralfkannenberg
Registriertes Mitglied
Hallo SRMeister,
nichts gegen schöne Benchmarks, aber hast Du es mal mit einem ganz konkreten Loadtest ausprobiert ? - Ich habe schon viel zu dem Thema gehört, aber wenn früher die Applikation, die ich programmieren sollte, zeitkritisch wurde, habe ich meist zuvor einen kleinen Loadtest gemacht, um zu schauen, welche Befehle mehr Zeit brauchen, und dann entsprechend programmiert. Mit sowas konnte man früher locker einen Faktor 5 - 10 herausholen.
Ok, ich habe zweimal ein Programm programmiert, dessen Laufzeit über 100000x länger als das Alter des Universums war - da helfen solche Tricks dann natürlich auch nicht mehr weiter.
Freundliche Grüsse, Ralf
SRMeister
Registriertes Mitglied
das ist denke ich genau das, was ich mit dem Profiler gemacht habe.
Da siehst du genau, welche Funktion Zeit kostet, sogar bis hin zu einzelnen CPU-Instructions.
Es sind natürlich die mathematischen Operationen. Besonders die Division und noch mehr das Wurzelziehen.
Ich hatte mich damit ausgiebig beschäftigt. Es gibt von Intel genaue Anleitungen, wo die CPU Zyklen pro Befehl aufgeführt sind. Das was man dort findet, habe ich 1:1 im Profiler widergefunden.
Da konnte ich aber auch durch Assembler viel Zeit rausholen.
Da siehst du genau, welche Funktion Zeit kostet, sogar bis hin zu einzelnen CPU-Instructions.
Es sind natürlich die mathematischen Operationen. Besonders die Division und noch mehr das Wurzelziehen.
Ich hatte mich damit ausgiebig beschäftigt. Es gibt von Intel genaue Anleitungen, wo die CPU Zyklen pro Befehl aufgeführt sind. Das was man dort findet, habe ich 1:1 im Profiler widergefunden.
Da konnte ich aber auch durch Assembler viel Zeit rausholen.
SRMeister
Registriertes Mitglied
hier nochmal ein anderes Video, wo nur die ersten 2 Jahre zu sehen sind, dafür 5000 Partikel.
http://www.youtube.com/watch?v=O2h1FjA24uo
http://www.youtube.com/watch?v=O2h1FjA24uo
Das hat bei genauem Hinsehen auch niemand behauptet und mit Overhead wird gerne nur zusätzlicher Code bezeichnet.
Das sieht schonmal ganz interessant aus. Wieviel Jahre werden hier eigentlich simuliert?
SRMeister
Registriertes Mitglied
für 350 Jahre(Schrittweite 8Tage) hat es etwa 6h gedauert, aber in das Video sind nur die ersten 65 Jahre eingeflossen, da sich dann wenig verändert. Man sieht nur dass die Exzentrizität runtergeht, durch Wechselwirkung mit den inneren Planeten.
Kollision habe ich ja nicht implementiert.
Was man aber schlussfolgern kann, ist, dass die Dichte der Objekte im Innern Sonnensystem viel größer ist und da dort auch mehr Planeten pro Volumen sind, wird wohl ein Großteil dort enden.
Viel mehr wird man wahrscheinlich mit dem BS nicht nachweisen können, vermute ich. Alles Andere spielt sich auf ganz anderen Zeitskalen ab.
Kollision habe ich ja nicht implementiert.
Was man aber schlussfolgern kann, ist, dass die Dichte der Objekte im Innern Sonnensystem viel größer ist und da dort auch mehr Planeten pro Volumen sind, wird wohl ein Großteil dort enden.
Viel mehr wird man wahrscheinlich mit dem BS nicht nachweisen können, vermute ich. Alles Andere spielt sich auf ganz anderen Zeitskalen ab.