Hot News:

Mit Unterstützung durch:

  Foren auf CAD.de (alle Foren)
  ANSYS
  Wiederholung von Lastschritten

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
  
Gut zu wissen: Hilfreiche Tipps und Tricks aus der Praxis prägnant, und auf den Punkt gebracht für Ansys
Autor Thema:  Wiederholung von Lastschritten (4425 mal gelesen)
Majan91
Mitglied



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

Beiträge: 15
Registriert: 06.09.2018

erstellt am: 13. Sep. 2018 11:38    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


Bild1.png

 
Hallo zusammen,

ich arbeite gerade für meine Masterarbeit mit ANSYS Workbench 18.2.

In zwei Lastschritten presse ich zunächst einen Ring in eine Nut zwischen zwei Bauteilen ein und belaste in einem 2. Lastschritt diese Verbindung.

Diesbezüglich gibt es für das Einpressen eine Kraft-Obergrenze und da es in Workbench nicht vorgesehen ist Relativbewegungen durch das Aufprägen einer Kraft zu erzeugen, muss ich eine Verschiebung vorgeben und kann dann die Lagerung in die Lösung ziehen und so über die Kraftreaktion herausfinden, welche Kräfte dabei gewirkt haben.

Im nächsten Schritt muss ich dann feststellen, mit welcher Verschiebung meine Kraftobergrenze erreicht wurde, die Verschiebung entsprechend anpassen und dann das ganze nochmal durchlaufen lassen, damit ich für den nächsten Lastschritt die korrekte Ausgangssituation habe.

Da ich dies für viele verschiedene Ring- und Nutgeometrien durchführen muss, die für die parametrisierte Geometrie in Design-Points vorliegen ist meine Frage:
Kann ich durch APDL Command-Snippets bestimmen, dass NUR der erste Lastschritt durchgeführt wird (für eine Verschiebung, die eine zu große Kraft benötigen würde), dann die Verschiebung nach Auswertung der Ergebnisse des ersten Lastschritts so anpassen, dass genau meine Kraftobergrenze erreicht wird und dann alle Lastschritte durchlaufen lassen?

Diesbezüglich muss ich sagen, dass ich zum ersten Mal mit APDL arbeite und mich nicht sonderlich gut damit auskenne. Meine Hoffnung ist, dass ich dadurch für jeden Disign-Point automatisch die Verschiebung anpassen kann und einfach alle Design-Points lösen lassen kann.

Dazu habe ich bisher die Multiple-Solve-Method (https://www.sharcnet.ca/Software/Ansys/17.0/en-us/help/ans_bas/Hlp_G_BAS3_10.html) ins Auge gefasst und stelle mir momentan vor, nach dem ersten Lastschritt die Verschiebung (im angehängten Bild "Einpressen") anzupassen und dann beide Lastschritte zu lösen. Dabei ist mir in der Veranschaulichung der Multiple-Solve-Method schleierhaft, wo ich den zu lösenden Lastschritt spezifiziere (es sieht so aus, als wenn ich trotzdem immer alle Lastchritte lösen würde).

Zusätzlich stellt sich mir dabei noch die Frage, ob das Command-Snippet im angehängten Bild an der richtigen Stelle eingefügt ist, auch wenn ich meines bisherigen Verständnisses nach den Block überall einfügen kann und über /prep7 , /post1, /solu dann die entsprechenden Bereiche beeinflusse.

Vielen Dank schonmal an alle, die sich diesem Post widmen und Antworten.

Gruß
Majan

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

Duke711
Mitglied



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

Beiträge: 826
Registriert: 14.11.2016

erstellt am: 13. Sep. 2018 13:47    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 Majan91 10 Unities + Antwort hilfreich

Wieso nicht kraftgesteuert rechnen?

"nicht vorgesehen ist Relativbewegungen durch das Aufprägen einer Kraft zu erzeugen"

Warum sollte das nicht möglich sein? Einfach Starrkörperbewegungen durch eine Kontaktschrittsteuerung, die z.B: ein durchrutschen unterbindet, ausschließen.
Und den Sparse Solver verwenden, dann gibt es auch mit der Konvergenz der Substeps keine Probleme.

Bezüglich der Frage:

Den Schritt mit der manuellen Verschiebungsanpassung hätte ich sowie so nicht unternommen. Stattdessen einfach eine Schleife über Schnippsel einbauen. Die Ist-Kraft wird mit der Soll-Kraft vergleichen, ist die Abweichung zu groß wird dementsprechend die Verschiebung angepasst und von neuem gerechnet.
Dann lässt sich diese Modell auch einfach automatisieren. Stellt sich nur die Frage ob das dann mit dem einfachen Parametersettool und der Schleife funktioniert. Kann auch gut sein, dass beim ersten Schleifendurchlauf das Parametersettool Aufgrund eines Fehlers die Studie abbricht.
Ansonsten einfach über Batch arbeiten und die Ergebnisse als TXT oder CSV herausschreiben lassen.
Und ohne einen intelligenten Algorithmus kann so eine Schleifenberechnung, je nach Toleranz, viel Zeit in anspruch nehmen. Da dann die variable Verschiebungsschrittweite klein sein sollte.

Ich würde mit dem Sparse Solver kraftgesteuert rechnen. Das Ergebnis ist genauer, spart vermutlich Zeit und dann funktioniert auch das einfache Parametersettool.

[Diese Nachricht wurde von Duke711 am 13. Sep. 2018 editiert.]

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

Majan91
Mitglied



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

Beiträge: 15
Registriert: 06.09.2018

erstellt am: 13. Sep. 2018 15:44    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


Bild2.png

 
Hi Duke,

danke für deine Antwort.

Ich habe nicht Kraftgesteuert gerechnet, da nach dem Praxisbuch FEM mit ANSYS Workbench
"Sind Bauteile mit ausschließlich nichtlinearem Kontakt mit einer Kraft belastet, ersetzen Sie diese durch eine angegebene Verschiebung (die Sie nach der Berechnung anhand der sich einstellenden Reaktionskraft wieder anpassen müssen)." dies besser nicht so gemacht werden sollte. Wenn ich mir (siehe Bild) meine axialsymmetrische (Achse ist die linke Kante des grauen Bolzens) 2D-Geometrie angucke, dann berührt der grüne Ring nicht immer die gleichen Flächen, was ich als nichtlinearen Kontakt interpretiert habe.

Wenn ich kraftgesteuert fahren kann wäre mir das natürlich sehr lieb, dies hat bei mir in meinen ersten Versuchen jedoch nie funktioniert (heute habe ich nicht mehr so viel Zeit, daher werde ich das morgen dann nochmal ausprobieren).

Ich nehme an, dass du mit der Kontaktschrittsteuerung einfach die normalen Kontakte meinst (reibungsbehaftet, reibungsfrei, etc.), richtig?

Den Solver, den du beschreibst kann ich leider nicht finden. Ich benutze eine Statisch-mechanische Analyse in Workbench und der gewählte Gleichungslöser ist dabei automatisch Mechanical APDL und ich habe es nicht geschafft, diesen zu ändern, da das Feld dafür gesperrt (ausgegraut) ist. Ich habe bei Google mal geschaut und eventuell gibt es über den Remote Solver Mager (RSM) eine Möglichkeit einen anderen Solver zu verwenden ... bin ich da in der richtigen Richtung unterwegs?
Diesbezüglich wäre ich für jeden Fingerzeig dankbar, da ich bisher keine schnelle Lösung zum Wechseln des Solvers gefunden habe.

Hinsichtlich der Beantwortung meiner Frage sagtest du, dass ich eine Schleife über die Schnipsel einbauen soll, die die Ist- mit der Sollkraft vergleicht ... meinst du damit nachdem der Step abgeschlossen ist? oder meinst du innerhalb des steps, dass laufend die Kraft abgefragt wird und die Verschiebung innerhalb des Steps dann an der Stelle gestoppt wird, an der die Kraft erreicht wird? ... letzteres würde für mich Sinn ergeben, auch wenn ich noch nicht wüsste, wie ich das umsetzen soll. Ersteres würde meiner Ansicht nach noch viel mehr Arbeit und Rechenzeit bedeuten, als meine ursprüngliche Herangehensweise.

Ich habe beim Einlesen in das Thema Batch bisher nur kurz berührt und kenne mich nicht damit aus. Hört sich generell aber vernünftig an.

Vielen Dank schonmal für die bisherigen Tipps und Hinweise!
Lg Majan

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

Duke711
Mitglied



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

Beiträge: 826
Registriert: 14.11.2016

erstellt am: 13. Sep. 2018 16:52    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 Majan91 10 Unities + Antwort hilfreich

Nicht lineare Kontakte sind:

Reibungsbehaftet, Reibungsfrei, Rau. Unabhängig davon ob nun der Kontakt geschlossen ist oder nicht.
Mit einer Kontaktschrittsteuerung meint man, dass Kontakte über Lastschritte aktiviert oder deaktiviert werden können.

Der Sparse Solver lässt sich unter Analyseeinstullungen -> Solvereinstellungen auswählen. Direkt steht für den Sparse Solver.

Das Modell sollte eigentlich auch kraftgesteuert gerechnet werden können. Ich sehe auf den ersten Blick keinen Grund für eine Verschiebungssteuerung.

Richtig die Schleife rechnet den jeweiligen Lastschrit solange, bis die definierte Toleranz bezüglich der Kraft erreicht ist.

https://books.google.de/books?id=5IFBp7rJMioC&pg=PA382&lpg=PA382&dq=ansys+schleife&source=bl&ots=RCM8D8opMB&sig=uccz_ZDmAmJ2kX_pJqT_ZVitr6w&hl=de&sa=X&ved=2ahUKEwiunMmWnbjdAhUHjSwKHWNACRgQ6AEwCXoECAUQAQ#v=onepage&q=ansys%20schleife&f=false

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

Majan91
Mitglied



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

Beiträge: 15
Registriert: 06.09.2018

erstellt am: 14. Sep. 2018 15:02    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


Bild3.png

 
Hi Duke,

ich habe jetzt das ganze mal kraftgesteuert gerechnet und stoße dabei auch mit dem Sparse-Solver (Danke für die Erklärung!) auf Probleme:

Zuerst konvergiert die Berechnung nicht, wenn der einzupressende Ring nicht schon "gut" mit den Flächen der Nabe in Berührung ist ... die lies sich durch eine kleine Verschiebung, die einen Kontakt erzwingt, jedoch vorweg regeln.

Das große Problem kommt dann aber auch erst nachdem die Kraft aufgebracht wird. Dabei wird der Ring zunächst ordentlich eingepresst, aber ab einem bestimmten Zeitpunkt wird das Zeitinkrement immer kleiner und die Berechnung bricht ab, weil sie mit dem minimalen (von mir vorgegebenen) Zeitinkrement nicht mehr weiterkommt.
Das minimale Zeitinkrement habe ich dann immer kleiner werden lassen und bin momentan bei 1*10^-8 angekommen. Es erscheint mir an dieser Stelle nicht sinnvoll, dieses noch kleiner werden zu lassen, da dies dann auch für sehr lange Berechnungen sorgen würde (wenn das minimale Zeitinkrement auch immer benötigt wird).
Liege ich mit dieser Annahme richtig, oder ist es sinnvoll, dieses noch deutlich kleiner werden zu lassen?
Die Zielkraft ist an dieser Stelle auch noch nicht erreicht und liegt gerade einmal bei einem Sechstel (Zustand siehe Bild 3).

Hinsichtlich der Idee mit der Schleife, die dann den ersten Lastschritt sicherlich rellativ oft (> 5 mal) berechnet habe ich dabei ähnliche Bedenken, da dann die Rechenzeit in die Höhe schießt und bei höchstwarscheinlich 500+ Geometrien evtl schon zu viel Zeit für die Berechnung gebraucht wird (wenn die kraftgesteuerte Berechnung so lange braucht, wie der mein gescheiterter Vresuch das vermutel lässt ~30 min, dann wären das über 10 Tage Rechenzeit, bei denen dann auchnoch alles gut gehen muss).

Daher wäre die kraftgesteuerte Berechnung optimal.

Alternativ wäre die auf der Verschiebung basierende Berechnung auch gut, für die jetzt noch eine weitere Herangehensweise aufgetan wurde. Dabei wird auch in zwei Schritten gearbeitet und zunächst eine Verschiebung vorgegeben, die eine Kraft, die größer als die Zielkraft ist, erzeugt. Dann wird die Verschiebung, wie schon in der vorherigen Idee angepasst, jedoch so, dass die Zielkraft noch immer nicht erreicht wird, aber kurz davor. Dann wird der restliche Weg Kraftgesteuert gefahren.
Das wären dann auch nur zwei Berechnungsdurchläufe, was bisher in < 10 min durchgelaufen ist (=> ca. 3,5 Tage Rechenzeit).

Der neue Vorschlag ist auf den ersten Blick etwas seltsam, was daran liegt, dass die Einpressmatrize (gelber Block - Bild2 (letzter Post)) für den Auspressvorgang zurückgefahren werden muss, was momentan über Lagerung-Verschiebung realisiert wird. Da diese Verschiebung aber anscheinend nur mit Absolutkoordinaten funktioniert (wenn es auch rellative Verschiebungen gibt, dann wüsste ich gerne, wie man das bewerkstelligt) ergibt sich ein Problem, wenn kraftgesteuert eingepresst wird, da das Programm dann schinbar nicht weiß, wo die Einpressmatrize dann ist. Daher geht es mit der angepassten Verschiebung nahe an den richtigen Punkt ran und mit dem letzten kraftgesteuerten Stück wird dann genau die Zielkraft getroffen. Da dann die Einpressmatrize nahe an dem durch die letzte Verschiebung bekannten Punkt liegt, scheint das Programm sie dann wiederzufinden und es funktioniert so.

Bezgl. deiner Antwort zu meiner ursprünglichen Frage: Warum würdest du die Verschiebung in Inkrementen bis zum Ziel erhöhen, statt einmal übers Ziel hinauszuschießen und dann im zweiten Durchlauf zu treffen? Konvergiert das so leichter?

Wenn du Hinweise hättest, mit denen ich die kraftgesteuerte Variante ans laufen kriege, wäre ich sehr dankbar dafür!
Dazu wären dann warscheinlich aber mehr Angaben zu meinen Randbedingungen und Kontakten nötig, richtig? Die Kontakte sind augenscheinlich richtig definiert, sonst hätte das Einpressen bis zu diesem Punkt ja auch nicht funktioniert. Wenn du also für eine Antwort mehr Informationen brauchst, sag mir bescheid welche das sein sollten, da ich mir gerade nicht vorstellen kann, welche das sein sollten.

Eine weitere Frage aus meinem ersten Post war noch, ob ich den Command-Block an der in Bild1 zu sehenden Stelle einfügen kann und dann von dort aus über /post1, /pre7, /solu auf jeden beliebigen Bereich zugreifen kann bzw. z.B. in diesem Befehl die von dir erwähnte Schleife unterbringen kann?

Lg Majan

[Diese Nachricht wurde von Majan91 am 14. Sep. 2018 editiert.]

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

hvac21
Mitglied


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

Beiträge: 5
Registriert: 07.09.2018

erstellt am: 14. Sep. 2018 15:44    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 Majan91 10 Unities + Antwort hilfreich

---

[Diese Nachricht wurde von hvac21 am 14. Sep. 2018 editiert.]

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

Duke711
Mitglied



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

Beiträge: 826
Registriert: 14.11.2016

erstellt am: 14. Sep. 2018 15:51    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 Majan91 10 Unities + Antwort hilfreich

Hmm ich sehe zwei Probleme:

1.

Der Kontakt vom Pressstück zum Werkzeug scheint ein linearer Kontakt zu sein, vermutlich keine Trennung. Ist das in Wirklichkeit so richtig? Das würde bedeuten das Pressstück würde sich beim Einschub sehr stark verformen, laut den Spannungen sogar plastisch verformen. Da kommt dann natürlich der Solver nicht mehr weiter, wenn kein Plastifizierungsmodell definiert wurde, da die Spannung ins unermessliche ansteigen und dann keine Verschiebung mehr ermittelt werden kann. Denn bis zum Substep sind die Ergebnisse ja plausibel, also kann hier nur ein Fehler im Modell oder Material vorliegen.

Sind geomterische Nichtlinearitäten (große Verformung) aktiviert?

Es gibt also zwei Möglichkeiten. Entweder der Kontakt vom Pressstück kann beim Einschub abheben, nicht linearer Kontakt. Ansonsten müsse ja eine enorme Spannkraft mit einer unendlichen Steifigkeit des Presswerkzeuges beim Einpressen jede auch noch so minimale Abhebung des Pressstückes unterbinden, kann ich mir nur schwer vorstellen. Und oder es liegt eine plastische Verformung vor.

Bitte auch mal Durchdringung und Flächenpressung auswerten, evtl. ist es angebracht die Kontaktsteifigkeit zu senken.

2.
Kein wirkliches Problem, aber das Netz an den Kontaktflächen vom Werkszeug könnte man noch etwas feiner vernetzen. Dazu gibt es z.B. die Funktion der Kontaktbereichvernetzung. An manchen Stellen unterscheidet sich die Kontaktnetzdichte um beinahe den Faktor 10 und das könnte zu Kontakt und Konvergenzproblemen führen.

Ob so das Ergebnis der Verschiebungsgesteuerten Rechnung dann so stimmt, bezweifel ich. Welche Durchdringung liegt hier zu Grunde, sind die Spannung und daraus abgeleitete Kraft plausibel ect. Denn auch hier treten die o.g. Probleme auf.


Nachtrag:

Wurde etwa der gesammte Kontaktbereich bis zur Nut als linearer Kontakt definiert? Wenn ja würde das zu einem Knick im Pressstück führen, da bricht dann natürlich der Solver ebenfalls ab.
In der Regel konvergiert eine kraftgesteuerte Lösung zwar etwas langsamer, aber bei nicht Konvergierung liegt entweder ein Modellfehler vor bzw. die Netzqualität ist nicht ausreichend.

[Diese Nachricht wurde von Duke711 am 14. Sep. 2018 editiert.]

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

Majan91
Mitglied



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

Beiträge: 15
Registriert: 06.09.2018

erstellt am: 17. Sep. 2018 10:51    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

Zu 1:
Nein, der Kontakt ist nicht linear, ich habe den Kontakt als reibungsbehaftet erstellt, beim Einpressen mit Verschiebung besteht dabei auch ohne "Verbund" und "ohne Trennung" durchgängiger Kontakt. Hinsichtlich der plastischen Verformung wurde für jedes Material Isentrope Elastizizät und Bilineare bzw. Multilineare isentrope Verfestigung definiert, die aus vorherigen Arbeiten stammen. Die Steifigkeit des einzupressenden Stücks ist gering, während das Einpressstück aus einem Hochfesten Stahl ist. Ich glaube daher, dass die Spannung nicht ins Unermessliche steigt (ich lasse mich gerne eines Besseren belehren).

Große Verformungen sind aktiviert und eine plastische Verformung des Presstücks ist auch erwünscht und tritt bei einer verschiebungsgesteuerten Rechnung auch auf.

Hinsichtlich der Kontakte habe ich alle Kontaktflächen, die mit dem einzupressenden Stück interagieren als reibungsbehaftet (Abheben also möglich) definiert. Andere (weniger interessante) Kontaktpaare sind reibungsfrei definiert aber es ist in jedem Fall überall Abheben möglich.
Wenn ich das richtig verstehe, habe ich damit nirgendwo lineare Kontakte definiert.

Ich habe jetzt an allen Kontakten für gleiche Netzdichten gesorgt und die Netzelementgröße im betreffenden Bereich liegt bei 0,1mm. Leider bleibt die Simulation noch immer an der selben Stelle hängen. Gibt es noch weitere Möglichkeiten, die Netzqualität zu erhöhen?
Was meintest du  am Ende von deinem Punkt eins mit der Reduktion der Kontaktsteifigkeit?


Momentan sieht es daher für mich so aus, als wenn ich zu meiner ursprünglichen Idee zurück müsste. Ich verfolge natürlich auch gerne parallel die kraftgesteuerte Berechnung weiter, wenn es da noch weitere Ideen gibt!

Bzgl. meines ursprünglichen Ansatzes bestehen daher bei mir noch einige Fragen:
1. Kann ich (ich muss das dann natürlich noch lernen, aber ich will nur wissen, ob es geht) über APDL Snippets (z.B. an der Position des Befehls in Bild 1) die Verschiebung ändern, nachdem ich diese aus dem ersten Durchlauf bei der Zielkraft ermittelt habe?
2. Ist es möglich nur z.B. den ersten Lastschritt durchlaufen zu lassen und dann nochmal alle Lastschritte? (pseudocodemäßig stelle ich mir dabei vor, dass es so abläuft: Solve Lastschritt 1, read Verschiebung @ Zielkraft, set neue Verschiebung, Solve alles).
3. Wo müsste ich dann mein Command-Snippet plazieren?
4. Kann ich alles in einem Snippet machen?

Danke nochmal für all die Hilfe!
@hvac11 ich habe erst nach dem WE wieder hier gelesen und da war dein Beitrag schon "gelöscht", wenn du noch Ideen und/oder Anregungen hast, bin ich ganz offen dafür!

[Diese Nachricht wurde von Majan91 am 17. Sep. 2018 editiert.]

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

Duke711
Mitglied



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

Beiträge: 826
Registriert: 14.11.2016

erstellt am: 17. Sep. 2018 17:33    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 Majan91 10 Unities + Antwort hilfreich

Also ich habe mal so ein ähnliches Modell nachgebaut und überzeugend ist eine Verschiebungsgesteuerte Rechnung ebenfalls nicht, bei einer größeren Verschiebung, so dass das Pressstück > 1/5 in die Nut ragt, ebenfalls keine Konvergenz in allen Zwischenschritten

Grund ist eine zu starke Elementenverzerrung, da die Eckknoten einfach kollidieren und das Pressstück nicht abheben kann.
Das Modell ist so jeden falls nicht lösbar und bei einer kleinen Verschiebung ist die Lösung nicht plausibel.

Ich würde empfehlen erstmal das Modell zu überarbeiten.
Hätte mich auch gewundert, warum eine kraftgesteuerte Rechnung nicht möglich sein sollte.

[Diese Nachricht wurde von Duke711 am 17. Sep. 2018 editiert.]

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

Majan91
Mitglied



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

Beiträge: 15
Registriert: 06.09.2018

erstellt am: 18. Sep. 2018 14:30    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


Bild4.png


Bild5.png


Bild6.png

 
Danke für deine Mühe!

Dazu habe ich natürlich einige Fragen:

Die zu starken Elementverzerrungen, die du meinst treten bei dir am einzupressenden Stück an den Eckknoten auf. Ist das in dem Moment, in dem diese Eckknoten mit der Fläche der Nut in Berührung kommen?
Falls ja, so hatte ich dieses Problem auch und konnte es durch eine Anpassung der Geometrie beheben (siehe Bild4). Dort trifft jetzt nicht mehr Eckknoten auf Eckknoten.
Falls mit der zu großen Elementverzerrung gemeint ist, dass das Netzt so stark verzerrt wird, dass es sich selbst durchdringt und die Rechnung sich ausgraut, so tritt dieses Problem bei mir nicht mehr auf.
Bei einer verschiebungsgesteuerten Rechnung gibt es bei mir keine solchen Verzerrungen und ich erhalte eine konvergente Lösung (siehe Beispiel Bild5). Könnte eine Überarbeitung des Modells für die kraftgesteuerte Rechnung auch eine Verbesserung bringen, auch wenn des System für die Verschiebung schon funktioniert? Welche Änderungen meinst du damit? Verrundung von Eckknoten sind das Einzige, was mir einfällt.


Was meinst du damit, dass das Pressstück nicht abheben kann? Den  Kontakt zwischen dem grünen und gelben Bauteil in Bild2?
Um das übrigens an dieser Stelle einmal zu klären: Mit Pressstück meinst du doch das grüne Bauteil in Bild2 richtig?


Als Letztes würde ich gerne wissen, was genau du mit "keine Konvergenz in allen Zwischenschritten" meinst? In Bild6 habe ich einmal die Kraftkonvergenz zu der Eingepressten Geometrie der Bilder 4 und 5. Ist das Auftreten einer Bisektion schon das was du damit meinst?

(In den Beispielbildern ist das Netz der Einpressmatrize übrigens noch grob, was mitlerweile angepasst ist!)

[Diese Nachricht wurde von Majan91 am 18. Sep. 2018 editiert.]

[Diese Nachricht wurde von Majan91 am 18. Sep. 2018 editiert.]

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

Duke711
Mitglied



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

Beiträge: 826
Registriert: 14.11.2016

erstellt am: 18. Sep. 2018 16:12    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 Majan91 10 Unities + Antwort hilfreich

Da ich das Modell nicht kenne, kann ich nur mutmaßen, aber das führt zu nichts.

Einfach mal in die Solver out schauen warum die kraftgesteuerte Rechnung nicht konvergiert.

Bei Elementenverzerung gibt es eine Error Meldung:

*** ERROR ***    SUPPRESSED MESSAGE    CP =    261.177  TIME= 22:53:13
One or more elements have become highly distorted....

Davon hatte ich reichliche, aber mein Material war einfach zu steif etc.

Bei Starrkörperbewegungen entsprechende Piovtwarnungen z.B.

"There is at least 1 small equation solver pivot term (e.g., at the UY
degree of freedom of node 594688).  Please check for an insufficiently
constrained model."   


Wie ich aber schon sehe, konvergiert die verschiebungsgesteuerte Rechnung ziemlich schlecht. Da die kraftgesteuere weniger robust ist, wird das dann natürlich problematischer.
Wenn keine Fehlermeldung auftauchen sollte dann mal versuchen die Substeps deutlich zu erhöhen, sowie die Iterationsschritte pro Substep -> über den APDL Befehl "NEQIT, xxx". Und mal die Durchdringung auswerten und evtl. über eine Absenkung der Kontaktsteifigkeit nachdenken bzw. den Kontaktalgorithmus selbst festlegen.


1. Das ist ja der Sinn einer Bedingungsschleife "If-else-then"
2. Ja ist möglich
3. Spielt in Mechanical kaum eine Rolle, einfach unter C5.
4. Ja

[Diese Nachricht wurde von Duke711 am 18. Sep. 2018 editiert.]

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

Majan91
Mitglied



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

Beiträge: 15
Registriert: 06.09.2018

erstellt am: 05. Okt. 2018 15:04    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

Hi Duke,

nachdem ich jetzt eine Weile wegen dringender Vorversuche, etc. dieses Thema aussetzen musste, bin ich nun wieder dran.

Zuerst also einmal Danke für die Antworten zu meinen APDL-Machbarkeits-Fragen! Bei diesen bin ich gerade dabei, diese in APDL-Snippets umzusetzen und bisher klappt alles so, wie ich es gerne hätte.

Die Berechnung betreibe ich momentan verschiebungsgesteuert und trotz einiger Error-Meldungen erhalte ich Ergebnisse. Du sagtest in einem deiner Beiträge, dass die verschiebungsgesteuerte Berechnung auch nicht überzeugend ist, da nicht in allen Substeps Konvergenz gegeben ist. Das ist bei mir leider auch noch immer der Fall. Die Fehler, die ich erhalte sind dabei die folgenden:

1)
*** WARNING ***                        CP =      3.266  TIME= 13:47:33
There is at least 1 small equation solver pivot term (e.g., at the UY 
degree of freedom of node 4403) which may indicate a numerically       
unstable model.  Please check your results carefully.                 
    DISP CONVERGENCE VALUE  =  0.1344E-18  CRITERION=  0.2378E-05 <<< CONVERGED
    EQUIL ITER  1 COMPLETED.  NEW TRIANG MATRIX.  MAX DOF INC= -0.1344E-18
    DISP CONVERGENCE VALUE  =  0.1344E-18  CRITERION=  0.2426E-05 <<< CONVERGED
    LINE SEARCH PARAMETER =  1.000    SCALED MAX DOF INC = -0.1344E-18
    FORCE CONVERGENCE VALUE  =  0.3291E-10  CRITERION=  0.5206E-04 <<< CONVERGED
    >>> SOLUTION CONVERGED AFTER EQUILIBRIUM ITERATION  1
*** LOAD STEP    1  SUBSTEP    2  COMPLETED.    CUM ITER =      3
*** TIME =  0.200000E-04    TIME INC =  0.100000E-04
*** AUTO TIME STEP:  NEXT TIME INC = 0.15000E-04  INCREASED (FACTOR = 1.5000)

    FORCE CONVERGENCE VALUE  =  0.1054E-09  CRITERION=  0.5102E-04

2)
*** ERROR ***                          CP =      19.641  TIME= 13:47:50
The value of UY at node 2 is 46235578.7.  It is greater than the       
current limit of 1000000 (which can be reset on the NCNV command).     
This generally indicates rigid body motion as a result of an           
unconstrained model.  Verify that your model is properly constrained. 

*** ERROR ***                          CP =      19.641  TIME= 13:47:50
*** MESSAGE CONTINUATION ---- DIAGNOSTIC INFORMATION ***               
If one or more parts of the model are held together only by contact   
verify that the contact surfaces are closed.  You can check contact   
status in the SOLUTION module for the converged solutions using       
CNCHECK.                                                               

*** ERROR ***                          CP =      19.641  TIME= 13:47:50
*** MESSAGE CONTINUATION ---- DIAGNOSTIC INFORMATION ***               
Rigid body motion can also occur when net section yielding has         
occurred resulting in large displacements for small increments of load 
or when buckling has occurred.  You can plot the time history curve   
for node 2 in the UY direction to check for stiffness (slope of the   
curve) approaching zero.                                               
    >>> DOF LIMIT EXCEEDED.  MAX VALUE= 0.4623558E+08  LIMIT=  0.000000   
*** LOAD STEP    1  SUBSTEP    15  NOT COMPLETED.  CUM ITER =    25
*** BEGIN BISECTION NUMBER  1    NEW TIME INCREMENT=  0.64873E-03

    FORCE CONVERGENCE VALUE  =  0.7043E+06  CRITERION=  3593.


3)
*** WARNING ***                        CP =      57.672  TIME= 13:48:29
Contact element 8855 (real ID 18) status changes abruptly from contact 
(with target element 9274) -> no-contact.                             
    DISP CONVERGENCE VALUE  =  0.9079      CRITERION=  0.4927E-01
    LINE SEARCH PARAMETER =  0.9398    SCALED MAX DOF INC =  0.9079   
    THERE IS TOO MUCH PENETRATION AT    1  CONTACT POINTS OF THE 2D CONTACT ELEMENTS
    FORCE CONVERGENCE VALUE  =  0.9999E+05  CRITERION=  0.2263


4)
*** ERROR ***                          CP =      58.109  TIME= 13:48:29
Element 1216 (type = 3, PLANE183) (and maybe other elements) has become
highly distorted.  Excessive distortion of elements is usually a       
symptom indicating the need for corrective action elsewhere.  Try     
incrementing the load more slowly (increase the number of substeps or 
decrease the time step size).  You may need to improve your mesh to   
obtain elements with better aspect ratios.  Also consider the behavior 
of materials, contact pairs, and/or constraint equations.  Please rule 
out other root causes of this failure before attempting rezoning or   
nonlinear adaptive solutions.  If this message appears in the first   
iteration of first substep, be sure to perform element shape checking. 
*** LOAD STEP    1  SUBSTEP    29  NOT COMPLETED.  CUM ITER =    89
*** BEGIN BISECTION NUMBER  1    NEW TIME INCREMENT=  0.32733E-02


5)
*** WARNING ***                        CP =    428.906  TIME= 13:54:52
Material number 20 (used by element 9275 ) should normally have at     
least one MP or one TB type command associated with it.  Output of     
energy by material may not be available.   


Momentan versuche ich daher das Model zu optimieren, um zumindest den Großteil dieser Fehlermeldungen loszuwerden.

1)Durch einen Versuch, bei dem der Bolzen (vgl. Bild 2) unten bündig mit der Nabe abgeschnitten wurde und beide separat gelagert wurden, wurde festgestellt, dass alle Pivot-Warnungen und Fehler vermieden werden können. Diesbezüglich werde ich jetzt versuchen, diese über einen "keine Trennung" Kontakt zu verbinden, der die Fehler genauso vermeidet, aber nicht über alle Lastschritte aktiv sein darf. Das wird aber geändert, sobald ich begriffen habe, wie ich per APDL-Snippet Kontakte ein-/ausschalten kann.

2)Dieser Fehler scheint mir momentan eine Kombination aus einem "trennenden" Kontakt und zu wenigen Substeps zu sein, da ich mir vorstelle, dass durch einen zu großen Substep plötzlich die Kontaktflächen sich schon durchdringen und es plötzlich eine astronomisch große Rückstoßkraft gibt, die Versucht eines meiner Bauteile aus dem Bild zu schießen. Meine Einzige Idee besteht auch hier also darin, mein Kontaktproblem per APDL zu lösen und mit mehr Substeps zu rechnen.

3)Ich vermute, dass dieser Fehler beim Übergang von der Einpressbewegung der Einpressmatrize zur Wegfahrbewegung auftritt und einfach nicht zu vermeiden ist?!

4)Dieser Fehler scheint mir eine Ähnliche Behandlung, wie Nr. 2) zu verlangen.

5)Bezgl. dieses Fehlers habe ich versucht mich im Internet zu belesen, aber die Forenbeiträge, die ich gefunden habe sprechen nur von einem mangelhaften Management von der Materialdatenverwaltung durch ANSYS und das man es einfach ignorieren soll. Kann man das so machen, oder liegt der Fehler doch irgendwo bei mir?

Bezüglich all dieser Fehler, habe ich jetzt meine Vermutungen dargestellt und wäre über jede Anregung froh, mit der ich diese beheben kann, bzw. mit der ich mein Model weiter optimieren kann, um die Berechnung besser zu machen.

Kann ich z.B. das Netzt noch geschickter anpassen?,
sollte ich bestimmte Ecken verrunden?,
Gibt es sonst noch irgendwelche Wege, mein Model zu optimieren?,
Wie senke ich die Kontaktsteifigkeit, von der du gesprochen hast herab und was stelle ich mir darunter vor?

Eine weitere Frage, die sich mir immer wieder aufdrängt ist: Ist es schon ein Fehler, wenn eine Bisektion auftritt?
Ich stelle mir immer vor, wenn ich den Solver-Output lese, dass eine Berechnungsiteration nicht konvergiert ist und deswegen mit einem kleineren Schritt (Bisektion) dies nochmal versucht wird. Wenn es dann konvergiert, geht es ab dort weiter. Ich stelle mir also vor, dass der Fehlversuch quasi überschrieben wurde und nur lokal an dieser Stelle kleinere Schritte benötigt wurden.
Liege ich damit richtig?

Lg und Danke wie immer für Die Hilfe
Majan

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

farahnaz
Ehrenmitglied V.I.P. h.c.
Ing.


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

Beiträge: 2467
Registriert: 24.04.2007

CAE, FEM, Test, NPD

erstellt am: 05. Okt. 2018 20:17    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 Majan91 10 Unities + Antwort hilfreich

>>> The value of UY at node 2 is 46235578.7.

Finde Knoten 2. Wenn du Zwischenergebnisse hast, guck was passiert da.

------------------
Grüße, Moe

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

Duke711
Mitglied



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

Beiträge: 826
Registriert: 14.11.2016

erstellt am: 12. Okt. 2018 01:44    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 Majan91 10 Unities + Antwort hilfreich

Bisektion bedeutet oberflächlich, dass die programmgesteuerte Schrittweite zu groß war und wird nach der Bisektion automatisch um den Faktor 2 verringert. Zwischen den Zeilen interpretiert lassen sich hier aber oft schon Fehler im Modell erkennen, ein sauberes Modell konvergiert schon nach wenigen Zwischenschritten.
Die Kontaktsteifigkeit kann man unter den einzelnen Kontakt, wie den Kontaktalgorithmus, einstellen. Entweder um einen Faktor (Voreinstellung 10) oder einen Wert.
Abhängig vom Algorithmus führt eine geringe Kontaktsteifigkeit zu einer besseren Konvergenz und einer geringeren Elementenverzerrung. Anderwertig zu einer höheren Durchdringung.

Bezüglich der Modellverbesserung:
Eine bessere Netzqualität wird wenig bewirken. Hauptproblem am Modell sind Starrkörperverschiebungen vom Presstück (plastische Verformung) und zu große Verformungen und somit innere Kräfte (Elementenverzerrung).
Das Problem ist genau genommen für eine statische Analyse sehr grenzwertig. Die plastischen Verschiebungen sind nämlich nicht mehr genau bestimmbar und deshalb hat der Solver Probleme mit Starrkörperverschiebungen . Einfach gesagt gleicht das Modell einer Crashsimulation ((knickt der Stab nun nach links oder rechts aus?), eine unlösbare Aufgabe für den statischen Solver.

Mein Vorschlag:

- entweder die pastischen Verformungen durch Randbedingungen einschränken, Lagerrung / Kontakte etc.
- oder auf den expliziten Solver (Autodyn/Lsdyna) wechseln und einen sehr kurzen Zeitabschnitt, so dass das System sich noch nicht nenneswert von einem statischen unterscheidet, definieren.

Gerne kann man auch darüber berichten wie nun bei diesen Modell zu einer Lösung gekommen ist bzw. für welchen Weg man sich entschieden hat.


Nachtrag:

Kontakte lassen sich via APDL einfach aus- und anschalten. Ansonsten gibt es im Appstore das ACT EKILL/ALIVE, im der Version 19 wurde das EKILL/ALIVE als Kontaktsteuerung fest und robuster in Mechanical implementiert.

[Diese Nachricht wurde von Duke711 am 12. Okt. 2018 editiert.]

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

Majan91
Mitglied



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

Beiträge: 15
Registriert: 06.09.2018

erstellt am: 23. Okt. 2018 15:17    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 Antwort, leider war ich krank und heute ist mein erster Tag wieder an meinem Projekt.

Den Punkt mit der Kontaktsteifigkeit habe ich jetzt endlich gefunden und werde mal damit rumspielen, um zu sehen, ob das einen positiven Einfluss bringt.

Die EKILL/EALIVE ACT aus dem Appstore von ANSYS scheint genau das zu sein, was ich momentan noch verusche in APDL umzusetzen. Wegen der Beschränkung am Fachgebiet was das Installieren von Software angeht kann ich das leider erst nächste Woche ausprobieren, denke aber, dass es eine große Hilfe sein wird.


Was die Modelverbesserung angeht, so bin ich der Meinung, dass es über eine weiter Einschränkung/Lagerung nicht möglich ist, die Starrkörperbewegung bzw. plastische Verformung noch weiter zu begrenzen und denke auch, dass das keinen Sinn macht, da die plastische Verformung ja erwünscht ist. Wenn ich durch die Änderung der Kontaktsteifigkeit keine Besserung erziele, werde ich (sobald sich die Zeit dafür ergibt) einmal versuchen, das Ganze als transiente Berechnung zu simulieren.
Die expliziten Dynamiken (Crashähnlich) halte ich nicht für sonderlich sinnvoll, da abgesehen von der plastischen Verformung des Pressstück mit 0,1mm/s (Versuchsstand) eingepresst wird und es daher meiner Meinung nach eher quasistatisch statt dynamisch ist.
Das der Solver in der statischen Berechnung nicht weiß, ob der Ring nach rechts oder links knickt, ist natürlich bei der ersten Berührung möglich, aber um dem entgegenzuwirken, wurde die Flanke der Nut, die das Pressstück beim Einpressvorgang trifft vorgezogen (vgl. Bild 4), sodass eine Biegung nach innen begünstigt wird.

Damit erstmal Danke für den Input und ich stürze mich jetzt in die Arbeit und melde mich wieder mit meiner Lösung oder neuen Fragen.

[Diese Nachricht wurde von Majan91 am 23. Okt. 2018 editiert.]

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

Duke711
Mitglied



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

Beiträge: 826
Registriert: 14.11.2016

erstellt am: 25. Okt. 2018 00: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 Majan91 10 Unities + Antwort hilfreich

Das Problem mit der Elementenverzerrung wird aber auch der iterative Solver (transient) haben. Gegen Starkörperverschiebung ist auch der interative Solver anfällig.
Vorteil vom direkten Solver (explizit) ist, das sich dieser von einer Elementenverzerrung und Starkörperverschiebung überhaupt nicht beeindrucken lässt. Hier können die Elemente auch problemlos völlig zerissen werden.
Alternativ mal über ein dynamisches Netz, Mesh Morphing nachdenken.

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

Majan91
Mitglied



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

Beiträge: 15
Registriert: 06.09.2018

erstellt am: 15. Nov. 2018 12:18    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


LS1.txt


LS2.txt


Solver-Output.txt

 
Hallo nochmal,

ich habe mitlerweile eine Lösung für das hier angesprochene Hauptproblem gefunden und wollte sie nun auch einmal zeigen. Die Idee war es ja, zunächst eine "zu große" Verschiebung zu wählen, dann die Kraftreaktion in jedem Substep zu ermitteln und anhand dessen die Verschiebung zu wählen, bei der 90KN erreicht werden, sodass mit den Ergebnissen dieses Substeps weitergerechnet werden kann. Dies habe ich in meinem Command-Snippet LS1 (Datei im Anhang) umgesetzt.

Dabei haben sich einige Änderungen gegenüber dem ursprünglichen Plan ergeben:

Ein Punkt, hinsichtlich dessen mich mir nun unsicher bin, ob es eine gute Idee war, ist die Idee, den Substep unmittelbar vor dem Erreichen der 90KN zu wählen und ab dort in meinem zweiten LS eine Kraft von 90KN aufzuprägen, um den Punkt genau zu erreichen.
Schön daran wäre natürlich, dass ich die 90KN genau erreiche und daher meine Ergebnisse besser vergleichen kann, leider funktioniert dies momentan noch nicht 100%ig, da ich in einem Test nun leider sehen muss, dass ich nach dem Aufprägen der 90KN keine Reaktionskraft von 90KN erhalte. (Siehe dazu Command-Snippet LS2 (Datei im Anhang))

Um dies zu testen, habe ich in LS2 Punkt IV) eine Prüfung durchgeführt und deren Ergebnis ist in der Datei im Anhang Solver-Output zu finden. Scheinbar werden die Kräfte entweder nicht richtig aufsummiert oder (was ich für warscheinlicher halte) ich habe die Kraft nicht richtig aufgebracht, da ich mit den selben Befehlen in einer anderen Testsimukation, in der ich nur die Oberkante eines Zylinders mit einer Kraft beaufschlagen will ein seltsames Verhalten feststelle. Dabei wird die Kraft auf nur eine einzelne Node der oberen Kante (2D-Simulation, axialsymmetrisch) aufgebracht und die Kraftreaktion ist das 10-fache der aufgebrachten Kraft. Ich kann nicht nachvollziehen, wie dies geschieht.

In der Hauptsimulation erhalte ich dieses Verhalten nicht. Dort fühlt es sich eher so an, als wenn eine Node der unteren Kante (Lagerung, Kraftreaktion) nicht mit einbezogen wird (Node 358, Solver-Output) oder als ob die Kraft garnicht aufgebracht wird, da die Summe der Kraftreaktion am Ende von LS2 die gleiche ist, wie am Ende von LS1 (Um den Wert -3,6... der zuvor erwähnten Node kleiner).

Falls ich die Kraft in LS2 nicht richtig aufbringe, wäre ich für jede Hilfe dankbar!

Um nun auf den Punkt zurückzukommen, dass ich mir mit der Idee der Beaufschlagung mit 90KN, um den Zielpunkt genau zu erreichen, nicht mehr ganz so sicher bin wollte ich auch euch einmal fragen, ob ihr dies für sinnvoll haltet. Alternativ könnte ich nämlich einfach die Substepzahl in LS1 erhöhen und somit mit dem selben Code aus LS1 erheblich näher an 90KN liegen. Die Abstände zu 90KN werden dann zwar für jeden Designpoint entwas variieren, aber ich bin zuversichtlich, dass sie zwischen 89900 und 90000 liegen werden (aber leider mit erheblichen Rechenzeitsteigerungen, die natürlich lieber vermieden werden sollten). Daher könnte man dies leicht vernachlässigen.
Wenn es allerdings eine leichte Änderung für meinen LS2 gibt, mit dem ich den Punkt exakt treffen kann, wäre mir dies natürlich lieber.

Danke schonmal für die Hilfe mit dem Hauptproblem (ich hoffe die Ergebnisse in LS1 können auch anderen noch helfen)!
Ich würde mich auch sehr freuen, wenn ihr Tipps für mein 2. Problem hättet.

Lg Majan

[Diese Nachricht wurde von Majan91 am 15. Nov. 2018 editiert.]

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

Majan91
Mitglied



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

Beiträge: 15
Registriert: 06.09.2018

erstellt am: 16. Nov. 2018 15:44    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


Simulation.txt


Testsimulation.txt


Testsimu.png

 
Ich habe nochmal eine Rückfrage zur Aufbringung der Kraft per APDL.

Diese beruht nach wie vor darauf, dass ich, wie im vorherigen Beitrag schon erwähnt per Command-Snipped (F-Befehl) Kräfte auf die Ndes der entsprechenden Kanten/Flächen aufbringe, jedoch keine Reaktionskräfte erhalte. Dies liegt meiner Meinung daran, dass die Kraft erst garnicht aufgebracht wird (die Kraftreaktion ist fast identisch zu der am Ende von LS1). Meine Meinung wird dadurch bestärkt, dass ich auch einmal eine um den Faktor 10 größere Kraft aufgeprägt habe und die Reaktionskraft sich GARNICHT verändert hat!

Ich habe nach der Aufprägung der Kräfte auf die einzelnen Loads dies immer mit FLIST,ALL getestet und es wird mir auch für jede relevante Node ein sinnvoller Wert angezeigt.

In einer Testsimulation, die ich schon erwähnt habe, habe ich es mitlerweile hinbekommen, dass die Kraft aufgeprägt wird und ich erhalte auch die passende Kraftreaktion. ... Mit dem selben Code erhalte ich in meiner eigentlichen Simulation jedoch keine Reaktionkräfte.
Siehe dazu die Textdateien, in denen jeweils der die Kraftaufprägung betreffende Code, dann der Solveroutput zur Kraftaufbringung und dann der Solver-Output zu den Reaktionskräften zu finden ist.
Eine weitere Merkwürdigkeit ist, wie die Kraft in der Testsimulation aufgebracht ist, da es so aussieht, als würde sie nur auf der ersten Node sein. Falls das durch meine Eingabe so falsch definiert wurde wäre ich höchst dankbar, wenn mich jemand berichtigen könnte.

Falls irgendjemand Ideen hat, wie ich die Kräfte besser per APDL verwalten kann, damit ich endlich meine Berechnung abschließen kann, wäre ich sehr dankbar!

Lg Majan

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