Solveurs utilisables pour un maillage mobile

Pour le cas des écoulements incompressibles, OpenFOAM est capable de gérer la résolution des équations avec un maillage mobile grâce à la méthode Arbitrary Lagrangian-Eulerian. Concrètement, le domaine est décrit par un seul maillage dont la vitesse de chaque noeud est imposée et donc connue. Les équations de Navier-Stokes à coder prennent en compte le fait que les volumes de contrôle sont en mouvement et aucune approximation supplémentaire n'est faite par rapport à un calcul avec maillage fixe.

Le solveur d'OpenFOAM permettant de réaliser de tels calculs s'appelle PimpleDyMFoam, pour Pimple Dynamic Mesh Foam.

Pour ce solveur, dans le cas des écoulements incompressibles, quatre tutoriels sont présents dans la version 2.1.0 d'OpenFOAM. Parmi ces quatre tutoriels, deux ont particulièrement retenu notre attention : le cas du movingCone ainsi que le cas du mixerVesselAMI2D.

Le premier traite l'avancée d'un cône solide dans un domaine fermé, un peu à l'idée d'un piston. Il résout une portion angulaire d'un problème axisymétrique. La gestion du maillage mobile est décrite dans le fichier dynamicMeshDict (dans le répertoire constant) et est assurée par le solveur dynamicMotionSolverFvMesh, où l'utilisateur indique que le déplacement des mailles se fait selon l'axe X. Avec ce solveur, il est aussi nécessaire d'introduire un fichier pointMotionUx dans le dossier 0 afin d'indiquer la vitesse de tous les bords du domaine de calcul. Toutes les mailles vont alors se déplacer de manière cohérente. Dans cet exemple, les mailles initialement à gauche du cône vont s'étirer lorsque ce dernier va se déplacer vers la droite, et les mailles à droite vont logiquement se contracter. Remarquons que la qualité du maillage est par conséquent modifiée au cours du calcul. Pour notre étude du mouvement du train, cet aspect sera un point primordial puisqu'il est évidemment impossible de réaliser des calculs avec un maillage de trop mauvaise qualité où certaines mailles auront un rapport hauteur sur longueur éloigné de 1.

 

Voici une animation décrivant l'évolution du maillage au cours du calcul, sans qu'on ait modifié les paramètres de la simulation :

Cas du tutoriel MovingCone

 

Le solveur en pratique


En pratique, l'utilisation de ce solveur nécessite d'effectuer quelques adaptations pour passer d'une configuration quelconque à une configuration fonctionnant avec ce solveur. En effet, il existe quelques contraintes auxquelles nous avons dû nous adapter pour faire fonctionner nos simulations.

Pour noter cas, où nous devions faire translater un objet sur une longue distance, nous avons utilisée une méthode qui consiste à mettre en place trois blocs. Le bloc central sera celui contenant l'objet à déplacer, et aura un maillage constant au cours du temps, au sens où le bloc bougera mais le maillage bougera avec sans se déformer. Il subira une simple translation.

A l'inverse, les deux blocs aux extrémités du domaine auront le rôle de tampon. Ils se compresseront ou s'étireront pour mettre en mouvement le bloc central.

Sur l'animation ci-dessus, on voit le bloc central se déplacer uniformément tandis que les deux blocs autour se compressent d'un côté et s'étirent de l'autre.

Dans toutes nos simulations futures, nous utiliserons cette configuration à trois blocs, avec le bloc central contenant le train, la sphère où tout autre géométrie.

Avec ces trois blocs, en plus des conditions initiales et limites sur la vitesse et la pression, il faut définir le déplacement des points du maillage. Ceci est réalisé dans le fichier pointMotionUx (mouvement suivant x) dans le dossier 0. Ce fichier est organisé de la même manière que les fichiers U ou p. Les parties left et right correspondant aux extrémités du tunnel sont fixées, avec fixedValue et uniform 0. Le train ainsi que le bloc central ont une vitesse de 40m/s définies avec fixedValue uniform 40. Enfin, les deux blocs "tampons" prennent la condition limite slip qui signifie que les points du maillage de ces blocs vont simplement glisser pour venir absorber le mouvement du bloc central.


Moving Reference Frame

Le deuxième concerne l'étude d'un mixeur en rotation dans un domaine fluide. Son intérêt est probablement de mélanger un fluide contenant plusieurs espèces afin d'homogénéiser leur répartition dans le fluide. Comme dans le premier exemple, le solveur qui gérera le maillage mobile est indiqué dans la fichier dynamicMeshDict et on peut alors remarquer qu'il s'appelle cette fois-ci solidBodyMotionFvMesh. Avec ce solveur, il faut indiquer certaines zones du domaine (zones MRF, pour Moving Reference Frame) de calcul et le déplacement de celles-ci sont indiquées dans le fichier MRFZones dans le dossier constant. La particularité supplémentaire par rapport au premier exemple est que, en plus de la méthode ALE pour gérer le fait que certains points de calculs sont mobiles, il est aussi nécessaire de faire des interpolations entre les zones MRF et les zones fixes. En effet, leur interface est fixe, mais les points de calculs de la zone MRF sur cette interface est mobile alors que ceux de la zone fixe sont immobiles. L'avantage de cette méthode est qu'il ne modifie pas la forme des mailles et donc si le maillage initial est de qualité correcte, il le sera tout au long du calcul.

 

Cas du tutoriel MixerVesselAMI2D

Pour deux raisons, nous préférerons donc partir sur le premier cas test. Le premier argument est géométrique. Il vient simplement du fait que nous souhaitons étudier la translation d'un train dans un domaine rectiligne, et ce cas du movingCone est relativement proche de ce que nous souhaitons finalement obtenir.

Le deuxième argument est davantage une anticipation de difficultés liées au solveur indiquant ces zones MRF. Outre le fait que nous aurions dans tous les cas du indiquer à certaines mailles de se contracter et de s'étirer (à hauteur du train), certaines zones auraient pu tout à fait être fixes (pour des hauteurs différentes de celles du train). Il aurait fallu interpoler les valeurs à l'interface entre ces deux zones du maillage. Cela n'étant pas indispensable, il ne nous apparaissait pas vraiment utile de se surcharger d'une contrainte supplémentaire avec cet outil d'interpolation, source probable d'erreurs.