---

Hallo,

mir wurde schon vor einigen Wochen hier erfolgreich geholfen, deswegen wende ich mich mit diesem Problem wieder an euch.

Nochmal kurz und knapp die Aufgabenstellung: Maßstabseffekt bei Balken ohne Querkraftbewehrung. Im Grunde eine Parameterstudie um herauszufinden, welchen Einfluss die verschiedenen Materialeigenschaften und Bewehrungsanordnungen etc. auf die Querkrafttragfähigkeit haben.

Kurz zur Durchführung: Ich habe die Balken modelliert und die Materialparameter sind auch eingegeben. Die .cae-Datei habe ich hier hochgeladen: http://uploaded.net/file/x0fbt9lc , falls jemand Lust und Laune verspürt, mal drüber zu schauen.

Die Last wird weggesteuert über eine mit "tie"-constraint angebundene Lastplatte aufgebracht.

Mein aktueller Balken hat eine Höhe von 640mm. Bei meinem ersten Versuch bin ich mit einer Senkung der Lastplatte um 40mm gestartet. Dies blieb erfolglos. Dann auf 80 usw. Bis ich letzlich auf 300mm war. Halte ich fast für undenkbar, in Anbetracht dessen, dass das schon fast der halben Balkenhöhe entspricht.

Ich prüfe dabei immer die Werte der Auflagerkräfte. Wenn diese konstant steigen, ist das für mich das Zeichen, dass es noch kein Versagen gegeben hat. Ich erwarte hier eigentlich dann einen abfallenden Ast im Graphen.

Einige Dinge die mir bisher aufgefallen sind:

1. Meine ausgegebenen Daten werden weniger, je höher ich die Verschiebung einstelle, OBWOHL ich den Output request erhöht habe. Insgesamt von (frequentely spaced time intervals, interval = 100 bis interval = 300, je größer die Verschiebung wurde). Ich war der Meinung, dass dies so richtig ist. Kann das jemand bestätigen?

2. Bei meinem Versuch mit Absenkung der Lastplatte um 230mm war die Auflagerkraft größer (ca. 101kN) als bei dem Versuch mit einer Senkung um 300mm (ca. 96kN).
Ich frage mich nun: Kann es sein, dass das Versagen irgendwo dazwischen liegt (zwischen 300 und 230) und mir eventuell mangels Output-Frequenz irgendwas nicht ausgegeben wird?

3. Das Rissbild im Visualization module lässt darauf schließen, dass das Versagen nicht weit entfernt ist. Allerdings gab es zumindest optisch keine großen Änderungen zwischen den großen Absenkungen wie zB 230 und 300mm.

Mein kleinster Balken hat auf Anhieb versagt. Das war relativ problemlos. Auflagerkraft fällt gegen Ende schön ab. (Gleiche Betonwerte wie bei diesem Balken)

Falls jemand von den ABAQUS-Veteranen hier eine Idee hätte, wäre ich sehr dankbar.
Ich weiß mittlerweile nicht mehr was ich noch ändern soll.
Da ich auch nur eine monatliche Begrenzung an Rechenstunden im Uni-Rechenzentrum habe, möchte ich nicht auf ganz eigene Faust blind rumprobieren. Diesen einen Balken habe ich mittlerweile schon 15 mal mit verschiedenen Einstellungen durchrechnen lassen. Das fehlende Versagen macht aber alles völlig unbrauchbar. 

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

---

Falls du anderweitig keine Lösung findest: Input-Datei, evtl komprimiert, hier hochladen. Evtl kann ich mal reinschauen

------------------
Pam

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

---

V07_640_300mmSenkung.zip

Danke für die Antwort!

Ich habe die gezippte Datei mal angehangen. (Wohlgemerkt mit der riesigen Verformung von 300mm)

Ich glaube ich bin aber auf mein eigentliches Problem gestoßen. Vielleicht kann jemand beurteilen, ob das richtig ist.

Ich habe erfahren, dass es aufgrund der Tatsache, dass Beton spröde ist und meine eingegebene Bruchenergie relativ gering ist, dazu führen kann, dass ABAQUS den Nachbruchbereich nicht wiedergibt. Ein abfallender Ast bei der Auflagerkraft würde dementsprechend nicht auftreten.

Nun war aber gerade jener abfallende Ast für mich ein Indiz dafür, dass mein Bauteil versagt hat.

Wäre denn ein anderes Indiz dafür, dass es zum Materialversagen gekommen ist, die Tatsache, dass ich eine Absenkung der Lastplatte von sagen wir 70mm "verlangt" habe, aber bei der Auswertung bei 19mm Absenkung Schluss ist?

Abaqus muss ja irgendeinen Grund haben, die Rechnung abzubrechen und an der Überschreitung der max. Inkremente liegt es nicht.
Die Rechnung wird nach ca. 1000 Inkrementen abgebrochen obwohl max. Inkremente bei 20000 liegt.

Wäre das also ein Indiz dafür, dass es zum Versagen gekommen ist?

Mich hatte bisher immer stutzig gemacht, dass es zu verschiedenen Auflagerkräften und Vertikalverschiebungen kommt bei größerer Absenkung der Lastplatte. Ich hätte erwartet, dass es dann immer bei der selben Verformung abbricht als Indiz fürs Versagen, aber ich vermute mal, dass dies mit Ungenauigkeiten zusammenhängt die sich vielleicht durch größer werdende Inkremente ergeben.

Ich rechne übrigens mit double precision und bin mittlerweile dazu übergegangen, alle n=10 Inkremente meinen Output anzufordern. Das löst auch das Problem von weniger werdenden Daten. Hatte vorher evenly spaced time intervals und irgendwie blicke ich da nicht genau, wie da der Output angefragt wird.

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

---

Zur BetonModellierung kann ich nichts sagen.

Was auffällt:
1) Der Preprozessor meldet, dass das Embedding der Bewehrung fehlschlägt
2) Lastplatte und Gegenlager können sich nicht verdrehen und nehmen dementsprechend Biegemomente auf. Ob das so gewollt ist ?

------------------
Pam

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

---

V07_1280.zip

Also den Punkt unter 1) kann ich mir nicht erklären. Ich erstelle meine input-Dateien immer mit "Data Check" und bei mir ist der Check immer erfolgreich verlaufen bisher.

Ich habe nochmal eine input-Datei erstellt, diesmal von einem anderen Balken. Eventuell möchtest du ja nochmal drüberschauen. Vielleicht ist da irgendwas schief gelaufen bei der anderen. Kann es mir, wie gesagt, nicht erklären wieso die Meldung bei dir kommt.

Zu 2): Das Modell an sich wurde so von meinem Betreuer abgesegnet.

Die Modelle entsprechen realen Versuchen. In denen ist wie in meinem Modell eine Stahlplatte unter dem Beton-Balken und DANN auf Rollen gelagert. Ich hoffe, das mit der Verschiebung in 2-Richtung korrekt dargestellt zu haben. Also (denke ich) stimmt es so, wenn ich die Auflagerplatte dann als Loslager ausbilde. Ebenso wurde in dem Versuch mit der Lastplatte verfahren. Sollte also so korrekt sein. 

Ich danke vielmals für deine Mühe!! 

Ich starte mal noch einen Rechenversuch mit wesentlich mehr Output. Vielleicht wurde der Nachbruchbereich auch einfach nicht getroffen, weil die Output-Frequenz zu gering war.

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

---

Zu 1) Der Preprozessor legt typischerweise eine Datei mit endung .pre an. Hier findest Du jede Menge Warnungen, u.a. zum fehlenden Embedding. Ein Blick ins Modell zeigt, dass keine Host-Elemente angegeben wurden. Der Checkrun läuft selbstverständlich durch, da kein Abaqus-Fehler (Syntax etc.) aufgetreten ist. Empfehlung: Modell überarbeiten bis pre-Lauf ohne nennenswerte Warnungen.

Zu 2) Rolle heißt wohl, dass Verdrehungen in der Ebene möglich. Deine Modellierung erlaubt nur Verschiebungen....

------------------
Pam

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

---

embedded.jpg

.pre-Dateien kann ich auf meinem ganzen Computer nicht finden.

Leider auch nicht im User Manual http://www.egr.msu.edu/software/abaqus/Documentation/docs/v6 .7/books/usb/default.htm?startat=pt01ch03s05aus29.html

Ich weiß nur, dass ich bei meinen absoluten Abaqus-Anfängen während dem Data Check (der daraufhin abgebrochen wurde) darauf hingewiesen wurde, dass embedded regions keinen Host haben, oder zB missing section properties. Daraufhin wurde schon eine kleine .odb erstellt in der genau die Parts und Instances markiert wurden, die fehlerhaft waren. Deswegen habe ich in meinem vorigen Post mit dem erfolgreich verlaufenen Data Check argumentiert.

Ich habe als Host das "whole Model" angegeben. Ist das so verkehrt? Müsste ich den Betonbalken als Region nehmen? Einen Screenshot habe ich angehangen.

Korrekt. Ich möchte nur die 2-Verschiebung blockieren, alle anderen Freiheitsgrad sollen frei sein. Habe auch dazu einen Screenshot angehangen.

In meinem Guide zu einem anderen Beispielbalken steht geschrieben, dass ich einen Freiheitsgrad blockiere, in dem ich den Wert 0 eingebe. Quasi also eine Verschiebung/Rotation von 0 aufbringe.
Ein Wert ungleich Null würde im Umkehrschluss eine Verschiebung/Rotation ungleich Null von Anfang an aufbringen.
Demnach müsste es doch korrekt sein, wenn ich die Felder einfach grau lasse, also keine Verschiebung/Verdrehung aufbringe. Wie müsste ich es anders machen?

Dann sollte es ja richtig sein, wenn die Auflagerplatte auf Rollen gelagert ist, da ich da ja keine Verdrehung eingebe und sie somit zugelassen sind (Also keine Momente übertragen). Veilleicht bin ich aber auch völlig auf dem Holzweg.

Nimm mir die Fragen nicht übel... Ich hatte bis eben gedacht, dass ich alles verstanden hätte, was das betrifft.

[Diese Nachricht wurde von HeftyFine am 17. Feb. 2016 editiert.]

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

---

Hier mal ein Auszug der pre-Datei

  *solidsection, elset=ASSEMBLY_BüGEL-1-LIN-5-1__PICKEDSET2, material=STIIIB
  *embeddedelement
  *embeddedelement

***WARNING: EMBEDDED ELEMENTS HAVE BEEN DEFINED WITHOUT A HOST ELEMENT SET.
            SPECIFYING A HOST ELSET IS RECOMMENDED PARTICULARLY IF THIS
            ANALYSIS IS TO BE FOLLOWED WITH AN IMPORT ANALYSIS. THIS MAY CAUSE
            UNEXPECTED BEHAVIOR UPON IMPORT SINCE ALL ELEMENTS IN THE VICINITY
            INCLUDING ANY NEWLY INTRODUCED ELEMENTS IN THE IMPORT ANALYSIS
            WILL BE CONSIDERED FOR EMBEDDING THESE ELEMENTS.
  *embeddedelement

***WARNING: EMBEDDED ELEMENTS HAVE BEEN DEFINED WITHOUT A HOST ELEMENT SET.
            SPECIFYING A HOST ELSET IS RECOMMENDED PARTICULARLY IF THIS
            ANALYSIS IS TO BE FOLLOWED WITH AN IMPORT ANALYSIS. THIS MAY CAUSE
            UNEXPECTED BEHAVIOR UPON IMPORT SINCE ALL ELEMENTS IN THE VICINITY
            INCLUDING ANY NEWLY INTRODUCED ELEMENTS IN THE IMPORT ANALYSIS
            WILL BE CONSIDERED FOR EMBEDDING THESE ELEMENTS.
  *boundary
  *boundary
  *boundary
  *boundary
  *boundary
  *boundary
  *boundary
  *boundary
  *tie, name=ASSEMBLY_AUFLAGER, adjust=YES

***WARNING: FOR *TIE PAIR (ASSEMBLY__PICKEDSURF16-ASSEMBLY__PICKEDSURF17),
            ADJUSTED NODES WITH VERY SMALL ADJUSTMENTS WERE NOT PRINTED.
            SPECIFY *PREPRINT,MODEL=YES FOR COMPLETE PRINTOUT.
  *tie, name=ASSEMBLY_LASTEINLEITUNG, adjust=YES

***WARNING: FOR *TIE PAIR (ASSEMBLY__PICKEDSURF18-ASSEMBLY__PICKEDSURF19),
            ADJUSTED NODES WITH VERY SMALL ADJUSTMENTS WERE NOT PRINTED.
            SPECIFY *PREPRINT,MODEL=YES FOR COMPLETE PRINTOUT.
  *tie, name=ASSEMBLY_AUFLAGER, adjust=YES
  *tie, name=ASSEMBLY_LASTEINLEITUNG, adjust=YES
  *tie, name=ASSEMBLY_AUFLAGER, adjust=YES
  *tie, name=ASSEMBLY_LASTEINLEITUNG, adjust=YES
  *solidsection, elset=ASSEMBLY_BETONKöRPER-1__PICKEDSET22, material=BETON
  *solidsection, elset=ASSEMBLY_LäNGSSTAB_26MM-1__PICKEDSET13, material=STIIIB
  *solidsection, elset=ASSEMBLY_LäNGSSTAB_26MM-1-LIN-2-1__PICKEDSET13, material=STIIIB
  *solidsection, elset=ASSEMBLY_RANDAUFLAGER-1__PICKEDSET2, material=STAHL_ELASTISCH
  *solidsection, elset=ASSEMBLY_LASTEINLEITUNG-1__PICKEDSET3, material=STAHL_ELASTISCH
  *solidsection, elset=ASSEMBLY_BüGEL-1__PICKEDSET2, material=STIIIB
  *solidsection, elset=ASSEMBLY_BüGEL-1-LIN-2-1__PICKEDSET2, material=STIIIB
  *solidsection, elset=ASSEMBLY_BüGEL-1-LIN-3-1__PICKEDSET2, material=STIIIB
  *solidsection, elset=ASSEMBLY_BüGEL-1-LIN-4-1__PICKEDSET2, material=STIIIB
  *solidsection, elset=ASSEMBLY_BüGEL-1-LIN-5-1__PICKEDSET2, material=STIIIB
  *surface, type=ELEMENT, name=ASSEMBLY__PICKEDSURF16
  *surface, type=ELEMENT, name=ASSEMBLY__PICKEDSURF17
  *surface, type=ELEMENT, name=ASSEMBLY__PICKEDSURF18
  *surface, type=ELEMENT, name=ASSEMBLY__PICKEDSURF19
  *tie, name=ASSEMBLY_AUFLAGER, adjust=YES
  *tie, name=ASSEMBLY_LASTEINLEITUNG, adjust=YES
  *embeddedelement

***WARNING: EMBEDDED ELEMENTS HAVE BEEN DEFINED WITHOUT A HOST ELEMENT SET.
            SPECIFYING A HOST ELSET IS RECOMMENDED PARTICULARLY IF THIS
            ANALYSIS IS TO BE FOLLOWED WITH AN IMPORT ANALYSIS. THIS MAY CAUSE
            UNEXPECTED BEHAVIOR UPON IMPORT SINCE ALL ELEMENTS IN THE VICINITY
            INCLUDING ANY NEWLY INTRODUCED ELEMENTS IN THE IMPORT ANALYSIS
            WILL BE CONSIDERED FOR EMBEDDING THESE ELEMENTS.

------------------
Pam

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

---

Ein "Element-Set" im wörtlichen Sinne habe ich ja tatsächlich nicht als Host definiert, sondern eben das ganze Modell mit der "whole model"-Host-Beziehung. Wenn ich also theoretisch, das ganze Modell (abgesehen von der Bewehrung) als Set definiere, müsste der Fehler ja behoben sein. Wobei dann diese "whole-model"-Option nichtig ist.

Ich bin gerade dabei rauszufinden, wie ich an so eine .pre-file komme. Dann kann ich mal ein wenig rumexperimentieren und gucken, was verschiedene Änderungen bewirken. Danke für den Auszug aus der .pre!

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

---

Dann stehts bei Dir in der dat-Datei

------------------
Pam

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

---

Tatsächlich taucht die Meldung nicht mehr auf, wenn ich Beton und Auflagerplatte/Lastplatte als Hostregion bestimme. (War übrigens wirklich .dat bei mir, danke!)

Wieso wird denn "whole model" nicht akzeptiert? Oder kommt die Meldung gar immer, wenn man kein "Set" in dem Sinne als Host definiert und ist vielleicht gar nicht schlimm? Ich werde mal eine Vergleichsrechnung durchführen und schauen, ob sich bei meinen Resultaten irgendwas ändert.   

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

---

Hast du noch einen Tip, wie ich das Auflager deiner Meinung nach gestalten müsste um Verdrehungen zuzulassen? Momentan ist es noch so wie oben im Screenshot. Was müsste ich bei den VerdrehungsFG eingeben um Verdrehung zu erlauben?

Edit: Die Umstellung von "whole model" auf ein Host-Set änderte nichts an den Resultaten. Werde aber jetzt trotzdem mit der neuen Host-Region arbeiten.

[Diese Nachricht wurde von HeftyFine am 17. Feb. 2016 editiert.]

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

---

Im Screenshot ist doch nur U2 gesperrt, d.h. Bewegungen und Rotationen um alle anderen Freiheitsgrade sind erlaubt.

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

---

Wenn die Lagerung, wie im Bild rechts gezeigt, längs einer Linie erfolgt, dann ist die Verdrehung um X möglich. Drehungen um Y und z dagegen nicht.

------------------
Pam

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

---

Last-Verformung.jpg

Ah, der Groschen ist gefallen.

Die linienförmige Lagerung ist also das Problem. Okay, ich lasse mir was einfallen.

Jetzt habe ich nur noch eine letzte Frage, dann seid ihr mich auch wieder los:

Ich hatte ja schon angesprochen, dass ich teilweise Probleme habe zu entscheiden, ob es letzlich zum Versagen gekommen ist oder nicht.
In dem Screenshot habe ich einen Plot von meinem größten Balken (Über 10m hoch) angehangen zur Vertikalverschiebung unterhalb der Lastplatte vs. Auflagerkraft. Die gegen Ende abfallende Auflagerkraft bleibt aus.

Eingegebene Verschiebung der Lastplatte waren 120mm. Erreicht werden hier, wie man sieht, knapp 50mm, bei ca. 8000 Inkrementen (Eingestellter Maximalwert: 100.000)

Was mir auffällt ist, dass die letzten ~20 Daten alle dieselben Werte ausgeben. Habe mir alle 8 Inkremente den Output angefordert (Viel zu viel eigentlich, aber hatte da etwas rumprobiert und wusste nicht, dass mich da so viel erwartet.)
Gleichzeitig zeigt mir aber der Graph, dass zwischenzeitlich, bei geschätzt 18mm Vertikalverschiebung, ein Abfall der Auflagerkraft stattfindet, welcher danach wieder ansteigt. Hatte ich bei meinen anderen Balken bisher nicht. Da war mein Graph immer monoton steigend.

Die Tatsache, dass am Ende die Werte quasi alle gleich sind IN KOMBINATION damit, dass meine aufgebrachte Verschiebung nicht erreicht wurde lässt mich irgendwie intuitiv darauf schließen, dass es zum gewünschten Materialversagen gekommen ist. Da auch die max. Inkrementzahl nicht erreicht wurde kann auch aus einem solchen Grund nicht abgebrochen worden sein.

Erklären kann ich mir hier nur nicht, warum es zu diesem zwischenzeitlichen Abfall gekommen ist und wieso am Ende die Werte alle gleich sind. Liegt es daran, dass Abaqus bei beginnender plastischer Verformung der Elemente die Last in kleineren Schritten aufbringt?

Wenn mir jemand noch darauf eine Antwort geben könnte und auf die Frage ob meine Argumentation bzgl. des Versagens richtig ist, wäre für mich endlich alles geklärt, was noch offen war. 

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

---

Die Kurve lässt Anrisse im Material vermuten. Letztendlich wird aber immer noch Kraft aufgebaut.

Die geringen Änderungen am Ende weisen auf sehr kleine Inkremente hin, aber nicht auf Versagen generell

------------------
Pam

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

---

Aber wenn ich doch die Verformung mit 80 eingebe und Abaqus nur bis 50 rechnet muss das ja irgendwas bedeuten, da ja die max Inkremente nicht überschritten wurden.

Das ist mir sehr unverständlich.

Ich habe mal Rechnungen mit höherer Bruchenergie laufen lassen und schaue mal, ob und wie sich da der Nachbruchbereich darstellt...

Edit: Der Abfall des Graphen wird schon extrem deutlich, jetzt wo die Bruchenergie höher ist. Ich vermute also einfach mal, dass die Bruchenergie zu gering war bei meinen ersten Rechnungen, um den Nachbruchbereich weiter abzubilden und deswegen die Rechnung beendet wurde. Anders kann ich mir das nicht erklären. Ist aber ja schonmal eine wichtige Erkenntnis. Bruchenergie ist schließlich auch ein Parameter dessen Einfluss ich untersuchen soll 

[Diese Nachricht wurde von HeftyFine am 19. Feb. 2016 editiert.]

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