5. Optimisation des performances

En quasistatique, il n’est pas rare de devoir effectuer plus de 10 itérations pour avoir la convergence au sens du résidu en équilibre. En dynamique implicite cette valeur de 10 itérations constitue, en général, une bonne valeur de départ pour le paramètre ITER_GLOB_MAXI du mot-clé facteur CONVERGENCE dans DYNA_NON_LINE. Si l’on ne peut converger en moins de 10 à 20 itérations, il est alors préférable de diminuer le pas de temps plutôt que d’augmenter le nombre maximal d’itérations autorisé.

En explicite, il n’y a pas d’itérations pour l’équilibre, le coût de calcul de chaque pas de temps sera donc constant, quel que soit le niveau de non-linéarité (hormis, éventuellement, la vérification locale du comportement).

L’utilisation, même courante, des schémas d’intégration explicites semble donc très séduisante au vu du temps CPU qui reste maîtrisé. Il faut cependant tempérer cet optimisme en gardant bien à l’esprit que l’on se prive du garde-fou qu’est la vérification précise de l’équilibre et que, par conséquent, la qualité de la solution explicite obtenue doit être analysée avec plus de précautions. L’algorithme explicite ne divergera pas (si l’on respecte la condition de stabilité de Courant), mais la solution obtenue n’est pas garantie par un critère de vérification de l’équilibre. En particulier une étude paramétrique sur le pas de temps est indispensable car l’allure de la solution peut varier fortement au fur et à mesure du transitoire.

De plus, code_aster n’est pas un code optimisé pour les calculs explicites et ses performances en explicite sont modestes, comparées aux codes spécialisés comme Europlexus [bib2].

5.1. Réduction de modèle et condensation dynamique par sous-structuration

Une solution pour diminuer le temps de calcul est de projeter le problème sur une base réduite (base modale ou base de Ritz). On diminue alors grandement le nombre de degrés de liberté et ce type d’approche est disponible dans DYNA_NON_LINE (la résolution gagne aussi à être explicite car la condition de stabilité de Courant sur base modale réduite est peu pénalisante, puisque cette base possède une fréquence de coupure basse). Pour résumer, ce type d’approche est particulièrement adaptée aux problèmes où les non-linéarités restent modérées et localisées. Dès que les non-linéarités deviennent fortes, on peut se poser la question de la réactualisation de la base réduite initiale qui perd de sa cohérence avec la solution courante. Le surcoût de calcul dû au recalcul de la base et aux reprojections vient alors diminuer l’intérêt de ce type de méthode. Le mot-clé facteur PROJ_MODAL permet de faire ce type de calcul avec un schéma d’intégration explicite, les degrés de liberté étant généralisés. Un exemple de calcul est fourni par le cas-test SDNV107a [V5.03.107]. Un autre exemple de calcul dynamique non linéaire sur un problème hydromécanique d’une colonne de sol est fourni par le cas-test WDNP101a [V5.03.107].

On préconise aussi d’utiliser cette démarche réduction /condensation de manière « mixte », pour des problèmes « basses fréquences », où le modèle est constitué de plusieurs sous-domaines en condensant la résolution des sous-domaines de comportement linéaire sur les degrés de liberté de leurs interfaces avec des sous-domaines de comportement non linéaire, traités eux en éléments finis. Chacun de ces sous-domaines linéaires est condensé sur un macro-élément dynamique MACR_ELEM_DYNA [U4.65.01] défini sur chaque interface. Au moyen de l’opérateur - [U4.63.33] après résolution du problème global « mixte » on peut reconstituer les champs dans chaque sous-domaine. Un exemple de calcul dynamique non linéaire par réduction /condensation est fourni par le cas-test FORMA12g [V2.08.012] avec un schéma d’intégration implicite. La méthodologie est présentée en détail dans [U2.07.04].

5.2. Parallélisme

Le parallélisme peut apporter un gain d’autant plus notable que le système à résoudre comportera un grand nombre de DDL et que le nombre de pas de temps sera faible. En effet, l’algorithme de résolution impose des communications importantes à chaque pas (on n’est pas dans une stratégie de type multi-domaine en temps et en espace). En pratique, sur des problèmes comportant quelques centaines de milliers de DDL, le speed-up reste bon jusque 16 à 32 processeurs. Dans la plupart des cas, le solveur itératif PETSC apportera un gain comparativement au solveur MUMPS. En plus du parallélisme au niveau solveur, le parallélisme des étapes élémentaires (résolution du comportement aux points de Gauss) apportera un gain supplémentaire important si l’intégration comportement est coûteuse. Dans tous les cas, il est très utile de consulter dans le fichier de message .mess les mesures de temps CPU par étape, ce qui permet d’identifier les étapes les plus coûteuse de la résolution transitoire pour adapter le parallélisme en conséquence. La documentation [U2.08.06] donne tous les détails pour l’utilisation du parallélisme.