---

Biegebalken_Dehnratenabhaengig_EKILL.txt

Hallo Zusammen,

anbei ein Skriptfile eines einseitig eingespannten Biegebalkens. Dieser wird im ersten Loadstep gebogen, im zweiten federt er zurück. Im dritten Loadstep möchte ich Elemente deaktivieren und schauen wie sich das auf den Spannungszustand auswirkt.
Die ersten beiden Loadstep konvergieren gut.
Der Biegebalken ist in n-schichten eingeteilt (n-Kombonenten). Ich möchte nun diese Schichten nacheinander killen, jedoch konvergiert die Lösung nicht.

Im Prinzip sieht der Loadstep wie folgt aus:

cmsel,s,s1 (Schicht 1 selektieren, eine Elementschicht)
ekill,all
alls
solve

Hat jemand eine ahnung wieso dieser Loadstep nicht konvergiert? (nropt,full ist eingeschaltet)

Viele Grüße MArkus

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

---

Ekill funktioniert so, dass die Elemente "weich" gemacht werden, so dass sie große Dehnungen aber kaum noch Spannungen aufnehmen. Es wird also der Emodul nach nahe Null gesetzt. So können sich aber auch sehr einfach Konvergenzschwierigkeiten bilden.

Versuch doch mal, die Elemente wegzuselektieren. Ich weiss nicht, ob dies bei transienter Analyse zwischen einzelnen Loadsteps möglich ist, sollte aber. Dazugehörige Knoten ebenfalls wegselektieren.

alls
cmsel,u,s1
nsle
solve

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

---

Deselektieren würde ich nicht, vielmehr mit Hilfe des ESTIF-Befehls andere Steifigkeitsmultiplikatoren definieren. Wenn Konvergenz auch bei ESTIF, 1 nicht erreicht werden kann, liegts nicht am Element Birth and Death. Wozu verwendest du denn Restart? Manchmal schleichen sich durch solche Definitionen auch Fehler ein, lass das einfach mal weg...

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

---

Hi, danke für die Antworten.

Restart verwende ich deshalb, weil ich nach jeder Schicht die ich killen möchte in den Postprozessor wechsel, damit ich die Spannungsveränderung auswerten kann.

Hintergrund ist dieser: Bei einen mit Eigenspannung versehenes Bauteil, wird im Normalfall durch eine röngtenographische Messung der Eigenspannungsverlauf untersucht. Dazu ätzt man Schichtweise Material weg und betrachtet die einzelnen Schichten.

In der Simulation kommen immer viel höhere Eigenspannungen raus , als tatsächlich gemessen werden. Bekannt ist das durch Abtrag von Materialschichten sich der Spannungsverlauf ändert und somit auch andere Werte gemessen werten, als tatsächlich vor dem Materialabtrag vorhanden waren. Dieses einfache Model soll eine Abschätzung aufzeigen in welcher Größenordnung diese Veränderungen sind.

Grüße

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

---

Habs mit estiff,1 probiert --> auch keine Konvergenz.

Ekill am Anfang gesetzt,Restart weggelassen --> keine Konvergenz

Das komische ist ich verwende diesselbe Befehlsfolge in einem anderen Model (transient gerechnet), da funktionierts. 

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

---

Zitat:

---

Original erstellt von skater2096:
Restart verwende ich deshalb, weil ich nach jeder Schicht die ich killen möchte in den Postprozessor wechsel, damit ich die Spannungsveränderung auswerten kann.

---

Kann man das nicht auch machen, wenn die Berechnung vollständig durchgelaufen ist?
Sagt denn die Error-Datei irgendetwas (Warnungen,...)? Hast du dir die Komponente s1 angeschaut, ist die richtig definiert?

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

---

Schreib doch mal, was im Output steht, wenn es nicht konvergiert.
Den Output kannst du mit /output,output,txt in ein Text-File umleiten.

Du hast ja die Verdrehung über einen Masterknoten aufgebracht. Dessen Target ist auch auf den gekillten Elementen. Vielleicht hängt es ja damit zusammen?

Wenn du nicht während der Rechnung eingriefen willst - also die Rechnung regeln willst - brauchst du nicht in den /post1 zu wechseln während deiner einzelnen Loadsteps.

Lass mal ohne Restart durchlaufen.

[Diese Nachricht wurde von Rico80634 am 18. Okt. 2010 editiert.]

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

---

Biegebalken_Dehnratenabhaengig_EKILL_funzt.txt Konvergent.jpg output.txt

Achtung Leute, jetzt kommt es. Das ist etwas was ich an Ansys manchmal nicht verstehe.

Kille ich die unteren Schichten, funktioniert es. Kille ich oben funktioniert es nicht. ???!!!???? (Das soll einer Verstehen)

Der einzige Unterschied ist in dieser Zeile

nsel,s,loc,y,0,4 (Funktioniert)
nsel,s,loc,y,6,10 (Funktioniert nicht)

Bauteil ist 10 hoch (y=0...10)

Anbei das Output bei nichtkonvergender Lösung. Ein Bild bei nsel,s,loc,y,0,4 (man sieht das die unteren Elemnetschichten spannungsfrei sind). Und das konvergierende Skriptfile.

Kleines weiteres Problem habe ich noch: Ich möchte nach der Rückfederung den Balken in dieser Position festhalten, bevor ich die Elementschichten kille. An der unteren Linie. Mach ich das mit, d,all,all,0 wird der Balken wieder gerade. Will aber in der gekrümmten Form das Ding festhalten.

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

---

Deine Force Convergenze Value ist im Loadstep 3 bei allen Konfergenzschritten gleich bei 911.6. Das erscheint mir sehr unwahrscheinlich.

Mach doch mal einen Screenshot von USUM der nicht-konvergierten Lösung (Step 999999), und poste ihn hier.

[Diese Nachricht wurde von Rico80634 am 18. Okt. 2010 editiert.]

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

---

usum.jpg

Nichts auffälliges zu erkennen an dem Screenshot. Das komische ist ja, kille ich unten klappts, kille ich oben klappt es nicht. (Thx Rico)

Einer ne Idee, wie ich das Teil im verformten Zustand festhalten kann??

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

---

Poste dann doch bitte nochmal das gesamte Error-File der nicht-konvergierten Rechnung. Dem muss man doch auf den Grund kommen können 

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

---

Was verändert sich denn noch, wenn du alle Knoten festhältst? Aber es würde so gehen:

Code:

---

*get, knoten, node, 0, num, min
*dowhile, knoten
  d, knoten, ux, ux(knoten)
  d, knoten, uy, uy(knoten)
  d, knoten, uz, uz(knoten)
  knoten = ndnext(knoten)
*enddo

---

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

---

Ich will ja nicht alle Knoten festhalten, sondern nur die untere Linie.

Im Error file steht nichts ausser:

*** ERROR ***                          CP =    1209.866  TIME= 15:31:16
Solution not converged at time 0.25 (load step 3 substep 1).           
  Run terminated.
*** WARNING ***                        CP =    1210.287  TIME= 15:31:18
The unconverged solution (identified as time 1.15 substep 999999) is   
output for analysis debug purposes.  Results should not be used for   
any other purpose.                                                       

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

---

dann einfach vor der Ausführung des Codes alle Knoten der unteren Linie selektieren...

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

---

Hab die untere Linie selektiert und die uz-Zeile deaktiviert, bin in 2D.

time,ZEIT+0.06
nsel,s,loc,y,0
*get, knoten, node, 0, num, min
*dowhile, knoten
  d, knoten, ux, ux(knoten)
  d, knoten, uy, uy(knoten)
  !d, knoten, uz, uz(knoten)
  knoten = ndnext(knoten)
*enddo
alls
solve

Aber der Loadstep konvergiert nicht.

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