Zeitdilatation bei Geschwindigkeitsänd. rechnen

    Liebe Astrofreunde,


    ich möchte gerne den Effekt der Zeitdillatation ausrechnen. Für gleichförmige Bewegungen ist das ja nach der Formel


    ZeitBewegt = ZeitRuhe * Wurzel(1-(GeschwindigkeitBewegt^2 / Lichtgeschwindigkeit^2))


    möglich. Rechenbeispiel: Fiktive Rakete fliegt mit 90%c, auf der Erde vergehen 100 Jahre, in der Rakete nur ~ 44.


    Wie aber rechnet man es für Körper, die ihre Geschwindigkeit ändern? Beispiel:
    Eine Rakete beschleunige mit 1m/s^2, und zwar, bis sie eine Geschwindigkeit von 90%c erreicht habe. Dann lege sie eine Strecke mit der konstanten Geschwindigkeit zurück (für diesen Teil kann ich es ja nach obiger Formel rechnen) und bremse dann mit den genannten Werten.


    Ich kann ausrechnen, dass die Beispielrakete 3123 Tage für bremsen und beschleunigen benötigt. Wie kommt man aber auf den Dillatationseffekt für diese Etappe? Da war mal was mit Integral, ich kann mich dunkel an die Schulzeit erinnern...wer kann mir auf die Sprünge helfen?


    Danke,
    Michael

    Hallo DK,
    Danke für die Info, das ist schon sehr hilfreich. Ich verstehe aber nicht, wofür das Gamma in der Gleichung steht. Ich habe die erste Gleichung nach der Überschrift "Bewegung mit konstanter Beschleunigung" gewählt und folgende Werte eingesetzt:
    a=10m/s, t=60000s, v0=0, gamma=0 oder 1 (zum testen) und c=300000000m/s.
    Wenn ich die Gleichung ausrechne, erhalte ich nur Unsinn. Je größer ich t wähle (also je länger ich beschleunige), desto größer wird die Geschwindigkeit v. Nach Einstein müsste aber vMax=c sein, also je größer t wird, desto eher müsste sich v an c annähern.
    Was mache ich falsch?

    Hallo Michael,


    Gamma ist der Lorentzfaktor, dritte Gleichung ganz oben im Beitrag.


    Bei deiner Rechnung muss was nicht stimmen, schau dir mal die deine Geschwindigkeitsberechnung nochmal an.
    Für t gegen unendlich geht v gegen c, das sieht man der Gleichung doch sofort an.
    (Hinweis: alle Summanden ohne Faktor t können vernachlässigt werden, dann einfach kürzen)


    Gruss
    Günter

    Hallo Günter,
    danke für den Hinweis, ich hatte eine Klammer falsch gesetzt. Die Momentangeschwindigkeit kann ich jetzt ausrechnen. Der Lorenzfaktor scheint dabei keine Rolle zu spielen, die Gleichung verändert sich dadurch nicht! Die Ergebnisse scheinen jedoch korrekt, wie Überschlagsrechnungen zeigen.
    Ich habe nun noch eine Folgefrage, ich hoffe, ich nerve damit nicht?
    Ich versuche nun, den zurückgelegten Weg x auszurechnen. In dieser Formel (von Wikipedia) ist der Lorenzfaktor wichtig. Aber welche Geschwindigkeit soll ich verwenden, um ihn zu auszurechnen?
    - Wenn ich die Endgeschwindigkeit der gleichförmig beschleunigten Rakete nehme, ergibt sich mit dem resultierenden Lorenzfaktor ein Weg von 0.
    - Nehme ich die "mittlere" Geschwindigkeit (also einen Wert zwischen Start- und Endgeschwindigkeit), ergibt sich mit dem daraus resultierenden Lorenzfaktor eine sinnvolle Wegstrecke (nicht-relativistischer Überschlag).
    Aber das ist bestimmt nicht korrekt? Ich habe es auch nur durch herumprobieren der Werte herausgefunden - ich benutze eine Excel-Tabelle zur Berechnung.


    Danke für die Hilfe!
    Michael

    Hallo Michael,


    das gamma kommt über eine Integrationskonstante in die Formeln und deswegen muss gamma (v_0) gesetzt werden. In Deinem Beispiel muss gamma also immer gleich <b>Eins</b> gesetzt werden, weil v_0 = 0.


    Wenn Dich die Thematik näher interessiert, empfehle ich als zusätzliche Literatur: T. Fließbach, "Mechanik". Dort werden die zitierten Formeln hergeleitet und erklärt. Der Stoff des Buches wird an der Uni üblicherweise im 3. Semester in der Vorlesung "Theoretische Mechanik" vermittelt.
    MfG


    Bernhard


    PS: Den zugehörigen Wiki-Artikel habe ich entsprechend erweitert.

    Hallo Bernhard,


    danke für die Korrektur, jetzt passt es.


    -&gt;Michael:
    ich habe gerade mal die Formeln auch in Excel eingegeben, und den Newton'schen Formeln gegenübergestellt.
    Dabei fällt auch, dass für zu kleine a wegen Rundungsfehlern Quatsch rauskommt.
    Die Differenz (fast) 1 - 1 ist schuld daran. Falls dich also gerade diese Werte interessieren, ist Umformen nötig.


    ps:


    z.B. mit der Potenzreihe:
    Wurzel(1+x) = 1 + 1/2*x - (1*1)/(2*4)*x^2 + (1*1*3)/(2*4*6)*x^3 -(1*1*3*5)/(2*4*6*8)*x^4 + (1*1*3*5*7)/(2*4*6*8*10)*x^5 -+ ....


    Das erste Glied liefert übrigens die bekannte Formel s=1/2at²


    Gruss
    Günter

    Danke, ihr seid super! Jetzt hab ich's verstanden - zumindest so, dass die Ergebnisse stimmen ;) Und Wikipedia war unpräzise, danke für's Ändern.
    Die Rundungsfehler habe ich auch erlebt, das ist gerade beim Ausprobieren nervig. Liegt eben an der Gleitkomma-Arithmetik. Da ich die Formeln aber in ein kleines Programm einbauen möchte, kann ich dort die Datentypen einfach auf 10-Byte Gleitkomma einstellen, dann ist das Problem entschärft.

    Hallo Michael,


    falls Dein Programm noch mehr als die Auswertung der relativistisch, konstant beschleunigten Bewegung behandelt, wäre eine Beschreibung des Programmes interessant. Die Auswertung relativistischer Wurzelausdrücke wurde neulich übrigens auch in einem Thema eines Nachbarforums diskutiert.
    Nur so als Anregung...

    Hallo Bernhard,
    mein Programm behandelt den Aspekt nur am Rande, aber danke für den Hinweis auf das Thema mit Pioneer. Dazu habe ich auch schon einige Artikel gelesen. Ich habe die Argumentation von "liva" nicht im Detail verstanden, aber man sollte auf jeden Fall Fließkomma-Muster ausschließen. Floating-Point Fehler können viel früher auftreten, als man gemeinhin annimmt; es gibt zahlreiche nicht-triviale Eigenschaften von Fließkomma-Rechnern. Wenn ein solcher 15 signifikante Stellen hat, kann eine Rechnung, die mehrere Schritte umfasst, viel weniger (z.B. 9) signifikante Resultat-Stellen haben. Der Artikel auf http://en.wikipedia.org/wiki/Floating_point erläutert einige Probleme sehr eingänglich. Für zeitunkritische Rechnungen wie im erwähnten Artikel würde ich empfehlen, mit sehr hoher Genauigkeit zu rechnen, um jedwede Fließkommafehler kategorisch auszuschließen. Dazu nehme man einen Rechner wie z.B. http://www.jonelo.de/java/bigal/index_de.html (Open Source) und wähle einfach eine Genauigkeit, die jenseits jeder Diskussionsschwelle ist.

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: michaelj</i>
    Ich habe die Argumentation von "liva" nicht im Detail verstanden, aber man sollte auf jeden Fall Fließkomma-Muster ausschließen.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    OFF TOPIC:
    liva geht es in seinem preprint hauptsächlich um eine (eher zufällige) numerische Übereinstimmung. Für die Auswertung von gamma reicht dabei die Genauigkeit des XP-Rechners (ca. 40 Dezimalen o.ä.) momentan völlig aus.


    Ich persönlich bin ebenfalls von Programmen fasziniert, wo die Genauigkeit beliebig vorgegeben werden kann. Mein Favorit ist hier jedoch ganz klar der C-Quelltext aus den numerical recipes (s. google). Daraus läßt sich sehr schnell eine Windows-dll bauen und die exportierten Funktionen sind dann äußerst universell einsetzbar [:)].


    Eine sehr fundierte Diskussion zur Pioneer-Anomalie findet übrigens auch hier statt.
    /OFF TOPIC

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Für zeitunkritische Rechnungen wie im erwähnten Artikel würde ich empfehlen, mit sehr hoher Genauigkeit zu rechnen, um jedwede Fließkommafehler kategorisch auszuschließen.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Hallo,
    so eben gerade nicht. Um seine Fehler zu kennen, muss man sie abschätzen. Man ändert seine Berechnung dann dahingehend ab, dass man eine Untergrenze und eine Obergrenze für sein Ergebnis liefert. Die lassen sich dann wenigstens beliebig genau angeben.
    Das gilt auch für die Umformung in sog. unkritische Formeln/Reihenbildung/etc. . Auch hier ist nur das unkritisch, wo ich die Grenze zum Kritischen genau benennen kann.


    Eines darf man nämlich nicht übersehen. Schon die Ausgangswerte haben nur eine bestimmte Anfangsgenauigkeit (z.B. Ortsbestimmung, Zeitbestimmung). Selbst bei einer exakten Rechnung ist somit das Ergebnis ungenau. Und, wenn dann die Frage aufkommt: "Wie ungenau?", dann helfen nur Intervallgrenzen für eine Ober- und Untergrenze.


    Eine Ansatz/Möglichkeit zur Fehlerabschätzung wäre z.b. die Rückrechnung vom Ergebnis zum Ausgangswert zurück.


    Eine andere Möglichkeit (vor allem bei finanzrelevanten Programmen üblich) wäre das Rechnung im Dezimalsystem und nicht die Nutzung von Binarzahlen. 4 Bit repräsentieren dann eine Ziffer (decimal packed binary). Das erspart Rundungsfehler bei z.B. 1/5=0,2 (Schaut euch mal 0,2 im Binärsystem an.)


    In "Excel" empfiehlt es sich bei Geldbeträgen (z.B. USt-Berechnung) immer gleich auf Einzelbetragsebene auf die Cents zu Runden "=runden([Zahl];2)". Das wird sonst immer 'eklig', wenn Zeilensummen und Spaltensummen nicht passen, weil das Programm zwar mit voller Genauigkeit rechnet, aber nur die Beträge auf zwei Nachkommastellen (cent-genau) anzeigt.


    Gruß

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden