Je tiens à remercier chaleureusement MM. Ayrton Lachat et Ahmed Abbas pour leur aide précieuse lors de la conception de ce 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.
Le but du projet de cette année est de simuler le comportement d'un système composé d'un grand nombre de particules en interaction les unes avec les autres dans un milieu visqueux, à la manière par exemple d'un tas de neige humide.
L'intérêt est double :
Le problème de la simulation d'un tel système est double :
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é établies
au préalable sur le papier).
Le problème considéré cette année relève typiquement de la première approche.
Le système que l'on souhaite simuler sera donc constitué de particule interagissant entre elles ou avec les obstacles aux moyens de forces que nous aurons pris soin de modéliser du point de vue mathématique, puis de programmer.
Pour simplifier, les particules seront considérées comme sphériques, et les obstacles auront des formes géométriques simples (plan, sphère, cylindre).
Du point de vue physique, on peut considérer pleins de modèles plus ou moins complexes pour les interactions, dont les deux plus simple suivants :
(empilement de boules de billard) les « particules » (boules) ne sont mues que par leur poids. Il faut alors simuler les chocs et les forces de frottement entre boules (ainsi que l'attraction terrestre et les forces de frottement avec le milieu) ;
(neige mouillé) les particule sont dans un fluide et nous pouvons modéliser les interactions au moyen d'une force dérivant d'un potentiel prenant en compte l'attraction des particules à moyenne distance (forces de capillarité du fluide « liant » les particules) et leur répulsion à courte distance (incompressibilité du fluide entre deux particules trop proches).
Dans ce projet, nous vous proposons de n'implémenter que la seconde, mais cela ne nous empêchera pas de concevoir le code comme si la première, ou encore d'autres, devai(en)t aussi être implémentée(s) (modularité du code).
Dans les deux modèles, chaque particule est soumise à chaque instant à une équation du mouvement de la forme
F(t) + m g - a v(t) = m dv/dt(t)
Ce qui change entre les deux modèles c'est la forme de la force F, et, par voix de conséquence, la façon de calculer l'évolution à partir de l'équation ci-dessus.
Dans le cas de la simulation de particule en interaction via un fluide de liaison, la force F résulte de la somme des forces exercées par les particules voisines. Chacune de ces forces dérivent d'un potentiel répulsif à courte distance, attractif à moyenne distance et nul à grande distance.
La forme mathématique de (la norme de) cette force est
F(d) = -24 ε / σ2 si d ≤ σ
F(d) = 24 ε / d2 * (σ/d)5 *
(1-2*(σ/d)6) si s < d ≤ 2σ
F(d) = 0 si d > 2σ
où d est la distance entre les deux centres de gravité, et σ et ε sont deux paramètres. La direction de la force entre deux particules est colinéaire à la droite passant par leur centre de gravité.
Les obstacles étant considérés comme fixes, l'interaction des particules avec eux se fait suivant la même formule qu'entre deux particules sauf que la force résultante est double (de sorte à conserver l'énergie du système).
Le point le plus délicat avec les obstacles étant donc de spécifier le point de contact. Ce sera fait pour des formes simples dans le complément mathématique qui vous est fourni.
Le problème est donc à ce stade totalement spécifié. Sa résolution informatique peut commencer... (mais rassurez-vous nous vous donnerons plus de détails !).
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+Δt, où Δt 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.
Contrairement à d'autres types de problèmes, la principale difficulté n'est pas ici de calculer le mouvement hors des chocs/contacts, ni même de simuler les chocs/contacts en question (cf équations précédentes), mais bien de savoir quelle particule interagit avec quelle autre. Nous y reviendrons le moment voulu.
Une fois les particules en interaction déterminés, le principe de base est de calculer pour chacune la force totale qu'elle subit. Ensuite, à l'aide de la loi de Newton qui nous donne l'équation du mouvement, on fait évoluer chacune de ces particules pour un pas de temps Δt (petit).
Ainsi, de proche en proche, le système évolue : pour chaque particule
et recommencer ainsi de suite, à chaque fois pour toutes les particules.
La simulation minimale pour viser le 6 devra permettre de visualiser étape par étape l'évolution d'un système contenant au moins 100 particules avec au moins 3 obstacles différents et au moins une source de particules.
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) :
...mais ne passez pas trop de temps sur ce projet, en particulier au détriment des autres branches !!
Le projet est à réaliser impérativement en groupe de deux personnes sans aucune exception. Les groupes sont à constituer d'ici au 12 mars 2026.
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).
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 31 mai à 23:59. (Cette date est absolument impérative. Aucune extension de délai ne sera accordée !) Mais je vous conseille fortement de rendre le projet avant la semaine 13 et vous libérer l'esprit pour l'examen final !
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'étudiant(e)s 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.
]
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 assistant(e)s.
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 :
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 :
répartir le travail au sein du binôme (définir qui fait quelles classes) ;
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 ;
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 ;
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-20260312
(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(e)-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,) 8, 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.
Voir ici l'échéancier détaillé, semaine par semaine.
vos cours de Physique (de cette année)
Mécanique, Jean-Philippe Ansermet, PPUR 2022 (3e éd.).