9. Conclusions, développements envisageables.

Le compte-rendu [RB12] a été diffusé. Il fait office de conclusion détaillée. Il offre un état des lieux et des perspectives plus détaillées sur la maintenance et les développements éventuels de MULT_FRONT, dans le contexte de la disponibilité dans Code_Aster , d’un autre solveur, MUMPS. On résume cependant dans les 2 paragraphes suivants, le périmètre d’exécution et le bilan des performances de MULT_FRONT.

9.1. Périmètre d’exécution

Le périmètre de la méthode multi-frontale est quasi-complet depuis les développements de 2011 qui permettent de factoriser les matrices dites «généralisées». Seuls les systèmes numériquement instables, nécessitant une méthode de pivot (X-FEM par exemple) sont à exclure du choix du solveur MULT_FRONT. Un développement moins récent (renumérotation des nœuds d’interpolation et non plus des degrés de liberté), permet de conserver l’ordre de ces degrés de liberté à l’intérieur d’un nœud et permet de traiter les éléments incompressibles. Le recours à MUMPS est la solution pour les systèmes nécessitant une méthode avec pivot. Cependant un développement de MULT_FRONT est envisageable: il est possible d’effectuer, à l’intérieur de chaque super nœud, c’est à dire parmi les inconnues éliminées à chaque étape, une recherche (évidemment partielle) de pivot. Une recherche plus complète, impliquerait alors la fusion de plusieurs super nœuds (fusion de matrices fille et mère ) et paraît difficilement envisageable. Ce pivotage partiel nécessite une quantité de travail non négligeable et constituerait un risque pour la stabilité du code.

9.2. Performance

Les performances séquentielles (mode mono-processeur) sont comparables à celles de MUMPS dans beaucoup de cas. Seuls les cas présentant beaucoup de relations linéaires entre les degrés de liberté peuvent être très défavorables à MULT_FRONT qui crée du remplissage matriciel dans ces cas. Parfois il a suffi de réordonner la données de ces conditions aux limites pour régler le problème.

En ce qui concerne le parallélisme (localisé comme on l’a vu plus haut, à l’intérieur de l’élimination de chaque super nœud), il est peu utilisé et peu offrir un facteur d’accélération entre 2 et 3 pour une exécution sur quatre processeurs (ou cœurs de processeurs). Ce parallélisme est intéressant pour les gros cas nécessitant beaucoup de mémoire et devant s’exécuter pratiquement seuls en machine. Cela permet de réduire notablement leur durée de résidence en machine. L’arrivée de processeurs dotés de plus en plus de cœurs devrait fournir l’occasion de nouveaux tests de performances pour de tels gros cas. Cependant cette parallélisation en mémoire partagée n’offre pas de gain en mémoire. Ce que permet la parallélisation en mémoire distribué (MUMPS). Souvent ce problème de mémoire est un point bloquant pour les gros systèmes linéaires.

La méthode multi-frontale offre la possibilité d’une autre parallélisation plus élaborée sur les différentes branches de l’arbre d’élimination. Il n’est pas envisageable de la programmer dans MULT_FRONT, ce serait «refaire» ce qui est fait dans MUMPS. Le code n’a pas été conçu pour la parallélisation par envoi de message.