Autor
|
Thema: Joberror mit Shell/Rigidkontakt: Displacement increment for contact is too big (1489 mal gelesen)
|
Ingeniorator Mitglied Student
Beiträge: 88 Registriert: 23.06.2015
|
erstellt am: 19. Jan. 2016 22:20 <-- editieren / zitieren --> Unities abgeben:
Ahoi, ich tüftele gerade daran, ein Modell einer PET-Flasche zwischen zwei Rigidplatten zu quetschen. Der Job bricht leider ab mit der Fehlermeldung Too many attempts made for this increment und der Warnung Displacement increment for contact is too big. Ich gehe davon aus, dass kein Kontakt zustandekommt, allerdings weiß ich nicht woran es liegt. Es tritt jedenfalls auch bei einem kleinen Modell mit zwei Solidkörpern auf. Die Kontaktoberflächen habe ich als Element based definiert, mit Rigidkörpern sollte das ja hinhauen, oder? Bei Analytical rigid blicke ich nämlich nicht im Geringsten durch, wie das einzustellen ist. Ich habe die Dateien angehangen. 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: 19. Jan. 2016 23:35 <-- editieren / zitieren --> Unities abgeben: Nur für Ingeniorator
Da sind diverse Dinge fragwürdig. - Statisch ohne NLGeom? Oft werden solche Analysen mit Explicit gerechnet, da neben großen Verformungen und schwierigen Kontaktsituationen auch beulen auftreten könnte. - 100% Last im 1. Inkrement? - Mit Schalendicke durchdringen sich die Bauteile. - Gibt es einen Grund für die vordefinierte lineare Kontaktsteifigkeit? - Die Starrkörper haben noch freie Bewegungsmöglichkeiten. - Durch die unklare Kontaktsituation im Anfangszustand hat auch die Flasche noch einen Starrkörpermode. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Ingeniorator Mitglied Student
Beiträge: 88 Registriert: 23.06.2015
|
erstellt am: 20. Jan. 2016 00:20 <-- editieren / zitieren --> Unities abgeben:
Ahoi, -für den ersten Versuch, ja -kann ich versuchsweise mal ändern -stimmt, ist mir im Nachhinein auch aufgefallen -ja, da ich die Solver von Abaqus und Calculix vergleiche, in Calculix gibt es keinen hard contact -stimmt, ich habe ganz vergessen, dass ich mit einem RefNode arbeite und dementsprechend 4-6 ebenfalls sperren muss -was meinst du mit Mode? Bei Explicit kommt jedenfalls das raus: Underlying element 2081 instance part-1-1 can not have spos as a face identifier Underlying element 2124 instance part-1-1 can not have spos as a face identifier Underlying element 2129 instance part-1-1 can not have spos as a face identifier Underlying element 2161 instance part-1-1 can not have spos as a face identifier Underlying element 2884 instance part-1-1 can not have spos as a face identifier Underlying element 2894 instance part-1-1 can not have spos as a face identifier 68 elements have missing property definitions. The elements have been identified in element set ErrElemMissingSection. Wobei ich mich frage, woher die fehlenden Eigenschaften herkommen. Mit dynamic implicit läuft es jetzt, nachdem ich die restlichen Knoten der obersten Oberfläche der Flasche ebenfalls in 1+3 gesperrt habe und sie sich nicht mehr wild herumdreht... Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Rechenknecht87 Mitglied Student
Beiträge: 51 Registriert: 22.09.2014
|
erstellt am: 21. Jan. 2016 08:51 <-- editieren / zitieren --> Unities abgeben: Nur für Ingeniorator
68 elements have missing property definitions. The elements have been identified in element set ErrElemMissingSection. Der Fehler weist darauf hin, dass bei 68 Elementen die Properties nicht zugeordnet worden sind (Assign Section). Die Bereiche in denen keine Properties zugewiesen sind erkennst du im Property-Modul an der unterschiedlichen Einfärbung. Zu dem anderen Fehler kann ich nicht viel sagen, ist mir selbst noch nicht untergekommen. Evtl. weist dieser auf ein Problem bei der Kontaktflächendefinition hin. Ist aber nur eine Vermutung. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Ingeniorator Mitglied Student
Beiträge: 88 Registriert: 23.06.2015
|
erstellt am: 21. Jan. 2016 16:38 <-- editieren / zitieren --> Unities abgeben:
Ahoi, es ist doch kurios, dass der reine Wechsel von implizit auf explizit fehlende Elementeigenschaften hervorrufen soll, etwas anderes habe ich nämlich nicht geändert. Im Visualization kann ich das Elementset sehen, die Elemente scheinen willkürlich über die Flasche verteilt zu sein. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Rechenknecht87 Mitglied Student
Beiträge: 51 Registriert: 22.09.2014
|
erstellt am: 21. Jan. 2016 17:11 <-- editieren / zitieren --> Unities abgeben: Nur für Ingeniorator
|
Ingeniorator Mitglied Student
Beiträge: 88 Registriert: 23.06.2015
|
erstellt am: 21. Jan. 2016 18:11 <-- editieren / zitieren --> Unities abgeben:
|
Rechenknecht87 Mitglied Student
Beiträge: 51 Registriert: 22.09.2014
|
erstellt am: 21. Jan. 2016 21:19 <-- editieren / zitieren --> Unities abgeben: Nur für Ingeniorator
Hast du den Kontakt jetzt komplett entfernt? Bekomme die gleichen Fehlermeldungen wie du. Die Elemente ohne Property Definitions kannst du dir im Visualization Modul anzeigen lassen. Ich habe mal einen Screenshot davon gemacht. Ich würde um mögliche Fehlerquellen zu minimieren zunächst erstmal die Flasche allein vernetzen, den Boden fixieren und einfach mal mal die obere Knotenreihe am Flaschenkopf über die Verschiebung belasten. Wenn das so funktionieren sollte liegt der Fehler bei der Verwendung der Rigids. [Diese Nachricht wurde von Rechenknecht87 am 21. Jan. 2016 editiert.] 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. Jan. 2016 23:28 <-- editieren / zitieren --> Unities abgeben: Nur für Ingeniorator
Wenn man das Bild sieht dürfte klar sein, dass die Dreiecke keine Shell Section abbekommen haben. Entweder fehlt eine extra Shell Section oder ein Elementset mit allen Schalenelementen muss in einer Shell Section verwendet werden. Eigentlich sollte sowas der Preprocessor regeln. Keine Ahnung was Hypermesh da da für ein Problem hat. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |