Conclusion et Perspectives

Synthèse


L'objectif de ce projet, qui était principalement la mise en place d'une méthode sous OpenFOAM pour pouvoir gérer le maillage mobile d'un train qui se déplace dans un tunnel peut être considéré comme atteint.

En effet, par l'élaboration du script qui automatise tout le processus, l'utilisateur n'a qu'à créer un dossier classique OpenFOAM avec tous les paramètres numériques de la simulation. Les simulations s'enchaînent alors toutes seules et l'utilisateur pourra post-traiter les résultats.

Le travail ainsi rendu à TECH-AM Ingénierie et à SETEC Bâtiment leur permettra ensuite de modifier s'ils le souhaitent la géométrie du train et du tunnel, les modèles et schémas numériques, dans de bonnes conditions. Les premiers résultats présentés sur ce site ont quand même permis d'être assez confiants dans les calculs effectués par le code. Les industriels pourront ainsi modifier les paramètres des modèles tout en étant assez optimiste sur la qualité des calculs.

Toutefois, l'utilisation des modèles nous éloigne forcément du cas réel, et le plus important reste d'être conscient de cet écart. Il faut pouvoir justifier les erreurs et en trouver les sources; Dans notre cas, on pourra toujours citer par exemple les interpolations entre chaque sous-simulation qui ont tendance à parfois lisser certains gradients importants.

 

Perspectives


Passer en 3D ...

Créer le domaine représentant le train et le tunnel en trois dimensions aurait tout à fait pu être une étape de ce BEI. OpenFOAM étant naturellement un solveur 3D des équations de Navier-Stokes, notre "seul" travail serait de créer la géométrie du domaine de calcul dans une troisème dimension. Cela concernerait à la fois le fichier blockMeshDict pour avoir plusieurs mailles dans la direction Z, et la géométrie du train décrite dans le fichier .obj et obtenue avec le logiciel FreeCAD.

Les temps de calcul auraient sans doute été beaucoup plus grands. De plus, les résultats n'auraient pas forcément été plus pertinents, comparés à l'effort supplémentaire nécessaire à fournir en ressources numériques et en temps de maillage (ressources humaines).

 

Entrée-sortie du tunnel ...

Un autre aspect qui aurait pu être étudié de façon numérique est l'entrée du train dans le tunnel ainsi que sa sortie. Cet aspect pourrait être en soi un travail qui nécessiterait un investissement conséquent, mais Mr Tekam ne désirait pas avoir un code résolvant ces problèmes d'entrée et de sortie du tunnel.

Cependant, nous avons eu quelques premières réflexions sur ce sujet et nous pouvons mettre en valeur le problème majeur. Vu la construction actuelle de notre maillage mobile, nous avons pu voir que les mailles, dans l'intégralité du domaine, sont mobiles. Or, si on souhaite modéliser aussi l'extérieur du tunnel, il est nécessaire d'avoir deux types de conditions limites. Un type de condition limite correspondrait à l'extérieur du tunnel, à l'air libre, et l'autre correspond à la paroi intérieure du tunnel. Ces conditions limites sont fixes dans l'espace alors que le maillage est mobile. C'est ici que le problème se pose puisqu'il n'est pas évident de gérer des conditions limites fixes avec un maillage mobile (même au niveau des parois).

Nous pouvons proposer deux pistes que l'on aurait pu poursuivre si cela faisait partie de nos objectifs.

La première proposition serait de trouver un moyen d'avoir un maillage fixe sur la partie haute du domaine, là où ne passe pas le train. On pourrait simplement envisager de créer un bloc fixe sur cette partie supérieure avec le fichier blockMeshDict. La partie inférieure serait en tout point similaire à ce que nous avons jusqu'à présent. Simplement, la condition limite pour modéliser soit la paroi du tunnel, soit l'air libre, devra être imposé cette fois sur le maillage fixe, ce qui se fait simplement. Le point compliqué est cependant de pouvoir gérer le lien entre les maillages fixe et mobile. Il faut pouvoir interpoler les valeurs à l'interface entre ces deux maillages,ce que OpenFOAM est capable de gérer si l'on en croit les résultats du tutoriel MixerVessel2D. Cependant, une très grande compréhension de cette interpolation est requise pour pouvoir l'appliquer à notre cas du train, rendant peut-être compliquée sa mise en place.

La deuxième solution serait d'utiliser un "package" que l'on peut trouver sur internet. En effet, un package du nom de "Swak4Foam" (couteau-suisse pour OpenFOAM) contient un outil appelé "Groovy Boundary Conditions". Celui-ci permet d'imposer des conditions limites en fonction de la position dans le domaine, alors que, classiquement, les conditions limites sont définies bloc par bloc. Ensuite, selon la position dans le domaine, on peut imposer une condition de type "Mur" ou de type "Air libre" selon qu'on se trouve dans ou en dehors du tunnel. Si l'on devait aller plus loin, nous serions partis sur cette piste puisqu'il assure une totale compatibilité avec notre solveur PimpleDyMFoam et l'outil de maillage mobile actuellement utilisé.