Aujourd’hui démarre le projet intégré numérique des 1er master ingénieur physicien que j’encadre avec Christophe Geuzaine.

Cette année, nous nous intéressons à la méthode “Particle in Cell” (PiC), une méthode numérique assez amusante qui permet de simuler de manière approchée des écoulements de fluides. Elle est utilisée principalement dans le cadre de la création d’animations (Computer Graphics : jeux vidéos, dessins animés, cinéma) et elle a la particularité d’être très simple et très efficace. On peut donc viser des simulations quasiment en temps réel. Cette instantanéité me change des résultats obtenus de manière laborieuse en CFD et notamment avec la méthode PFEM, la méthode qu’on utilise dans le laboratoire pour modéliser des écoulements à surface libre.

La question qui se pose est “a quel point cette méthode très rapide est-elle capable de reproduire la physique réelle des écoulements?”. On voit bien que PiC, dans sa version la plus simple, produit un fluide extrêmement visqueux alors qu’aucune viscosité n’est modélisée par les équations. Des méthodes plus avancées existent pour améliorer les résultats. On parle de FLIP (Fluid Implicit Particle) et APIC (Affine Particle in Cell). Certains auteurs mélangent ces méthodes pour obtenir quelque chose de convaincant (…visuellement!)

Le but du projet sera donc de répondre à cette question en codant “à partir de rien” différentes variantes de la méthode et en comparant les résultats à ceux de benchmarks (écoulements simples: Couette, Poiseuille, dans des conduites, … et plus compliqués: écoulement autour d’un cylindre et simulation de Allée de tourbillons de von Karman).

Pour préparer le cours, j’ai débuté la programmation d’un prototype en me basant sur la vidéo de Sébastian Lague (Coding Adventure). Ce youtubeur arrive à rendre les choses excessivement simple à comprendre et montre sa progression, ses erreurs, ses simplifications. Le résultat est toujours impressionnant.

La méthode PiC se prête bien à la simulation d’écoulements en temps réel. On a donc envie d’interagir avec le fluide à la souris, directement dans la fenêtre de simulation, un peu comme dans un jeu. Sébastian Lague utilise Unity comme moteur graphique. Ca lui permet de définir des objets géométriques, des menus de paramètres qui peuvent être ajustés pendant la simulation. Dans mon cas, je n’ai pas envie d’utiliser Unity mais plutôt renforcer ce que je connais déjà bien: le Pixel Game Engine. Ca a plusieurs avantages: c’est du C++ (face au C# d’Unity que je ne maîtrise pas), c’est très léger (un header, pas de bibliothèque à linker) et ça me met face à plusieurs problèmes annexes:

  • Des choses simples comme gérer les coordonnées “view” et “world”, un niveau de zoom, l’interaction avec la souris, afficher un dégradé de couleurs sur une grille, afficher des vecteurs… et même du texte sur plusieurs lignes, … tout ça doit être codé soi-même! Chaque chose n’est pas compliquée en soi mais le nombre de choses à faire est énorme. J’aimerais tirer parti de ce projet pour me créer une petite bibliothèque de routines qui font toutes choses “à ma manière” pour pouvoir les réutiliser ensuite et ne plus avoir ce “mur” de démarrage de projet en face de moi. Bien souvent, j’abandonne l’idée de coder un projet parce que je sais que je vais trébucher sur des bêtises.
  • J’aimerais aller jusqu’à interfacer une bibliothèque telle qu’ImGui pour afficher des widgets, des menus, etc… ceci pour avoir une sorte d’interactivité comme sous Unity. Une autre solution serait d’utiliser Qt que je connais bien, mais Qt est un mastodonte de plusieurs Go à installer… Bof, bof…
  • J’aimerais enfin comprendre comment compiler du code C++ en WebAssembly pour mettre le résultat sur le web. Là aussi, l’idée est de renforcer ce que je connais (C++) au lieu de partir sur un “nouveau” langage (Javascript) pour atteindre mon but. Je sais que c’est simple à faire, mais il faut prendre le temps de regarder comment ça marche. La dernière étape étant d’automatiser ça sur le GitLab de ULiège et publier le résultat sur GitLab pages…

Liens: