Hallo liebes Forum,
für meine Masterarbeit modelliere ich einen sehr detaillierten Verbundträger aus Holz. Ich habe in meinem System das Problem, dass ich verschiedene Ergebnisse (Last-Verformungskurve in Feldmitte) erhalte, je nachdem wie ich meine Federn zur Kopplung definiere. Wenn ich sie direkt in Grasshopper im Modul “Elastic Link” mit Steifigkeiten belege, bekomme ich das richtige Ergebnis, das auch den Ergebnissen aus dem Schubanalogieverfahren entspricht. Wenn ich jedoch ein Federmaterial zuweise (MNO 101), dann wird das Ergebnis deutlich steifer, obwohl dieselben Steifigkeiten im Report Browser zu sehen sind wie zuvor. Ansonsten ändert sich nichts im System, ich habe auch keinen Unterschied in der .txt aus "Alle Tasks als Text speichern" gefunden. Die einzige Änderung ist die Definition der Federsteifigkeit, z.B. einmal als
SPT 1056 X 0.11000000 0.00000000 0.02400000
SPTS REF 1040 CP 10000000 CM 10000000 CQ 2519.2 DX 0 DY 0 DZ 1
vs.
SPT 1056 X 0.11000000 0.00000000 0.02400000
SPTS REF 1040 CP 0 CM 0 CQ 0 DX 0 DY 0 DZ 1 MNO 101
Das Material 101 ist als “Arbeitslinie für Standardfedern” in SSD definiert. Dabei habe ich die Option “linear-elastisch” gewählt und dieselben Steifigkeiten eingegeben. Ob ich dabei als Materialtyp “hyperelastisch” oder z.B. “Elastoplastisch, anisotrop” gewählt habe, hat hier keinen Unterschied gemacht.
Interessanterweise tritt das Problem nur bei einer Laststeigerung auf. Beim ersten Lastschritt liegen die Kurven beider Varianten noch aufeinander, weichen aber ab dem zweiten Lastschritt voneinander ab. Außerdem scheint auch die Steifigkeitseingabe richtig zu sein, weil eine Rückrechnung von k=PT/vt in den Federergebnissen zeigt, dass die Federn mit der richtigen Steifigkeit reagieren. Die lokalen Verschiebungen und Kräfte der Federn sind also einfach nur kleiner, das Verhältnis stimmt aber.
Leider brauche ich die Eingabe über eine Federarbeitslinie, um mein eigentliches, nichtlineares Modell zu implementieren.
Kann mir hier jemand beim Finden der Ursache weiterhelfen? Ich habe die jeweiligen Modelle und die ase-Berechnung mal an den Beitrag angehängt.
Vielen Dank schonmal!
model_GH_spring.dat (82.4 KB)
model_worklaw.dat (81.3 KB)
ase.dat (189 Bytes)
Wie die Definition der Arbeitslinien aussieht, ist aus den angehängten Dateien nicht ersichtlich. Aber grundsätzlich muss da der Unterschied zwischen beiden Varianten sein. Schau Dir mal die Arbeitslinie in der Reportbrowserausgabe an, vielleicht hast du dann eine Idee.
Beste Grüße,
Jost
Hallo Jost,
danke für die Antwort! Tatsächlich sind die Steifigkeiten aus der Arbeitslinie im Report Browser genau gleich wie die aus der GH-Eingabe (siehe pdf). Das System reagiert im ersten Lastschritt auch immer mit der richtigen Steifigkeit (landet auf der richtigen Kurve, egal wie viele Lastschritte gewählt werden), wird aber ab Lastschritt 2 steifer. Das Verhältnis von Federquerkraft/Federquerverschiebung stimmt auch laut Tabelle in jedem Lastschritt, was dafür spricht, dass die Steifigkeit selbst richtig eingegeben ist.
Report_browser_output.pdf (50.1 KB)
Ich habe mir zur Fehlersuche eine Systemsteifigkeit definiert, die aus ΔF/Δw in Feldmitte je Lastschritt n berechnet wird. Während diese Systemsteifigkeit mit der Grasshopper-Feder konstant bleibt, pendelt sich die aus der Federarbeitslinie bei einem höheren Wert ein. Merkwürdig ist dabei, dass egal wie viele Lastschritte ich zum Erreichen der Gesamtlast wähle, die Systemsteifigkeit ist in Lastschritt 1 immer gleich, in 2 immer gleich, in 3 immer gleich etc., obwohl der Absolut-Wert der aufgebrachten Last je Lastschritt natürlich variiert (siehe Bild)
Falls jemand eine Idee hat, woran das liegen kann, bin ich über jeden Tipp dankbar! 
Grüße
Sebastian
Hallo nochmal,
hier sind zur hoffentlich eindeutigeren Nachvollziehbarkeit die beiden vollständigen Sofistik-Dateien. Ich habe die entsprechenden Files aus Grashopper direkt eingefügt und in eine Gruppe zusammengefasst.
Der Fehler ist anhand der Verschiebung des Knotens 1018 (in Feldmitte) in global Z aufgefallen, da ich dort ab dem zweiten Lastschritt verschiedene Ergebnisse erhalte. Das Problem tritt sowohl bei linearer Berechnung als auch bei Berechnung nach TH3 auf.
Beste Grüße
Sebastian
Federarbeitslinie.sofistik (115.6 KB)
Federsteifigkeit.sofistik (118.6 KB)
Servus Sebastian,
ich habe beim Vergleich der Datensätze festgestellt, dass beide “Federarten” tatsächlich von ASE unterschiedlich verarbeitet werden. Ich gebe das intern zur Prüfung weiter.
Du wirst gleiche (und meines Erachtens richtige) Ergebnisse erhalten, wenn Du in den ASE Läufen jeweils ein
CTRL SPRI 0
ergänzt. Was das bedeutet, wird im ASE-Handbuch im Kapitel 3.3.5 erläutert und recht anschaulich anhand der Abbildungen 3.1 und 3.2 dargestellt.
Hallo Sebastian,
das unterschiedliche Verhalten wird mit dem kommenden Servicepack behoben sein. Es hat damit zu tun, dass beim Aufsetzen auf einen Primärlastdall was nicht richtig verarbeitet wird.
Als weitere Umgehung empfiehlt der Programmautor, nicht auf den Primärlatfall aufzusetzen:
+prog ase
…
ulti step … PRIM NO
Danke für diesen wichtigen Hinweis!
Beste Grüße,
Jost
Hallo Jost,
danke für die Vorschläge, ich habe die letzten Tage mal ein bisschen damit rumprobiert. Die Lösung liegt grundsätzlich auf der richtigen Kurve, was schonmal super ist. Allerdings kommt es bei der Verwendung von PRIM NO immer zu ein paar größeren numerischen Ausreißern (siehe gestrichelte Kurven im Plot). Kann ich da irgendwas tun, um die numerische Stabilität zu erhöhen? Die Ausreißer entstehen auch bei einer hohen Zahl von Lastschritten (z.B. 200).
Beste Grüße
Sebastian
Hallo Sebastian,
reduziere mal die Toleranz bei der Berechnung. Das System konvergiert ja ziemlich gut, daher ist SYST… TOL -0.5 sehr großzügig. Mit TOL -0.0001 sind m.E. diese Sprünge verschwunden.
Schönes WE 
1 Like
Hallo Jost,
funktioniert jetzt alles wunderbar, dankeschön!
Grüße
Sebastian