---

connector.png

Guten Abend miteinander,

ich verzweifle an der Modellierung eines weichen Auflagers. Grund für das weiche Auflager ist, dass sich mein Modell etwas steifer verhält, als es sollte. Ich habe deswegen den kompletten Versuchsstand mal probeweise modelliert und dann belastet. Festgestellt habe ich, dass es zu einer kleinen elastischen Durchbiegung kommt, welche ich nun wiederum gerne in Form einer Feder ins Modell implementieren möchte um nicht den kompletten Versuchsstand immer wieder mit simulieren zu müssen.

Die Fläche meines Modells, welches bisher starr gelagert war, habe ich dafür mit einem reference Point gecoupled und diesen wiederum mit einem weiteren Reference Point über einen "Translator"-Connector verbunde (siehe angehängtes Bild). Diesem Connector habe ich eine Federsteifigkeit von 12500N/mm zugewiesen (entspricht dem Verhalten des Versuchsstandes in der Simulation). Es gestaltet sich aber irgendwie schwieriger als gedacht. Ohne Feder ist das Modell an meinem Laptop in 1,5h gerechnet und braucht etwa 250.000 Inkremente.

Das Modell mit Feder habe ich dagegen heute nach über 1,5 TAGEN Rechendauer auf einem Rechencluster abgebrochen. Erfolgt waren über 23 Mio. Inkremente und das obwohl gerade einmal 10% der geplanten Verschiebung aufgebracht waren.

Normalerweise hätte ich das ganze wohl spätestens jetzt verworfen, wenn die Steifigkeit durch die Feder nicht quasi perfekt getroffen worden wäre. Für mehrere Versuche ist die Rechendauer aber nicht zu rechtfertigen.

Ich nehme an, dass eine linear-elastische Feder eigentlich nicht so komplex ist, dass eine Rechnung so extrem beeinflusst wird. Also muss das Problem eher an meinen Eingaben, anstatt der Feder liegen.

Ich erhalte folgende Warnung:

The nodes in node set WarnNodeMassAugment-Step1 areinvolved in constraints that have to be solved using the implicit solver. The nodes involved in these constraints have masses that are highly mismatched, hence the implicit solver may encounter convergence problems. To prevent this from happening the masses of the nodes in this set have been augmented by a small amount. The additional mass will almost never affect the solution significantly except for strongly dynamic analyses.   

(BEZIEHT SICH AUF RP-2)

The nodes in node set WarnNodeInertiaAugment-Step1 areinvolved in constraints that have to be solved using the implicit solver. The nodes involved in these constraints have rotary inertia that are highly mismatched, hence the implicit solver may encounter convergence problems. To prevent this from happening the rotary inertias of the nodes in this set have been augmented by a small amount. The additional rotary inertia will almost never affect the solution significantly except for strongly dynamic analyses.

(BEZIEHT SICH AUF RP-1)

Ich verstehe es so, dass jeweils ein connector Element eine Masse zugewiesen bekommt, da es sich eben bewegt und entsprechend träge ist, was wiederum nur mit Masse möglich ist. Ich habe bereits versucht den im Set dargestellten Reference Points eine Masse zuzuweisen, aber leider behebt das das Problem nicht. Abgesehen davon wüsste ich auch nicht, welche Masse sinnvoll ist. Da es sich um einen quasistatischen Versuch handelt, vermute ich aber mal, dass die Masse keinen großen Einfluss haben sollte.

Kann mir jemand unter die Arme greifen? 

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

---

Mhhh, hast du die Integration des Connectors geändert? Eventuell ist die von Abaqus automatisch definierte Masse zu gering relativ zu der von dir definierten Steifigkeit.

Users Manual 31.2.1 Connector behavior:
In Abaqus/Explicit kinematic constraints, stops, locks, and actuated motion in connector elements are treated with implicit time integration. By default, connector constitutive behavior (for example, elasticity, damping, and friction) is also integrated implicitly. The advantage of implicit time integration is that elements with these behaviors do not affect the stability or time incrementation of the analysis in any way.

When “soft” springs are modeled with connectors, a more traditional explicit time integration for the constitutive response can be used. This explicit time integration may lead to a small improvement in computational performance. However, explicit integration of relatively stiff springs will reduce the global time increment size, since such connector elements are included in the stable time increment size calculation.

Du kannst ja mal einige Dinge ausprobieren. In der .sta kannst du ja nach Beginn der Analyse sehen, wie die Auswirkung auf das stabile Zeitinkrement ist und die Rechnung dann wieder abbrechen.

Optionen zum testen:
- Viel Masse auf die Knoten geben.
- Die Integration des Connectors umstellen.
- Eine normale Feder zwischen den RPs (oder to-ground) anbringen und die anderen DOFs mit Randbedingungen halten. Siehe Interaction-Modul > Special > Spring/Dashpot

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

---

Energiebilanz.jpg

Hallo Mustaine!

Danke Dir, für Deine Hilfe. Ich habe das Problem letzlich in den Griff bekommen. Was genau der Grund war, kann ich momentan noch nicht sagen. Das liegt vor allem daran, dass ich mein Modell anhand einer weiteren Symmetrieachse nochmal neu erstellt habe und bis zum Lösen des Federproblems mit diesem weiterrechnen wollte. Mit diesem neuen Modell hatte ich das Problem mit den Inkrementen nicht. Den 23 Mio. Inkrementen stehen nun ~150.000 gegenüber. Also durchaus akzeptabel.

Da es mir ja erstmal auch nur um die Steifigkeit ging, habe ich alle Materialien auch nur elastisch gelassen und die Rechnung ist in knapp 5-10 min am Laptop beendet.

ABER (ich wünschte, da wär kein "aber"...): Jetzt habe ich ein neues Problem.

Ich nutze statt connectors jetzt den Spring-connector, wie von Dir beschrieben (ist etwas weniger Aufwand mit der Konfiguration). Diesen habe ich zwischen den zwei Reference Points angeordnet (Spring-to-ground geht laut manual nur bei impliziter Berechnung).

Jetzt spinnt aber meine Energiebilanz. Im Grunde sind alle Energien in Ordnung, abgesehen von der ETOTAL, welche sich meines Wissens nach wie folgt zusammensetzt:

ETOTAL=  ALLIE (total internal energy) + ALLKE (kinematic energy) + ALLVD (viscous dissipation energy) + ALLFD (frictional dissipation energy) – ALLWK (external work)

Ein Blick auf das angehängte Bild der Energiekomponenten zeigt: Alle Summanden sind die ganze Rechnung über positiv und ALLWK ist niemals größer als die Summe aus den restlichen Summanden. Wie ist es dann zu erklären, dass meine totale Energie teilweise bei -0.15*10^6 liegt?

Kommt durch die Feder noch eine Energiekomponente hinzu? Ich würde natürlich gerne einen ansatzweise konstanten Verlauf von ETOTAL haben, da mein Versuch statisch ist und ich verstehe nicht ganz, wieso die lineare Feder das so krass verändert... 

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

---

Ich weiß nicht, was da passiert ist. Aber offenbar wurde einer meiner Reference Points nicht von Abaqus registriert, obwohl er zweifelsohne richtig gesetzt war. Coupling und Auflager etc. war alles in Ordnung und in der Assembly war der Reference Point auch zu sehen.

Durch Zufall ist mir aufgefallen, dass besagter Reference Point aber nicht im Viewport meiner .odb angezeigt wurde, als ich es in den Optionen eingeschaltet habe. Ich habe anschließend nochmal einen neuen Punkt gesetzt und alles wieder genau so gemacht, wie vorher. Und schon passte alles. Energien in Ordnung, Auflagerkraft in Ordnung.

Leider ist das Ergebnis mit der Feder doch nicht so gut, wie erhofft. Der elastische Teil passt zwar, aber sobald es zu Betonschädigung infolge CDP kommt, gibt es starke "Schwankungen" innerhalb der Auflagerkraft. Durch die Feder wird das Verhalten nur noch verstärkt.

Ist zwar schade, aber ich denke, dass ich immerhin nun die Anwendung von Connectors und Federn verstanden habe. 

Also danke!

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