Hot News:

Mit Unterstützung durch:

  Foren auf CAD.de (alle Foren)
  SIMULIA/ABAQUS
  Vernetzung von Kontaktpaaren in Abaqus

Antwort erstellen  Neues Thema erstellen
CAD.de Login | Logout | Profil | Profil bearbeiten | Registrieren | Voreinstellungen | Hilfe | Suchen

Anzeige:

Darstellung des Themas zum Ausdrucken. Bitte dann die Druckfunktion des Browsers verwenden. | Suche nach Beiträgen nächster neuer Beitrag | nächster älterer Beitrag
Autor Thema:  Vernetzung von Kontaktpaaren in Abaqus (1348 mal gelesen)
Mini19
Mitglied



Sehen Sie sich das Profil von Mini19 an!   Senden Sie eine Private Message an Mini19  Schreiben Sie einen Gästebucheintrag für Mini19

Beiträge: 12
Registriert: 21.09.2018

erstellt am: 21. Sep. 2018 11:23    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

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.



Sehen Sie sich das Profil von Mustaine an!   Senden Sie eine Private Message an Mustaine  Schreiben Sie einen Gästebucheintrag für Mustaine

Beiträge: 3554
Registriert: 04.08.2005

Abaqus

erstellt am: 21. Sep. 2018 14:40    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Mini19 10 Unities + Antwort hilfreich

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



Sehen Sie sich das Profil von Mini19 an!   Senden Sie eine Private Message an Mini19  Schreiben Sie einen Gästebucheintrag für Mini19

Beiträge: 12
Registriert: 21.09.2018

erstellt am: 21. Sep. 2018 15:09    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

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.



Sehen Sie sich das Profil von Mustaine an!   Senden Sie eine Private Message an Mustaine  Schreiben Sie einen Gästebucheintrag für Mustaine

Beiträge: 3554
Registriert: 04.08.2005

Abaqus

erstellt am: 21. Sep. 2018 15:45    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Mini19 10 Unities + Antwort hilfreich

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



Sehen Sie sich das Profil von Mini19 an!   Senden Sie eine Private Message an Mini19  Schreiben Sie einen Gästebucheintrag für Mini19

Beiträge: 12
Registriert: 21.09.2018

erstellt am: 27. Sep. 2018 22:34    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

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.



Sehen Sie sich das Profil von Mustaine an!   Senden Sie eine Private Message an Mustaine  Schreiben Sie einen Gästebucheintrag für Mustaine

Beiträge: 3554
Registriert: 04.08.2005

Abaqus

erstellt am: 02. Okt. 2018 11:54    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Mini19 10 Unities + Antwort hilfreich

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


Sehen Sie sich das Profil von schleckschling an!   Senden Sie eine Private Message an schleckschling  Schreiben Sie einen Gästebucheintrag für schleckschling

Beiträge: 52
Registriert: 19.04.2004

erstellt am: 18. Okt. 2018 12:50    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Mini19 10 Unities + Antwort hilfreich

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

Anzeige.:

Anzeige: (Infos zum Werbeplatz >>)

Darstellung des Themas zum Ausdrucken. Bitte dann die Druckfunktion des Browsers verwenden. | Suche nach Beiträgen

nächster neuerer Beitrag | nächster älterer Beitrag
Antwort erstellen


Diesen Beitrag mit Lesezeichen versehen ... | Nach anderen Beiträgen suchen | CAD.de-Newsletter

Administrative Optionen: Beitrag schliessen | Archivieren/Bewegen | Beitrag melden!

Fragen und Anregungen: Kritik-Forum | Neues aus der Community: Community-Forum

(c)2023 CAD.de | Impressum | Datenschutz