Appliquer Runge-Kutta 4 à un pendule élastique.

[neokiller007]

Bonjour,


J'ai crée un programme C qui me permet de simuler l'évolution du pendule élastique (pendule avec un ressort au lieu d'une corde).

Pour cela j'ai utilisé la méthode d'Euler:

Donc on approxime en enlevant le o(h)

Du coup on a:



Et j'applique l'algorithme suivant:
On connait x(t) et v(t)(conditions initiales), on calcul a(t) par le PFD (pour cela on a besoin de x(t) et v(t) à cause de la force de frottement). Puis on calcul grace à euler, puis et on recommence.

Mais le problème c'est que les erreur numériques sont trop grandes et amplifient le mouvement quand on ne met pas de frottements.

Donc j'aimerais utiliser une autre méthode.
J'ai pensé à la méthode de Verlet qui nous donne:



Mais le problème c'est que pour calculer j'ai besoin de . Et pour calculer j'ai besoin de ça pas de problème je le calcul avec x(t0) et v(t0), mais j'ai aussi besoin de ! (à cause des forces de frottements) donc le problème est insoluble

J'ai donc pensé à la méthode de runge-kutta d'ordre4:
Sous wikipédia on donne les formules ici http://fr.wikipedia.org/wiki/M%C3%A9...de_Runge-Kutta
Mais je ne comprend pas à quoi correspond , et.
f est une fonction à deux variables alors que moi je n'ai que des fonctinos d'une variable donc je comprend pas.

Est-ce que quelqu'un pourrait m'expliciter ça en terme de f(a+h)=quelque chose ou alors en terme de x(t), v(t) et


Merci.
-----

[LPFR]

Bonjour.
Je viens de relire ma bible de calcul numérique "Numerical recipes".
Et c'est plus clair que wikipedia (rien de surprenant!).
En fait la fonction f(x, y) de wikipedia est écrite dans mon bouquin f'(x, y). C'est bêtement la dérivée de la fonction au point x.
Les k1, .., k4 sont les dérivées aux points indiqués.
Au revoir.

[neokiller007]

Donc si je résume avec des notations compréhensible ça nous donne:


avec:





Est-ce correcte ?

[LPFR]

Re.
Oui, c'est ça.
A+

[A voir en vidéo sur Futura]

[philou21]

Bonjour
Verlet c'est pas :

qui laisse une erreur en ?

[neokiller007]

Bonjour
Verlet c'est pas :

qui laisse une erreur en ?

Je ne sais pas, j'ai trouvé cette formule sur internet.
En fait c'est la même chose qu'Euler mais on fait un DL à l'ordre 2.
Puis on approxime a'(t0) par son taux d'accroissement en et on obtient cette expression.

Mais si tu me dis comment trouver ton expression je serais ravis de l'utiliser.

[philou21]

Oui, facile :
tu developpes au 3ème ordre d'un coté :


et de l'autre (en remontant le temps) :


tu additionnes les deux expressions et tu obtiens :


les vitesses et le troisième ordre s'annulent. Tu as donc une précision jusqu'au 3ème ordre.

Mais il faut que tu calcules le premier point pour pouvoir enclencher le processus.
Tu peux le faire avec :


Le seul problème est que tu n'as pas les vitesses, ça peut être embêtant si tu as des frottements. Tu peux toujours l'estimer par :

[neokiller007]

Merci pour la démo.

Effectivement c'est embêtant pour la vitesse.
On calcul avec précision x mais on fait une erreur grossière sur la vitesse :/

[philou21]

Merci pour la démo.

Effectivement c'est embêtant pour la vitesse.
On calcul avec précision x mais on fait une erreur grossière sur la vitesse :/

Oui et non ... l'erreur ( en O(h²)) ne s'accumule pas trop puisque la vitesse est calculée à chaque fois à partir de valeurs assez précises (les x).
essaye...
C'est facile à programmer et ça donne en général de bon résultats

remarque : de plus, souvent les forces de frottements dépendent de v de façon un peu empirique, je ne suis pas persuadé qu'une valeur très précise soit absolument indispensable.
si tu n'as pas besoin de v(t) pour calculer a(t) mais juste pour information il vaudra mieux, bien sûr, calculer la vitesse a posteriori par :

[neokiller007]

Effectivement,c'est quand même beaucoup plus stable qu'avec euler.

[philou21]

Effectivement,c'est quand même beaucoup plus stable qu'avec euler.

Ça ne m'étonne pas... (de toute façon il faut régler Δt de manière à avoir une stabilité)
Tu as mis un peu de dissipation ? sous quelle forme ?

[neokiller007]

Frottements visqueux en régime turbulent (car dans l'air on atteins très vite le régime turbulent)

[philou21]

Frottements visqueux en régime turbulent (car dans l'air on atteins très vite le régime turbulent)

de toute façon, je pense que tu résous les équations pour l et thêta et que les accélérations comportent forcement des termes de vitesses.

[neokiller007]

de toute façon, je pense que tu résous les équations pour l et thêta et que les accélérations comportent forcement des termes de vitesses.

Non non, sans frottement y a pas de vitesse dans l'accélération.

J'ai une question, pourquoi la plupart des logiciels scientifiques sont codés en Fortran ?
Je trouve ce langage horrible et bien moins pratique que le C/C++. Et niveau performance c'est le C/C++ qui remporte.
De plus le C/C++ sont très utilisés donc plus facile de trouvé de la doc et des bibliothèques (openGL, SDL que j'utilise, SFML...) notamment des GUI comme Qt etc...

[philou21]

Non non, sans frottement y a pas de vitesse dans l'accélération.

J'ai une question, pourquoi la plupart des logiciels scientifiques sont codés en Fortran ?
Je trouve ce langage horrible et bien moins pratique que le C/C++. Et niveau performance c'est le C/C++ qui remporte.
De plus le C/C++ sont très utilisés donc plus facile de trouvé de la doc et des bibliothèques (openGL, SDL que j'utilise, SFML...) notamment des GUI comme Qt etc...

A bon ?
j'avais souvenir que dans il y avait un terme en
et pareil pour

[neokiller007]

A bon ?
j'avais souvenir que dans il y avait un terme en
et pareil pour

Un petit schéma:

-
- avec: la longueur du ressort à vide etl'allongement du ressort par rapport à la longueur à vide.
-
PFD:
avec:
Donc






On voit bien que les vitesse ne sont là qu'a cause des frottements.

[philou21]

En ce qui concerne le fortran on va pas relancer ce vieux débat...
Toujours est-il qu'ils existent des millions de lignes codés en fortran et on ne va pas recoder à chaque fois que sort un nouveau langage...
Contrairement à ce que tu penses, le fortran génère un code très efficace (depuis le temps, le compilateur est plutôt performant) de plus les bibliothèques sont extrêmement bien fournies.
Tu sais, ce qu'exécute une machine c'est du code machine, c'est pas du C ou du fortran ou autres...

[philou21]

...On voit bien que les vitesse ne sont là qu'a cause des frottements.

Oui, oui, OK
je parlais de résolution en et en
pas en et

[neokiller007]

Oui, oui, OK
je parlais de résolution en et en
pas en et

Ok, mais je vois pas comment coder le truc si tu résouds en et en

[philou21]

Ok, mais je vois pas comment coder le truc si tu résouds en et en

Non, si tu veux inclure le frottement, je pense qu'il vaut mieux faire en cartésien comme tu as fait.
(autrement c'est lagrangien...)

[neokiller007]

intéressant je savais pas que c'était possible.