Définition d’un problème adapté à la dynamique transitoire ========================================================== Dans ce chapitre, nous allons proposer des conseils pour la mise au point de la modélisation d’un problème de mécanique dont on souhaite faire la simulation numérique transitoire non linéaire avec *Code_Aster*. Le chapitre suivant traitera de la discrétisation en espace et en temps, alors que dans ce chapitre seul le modèle continu sera abordé. Les non-linéarités en dynamique transitoire avec DYNA_NON_LINE sont : * les grands déplacements et grandes transformations, * les relations constitutives non linéaires (plasticité, endommagement, viscoplasticité...), * les non-linéarités d'interface : contact-frottant, collisions... Modèle ------ La première étape est la définition d’un modèle cohérent avec l’hypothèse d’évolution transitoire. Ainsi, tout système mécanique ne devant pas avoir de mode à énergie cinétique nulle, il convient de s’assurer que la masse volumique est définie en tout point du modèle continu. De même, si l’on veut introduire des éléments discrets pour simuler des corps solides, il faut leur associer une masse. De même, pour les éléments finis de type coques ou plaques, l’utilisateur peut avoir à s’assurer que tous les degrés de liberté, en particulier les rotations, ont un terme de masse associé. Pour vérifier cette condition, on conseille de spécifier l’option INER_ROTA='OUI' lors de l’appel à la commande [:ref:`AFFE_CARA_ELEM `] pour tous les modèles COQUE. Certaines modélisations n’ayant pas de matrice de masse (ce calcul n’a pas été programmé) ne peuvent être utilisées directement avec DYNA_NON_LINE, comme les modèles non locaux. Cette difficulté peut être contournée en leur superposant un modèle classique permettant de représenter l’énergie cinétique (matrice de masse) : les deux modèles s’appuyant sur les mêmes nœuds. L’usage de certains artifices courants en quasistatique, comme des zones très raides (matériau fictif ayant un très grand module de Young) pour tenir compte de renforts que l’on ne souhaite pas représenter finement géométriquement, par exemple, peut engendrer des perturbations en dynamique. En effet, ce matériau très raide peut générer des oscillations hautes fréquences et des propagations d’ondes dont la célérité est non physique. De plus, avec un schéma en temps explicite, ces zones très raides risquent de faire chuter la valeur du pas de temps critique (condition de stabilité CFL, cf. [:ref:`R5.05.05 `]). En plus de la contribution inertielle, le système aura une contribution dissipative, donc amortissante. En non linéaire, de la dissipation peut être due à la relation de comportement (plasticité…), au frottement dans les liaisons … Habituellement, la méconnaissance détaillée de tous les mécanismes dissipatifs dans le système est compensée par une représentation simplifiée qui permet de définir un amortissement global. Dans *Code_Aster*, on dispose de deux modèles d’amortissement visqueux globaux (que l’on peut associer dans la modélisation à des amortisseurs sur des éléments discrets, cf. commande [:ref:`AFFE_CARA_ELEM `] (mot-clé facteur DISCRET ou DISCRET_2D, etc...) : le modèle de Rayleigh et l’amortissement modal. En pratique, dans les deux cas, il est indispensable d’avoir effectué un calcul modal préalable. En effet, l’amortissement modal est défini sur les modes qui sont alors des arguments de DYNA_NON_LINE. Pour l’amortissement de Rayleigh, la seule manière d’appréhender simplement son sens physique, c’est de le recaler sur des valeurs d’amortissement modal (qui peuvent venir de résultats expérimentaux). Nous reviendrons plus en détail sur l’amortissement de Rayleigh dans le chapitre suivant :ref:`u2.06.13-Discretisation_du_probleme_continu`. D’une manière générale, il faut garder à l’esprit que tous les modèles d’amortissement global ont été conçus pour les cas linéaires et qu’ils servent alors à prendre en compte certains phénomènes dissipatifs comme le frottement ou des liaisons imparfaites. Donc, si on rajoute au modèle la prise en compte de ces non-linéarités, alors qu’on garde les valeurs d’amortissement global recalées sur une approche linéaire, cela peut conduire à avoir trop de dissipation dans le système non linéaire en particulier en basses fréquences. Idéalement, la prise en compte de toutes les non-linéarités, associée à une discrétisation fine du système, devrait permettre de ne pas avoir à utiliser en plus un amortissement global forfaitaire. Dans la réalité, on est obligé de négliger certains aspects non linéaires pour des raisons de coût CPU et/ou de méconnaissance sur les mécanismes mis en œuvre, et dans ce cas, l’amortissement global a son rôle à jouer. La documentation [:ref:`U2.06.03 `] présente plus en détails son usage. Conditions aux limites et excitations -------------------------------------- La première décision à prendre pour résoudre le transitoire est le choix du référentiel de configuration (le champ de déplacements) : le cas général est un référentiel galiléen (repère absolu). Dans des cas fréquents où le système est entraîné dans un mouvement de translation rigide, on pourra résoudre le transitoire en référentiel relatif. Le calcul se fera en base encastrée, voir :ref:`u2.06.13-Mono_appui`. Si le système est sollicité par divers appuis excités différemment, on est dans le cas :ref:`u2.06.13-Multi_appuis` et on devra résoudre le transitoire en référentiel absolu (sauf si le comportement est totalement en HPP élastique linéaire). En quasistatique, il est courant d’imposer des conditions aux limites dont les évolutions en temps sont des fonctions simples à définir, comme des rampes ou des fonctions continues affines par morceaux. Il est fréquent qu'en dynamique les excitations soient décrites par le produit d'une fonction de l'espace et d'une rampe ou fonction du temps (ou signal en temps). On utilisera ainsi le mot-clé facteur : EXCIT. Il est recommandé de définir ce signal en temps de sorte de partir et de finir à zéro. Il peut être utile aussi que la liste d'instants choisie pour le transitoire avec DYNA_NON_LINE dure plus longtemps que le signal immposé de sorte de laisser le système étudié revenir au repos par effet de l'amortissement qui a été choisi. En dynamique, si l’on veut éviter les oscillations parasites de la solution, il faut absolument imposer des quantités suffisamment régulières en temps : donc au moins continûment dérivables, par morceaux. Pour arriver à cela simplement, on peut choisir de se définir des fonctions du temps polynomiales à la place des fonctions affines. D’éventuelles irrégularités dans les chargements imposés peuvent être partiellement compensées par l’utilisation d’un modèle d’amortissement adapté (ou en particulier grâce à un schéma d’intégration en temps dissipatif de type HHT, voir :ref:`u2.06.13-Schema_integration_temps`). Néanmoins, des oscillations excessives en non linéaire peuvent compromettre irrémédiablement la suite des calculs car la solution (dont les variables internes) dépend de son historique. Sur le schéma :ref:`u2.06.13-lissage` on montre une régularisation possible d’un courbe affine (en pointillés) par une courbe adaptée au calcul dynamique. On peut noter la nécessité, sur cet exemple, de devoir faire commencer l’évolution dynamique en un temps négatif, si l’on veut garder des valeurs comparables pour les instants positifs (en dehors des zones de régularisation). .. figure:: images/Shape1.gif :name: u2.06.13-lissage Lissage d’une évolution imposée pour l’adapter à un calcul transitoire Dans tous les cas où l’on peut calculer le spectre des signaux imposés, la règle de Shannon pour définir l’échantillonnage n’est pas assez stricte pour les calculs non linéaires. En pratique, on conseille d’avoir entre 4 et 10 pas de temps sur la période la plus courte de tous les signaux imposés. Toute discrétisation insuffisante en temps risque de se traduire par des sur-oscillations hautes fréquences de la solution. Il existe alors un palliatif à cela en choisissant certains schémas en temps, mais au risque d’introduire trop d’amortissement dans le système. .. _u2.06.13-Mono_appui: Mono-appui ~~~~~~~~~~ Les chargements de type mono-appui (entraînement par un mouvement de translation rigide), qui sont couramment employés lors des calculs sismiques, se caractérisent par des particularités qu'il convient de rappeler ici. Tout d'abord, la résolution, selon l'hypothèse mono-appui, se fait nativement dans le repère relatif lié au support (radier...). En post-traitement, il faut donc recombiner avec le mouvement d'entraînement pour obtenir les champs cinématiques absolus. Pour l'accélération, c'est en général immédiat car l'accélération d'entraînement est la donnée d'entrée connue sous la forme des accélérogrammes employés. En revanche, pour reconstruire le déplacement absolu, il faut disposer du déplacement d'entraînement. Dans le cas classique où l'on ne dispose que d'accélérogrammes, on est obligé d'intégrer deux fois en temps pour calculer le déplacement correspondant (cette intégration peut se faire avec l'opérateur [:ref:`CALC_FONCTION `], mot-clé INTEGRE). L'utilisateur doit alors être très attentif aux problèmes de l'intégration numérique de signaux échantillonnés tels des constantes d'intégration qui peuvent induire de la dérive ou des oscillations à très basse fréquence. L'opérateur [:ref:`CALC_FONCTION `] dispose d'options pour corriger ces dérives (mot-clé CORR_DEPL et ``CORR_ACCE``), mais on recommande très fortement de bien contrôler la qualité du résultat intégré final car, dans certains cas, ces corrections sont insuffisantes, y compris la correction par filtrage passe‑haut de [:ref:`CALC_FONCTION `] (avec ``CORR_ACCE``, ``METHODE = 'FILTRAGE'``). Une correction spécifique complémentaire est alors indispensable. Le passage par la FFT pour faire l'intégration en fréquence peut alors constituer une bonne alternative permettant d'aboutir à des signaux intégrés plus corrects ou au moins plus faciles à corriger (juste un décalage d'une constante, par exemple, mais sans dérive). .. _u2.06.13-Multi_appuis: Multi-appuis ~~~~~~~~~~~~ Parmi les types de chargements qui peuvent demander une adaptation à DYNA_NON_LINE, on peut évoquer le cas du multi-appuis (en accélérations imposées sur les supports) pour les études sismiques. Cette méthode, originellement développée pour les calculs transitoires en hypothèse linéaire, repose sur la définition de modes statiques élastiques aux appuis. En non linéaire, tant que ces modes restent pertinents, c’est-à-dire que les non-linéarités sont suffisamment faibles pour ne pas demander leur réactualisation, l’approche multi-appuis usuelle reste acceptable. En revanche, dans le cas général, on doit remettre en cause l’utilisation de modes statiques élastiques calculés initialement. Dans ce cas, pour éviter leur usage, la sollicitation multi-appuis doit être prise en compte en imposant aux appuis les déplacements correspondants à l’intégration des accélérogrammes qui sont des données d’entrée de la méthode multi-appuis linéaire usuelle. La méthode est alors rigoureuse, quel que soit le type de non-linéarité, mais l’intégration des accélérogrammes doit être menée avec précaution, pour ne pas aboutir à des signaux incorrects. En dehors de l’échantillonnage, il est indispensable, entre autres, de vérifier l’absence de dérive du signal (une correction peut être faire avec l’option ``CORR_ACCE`` de [:ref:`CALC_FONCTION `]). Dans *Code_Aster* , on peut effectuer cette intégration facilement en se servant de la ``FFT`` qui est disponible dans [:ref:`CALC_FONCTION `]. C’est aussi l’occasion d’analyser le contenu fréquentiel du signal. On a alors la relation, dans le domaine fréquentiel: :math:`U=-A/{\omega}^{2}` . On peut aussi se servir de l’option ``INTEGRE`` de [:ref:`CALC_FONCTION `]. Pour plus d’informations sur la mise en œuvre des sollicitations de type mono ou multi-appuis, la lecture des documentations [:ref:`U2.06.09 `] et [:ref:`U2.06.10 `] est toute indiquée. Contact et collisions ~~~~~~~~~~~~~~~~~~~~~ Les chargements issus du contact par pénalisation peuvent aussi perturber la solution par des oscillations hautes fréquences, qui sont liées à la valeur du coefficient de pénalisation. Ces artefacts peuvent être réduits avec l'usage d'un schéma d'intégration en temps dissipatif en hautes fréquences. On peut également se doter d'une liste d'instants de calcul qui gère les difficultés par découpage, cf. la commande [:ref:`DEFI_LIST_INST `] avec le mot-clé facteur ``ECHEC= _F(EVENEMENT = 'DELTA_GRANDEUR', ...)``, de type « event-driven », en testant si l'incrément d'une composante d'un champ (de vitesse par exemple au point de contact) dépasse un seuil fixé. Si l’on veut utiliser un schéma d'intégration en temps explicite, un coefficient de pénalisation trop grand va entraîner une chute du pas de temps critique. Comparé à la statique, il peut s’avérer obligatoire de baisser le coefficient de pénalisation, avec l’inconvénient d’augmenter l’interpénétration des solides lors du contact. On pourra consulter les cas-test : * sdnv100, impact d'une poutre sur une paroi rigide [:ref:`V5.03.100 `], * sdnv105, balancement d'un bloc sur une table [:ref:`V5.03.105 `], * sdnv301, collision hertzienne de deux billes élastiques [:ref:`V5.03.301 `]. Remarque Pour les schémas en temps explicites ():ref:`u2.06.13-Schema_integration_temps`), si l’on impose des conditions aux limites en déplacement qui évoluent au cours du temps, il faut tenir compte du fait que ces conditions sont en fait imposées en accélération en explicite (car c’est l’inconnue primale). Cela signifie que l’on doit entrer dans DYNA_NON_LINE la dérivée seconde du signal en déplacement que l’on veut imposer. Cette évolution du déplacement imposé doit donc être dérivable au moins deux fois en temps Conditions initiales -------------------- Dans la même logique que pour les conditions aux limites, on recommande d’éviter les conditions initiales singulières, comme ce que peuvent générer des chargements imposés ayant des évolutions en temps de type Dirac ou Heaviside. On privilégiera les conditions régulières donc avec des dérivées (première et si possible seconde) en temps en :math:`{t}_{0}` nulles. Si l’on veut partir d’un état précontraint (non vierge), il est tout à fait possible et recommandé d’enchaîner un calcul dynamique à un calcul quasistatique. Dans ce cas, l’état initial (mot-clé facteur ETAT_INIT) doit être alors parfaitement équilibré (déplacements, contraintes, variables internes, efforts appliqués à cet instant) et, sous réserve de régularité dans les conditions imposées au moment du passage statique vers dynamique, l'excitation dynamique devant démarrer avec un signal nul, la solution transitoire ne devra pas présenter d’oscillations non physiques. Cette méthode d’enchaînement de la quasistatique vers la dynamique permet la prise en compte aisée de toutes les précharges, comme par exemple la pesanteur. Par exemple, dans une simulation de lâcher, avec un déplacement initial imposé non nul, alors il faut renseigner les contraintes et variables internes correspondant à cet instant. Si l’on avait voulu prendre en compte cet état initial précontraint avec uniquement une résolution dynamique, il aurait fallu introduire un fort amortissement initial et attendre que les oscillations se soient dissipées pour avoir l’état statique précontraint. Ensuite, on peut continuer le calcul avec l’amortissement physique. On est obligé de procéder ainsi lorsqu’on utilise un code de calcul qui ne traite pas la quasistatique non linéaire ( *cf.* Europlexus, voir [bib2]_). Dans certaines situations, on doit enchaîner une simlation en statique, avec des conditions aux limites bloquées puis en dynamique sous l'action d'un champ d'ondes incidentes avec des conditions aux limites de frontières absorbantes et libérées. On consultera [:ref:`U2.04.08`]. Lors de l’initialisation du schéma d’intégration pour le calcul transitoire non linéaire, on cherche donc à inverser la matrice de masse. Si elle est singulière, alors un message avertit l’utilisateur et on met arbitrairement l’accélération initiale à zéro. On peut craindre alors la présence d'oscillations parasites au début du transitoire ; on peut les réduire en adoptant un pas de temps plus petit au tout début du transitoire. D’une manière générale la non-inversibilité de la matrice de masse doit amener l’utilisateur à vérifier son modèle, sauf si c’est volontaire. Lors de poursuites, deux aspects sont sensibles. D’une part, il vaut mieux éviter d’avoir de trop brusques variations de pas de temps: la cohérence de la solution au passage de la poursuite en serait affectée. Un fort changement de pas de temps peut être vu comme un filtre. Un grand pas de temps constitue un filtre passe-bas d’une solution initialement calculée avec un pas de temps fin. D’autre part, si l’on veut changer de type de schéma en temps, certaines règles sont à respecter. Si l’on veut passer d’une méthode d'intégration temporelle implicite (quasistatique ou dynamique) à un schéma explicite, la poursuite sera mathématiquement valide car l’état initial sera équilibré (au résidu près). En revanche, la bascule inverse directe introduit une erreur car l’état initial, venant d’un calcul explicite, ne respectera pas l’équilibre au sens implicite. En effet, cet opérateur va chercher à revérifier l’équilibre: on résout l’équilibre en inversant la matrice de masse, ce qui donne l’accélération initiale. Si ce champ est non nul, cela traduit la non-vérification, au sens statique, de l’équilibre, à l’instant initial. En pratique, cette imprécision peut engendrer des oscillations de la solution (phénomène d'overshooting). D’une manière plus subtile, la bascule du :math:`\theta` -schéma vers un schéma du second ordre comme l’accélération moyenne ``NEWMARK`` ou ``HHT`` complet va introduire une petite erreur sur les termes d’accélération, ce qui peut perturber la solution numérique. Si, malgré tout, on veut faire ces bascules qui induisent des erreurs, on peut minimiser les imprécisions en choisissant de faire ces bascules lors de phases où l'excitation donc la solution évolue peu. En résumé : .. csv-table:: Enchaînements de calculs transitoires :header: "Origine", "Destination", "Possible" STAT_NON_LINE, DYNA_NON_LINE, oui DYNA_NON_LINE avec schéma en temps implicite, DYNA_NON_LINE, oui DYNA_NON_LINE avec schéma en temps explicite, DYNA_NON_LINE avec schéma en temps explicite, oui DYNA_NON_LINE avec schéma en temps explicite, DYNA_NON_LINE avec schéma en temps implicite, non