Physikalisch: Coulombkraft



  • Hi,

    Ich hoffe ihr habt den Thread noch nicht vergessen 🙂

    Ich glaube langsam nicht mehr dran, dass es an den Rundungsfehlern liegt...Ich weiß nimmer was ich machen soll, ich habs in Flash (Actionscript) probiert, ich habs in C probiert, ich habs in Pascal probiert und immer mit den aller größten Datentypen (long double/extended)...irgendwas muss an der Formel nicht stimmen schätz ich mal, ich kann mirs echt anders nimmer erklären...Bitte helft mir 🙂 Ich muss die Facharbeit in 3 Wochen abgeben und da muss alles funktionieren....

    MfG



  • Dieser Thread wurde von Moderator/in Jochen Kalmbach aus dem Forum WinAPI in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • hi,

    schmeiß mal den winkel raus: du kannst das ganze viel schöner rein vektoriell machen. es kann sein, dass bei kleinen geschwindigkeiten dy/dx nicht mehr viel mit dem "echten" winkel zu tun hat. obs aber wirklich daran liegt kann ich natürlich nicht sagen 😉



  • Edit: Hier stand Mist.



  • Herr-Vorragend schrieb:

    static UINT		offsetX, offsetY;
    	static UINT		targetX, targetY;
    
    //...
    
    	bulletX = offsetX + speedX*t	- (0.5 * (Fx/0.001) * (t*t));
    	bulletY = offsetY + speedY*t	- (0.5 * (Fy/0.001) * (t*t));
    

    Kann es vieleicht sein, das das Ergebnis aus

    speedX*t - (0.5 * (Fx/0.001) * (t*t))
    

    nach UINT (OffsetX & OffsetY) konvertiert und somit (vorzeichenlos) gerundet wird?

    Probiers mal mit

    bulletX = (double)offsetX + speedX*t	- (0.5 * (Fx/0.001) * (t*t));
    	bulletY = (double)offsetY + speedY*t	- (0.5 * (Fy/0.001) * (t*t));
    

    oder mit:

    bulletX = ( speedX*t	- (0.5 * (Fx/0.001) * (t*t)) ) + (double)offsetX;
    	bulletY = ( speedY*t	- (0.5 * (Fy/0.001) * (t*t)) ) + (double)offsetY;
    


  • Herr-Vorragend schrieb:

    case WM_TIMER:
    
    		dx = targetX - bulletX;
    		dy = targetY - bulletY;
    
    		alpha = atan(dy/dx);
    
    		r = sqrt(dx*dx + dy*dy);
    
    		F = 1/(r*r);
    
    		Fx = cos(alpha)*F;
    		Fy = sin(alpha)*F;
    
    		bulletX = offsetX + speedX*t	- (0.5 * (Fx/0.001) * (t*t));
    		bulletY = offsetY + speedY*t	- (0.5 * (Fy/0.001) * (t*t));
    		t++;
    
    		InvalidateRect(hWnd, NULL, TRUE);
    
    		return 0;
    

    Ok, mal gucken. Das läuft also schrittweise. In jedem Schritt berechnest Du die momentane relative Position zwischen den beiden Teilchen, dann den momentanen Winkel. dann die momentane Kraft. So, jetzt kommt es Du zählst die Zeit immer weiter hoch. Das heißt, Du lässt die Kraft, die du für einen bestimmten Zeitpunkt berechnet hast, über die gesamte Zeit wirken. Dein Algorithmus soll offensichtlich plötzlich nichtmehr schrittweise funktionieren, sondern stattdessen willst Du einfach die Zeit in eine vorbereitete Formel einsetzen. Da vermischt Du zwei Dinge, die IMHO so nicht zu vermischen sind. Entweder Du musst die Trajektorie komplett vorher berechnen und dann nur noch die Zeit einsetzen oder Du musst komplett schrittweise arbeiten.



  • Und bitte nicht hau deine Algorithmen nicht in den GUI-Code. Das ist ja schrecklich.



  • @Gregor: Ich glaub du hast wirklich Recht, ich hab die Sache mit der Kraft zu sehr vereinfacht...Am einfachsten wär es glaub ich zu der Position ständig etwas hinzuzuaddieren, also so ne Art Momentangeschwindigkeit*Zeitintervall...Nur wie kann ich in diesem Fall die Momentangeschwindigkeit errechnen? Die hängt ja auch von der Kraft ab...KAnn mir da jemand helfen?

    Schonmal Tausend Dank für die Tipps!



  • Ich hätte da einen Ansatz, aber damit auch ein Problem 🙂

    Also, ich hab mir gedacht, ich mach einfach eine Endlosschleife und addiere in jedem Durchlauf eine Strecke zur Position des Protons hinzu. Diese ergibt sich durch s = v*t wobei v die Momentangeschwindigkeit ist, die bei jedem Schleifendurchlauf aufgrund des sich ändernden Abstandes variiert. t ist das "Aktualisierungsintervall". Nur wie komm ich an die Momentangeschwindigkeit?

    Dazu hab ich mir gedacht, dass das Proton im unendlichen eine kinetische Energie E_kin hat und diese nach und nach in potentielle (elektrische) Energie umgewandelt wird. Also dann

    Epot+Ekin=EkinE_{pot} + E_{kin}^{'} = E_{kin}

    Nach Einsetzen und Auflösen nach v in E_kin' ergibt sich dann:

    v = \sqrt{\frac{2(E_{kin} - \frac{Q_{1}\*Q_{2}}{4\*\pi*\epsilon_{0}*r})}{m}}

    Ich hoffe da steckt bisher kein Fehler drin und der Ansatz ist richtig...Wenn nicht bitte melden! 🙂

    Nun ist das Problem, das das ganze zwar schön abgebremst wird, aber das Proton bewegt sich wenn es stehen geblieben ist nicht in die andere Richtung bleibt einfach wo es ist, was ja klar ist, weil E_pot = E_kin und sich das so schnell mit dieser Formel nicht ändert...

    Steckt jetzt ein Fehler in meinem Ansatz oder muss ich nur was ergänzen?

    MfG, Herr-Vorragend (für jede Hilfe dankbar)



  • hi,

    grob gesagt fehlt die trägheit des teilchens. die 0-8-15-lösung sieht so aus:

    Fneu = q1 q2q / ( bla* r2)
    aneu = Fneu/m
    vneu = valt + Δtaneu
    xneu = xalt + Δt
    vneu

    wobei f,a,v,x vektorielle größen sind und jeweils eine x- und eine y-komponente haben. (die formeln gelten für jede komponente einzeln, bis auf die erste: da musst du für r pythagoras benutzen.)

    @gregor:
    wieso mist? ich dachte, das, was du gepostet hast, benutzt man auch für numerische integration 😕



  • 4db814f0-13ac-4521-a7e4-1 schrieb:

    @gregor:
    wieso mist? ich dachte, das, was du gepostet hast, benutzt man auch für numerische integration 😕

    Was ich da in dem einen Beitrag geschrieben habe, hatte nichts mit dem Problem hier zu tun. Ich hatte das geschrieben, ohne den Sourcecode überhaupt anzugucken oder den entsprechenden Beitrag wirklich zu lesen. Hatte einfach mal auf einen Fehler getippt und eine Lösung für das entsprechende Problem beschrieben. Es hat sich hier aber doch um ein anderes Problem gehandelt, was ich dann kurz danach festgestellt habe. 🙄

    Mit "Mist" meinte ich da also, dass es an der Stelle nicht in den Thread gepasst hat.


Anmelden zum Antworten