Assistance #227
Stabilisation membrane
Description
Après déploiement du mon fuseau BSO en RD l'incrément de calcul se prolonge avec un calcul statique (voir Assistance #226). J'active alors la stabilisation de membrane.
Même en finissant le calcul RD en visqueux avec une précision élevée et en choisissant une stabilisation forte (0.5) le calcul statique diverge.
Est-ce ce calcul particulier avec une seule rangée d'éléments et bloquées latéralement (Y=0) qui pose problème ?
Fichiers
Mis à jour par Gérard Rio il y a plus de 4 ans
- Statut changé de Nouveau à En cours
- % réalisé changé de 0 à 20
Bonjour Frank,
Je ne suis pas sûr de mon analyse néanmoins en voici des éléments à la suite de plusieurs essais:
- tout d'abord en désactivant les éléments bielle, la convergence est immédiate ! donc a priori le pb vient des éléments bielles ou de leur action,
- lorsqu'il y a non convergence, l'incrément de déplacement à chaque itération de Newton est de l'ordre de 1.e-6 à 1.e-5, ce qui est petit
- si je modifie les données concernant ces éléments:
1) pas de variation de section -> pas de changement
2) une raideur 10 fois plus petite -> convergence en 1 itération
2) une raideur 10 fois plus grande -> un incrément de déplacement en Newton qui devient très grand => divergence franche, on remarque également une convergence beaucoup plus difficile en RD
En regardant l'évolution de la déformée à chaque itération de Newton, pour la divergence franche, on voit apparaitre une sorte de flambage des bords de la structure du coup une explication serait peut-être qu'il y a une compétition entre les éléments de membrane et bielle. Les membranes sont stabilisées pour un mouvement hors plan, les bielles lorsqu'elles entrent en compression ont tendance à imposer un mouvement hors plan. Du coup si les bielles sont les plus fortes, c'est elles qui imposent la déformée. Et peut-être que dans ce cas, les conditions limites associées font que le système devient instable, d'où une non-convergence ...
Bilan: ???
- 1) une précision de 1.e-4 en implicite n'est peut-être pas nécessaire, il suffit que l'on ait une itération (ou 2) avec une précision de 1.e-3, compte tenu des incréments de déplacement constaté à chaque itération de Newton: 1.e-6 à 1.e-5
- 2) tu pourrais peut-être essayer une loi 1D qui est quasi nulle en compression, ce qui est le cas des bords ?
- 3) pour l'instant, j'ai l'impression que le comportement numérique est logique (pas de bug), mais on n'est jamais totalement sûr !!
Mis à jour par Frank Petitjean il y a plus de 4 ans
Merci Gérard pour cette analyse et tes retours.
Mon maillage étant simple je n'avais pas du tout incriminé les bielles mais je comprends maintenant qu'elles peuvent poser problème. Maintenant que tu as déceler la cause de l'instabilité je vais pouvoir creuser davantage...
Frank
Mis à jour par Frank Petitjean il y a plus de 4 ans
Ce cas résiste toujours...
Avec des bielles de raideur /10 le calcul statique converge mais à la condition de conserver la même précision de convergence que le cas RD qui précède. Sinon le calcul statique diverge très vite.
Avec la raideur bielle initiale le calcul statique ne converge pas, sauf à dégrader la précision de convergence mais est-ce sensé ?
J'ai introduit un critère plis pour les bielles pour éviter une éventuelle compression mais cela ne change rien. De toute façon après déploiement de la structure les bielles sont toutes tendues. Je ne vois pas pourquoi les itérations d'équilibre introduiraient de la compression...
Y a t-il un problème de fond avec les bielles que l'on ne voit pas ? Je vais ajouter une seule bielle au cas du coussin de Hugo qui fonctionne bien.
A suivre...
Mis à jour par Frank Petitjean il y a plus de 4 ans
- Fichier maillage.her maillage.her ajouté
- Fichier modele.CVisu modele.CVisu ajouté
- Fichier modele.info modele.info ajouté
Ajout des fichiers tests
Mis à jour par Anonyme il y a plus de 4 ans
- Fichier modele.info modele.info ajouté
- Fichier mesh1.png mesh1.png ajouté
- Fichier mesh2.png mesh2.png ajouté
Bonjour Frank,
il me semble que tu as oublié de rajouter un peu d'élasticité (sans loi plis dans la phase de l'implicite).
Lorsqu'il y a des plis dans ta structure, tu passes localement d'un comportement 2D à 1D!! Une direction est très raide (la direction du pli) alors que la direction transverse à celle du pli est nulle. C'est la présence de ces plis qui cause une non-convergence en implicite par défaut pour deux raisons:
1- La direction des plis évolue à chaque itération (même si c'est parfois très faible entre 2 itérations il y a une légère variation): --> Solution proposée: on fixe la direction des plis dans cette ce qui permet d'éviter ce problème (c'est que tu as fait donc pour ce point c'est ok dans ton .info)
2- Présence de plis ==> Raideur dans la direction du pli très nettement supérieur à la direction transverse : --> Solution proposée: on utilise une loi des mélanges qui combine modèle plis + loi élastique "classique". Par conséquent, il faut piloter ce mélange ... Lorsque l'on est en RD Il faut juste le modèle plis, car la moindre élasticité introduite dans la loi de comportement va directement se traduire par des plis dans ta structure et donc tu peux avoir un équilibre global très différent entre le modèle plis seul et une loi des mélanges plis(95/%) /+ élastique (5/%).
Dans ton .info, la loi de comportement est uniquement piloter par une fonction 1D qui permet de choisir la loi élastique ou le modèle plis (f_ponderation dans le .info). Donc de cette façon, tu vas introduire des contraintes de compression qui vont perturber l'équilibre global du calcul. En revanche si tu utilises une fonction nD ce type:
f_melange_plis_elas_pour_implicite FONCTION_EXPRESSION_LITTERALE_nD
un_argument= algo_global_actuel un_argument= temps_courant
fct= (temps_courant <= 1.) ? 1 : (algo_global_actuel > 7) ? 0 : 0.001
fin_parametres_fonction_expression_litterale_
Dans ce cas, tu rajoutes un peu de compression en implicite à la fin, mais si cette proportion est suffisamment faible l'équilibre local sera très faiblement impacté !!
Mais tu auras une forme de ballon équivalente à un calcul RD+ modèle plis seul !!
Bon maintenant cela ne règle pas le problème des bielles ...
Mais il me semble avoir trouvé le problème... Si tu regardes les images mesh1.png et mesh2.png tu peux voir que les références E_biel_bord1 et E_biel_centre sont situées au même endroit ! J'ai donc regardé ton maillage et il y a des éléments superposés (je pense que c'est dans la manière de faire les maillages avec Ohmer ??). Maintenant quand tu regardes ton .info, la référence E_biel_centre correspond à une loi_rien_1D ce qui en implicite peut avoir des conséquences!! J'ai donc utilisé une loi de comportement équivalente entre E_biel_centre et E_biel_bord1 et la convergence est quasi-immédiate (4 itérations).
Est-ce que cette superposition est normale ?
Mis à jour par Frank Petitjean il y a plus de 4 ans
Bonjour Hugo,
Tu avais déjà évoqué dans tes calculs de coussin le besoin de conserver un peu d'élasticité avec le critère pli. Je n'ai pas repris tes recommandations pour le BSO et c'était une erreur ! L'ajout de 0.1% d'élasticité, et seulement pour le calcul statique, me parait parfaitement acceptable d'un point de vu mécanique. Cette faible rigidité en compression permet maintenant calcul implicite. A voir quand même avec un maillage plus fin...
Je compte quand même comparer les résultats dans les 2 cas de calcul :
1 RD seul
2 RD + implicite avec élasticité
La présence des éléments bielles doubles sur l'un des bords est, comme tu l'as supposé, un artefact de la mise en donnée Omher. Certains ballons ont un ruban d'assemblage au centre du fuseau (les BSO SF par exemple). Ces rubans sont modélisé par des éléments bielles situés centre du fuseau. A l'utilisateur de définir un maillage adéquat avec un nombre d'éléments quadrangles pair dans la largeur. Par souci de simplicité de la programmation de l'algo de maillage génère toujours ces éléments. Ils ne sont rendus "actifs", c'est à dire affecté d'une loi autre que RIEN1D, que si leurs propriétés méca sont définies dans l'interface. La présence de ces éléments avec une loi RIEN1D passe en RD mais pas en implicite. Je n'avais pas soupsonner ce problème et donc pas fait cette vérification. Je vais d'un pas décidé les supprimer dans mes scrips. Pour autant je ne comprends pas pourquoi ces éléments génèrent de l'instabilité puisque les nœuds concernés sont, de toute façon, en relation avec des éléments membrane qui ont une rigidité non nulle.
Merci Hugo, ton intervention a permis de débloquer ce problème. Je reviendrai très vite vers toi dès les prochains :-)
Frank
Mis à jour par Gérard Rio il y a plus de 4 ans
oui, moi aussi je ne comprends pas pourquoi les éléments avec une loi rien induisent des pb. Cela n'est pas normal pour les raisons évoquées par Frank.
Bon... il faudra que je creuse un peu dès que j'ai un moment !
Mis à jour par Gérard Rio il y a plus de 4 ans
- % réalisé changé de 20 à 50
Bonjour,
après quelques recherche j'ai introduit des modifs ...
Jusqu'à présent, l'utilisation d'une loi rien, influençait uniquement la partie loi de comportement, le reste du calcul se déroulant habituellement. L'idée était par exemple que l'on puisse quand même effectuer des calculs relatifs aux intégrales, même pour des éléments avec une loi rien.
Comme la contrainte et variation étaient nulles, cela n'influençait pas le résultat.
Mais... j'avais oublié quelques points !!
1) pour les éléments biel, la section des éléments avec loi rien, était mise à jour et celle-ci était calculée avec l'incrément de contrainte qui pour la loi rien = 0 => donc inutile -> j'ai donc modifié et simplifié cette partie
2) pour les membranes et coques SFE avec loi rien, idem au niveau de la variation d'épaisseur
3) pour le calcul du résidu et de la raideur, j'ai également modifié et simplifié en tenant compte de l'existence d'une loi rien
ceci étant, cela ne change pas normalement le résultat coté raideur et résidu ... mais à tester.
@suivre
Mis à jour par Frank Petitjean il y a plus de 4 ans
Cela me parait bien que l'on puisse conserver ces éléments avec des lois rien en implicite.
J'attends donc la prochaine version avant de faire éventuellement des modifs un peu lourdes dans mes scripts...
Mis à jour par Frank Petitjean il y a plus de 4 ans
Bonjour Gérard,
J'ai relancé un calcul BSO en conservant la loi rien pour certains éléments biel superposés à d'autres éléments et cela fonctionne maintenant. Tu peux fermer le ticket.
Merci
Mis à jour par Gérard Rio il y a plus de 4 ans
- Statut changé de En cours à Résolu
- % réalisé changé de 50 à 100