La connaissance de la bathymétrie et le maillage

Lorsque l’on veut faire une simulation du cours d’eau d’une rivière, le premier obstacle est la connaissance précise de la bathymétrie. La bathymétrie correspond aux relevés de la profondeur de la rivière et sa connaissance précise est cruciale pour que les simulations numériques aient une chance de correspondre à la réalité. Dans cet objectif, des relevés bathymétriques sont effectués dans les rivières et fleuves que l’on veut simuler. Ces campagnes de mesures sont souvent coûteuses, d’autant plus que la précision demandée est importante. Plusieurs méthodes peuvent être employées pour faire ces relevés. Des lasers peuvent être utilisés pour mesurer la profondeur de l’eau mais ils se limitent souvent à des eaux très peu profondes ou parfaitement limpides. Le reste du temps, ce sont des versions plus ou moins sophistiquées de sonar qui sont utilisées. Ces relevés bathymétriques permettent de générer un maillage du fond de la rivière. Dans le cadre de l’étude d’inondations le domaine à mailler comprend le domaine fluvial ainsi que les rives qui pourront être inondées lors des simulations. Les données bathymétriques doivent donc être couplées à des données topographiques pour créer un maillage complet du domaine d’étude. La création d’un tel maillage nécessite aussi de prendre compte tout un tas d’obstacles dans la rivière, la présence d’îles, de piles de pont et toutes autres structures. La création du maillage d’un domaine de simulation est une tâche longue et demandera souvent une étape de validation durant laquelle plusieurs résultats de simulations seront comparés à des relevés de hauteur d’eau réels pour assurer une bonne précision. On se servira donc, dans un premier temps, de simulations pour lesquelles des relevés de hauteur d’eau sont connus pour valider le maillage. On pourra, dans un second temps, faire une étude des inondations dans des situations plus critiques pour lesquelles des relevés de hauteur d’eau ne sont pas présents.

Différents objectifs de simulation

Lorsque l’on traite un nouveau domaine de simulation, il y a deux phases importantes à traiter. La première consiste à générer une solution stabilisée, c’est-à-dire au régime permanent, sur le domaine pour un débit d’entrée moyen de la rivière. On considère que le régime permanent est atteint lorsque le débit de sortie de la rivière est égal au débit d’entrée pendant une longue période. Cette phase est souvent la plus complexe car l’initialisation de la solution sur tout le domaine pose plusieurs problèmes. On a rarement des relevés précis de hauteur d’eau dans toute la rivière et encore moins des relevés de vitesse. Il nous faut alors choisir arbitrairement ces paramètres pour les premières simulations. Les paramètres ainsi choisis mèneront plus ou moins rapidement à une solution stabilisée. Beaucoup de bancs couvrant-découvrant seront présents et mettront en difficulté la stabilité des différents schémas numériques. On pourra alors utiliser plusieurs stratégies d’initialisation pour converger le plus rapidement vers la solution permanente, parfois au prix d’une solution transitoire qui n’est pas physique. La seconde phase est celle qui présente le réel intérêt pour faire l’étude des inondations. Lors de cette phase on initialisera la simulation à partir de la solution stable calculée précédemment. On lancera ensuite plusieurs simulations en faisant varier certains paramètres. On pourra par exemple simuler de fortes intempéries en augmentant le débit d’entrée de la rivière. Le but de cette seconde phase est de générer une base de données de résultats de simulations lancées avec différents paramètres (débit d’entrée, hauteur de sortie, coefficient de frottement). On pourra par la suite utiliser cette base de données pour faire des études statistiques des inondations (Abdedou & Soulaïmani, 2018; Fahsi, Soulaïmani & Tchamen, 2010; Zokagoa & Soulaïmani, 2012). On peut aussi utiliser ces bases de données pour entraîner des algorithmes de machine learning (Jacquier, Abdedou, Delmas & Soulaïmani, 2020) pour prédire en un temps très faible des situations qui n’ont pas été simulées.

Le besoin d’un calcul rapide Que ce soit pour la première ou la seconde phase des simulations, on veut toujours pouvoir traiter des domaines les plus grands possibles le plus rapidement possible. La possibilité de traiter de très grands maillages comprenant un nombre de cellules très important est cruciale pour avoir une représentation précise de la bathymétrie du domaine. Plus le maillage aura un grand nombre d’éléments, plus il sera simple d’y traduire les relevés bathymétriques et plus le maillage pourra être raffiné dans les zones critiques de la rivière (barrages, piles de ponts, îles). Un maillage plus raffiné combiné à des mesures de bathymétrie précises permettra à coup sûr d’avoir de meilleures solutions. D’autre part, si les calculs sont plus rapides on pourra simuler bien plus de cas d’inondations différents dans un même temps. Plus on simulera de cas différents, plus les bases de données seront fournies ce qui permettra de diminuer les incertitudes sur les prédictions. Pour atteindre ces objectifs on se tourne vers de la programmation parallèle pour distribuer les calculs et/ou la mémoire sur plusieurs unités de calculs. Une revue de littérature des différentes méthodes utilisées pour faire de la programmation parallèle dans le cadre de la résolution des équations de St-Venant sera présentée dans le chapitre 1. On souhaite pour finir cette introduction présenter les raisons qui nous poussent à vouloir utiliser des GPU, puis pourquoi on veut coupler leur utilisation à MPI.

Pourquoi utiliser un GPU? Le GPU : Graphical Processing

Unit est un coprocesseur qui a été historiquement utilisé pour faire du calcul graphique beaucoup plus rapidement que le CPU : Central Processing Unit. Dans cet objectif le GPU est construit avec une architecture SIMD : Single Instruction Multiple Data qui lui permet d’effectuer les mêmes opérations sur une grande quantité de données. Il a vite été remarqué qu’une telle architecture pouvait être particulièrement adaptée à certaines simulations numériques dans lesquelles les mêmes opérations sont répétées sur des données différentes. Dans notre cas, avec une méthode volumes finis explicite en temps, porter le code sur GPU n’est pas une tâche très complexe, bien que l’optimisation requise pour atteindre les plus hauts speed-up peut être longue. Comme on le verra, ce qui rend l’adaptation d’un code sur GPU relativement facile est la manière incrémentale avec laquelle ce portage peut être fait. Finalement, il est relativement simple de trouver de nos jours des ordinateurs fixes ou même portables qui contiennent un GPU et sur lesquels un tel code peut être lancé. Le code est donc relativement portable même si des étapes de configuration du système sont requises.