3. Quelques conseils d’utilisation#

Si on souhaite [2] changer de solveur linéaire ou adapter son paramétrage, plusieurs questions doivent être abordées: Quel est le type de problème que l’on souhaite résoudre ? Qu’elles sont les propriétés numériques des systèmes linéaires rencontrés ? etc.

On liste ci-dessous et, de manière non exhaustive, plusieurs questions qu’il est intéressant de se poser lorsqu’on cherche à optimiser les aspects solveurs linéaires. Bien sûr, certaines questions (et réponses) sont cumulatives et peuvent donc s’appliquer simultanément.

En bref:

La méthode par défaut reste la multifrontale interne MULT_FRONT . Mais pour pleinement bénéficier des gains CPU et RAM que procure le parallélisme , ou pour résoudre un problème numériquement souvent difficile (X-FEM, incompressibilité, THM), on préconise l’utilisation du produit externe MUMPS . Plus le problème est de grande taille, plus on conseille d’utiliser le parallélisme MPI et les technique d’accélération/compression (ACCELERATION/LOW_RANK_SEUIL).

Si, malgré tout, sur une plate-forme informatique donnée, le problème ne passe pas en mémoire, le recourt aux solveurs itératifs de PETSC peut être une solution (si leurs périmètres fonctionnels le permet). Notons que par par défaut ils utilisent en «sous-main» MUMPS en tant que préconditionneur (option PRE_COND=”LDLT_SP”).

Pour aller plus loin dans les économies en place mémoire , on peut aussi dégrader le préconditionnement (le calcul sera probablement plus long) en choisissant un des autres préconditionneurs de PETSC(“LDLT_INC”…).

En non-linéaire, pour gagner en temps , on peut aussi jouer sur plusieurs paramètres de relaxation (SYMEen non symétrique) ou d’intéractions «solveur non linéaire/solveur linéaire» (REAC_PRECOND, NEWTON_KRYLOV..).

Pour des problèmes non linéaires bien conditionnés (thermique…), le recours à un MUMPS«relaxé» (MIXER_PRECISION/FILTRAGE_MATRICE) peut amener des gains mémoire très sensibles. De même, en linéaire comme en non linéaire, avec PETSCsans préconditionneur (PRE_COND=”SANS”).

Pour plus de détails et de conseils sur l’emploi des solveurs linéaires on pourra consulter la notice d’utilisation [U4.50.01] et les documentations de référence associées [R6…]. Les problématiques connexes d’amélioration des performances (RAM/CPU) d’un calcul et, de l’utilisation du parallélisme, font aussi l’objet de notices détaillées: [U1.03.03] et [U2.08.06].

Quel est le type de problème à résoudre ?

  • Résolution de nombreux systèmes avec la même matrice (problème de type multiples seconds membres [3]

) ⇒ solveurs MULT_FRONT ou MUMPS (si possible en désactivant RESI_RELA et avec GESTION_MEMOIRE=”IN_CORE”).

  • Calcul paramétrique standard en linéaire ⇒ un premier essai avec MUMPS en laissant les paramètres par défaut, puis tous les autres runs en débranchant RESI_RELA ou avec POSTTRAITEMENTS=”MINI”.

  • Calcul paramétrique en non linéaire avec une matrice bien conditionnée ⇒ un premier essai avec MUMPS en jouant sur les paramètres de relaxation (FILTRAGE_MATRICE/MIXER_PRECISION ou SYME si on est en non symétrique). Puis, si un point de fonctionnement optimisé (consommations CPU/RAM) a été dégagé, l’utiliser pour tous les autres runs.

On peut aussi essayer MUMPS mais, cette fois, comme préconditionneur simple précision de PETSC/GCPC (LDLT_SP). L’intérêt est alors de ne le réactualiser que périodiquement (REAC_PRECOND).

Quelles sont ses propriétés numériques ?

  • Système linéaire bien conditionné [4]

(<104) ⇒ solveurs MUMPS+MIXER_PRECISION ou GCPC/PETSC.

  • Système linéaire difficile (mauvais conditionnement, éléments finis mixtes, prédominances de Lagranges…) ⇒ solveur MUMPS.

A-t-on besoin d’une solution très précise ?

  • On peut se contenter d’une solution très approximée [5]_

⇒ solveurs GCPC ou PETSC avec un RESI_RELA=10-3 ou MUMPS avec LOW_RANK_SEUIL<10-9 et POSTTRAITEMENTS=”SANS”.

  • On veut une solution précise ou, au moins, un diagnostic sur sa qualité et sur les difficultés numériques du système à résoudre ⇒ solveur MUMPS en activant NPREC et RESI_RELA (en INFO=2).

Comment optimiser les consommations temps/mémoire RAM du solveur linéaire ?

  • Temps ⇒ solveur MUMPS en désactivant l’OOC (GESTION_MEMORE=”IN_CORE”) voire RESI_RELA. Calcul parallèle hybride MPI/OpenMP (cf. doc. U2 sur la parallélisme). Sur les problèmes de grande taille usage des compressions low_rank et des accélérations via les mots-clés ACCELERATION/LOW_RANK_SEUIL.

  • Mémoire ⇒solveur MUMPSen activant GESTION_MEMOIRE=”OUT_OF_CORE”/MATR_DISTRIBUE et en mode parallèle distribué. Ou solveur itératif de type Krylov: GCPC/PETSC+LDLT_SP.

En non linéaire, si la matrice est bien conditionnée et/ou non symétrique, on peut aussi jouer sur les paramètres de relaxation de MUMPS (FILTRAGE_MATRICE, MIXER_PRECISION etSYME) ou utiliser un solveur itératif en réduisant le coût du préconditionnement. On trouvera plus de détails dans la discussion du § 7.2.6 .

  • Mémoire ⇒solveur PETSCen activant MATR_DISTRIBUE et en mode parallèle distribué.

Est-ce un problème frontière de très grande taille (> 5.10 6degrés de liberté ) ?

  • Solveur robuste ⇒ solveur MUMPS avec les optimisations mémoires précédentes et les compressions low-rank (ACCELERATION/LOW_RANK_SEUIL).

  • Solveurs de la «dernière chance» ⇒solveurs itératifs (avec un niveau de préconditionnement faible).

Comment optimiser les performances globales de mon calcul ?

  • Notice d’utilisation [U1.03.03].

Comment effectuer, calibrer et optimiser un calcul parallèle ?

  • Notice d’utilisation [U2.08.06].