Autor
|
Thema: Vernetzung von Kontaktpaaren in Abaqus (1348 mal gelesen)
|
Mini19 Mitglied
Beiträge: 12 Registriert: 21.09.2018
|
erstellt am: 21. Sep. 2018 11:23 <-- editieren / zitieren --> Unities abgeben:
Hallo, ich habe eine Frage bezüglich der Vernetzung und Erstellung von *CONTACT PAIRs in Abaqus und deren Kontaktflächen. Laut Abaqus Manual sollte die Slave-Surface feiner vernetzt sein als die Master-Surface. Ich habe allerdings auch schon gehört das Kontaktpaare welche ein identisches Netz haben am besten (schnellsten und stabilsten) rechnen, da die Knoten ja dadurch zu Beginn der Simulation genau aufeinander liegen. Ich habe versucht das mal in einer kleinen Simulation zu testen, konnte aber keinen wirklichen Performance-Unterschied feststellen. Gibt es hier Jemanden der damit Erfahrungen gemacht hat? Es kommt wahrscheinlich auch ganz auf den Lastfall und die Modellgeometrie an, es geht im vorliegenden Fall um einen statischen Lastfall. Meine Kontakte sind folgendermaßen definiert: *CONTACT PAIR, INTERACTION = Fric, TYPE = SURFACE TO SURFACE, ADJUST = 0.2 Surf_1, Surf_2 *SURFACE INTERACTION, NAME = Fric *FRICTION 0.2, Es wäre nett wenn mir diesbezüglich jemand weiterhelfen könnte. Viele Grüße Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Mustaine Ehrenmitglied V.I.P. h.c.
Beiträge: 3554 Registriert: 04.08.2005 Abaqus
|
erstellt am: 21. Sep. 2018 14:40 <-- editieren / zitieren --> Unities abgeben: Nur für Mini19
Zwei Dinge gilt es zu unterscheiden: 1. Die Oberflächen liegen sauber aufeinander. Der Spalt ist also null. 2. Die Knotenpositionen sind zusätzlich identisch. Die Knoten liegen also genau aufeinander. Der Punkt 1 ist sinnvoll und effektiv. Dafür gibt es die adjust-Option. Mit direkt sauber geschlossenen Kontakten, ist in der Regel zu Beginn die Konvergenz viel besser und die Gefahr von Singularitäten geringer.
Punkt 2 ist nicht wirklich relevant. Speziell mit der neueren Surface-to-Surface Option und dem General Contact, ist das kein Thema mehr. Man sollte natürlich weiterhin hinterfragen, ob das Netz auf beiden Seiten fein genug ist, um realistisches Verhalten und Ergebnisse zu bekommen. Ebenso sollte eine stark deformierende Region Slave und nochmal feiner vernetzt sein. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Mini19 Mitglied
Beiträge: 12 Registriert: 21.09.2018
|
erstellt am: 21. Sep. 2018 15:09 <-- editieren / zitieren --> Unities abgeben:
Danke für die Erklärung, die Oberflächen liegen aufgrund der CAD-Geometrie nicht überall perfekt aufeinander, das Problem sollte ja durch den Adjust Parameter gelöst werden. Bezüglich General Contact würde ich gerne eine Frage nachschieben: Ich habe diesen entfernt und alle möglichen Kontaktpaare über *CONTACT PAIR definiert, weil ich davon ausgegangen bin, dass dadurch die Rechnung beschleunigt wird, ist das richtig? Abaqus müsste ja dann nicht immer alle Außenflächen auf Durchdringungen überprüfen oder? Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Mustaine Ehrenmitglied V.I.P. h.c.
Beiträge: 3554 Registriert: 04.08.2005 Abaqus
|
erstellt am: 21. Sep. 2018 15:45 <-- editieren / zitieren --> Unities abgeben: Nur für Mini19
Dein Gedanke ist korrekt. Bei A/Standard ist es immer die Abwägung zwischen Aufwand im Preprocessing und Aufwand im Solver. Bei General Contact hat man meist nicht viel zu definieren, dafür braucht der Solver etwas länger. Man kann mit Paarungen also ggf. Rechenzeit sparen. Außerdem kann man überlegen, ob man in Paarungen ohne nennenswerte Relativbewegungen Small Sliding aktiviert. In A/Explicit ist der Kontakt deutlich weniger rechenaufwändig, so dass es kaum Gründe gibt nicht General Contact zu verwenden.
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Mini19 Mitglied
Beiträge: 12 Registriert: 21.09.2018
|
erstellt am: 27. Sep. 2018 22:34 <-- editieren / zitieren --> Unities abgeben:
Danke für deine Antwort. Eine Frage hätte ich noch bezüglich Small / Finite Sliding: Ich weiß das beim Small Sliding für jeden Slave Knoten über ausgewählte Knoten der Master-Surface eine Kontakt-Ebene erstellt wird mit der der entsprechende Knoten während der Simulation interagieren kann, das heißt das Ganze funktioniert nur in diesem ursprünglichen Gebiet gut, sobald die Relativbewegungen zu groß werden, wird die Rechnung ungenau. Jetzt habe ich zwei Simulationen gestartet, um zu testen wie groß der Unterschied zwischen Small und Finite Sliding in meinem Modell ist. Einmal sind alle *CONTACT PAIRs SMALL SLIDING, einmal alle FINITE SLIDING (erstmal ohne dabei zu beachten bei welchen Kontaktpaarungen das eventuell Sinn macht oder nicht). Die Rechnung mit Small Sliding Definitionen rechnet dabei aber grundsätzlich länger, hat früher Increment Cutbacks und mehr SEVERE DISCON ITERS. Ich hätte erwartet das die Rechnung schneller und stabiler läuft, genau das tut sie jedoch nicht, hat jemand eine Idee woran das liegen könnte? Gibt es für Small Sliding Anwendungsfälle in denen nicht nur das Ergebnis ungenau wird sondern auch der Rechenaufwand steigt? Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Mustaine Ehrenmitglied V.I.P. h.c.
Beiträge: 3554 Registriert: 04.08.2005 Abaqus
|
erstellt am: 02. Okt. 2018 11:54 <-- editieren / zitieren --> Unities abgeben: Nur für Mini19
Es ist zwar ungewöhnlich, aber ich denke es kann schon Situationen geben, wo Small Sliding langsamer ist, da es schlechter konvergiert. Wenn z.B. durch die künstlichen Kontaktebenen weniger Knoten im Kontakt sind, müssen diese höhere Kräfte übertragen, was es für den Solver schwieriger macht. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
schleckschling Mitglied M.Eng. - Simulation Engineer
Beiträge: 52 Registriert: 19.04.2004
|
erstellt am: 18. Okt. 2018 12:50 <-- editieren / zitieren --> Unities abgeben: Nur für Mini19
Hi, SMALL SLIDING konvergiert grundsätzlich etwas langsamer, da als Kontaktalgorithmus "DIRECT" definiert ist -> dies ist ein harter Kontakt, bei dem keine Durchdringungen der Kontaktflächen zulässig sind. Bei FINITE SLIDING ist als Standard der "PENALTY" Kontaktalgorithmus eingestellt. Hier können sich die Flächen minimal durchdringen. Der Kontakt ist "weicher"; die Steifigkeit berechnet sich aus der Hintergrundsteifigkeit im Kontaktbereich. Die Wahl des Kontaktalgorithmus kann mittels *SURFACE BEHAVIOR beeinflusst werden. Gruß Frank Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |