Ja, das mit der Lupe ist so ne Sache.... Da muss ich noch ran. Weiß ich.Sollte so auch noch gar nicht zu verwenden sein... Man kann ja auch nicht scrollen. Vergrößert wird ja auch nicht wirklich, sondern die Pixel werden nur größer dargestellt. Das ist sozusagen nur eine Lupe für's Bild, nicht für das Diagramm selber, weil man ja mit Lupe genauso wenig erkennt wie ohne. (die Auflösung des Diagramms wird nicht verändert).
Jap, das mit den Labeln werde ich machen. Die Hints bzw Tooltips kommen auch noch auf jeden Fall.
Gibt's noch mehr Vorschläge?

Gruß bastler

Geändert von bastler am 18. Februar 2006 um 15:54

Hallo, die ersten 30cm nimmt die Masse kaum ab und die Beschleunigung beginnt gleich mit einem hohen Wert und nimmt dann auch ab. Kann das stimmen? Die ersten 30cm ohne Wasserverlust?

Die maximale Beschleunigung liegt über 1000m/s²? Ist das so? Da würde doch alles zerfetzt werden...

Oder sind die Einheiten falsch?

PS: Standartwerte mit Wassermasse 0,8kg...

Zitat:

---

Original geschrieben von Neil

bestimmte Prozessoren haben keine Logik für Rechnungen wie Wurzel oder so. Die haben intern eine Tabelle abgelegt wo das Ergebnis drin steht. Das ist einfacher und schneller.

---

Das macht man schon lange nicht mehr so. Es gibt nämlich einen Algorithmus, mit dem man die Wurzel in einer festen Anzahl von Schritten mit der Genauigkeit der Maschine bestimmen kann. Das ist viel besser als jede Tabelle, oft auch schneller, und einem Näherungsverfahren überlegen, bei dem die Anzahl der Schritte oft schlecht abzuschätzen ist. Der Algorithmus ist eine binäre Version der Wurzelbestimmung mit Papier und Bleistift. Eine C++ Implementation (zur Berechnung der Wurzel einer ganzen Zahl auf ein paar Tausend stellen) findet man zum Beispiel hier.

Auch für trigonmetrische Funktionen gibt es besseres als Tabellen: zum Beispiel Potenzreihen für kleine Argumente und Additionstheoreme, um die grösseren Argumente zu behandeln.

Zitat:

---

Wenn ihr also unterschieldiche Prozessoren verwendet könnte das eine Fehlerquelle sein. Genauso auch die Fließkommarechnung. Aber ich glaube der Fehler durch runden sollte nicht so groß ausfallen.

---

Der relative Rundungsfehler der Einzeloperation ist bei float 10^-38, d.h. bei 30000 Operationen kann der sich schlimmstenfalls auf 10^-33 aufaddieren. Wenn er grösser ist, macht man wahrscheinlich etwas falsch. Zum Beispiel zwei fast gleich grosse Zahlen subtrahieren.

@ Hansi: Müsste schon so stimmen, wenn du ein Startrohr von 30cm länge verbaut hast. Das wirkt dann wie ein Kolben. Dabei bleibt nur der Kolben stehen und der Zylinder (die Rakete) wird weggeschossen.
Dabei wird angenommen dass zwischen Startrohr und Düse keine Reibung auftritt, aber auch kein Wasser ausgestoßen wird.
Wenn du kein Startrohr verbaut hast, ist dieser Vorgang bedenklich.
Hoffe, dass die Sache damit geklärt ist.
Die 1000m/s² haben mich auch schon erstaunt. Ob es stimmt weiß ich nicht, glaube aber auch dass das ein wenig zu heftig ist...


Gruß bastler

Geändert von bastler am 19. Februar 2006 um 17:32

1000m/s².....hm, das wären ja etwas über 100G. Doch schon recht hart, aber kurzzeitig könnte das durchaus sein. Ist im Prinzip wie ein fester Schlag. Trotzdem lieber noch mal überprüfen.

Soooo,

An der Lupe habe ich diese Woche noch ein wenig rumgemurkst. Das Prinzip ist das selbe wie bei Stefan Stroems' Simulator. Es funktioniert auch, nur mit dem scrollen gibt es noch Probleme, da wird das Diagramm noch nicht aktualisiert, da es in Delphi für Frames kein OnScroll-Event gibt...Mal sehen wie sich das lösen lässt.
Habe mir auch erste Gedanken zum Mehrstrahl-Teil gemacht. Das wird entweder unglaublich Aufwendig, oder unheimlich knifflig, da ja die verschiedenen Phasen des Fluges (Startrohr, Wasser, Luft, Leerlauf) bei Mehrstrahlraketen vermischt ablaufen ( z.B.: Booster stößt schon Wasser aus, während der Haupttank noch auf dem Startrohr ist...) Je nach Bauweise der Rakete läuft das also anders ab. Und für jede mögliche Bauweise eine eigene Simulation schreiben... Nein Danke.
Die Schubkurven kann man auch nicht einfach addieren.
Also muss man die Raketenteile irgendwie Gleichzeitig, getrennt aber doch zusammen berechnen. Wie weiß ich noch nicht genau. Da fällt mir im Lauf der nächsten Woche bestimmt was ein. Da ich nächste Woche wohl keine Möglichkeit hab ins Internet zu gehn, werdet ihr erst später wieder von mir hören.
Gab's bei der neueren Simulator-Version irgendwelche Bugs, ausser dass der Zoom absolut verpeilt ist?

Gruß bastler

Hi Bastler,

wie wärs wenn du die Berechnungen einfach in eine Prozedur haust, die dann für jeden Booster seperat rechnet ???
Ich gehe mal davon aus, dass ud schrittweise immer einen Teilschub berechnest, oder?
Dann kannst du diese Teilschübe ja auch zusammenrechnen und dann erst auf die Rakete wirken lassen ...

mfG

Markus

PS: Kannst du mir mal das Formelwerkzeug ddazu per PM zusenden? Und vielliecht den Code gelich dazu, dann kann ich mal gucken ob ich meine Idee umsetzen kann

So,

Auf der Fahrt in den Skiurlaub hatte ich de Idee wie ich die Mehrstrahl-Sache Programmieren kann.
Programmiert habe ich es jetzt schon und die ersten Ergebnisse sind ganz gut. Dazu habe ich die Daten meiner 3-Strahl-Rakete eingegeben und mit den Videos verglichen. Im einen Video braucht die Rakete ~5s, im anderen ~4s (da Flog sie ziemlich schief) bis zum Gipfelpunkt. Der Simulator hat 4,9s berechnet.
Die Lupe funktioniert jetzt auch soweit.
Allerdings hakelt das Programm manchmal hier und da. Aber das wird man ja noch in den Griff kriegen.

Gruß bastler

Geändert von bastler am 16. März 2006 um 15:47

So, innerhalb der letzten 7 Tage hat sich ein wenig getan.
Die Optimierung laüft jetzt soweit, habe bei den letzten Tests keine Fehler mehr bekommen.
Im Diagramm-Teil gibt es noch kleine Probleme. Sehr große Werte werden noch nicht richtig gezeichnet.
Inzwischen kann man auch Raketen speichern und laden. Hier ein Dank an Scorpion, der mir da einen genialen Tipp gegeben hat!
Ansonsten fehlen nur noch kleinigkeiten.
Der Simulations-Algorithmus hat inzwischen nur noch ca 30 Zeilen, am Anfang hatte er um die 60...
Hoffe dass das jetzt bald ein Ende findet,

Gruß bastler

Jetzt gibt's eine weitere, neue Version des Simulators.
Die Raketendaten werden jetzt in *.wr dateien gespeichert, eigentlich sind es nur umbenannte *.ini-Dateien.
Jetzt ist es auch möglich, eine Rakete mit Boostern und einer zweiten Stufe zu simulieren.
An sich fehlt jetzt noch die Hilfe, der Export der Rakete als Treibsatz und der Export der Wertetabelle als *.txt datei. Und halt noch so Kleinkram wie Tooltips und so...
Es wäre Spitze, wenn ihr den Simulator wieder ein wenig quälen würdet, vor allem die Kombination Booster&Zweite Stufe. Spielt auch mit der Auslösezeit/Druck der Zweiten Stufe herum, und auch dem Boosterabwurf... testet einfach alles mal durch. Seid kreativ!
Baut eure "Traumrakete" im Simulator und lasst sie fliegen...
Es kann übrigens sein, dass der Simulator recht viel Zeit zum berechnen braucht, z.B. bei einer Rakete mit 16l Volumen und 50 bar Druck. Abhilfe schafft da die Vergrößerung des delta-t wertes (Standardmäßig auf 0,0001s gesetz). Beträgt er nur 0,001s, ist das Ergebnis auch nicht so viel anders.
Weitere erweiterungen (z.B. 5.Stufe, 20-Strahl-Raketen,....) werde ich selber nicht mehr machen, da ich dafür keinen Bedarf sehe... Wer sowas simulieren will, kriegt den Quelltext gern von mir, dann kann er sowas selber programmieren.

Zum download (knapp 300k) da drüben klicken-> Anhang: simulator1.5.zip

Viel Spaß beim Testen, würde mich wieder über Feedback freuen (Verbesserungsvorschläge, Lob, Kritik)
Ich würde nämlich gerne wissen, wie und ob der Simulator auf anderen Rechnern läuft...

Viele Grüße.

Geändert von bastler am 16. April 2006 um 17:26