Projet Informatique 2025 :
Simulateur pour exercices de Physique.
Présentation

Remerciements

Je tiens à remercier chaleureusement M^elle Lucie Moulin et M. Raphaël Faltin pour leur aide précieuse lors de la conception de ce projet.

Description générale du projet

Voici une présentation générale du projet que vous aurez à réaliser ce semestre. Il ne s'agit ici que d'une présentation générale pour vous donner le cadre. De nombreuses explications complémentaires vous seront fournies au fur et à mesure du semestre et les détails mathématiques ont été regroupés dans un document PDF, complément mathématique du projet.

Buts

Le but du projet de cette année est de simuler le comportement d'un système composé de plusieurs objets physiques de différente nature tels que vous avez pu en modéliser dans les exercices de votre cours de « Physique avancée » le semestre passé. Un des buts est justement de simuler numériquement certains de ces exercices.

L'intérêt est double :

• vous faire réaliser, en C++, un simulateur basés sur des lois physiques, soumis à des équations d'évolution ; ainsi essayer de retrouver, à partir de la simulation, quelques fondamentaux vus en cours de Physique, et d'observer la sensibilité des intégrateurs numériques ;
  cela pourra d'ailleurs peut être vous servir de base pour plusieurs extensions qui pourraient vous être utiles dans votre futur d'étudiant(e) en Physique ;
• vous apprendre à réaliser un programme de taille plus importante que ceux que vous voyez habituellement en exercices et impliquant une interface graphique ; ce projet a pour but de consolider vos connaissances en programmation et de vous faire pratiquer des concepts de programmation orientée-objet.

Positionnement du problème

Le problème de la simulation d'un tel système est double :

1. tout d'abord, calculer toutes les interactions entre toutes les composantes en interaction (objets, forces, contraintes) ;
2. ensuite (et principalement) calculer le mouvement de chacun des objets.

Il y a pour cela fondamentalement deux types d'approches (qui peuvent être complémentaires) : simuler toutes les interactions physiques, ou bien intégrer numériquement les équations globales du mouvement (lesquelles auront été au préalable calculées sur le papier).
Un des intérêts du projet de cette année est d'utiliser une combinaison de ces deux approches.

Le système que l'on souhaite simuler sera donc constitué de divers objets (points matériels, essentiellement) que nous aurons pris soin de modéliser du point de vue mathématique, puis de programmer.

Il y a de nombreuses façons de modéliser informatiquement un problème aussi général (voir les remarques sur les choix de conception). Pour simplifier, nous considérerons qu'il y a 3 types d'objets sur lesquels nous ferons diverses hypothèses simplificatrices, et que nous ferons évoluer au cours du développement du projet :

1. les objets mobiles, soumis à des forces extérieures et dont on connaît l'équation du mouvement (exemple : un point matériel dans un champ gravitationel) ;
2. des champs de forces immatériels (exemples : gravité, champs électromagnétique, vent, ...) qui ajoutent des forces aux objets mobiles ;
3. des contraintes qui modifient les forces subies par les objets; p.ex. rester sur un plan, être maintenu par une tige (pendule pesant ou pendule sphérique), ...

Plus concrètement, un objet mobile sera caractérisé par un certain nombre de degrés de liberté, différentes forces, et une équation d'évolution donnée par ses contraintes. Il pourra aussi avoir des paramètres internes spécifiques suivant les besoins (typiquement sa masse, sa charge, ...).

Par exemple dans le cas simple d'un pendule pesant :

l'objet est caractérisé par le paramètre θ, angle d'écart par rapport à la position d'équilibre, et l'équation :

m L² θ'' + b θ' + m g L sin(θ) = 0,

qui décrit son mouvement au cours du temps, où x' représente (de façon générique) la dérivée temporelle de x : x'=dx/dt.
Les paramètres internes spécifiques au système étant ici la longueur L du pendule, la masse m et éventuellement (optionnel) le coefficient de frottements fluides b.

Tous les détails sont fournis dans le complément mathématico-physique du projet (format PDF), mais fondamentalement, du point de vue mathématique, un objet mobile sera donc caractérisé par un vecteur d'état E (à n dimensions), sa dérivée temporelle E' et une fonction f(t, E, E') (de RxRⁿxRⁿ dans Rⁿ) telle que le système ait pour équation d'évolution :

E'' = f(t,E, E').

Par exemple dans le cas précédent, E=θ (de dimension 1) et f(t, E, E') = -g/L sin(E) -b/(m L²) E'.

Un autre exemple serait un objet libre (sans rotation propre) dans l'espace à 3 dimensions. Dans ce cas, E n'est autre que sa position et E' sa vitesse.

D'un point de vue graphique, les objets auront par ailleurs une fonction spécifique permettant de les représenter à partir de leurs paramètres (vecteur d'état et paramètres internes) ; par exemple dans le cas du pendule, ce sera une fonction dessinant une barre de longueur L inclinée de E par rapport à la verticale.

Du point de vue modélisation, l'équation d'évolution et la fonction spécifique permettant de représenter un objet sont regroupées dans la notion de contrainte (s'appliquant à l'objet).

Principes généraux pour la conception

Pour résumer les objets auront (au moins) 2 fonctions, qui nous guideront pour notre conception :

1. une fonction pour les faire évoluer (disons evolution() ou mise_a_jour() ou update() si vous préférez coder en anglais) ;
2. et une pour les représenter/dessiner (dessine_sur()), qui sera adaptée soit au mode texte, soit au mode graphique.

D'un point de vue physique cela correspond d'un coté à l'évolution de l'objet dans l'espace des phases (c.-à-d. dans ses paramètres propres) et de l'autre à son évoluation dans le monde 3D de visualisation.

Remarques au sujet de la conception

Nous avons proposé ci-dessus un cadre général pour une conception du projet qui nous semble réalisable dans le cadre de ce cours. Elle n'est

• d'une part pas assez spécifiée ici, et sera plus détaillée semaine après semaine;
• pas du tout unique, ni même imposée; vous êtes libre de choisir une conception plus générale si cela vous semble adapté, mais vous devez, bien sûr, l'expliquer et donner sa correspondance avec celle proposée ici.
  Par contre, une conception à l'opposé plus spécifique (trop rigi) est à proscrire et sera pénalisée.

Simuler ce « petit monde »

Le but du projet est de simuler l'évolution temporelle d'un système tel que décrit ci-dessus. D'un point de vue programmation informatique, il faudra bien sûr pour cela concevoir les classes/objets nécessaires et les organiser de façon pertinente (héritage, encapsulation, cf cours à venir).

D'un point de vue mathématique (analyse numérique), nous allons chercher à calculer numériquement (et non pas analytiquement) une solution approchée au problème précédent (intégration numérique des équations du mouvement).

Connaissant les équations qui régissent le problème, et connaissant toutes les données (positions et vitesses) à un certain temps t, on cherche à calculer itérativement une solution approchée au temps t+dt, où dt est ce que l'on appelle le « pas de temps » ou « pas d'intégration » (qui peut être fixe ou variable selon les méthodes. Ici, il sera fixe). Plus il est petit, plus la solution s'approche de la solution réelle, mais plus elle est longue à calculer.

Nous reviendrons plus en détail sur ces méthodes d'intégration le moment voulu (semaine 6), mais l'idée générale de base de la simulation est la suivante :

• pour tous les objets mobiles et tous les champs de forces : appliquer la force du champ à l'objet (ceci n'est nécessaire que dans les simulations où il y a des champs de forces locaux et que les objets risquent d'y entrer/sortir) ;
• pour tous les objets mobiles : calculer leur évolution (c.-à-d. nouvel état dt plus tard) ; cela se fera au moyen d'un intégrateur (numérique) ;
• pour toutes les contraintes : les mettre à jour (ceci n'est nécessaire que dans les simulations où il y a des contraintes variant dans le temps).

Spécification (minimale)

Pour viser le 6, la simulation devra au minimum contenir la simulation de trois exercices (qui seront précisés au fur et à mesure du semestre):

• un point matériel en chute libre (semaine 6);
• un exercice simple (au choix; semaines 6-7);
• un exercice plus complexe (au choix; semaine 11);

avec au moins deux intégrateurs différents (au choix; pas en même temps) (semaine 11).

Il est impératif que le projet compile et s'exécute correctement sur les VMs de l'Ecole (VM IC-CO-IN-SC), seules machines officielles de ce cours.

Un barème précis vous est fourni sur la page d'administration du projet.

Bien sûr, plusieurs pistes d'extension seraient possibles (mais hors projet) :

• offrir une large palette de différents exercices possibles;
• implémenter la contrainte « corde » ;
• changer dynamiquement d'intégrateurs, voire comparer leur évolution en parallèle;
• autoriser des « points de reprise » (via un fichier de sauvegarde) : avoir un moyen, par exemple un clic de souris ou une touche, d'arrêter la simulation à un point donné et de la sauver dans un fichier pour pouvoir relancer la simulation plus tard à partir de cette sauvegarde ;
• gérer les chocs ;
• ajouter la notion de repère non galliléen / changement de repère ;
• implémenter les corps solides (et leur tenseur d'interie);
• ajouter le calcul de l'énergie (totale) et en particulier modiliser correctement l'énergie potentielle (liée aux notions de repère et de contrainte);
• ...

...mais ne passez pas trop de temps sur ce projet, en particulier au détriment des autres branches !!

Administration

Rendu

Le projet est à réaliser impérativement en groupe de deux personnes sans aucune exception. Les groupes sont à constituer d'ici au 13 mars 2025.

Concernant le rendu, nous ne vous demandons pas de rapport (document) sur le projet ; par contre, nous vous demandons de commenter abondamment et intelligemment les codes sources que vous nous rendrez (les commentaires remplaceront le rapport) et de fournir quatre fichiers complémentaires :

• un fichier JOURNAL.txt résumant votre progression (où vous en êtes) et reportant (brièvement), semaine après semaine, ce que vous avez fait sur le projet (exemple ici).
  Cela permettra à votre groupe de mieux se coordonner et toujours savoir où vous en êtes.
  Soyez concis mais précis, clairs et objectifs (on peut très bien comprendre que, ponctuellement, telle ou telle semaine vous ayez eu d'autres contraintes et ayez moins avancé sur le projet).
  Vous pouvez également inclure vos états-d'âme.

  Veillez donc à bien mettre à jour votre JOURNAL chaque semaine (cela fera partie de la notation).

• Un fichier REPONSES répondant point par point aux questions posées dans les séries hebdomadaires relatives au projet. Ces réponses ne sont bien sûr pas uniques mais dépendent de la façon dont vous concevez l'énoncé. Elles serviront aux correcteurs à mieux comprendre votre conception.

• Un fichier CONCEPTION (à faire au fur et à mesure) décrivant la hiérarchie de classes utilisée (relations d'héritage et d'encapsulation) et une brève justification de vos choix.

  Ce fichier peut être soit sous forme textuelle donnant simplement la liste des classes et leur relations, soit sous forme graphique (en utilisant par exemple inkscape).

• Un fichier README (à faire tout à la fin !!) expliquant ce qu'est votre programme, comment le compiler et comment l'utiliser. Donnez quelques exemples concrets.

En plus des commentaires usuels sur le code lui-même (qui seront pris en compte dans la notation du projet), vous avez tout loisir de porter un regard critique sur la modélisation du problème proposée, d'identifier les faiblesses et insuffisances de ce modèle, et naturellement de proposer des solutions pour pallier ces faiblesses.

Tous ces fichiers (JOURNAL, REPONSE, CONCEPTION et README) peuvent être écrits dans n'importe quel format ouvert : texte simple (par exemple dans geany, gedit, emacs, ...), PDF, OpenDocument, ..., mais en aucun cas dans un format propriétaire fermé ! (Les .doc sont un format propriétaire fermé, donc exclus !)

La date limite de remise du projet est le dimanche 1er juin à 23:59. (Cette date est absolument impérative. Aucune extension de délai ne sera accordée !)

Organisation du travail

Ce projet constitue une part importante de l'évaluation du cours (la moitié) et est spécifié de façon assez large pour permettre un travail créatif. Le « danger » est donc grand de se laisser submerger par ce projet ; ce qu'il faut éviter à tout prix ! Voici donc plusieurs conseils et remarques afin d'organiser au mieux votre travail, dans une harmonie maximale avec toutes les autres contraintes de votre semestre.

Pour bien apprendre la programmation, il faut pratiquer. Cela ne se fait pas du jour au lendemain et demande en effet une certaine quantité de travail et une certaine régularité. Néanmoins, vous n'êtes pas en Section d'Informatique et cette quantité de travail doit rester raisonnable (entre 5 et 7 heures grand maximum par semaine tout compris (cours, exercices, travail personnel ; soit entre 2 et 4 heures grand maximum de travail « à la maison »)).
[ A noter qu'il s'agit là d'une branche de semestre pour laquelle vous ne travaillez plus du tout après le dernier cours (c.-à-d. pas de période de révisions). La période sur laquelle vous devez fournir le travail pour cette branche étant plus courte, il est évident qu'à charge totale égale, la charge par semaine devient plus grande. ]
Réussir à tout prix la branche « Programmation Orientée Objet », au détriment des autres branches, ne me semble pas une bonne solution. Comme a dit un de vos prédécesseurs : «Ça ne sert à rien de faire 6.0 au projet si c'est pour quitter l'EPFL ensuite !»
Apprenez à vous organiser, à correctement gérer votre temps et vos priorités.

Si donc certains passent effectivement trop de temps sur ce projet, et, pire !, au détriment d'autres branches, c'est essentiellement pour les raisons suivantes :
[ Mais je ne voudrais cependant pas par mes remarques donner une image trop négative de ce projet et tiens donc à signaler ici qu'il y a chaque année un grand nombre d'étudiants qui arrivent très bien à gérer ce projet et considèrent que c'est une charge lourde certes, mais justifiée, non excessive et enrichissante. ]

1. une mauvaise répartition du travail entre binômes et dans le temps ;
2. une mauvaise évaluation du travail à effectivement fournir dans ce projet ;
3. une mauvaise gestion des contraintes et priorités.

Pour 1) : le projet est un travail que je vous demande d'effectuer en binôme (ne faites donc pas le travail à double) et de commencer dès le début du semestre.

Pour 2) : le projet est en effet conçu dès le départ pour laisser une large place à la création et au développement personnel. Il est de plus prévu pour une population extrêmement hétérogène. Plusieurs ont donc tendance à trop en faire : trop par rapport aux attentes minimales du cours (niveau 2) et trop par rapport à leur propre niveau en programmation. Je constate chaque année chez certains une implication dans le projet disproportionnée par rapport à leur niveau effectif. Utilisez le barème et le niveau indiqué des exercices pour travailler à votre niveau (ou légèrement au dessus). En clair : faites ce que vous pouvez en un temps imparti, au lieu d'essayer de faire le maximum en un temps infini ! Fixez-vous un objectif raisonnable, atteignable pour votre niveau.

Le point 3) [gestion des contraintes et choix des priorités], est une conséquence du point précédent : ne sachant se limiter raisonnablement dans le projet, certains s'investissent trop dans cette branche de semestre au détriment d'autres branches plus fondamentales pour leur Section. Cela relève plus largement de l'organisation globale de leurs études et de la bonne gestion des contraintes que la charge de travail globale, à laquelle ils n'étaient pas habitués au Gymnase, leur impose.

Donc, pour résumé à ce stade, je dirais : faites attention à bien vous organiser et à ne pas vous laisser noyer par le projet. C'est dans ce sens que je vous donne les conseils d'organisation suivants.

Ce projet est prévu pour être réalisé partiellement pendant les séries d'exercices et partiellement sous forme de travail personnel indépendant : comme la programmation complète du projet n'est évidement pas envisageable sur un laps de temps réduit aux séances d'exercices, vous ne pourrez réaliser lors de ces séances que des portions de l'ensemble du projet, le reste devant être fait « à la maison ». Profitez par contre des séances d'exercices pour poser des questions aux assistants.

Par ailleurs, je vous conseille de vous assurer avoir bien compris les concepts présentés en cours avant de vous lancer dans la réalisation de la nouvelle partie correspondante du projet, par exemple en faisant au préalable quelques exercices proposés dans les séries ou dans le livre (nombre et difficulté en fonctions de votre niveau). Une fois les concepts bien compris, la réalisation du projet constitue bien sûr aussi un entraînement et une révision pour la série notée ou l'examen écrit.

La réalisation informatique du projet comporte plusieurs aspects :

• une hiérarchie d'objets permettant la représentation d'objets du monde sous forme de classe C++ ;
• un module permettant la simulation numérique  (évolution du système) ;
• un module permettant l'affichage à l'écran (graphisme).

N'abordez pas tous ces aspects de front, ni à la fois : organisez votre travail et votre projet et fixez vous des objectifs raisonnablement atteignables.

Ce projet est prévu pour être réalisé par binômes. Nous vous conseillons de rapidement vous répartir les tâches au sein du binôme (voir ici pour le travail en groupe). Il est évident pour moi que vous ne devez pas chacun faire tous les exercices liés au projet. Je considère qu'une personne doit faire seulement environ la moitié de ces exercices. Essayez donc de rapidement vous organiser, concevoir correctement la répartition des tâches et utiliser la conception modulaire et la compilation séparée (Makefile) afin de diminuer votre charge de travail individuelle.

Pour cela, je vous conseille de :

1. répartir le travail au sein du binôme (définir qui fait quelles classes) ;

2. faire les interfaces (méthodes publiques) de toutes les classes, même si la plupart restent vides ou ne contiennent au départ qu'un simple affichage ;

3. commencer à implémenter, à votre rythme, chacune des classes ;

   procéder classe par classe, en pensant bien à faire un fichier de test complémentaire testant les points (qui vous semblent) critiques de la classe ;

4. noter clairement dans votre JOURNAL ce que vous avez fait, où vous en êtes et ce qu'il vous reste à faire.

Un des buts du projet est justement de vous apprendre à développer du code en parallèle et de façon complémentaire. Par contre, jetez quand même un coup d'œil à la partie développée par votre partenaire et discutez-en ensemble. Vous apprendrez sûrement beaucoup de ce genre de pratique.

Enfin, pour vous faciliter la vie durant le projet :

• Travaillez avec régularité et ne prenez pas trop de retard. C'est une illusion que de croire pouvoir le rattraper par la suite.

• Pensez à sauvegarder régulièrement votre travail, faire des archives à chaque étape (même incomplète), afin d'éviter des pertes/écrasements de fichiers malencontreux.

  Je vous recommande pour cela très fortement de faire une copie complète de votre répertoire de projet toutes les 1 à 2 semaines :

      cp -a mon_projet archive-mon_projet-20250312

  (changez la date à chaque fois).

• Pensez également à faire des tests (petits programmes indépendants), à les sauvegarder et à les rendre. Les fichiers tests sont aussi importants. Cela peut vous sembler inutile, mais vous perdrez  moins de temps en écrivant un programme de test qu'en recherchant les causes d'erreurs au sein de nombreuses fonctions.

• Familiarisez vous dès le début avec l'ensemble du projet en lisant bien ce descriptif (plusieurs fois si nécessaire) et en naviguant sur les sites donnés en références. 

• Commencez rapidement ! 

• Réfléchissez avant de commencer à programmer. Prenez le temps avec votre collègue de bien réfléchir à comment coder, quelles structures de données utiliser etc.. Cela facilitera grandement la programmation par la suite et vous évitera d'avoir à refaire plusieurs fois la même chose.

• Modularisez votre code.

• Commentez votre code au fur et à mesure : il est quelque peu ingrat (pour ne pas dire plus) de devoir commenter un grand nombre de lignes de codes la veille de la remise et en ne se rappelant plus trop bien ce que l'on avait voulu faire (les commentaires aident à la correction et, en ce sens, participent à la notation).

• Compilez régulièrement. Il est plus facile de corriger 2 ou 3 fautes de syntaxe dans quelques nouvelles lignes de code que 100 fautes dans 400 lignes de code !

• Utilisez dans votre code des noms (identificateurs) porteurs de sens, ça permet de s'y retrouver plus facilement par la suite (reprise de code, correction d'erreurs et... ...évaluation par les correcteurs !).

• N'hésitez pas à poser des questions durant les séances d'exercices et sur le forum (de façon privilégiée).
  Par contre, NE POSTER AUCUN CODE DU PROJET SUR LE FORUM (des pénalités seront appliquées aux groupes qui le font).

  N'hésitez pas non plus à discuter de vos éventuelles difficultés avec votre assistant responsable ou avec l'enseignant.

• Faites ce que vous pouvez en un temps imparti (que vous vous serez fixé au départ), au lieu d'essayer de faire le maximum en un temps infini ! Fixez vous un objectif raisonnable, atteignable pour votre niveau.

  Certains en font beaucoup trop sur le projet, principalement en raison de la stimulation des autres groupes (dont certains passionnés) et la moyenne des projets finalement rendus est souvent très élevée (5 à 5.5). Il est donc clair que pour quelqu'un qui a un niveau moyen de 3.5 à 4.5, fournir le travail de développer un projet à un niveau de 5.5 à 6.0 est simplement colossal ! Ce n'est pas ce que je vous demande...

• Remarquez que les semaines (1,) 5, 9, 12 et suivantes n'ont pas de sujet associé (c.-à-d. pas de nouvelle donnée). Profitez-en pour approfondir votre connaissance des concepts du cours (exercices) et rattraper votre éventuel retard dans le projet (mais vous ne devriez pas en avoir !).

Je terminerai par une note au sujet de la tricherie :
L'échange d'idée entre groupes ou avec des tiers est autorisée (et même recommandée). Par contre, l'échange de code est strictement interdit (cela inclut la diffusion de code sur le forum) ! Le plagiat de code de quelque façon que de soit et quelle qu'en soit la source sera considéré comme de la tricherie (en plus, c'est illégal et passible de poursuites pénales).

En cas de tricherie, vous recevrez la note « NA », soit pour le projet, soit même pour l'entièreté du cours. Vous serez de plus dénoncés et punis suivant l'ordonnance sur la discipline.
(je me permets également de vous rappeler le code d'honneur et le code de déontologie dont vous avez pris connaissance au début de vos études).

Dans tous les cas, il est fortement conseillé de pouvoir expliquer toutes les lignes de code de son projet.

Décomposition en sous-tâches / séries associées

Voir ici l'échéancier détaillé, semaine par semaine.

Bibliographie

• un complément mathématique au projet

• vos cours de Physique (de cette année)

• Mécanique, Jean-Philippe Ansermet, PPUR 2018 (2e éd.).