6Optimisation des performances. Code_Aster Méthodes de résolution transitoires
Code_Aster
Titre :
Utilisation de méthodes de résolution transitoires[...]
Responsable :
Nicolas GREFFET
Version default
Date :
12/05/2009
Page :
12/13
Clé :
U2.04.07
Révision :
1349
6Optimisation des performances
Dans la plupart des cas il est recommandé de mener le calcul en quasi-statique lorsque les nonlinéarités sont modérées, puis, dès que le nombre d’itération à convergence pour l’équilibre augmente significativement, de basculer en dynamique (implicite, puis explicite si besoin est). Plus précisément on conseille de basculer avant l’apparition de fortes non-linéarités, de manière à ce que le calcul dynamique s’initie sur une évolution encore assez «régulière ».
En quasi-statique, 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 de CONVERGENCE. 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). Dans le cas d’un calcul quasi-statique où la non-linéarité va en croissant avec le temps, on peut donc trouver un point de croisement, au niveau du temps CPU, pour lequel l’efficacité des méthodes explicites (voire implicite suivant les cas) devient plus grande que de continuer en quasistatique. Le gain apporté par un pas de temps plus grand en quasi-statique est annulé par la nécessité de faire de plus en plus d’itérations à chaque pas. De même, le coût de calcul en explicite restant constant, on peut aussi évaluer assez précisément le temps de calcul total nécessaire à la résolution du cas complet, alors qu’en quasi-statique, le nombre d’itérations à chaque pas étant très variable et pouvant aussi entraîner un nombre inconnu de subdivision du pas, le temps de calcul total est parfois très difficile à prédire.
L’utilisation, même courante, des méthodes 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 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 lorsque ce pas devient trop grand.
Cette obligation de contrôle de la solution explicite est d’autant plus grande que l’on cherche en plus à vérifier l’hypothèse fondamentale d’évolution lente.
Manuel d'utilisation Fascicule u2.04 : Mécanique non linéaire
Copyright 2015 EDF R&D - Document diffusé sous licence GNU FDL (http://www.gnu.org/copyleft/fdl.html)

Öffentlicher Link aktualisiert
Der öffentliche Link zu Ihrem Chat wurde aktualisiert.