---

scratch.txt

Hi,

ich bin relativ neu bei Abaqus und soll nun einen "Scratch-Test" simulieren. Dabei handelt es sich um einen spärischen Indenter der mit einer gewissen Kraft auf eine beschichtete Oberfläche gedrückt wird und um eine gewisse Weg-Strecke verfahren wird.
Das klappt soweit ganz gut.
Mein Problem liegt jedoch darin dass ich am Ende die Kugel wieder von der Oberfläche anheben möchte, um nur noch die plastische Verformung zu sehen und nicht auch die elastische.
Dabei bricht die Simulation im letzten Step jedoch schon beim ersten Inkrement ab.
Folgende Fehler werden angezeigt:
The strain increment has exceeded fifty times the strain to cause first yield at 23 points
Excessive distortion at a total of 17 integration points in solid (continuum) elements
The system matrix has 1 negative eigenvalues.
Anbei noch mein Input-file.
Danke schon mal für eure Hilfe,
FMX

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Negative Eigenvalues sind schonmal ein Indiz darauf, das irgend ein Bauteil nicht vollständig eingespannt ist.
Leider habe ich kein Abaqus/CAE zur Hand und konnte nur versuchen das Inputdeck zu lesen.

Grundsätzlich solltest du nochmal deinen Entlastvorgang überdenken ob die Boundarys richtig vergeben sind.
Ich habe gesehen, du nimmst einfach die Kraft bzw. den Druck weg. Vielleicht wäre besser mit einer definierten Verschiebung weg von der Platte (wie ähnlich wie beim Verfahren) zu arbeiten?

Viele Grüße
Patrick

PS: poste doch bitte ein Screenshot (inkl. Koordinatensystem) damit ich das ein bisschen zuordnen könnte.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Screenshot.PNG

Danke schon mal für deine Hilfe!
Also die Randbedingungen sind folgende:
Feste Einspannung auf der Unterseite der Probe (ENCASTRE)
Sperrung der Verschiebung in z-Richtung der Probe aufgrund von Symmetrie
Selbiges für den Indenter
Diese BC's bleiben über die gesamte Simulation unverändert.
Zusätzlich für den Indenter:
Step 1 und 2: Anheben und Zurückfahren des Indenters um eine klare Kontaktdefinition zu erzeugen
Step 1: Verschiebung: x=0, y=0.1
Step 2: Verschiebung: x=0, y=-0.1
Step 3: Eindrücken: Verschiebung: x=0; Rotation: z=0 (Kraft 5N (Ramp))
Step 4: Verfahren: Verschiebung: x=2; Rotation: z=0 (Kraft 100N (Ramp))
Step 5: Entlasten: Verschiebung: y=0; Roataion: z=0 (Kräfte deaktiviert)

Die Idee mit dem hochfahren teste ich gerade, also bei Step 5: Verschiebung y=0,1

Anbei der Screenshot

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Absolut gesehen sollte die Viertelkugel wieder auf y=0 fahren, so wie du es definiert hast - das passt eigentlich alles. Ich denke das größte Problem macht hier wohl die x-Verschiebung, die in Step 5 komplett frei ist. Das würde bedeuten, dass die Kugel zurückfedert -> deswegen die negative Eigenvalues.
Halte diese am besten auch im Step 5 an der Endposition von Step 4 fest, sprich:

*Boundary, op=NEW
_PickedSet15, 1,  , 2. <- zusätzliche Boundary
_PickedSet15, 2, 2
_PickedSet15, 3, 3
_PickedSet15, 6, 6

Gruß
Patrick

PS: Berichte doch, ob es läuft  

[Diese Nachricht wurde von Stoli am 30. Jul. 2013 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Okay danke das kann gut sein dass es daran liegt, werde ich testen.
Ich muss gestehen dass ich dieses Input-File nicht ganz verstehe, aber die beiden Kommas sehen doch ein wenig komsich aus :P
Stimmt das so? Also _PickedSet15, 1 sehe ich ja ein aber dann 2 Kommas hintereinander? Und hat der Punkt nach der 2 noch eine Bedeutung?
Ich berichte sobald es ein Ergebnis gibt, dauert allerdings etwas, da die Berechnung mit ca 100.000 Knoten nicht ganz klein ist 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ja das stimmt so

Knotenset, erste Komponentem, zweite Komponente (wir wollen ja nur x-Verschiebung, deswegen "leer"), Betrag der Verschiebung
_PickedSet15, 1, , 2.
                                     

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Wunderbar, hat genau so geklappt wie ich mir das vorgestellt habe.
Vielen, vielen Dank

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi,

im weiteren Verlauf hat sich leider ein weiteres Problem ergeben.
Und zwar versuche ich nun genau das gleiche mit einem größeren Indenter (Durchmesser 2,7mm statt 0,4mm).
Allerdings bricht die Simulation in Step Verfahren recht bald ab. Gleich zu Beginn werden die Inkrement Größen verkleinert, bis das Minimum erreicht ist und die Simulation abbricht.
Ich habe keine Ahnung woran das liegen könnte. Ich habe außer der Größe der Kugel und des Substrates nichts geändert (Copy Model -> Edit Sketch).
Vielen Dank für euere Vorschläge

FMX

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Servus,

das hört sich sehr stark danach an, dass die Elementgröße wohl nicht ganz stimmt. hast du die Kugel mit gleicher Elementkantenlänge vernetzt? Darauf ist sehr zu achten, ansonsten kann der Kontakt wohl nicht gefunden werden - wie du schon sagst, bricht sehr schnell ab.

Wie sieht das .sta-File aus? Bricht er von anfang an runter und dann ab oder findet er zumindest für ein bis zwei zeitinkremente mit Konvergenz?

Viele Grüße
Patrick

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

27.sta.txt

Die Elementgröße musste ich anpassen und vergößern (-> gröberes Netz) da ich leider mit einer Studentenversion arbeite und ich dadurch auf 100.000 Knoten beschränkt bin. Inwiefern wird das zum Problem?
Das Eindrücken klappt ganz normal wie beim kleinen Indenter auch (gleich Anzahl an Inkrementen), erst ab dem Verfahren wirds komisch.
Nene er findet schon für einige Inkremente eine Konvergenz.
Hab die Simulation gerade erst neu gestartet, da ich ausschließen wollte dass ich einen Fehler in den Einstellungen habe.
Daher läuft die Simulation gerade noch (.sta-File noch nicht sehr aussagekräftig).
Zu erkennen ist allerdings, dass nach 30 Inkrements 5.6e-5 von 10 Sekunden berechnet sind (quasi nix), während bei der Simualtion mit dem kleinen Indenter nach 30 Inkrements schon über eine halbe Sekunde berechnet war.
Demnach wird die Ausgabedatei dann riesig groß, da ewig viele Inkrements verwendet werden (ich glaube ich hab's schon vor längerer Zeit mal laufen lassen wo es nach 19GB abgebrochen ist weil der Speicher voll war)

[Diese Nachricht wurde von FMX am 12. Aug. 2013 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ja das sieht nach sehr schlechter Konvergenz aus, Hast du dir das .odb auch schon im Viewer angesehen? Sieht das alles okay aus?
Schau dir mal das .msg-File an, ob du Negative Eigenvalues hast, evtl. ist etwas bei der Einspannung schiefgelaufen und er versucht das mit Stabilize wegzudämpfen, deswegen die immer kleiner werdende Inkrementierung.

PS: Ich weiß nicht ob dir das bekannt ist, aber:
Du kannst mit
*OUTPUT FIELD, FREQUENCY=10
*NODE OUTPUT
U etc.
auch die ins .odb geschriebenen Schritte reduzieren, also im oberen Beispiel jeden zehnten - somit werden die .odb's kleiner.

[Diese Nachricht wurde von Stoli am 13. Aug. 2013 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ja habe ich mir angesehen, schaut eigentlich alles wunderbar aus.
Im .msg-File lässt sich nichts mit negative eigenvalues finden.
Es wird allerdings dauernd die Warnung angezeigt "There is zero force everywhere in the model..."

Das mit der Ausgabe jedes 10. Schrittes ist mir neu, hört sich aber interessant an.

Habe die Simulation jetzt mal über nacht weiterlaufen lassen. Mittlerweile sind mehr als 1030 Inkrements gerechnet, allerdings sind die Schritte so klein dass erst 0.00086 von 10 Sek. berechnet wurden. Da reicht auch jeder 20. Schritt wenn nicht noch weniger.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi,

die Simualtion läuft mittlerweile seit Donnerstag.
sind schon über 6200 Inkrements berechnet, allerdings erst 0,0046 Sekunden.
Im Step-Modul habe ich mittlerweile die Stabilization eingeschaltet und einen Damping factor von 0.0002 angegeben.
Zielführend ist das aber irgendwie immer noch nicht.

FMX

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP