---

test2.inp.zip

Hallo,
ich habe folgendes Problem:
Ein Blech soll durch einen Druck von außen in ein Werkzeug umgeformt werden. Die Druckwerte werden Elementweise aus einer anderen Simulation übernommen und nach definierten Zeitschritten sollen Restarts mit den aktualisierten Druckwerten durchgeführt werden. Ein erster Ansatz das Problem ohne Restarts zu lösen war mittels einer Subroutine(VDLOAD/DLOAD). Allerdings bietet sich dies bei der expliziten Rechnung nicht an, da durch den millionenfachen (!!) Aufruf der Subroutine enorm viel Zeit verloren geht. Daher der Gedanke mit den Restarts.
Als problematisch stellt sich nun allerdings die Zeit heraus, die die package.exe benötigt. Leider konnte ich nirgends brauchbare Informationen darüber finden, was genau und vor allem wie genau package.exe die inp verarbeitet, sodass ich diese nicht daraufhin optimieren kann, dass package.exe sauber und zügig durchläuft... (zur Zeit sind es 15h...)
Ich habe die inp zu dem Modell angehängt, einige Kleinigkeiten stimmen natürlich noch nicht (Temperaturen, Massenskalierung, Field und History Output), allerdings dürften die meiner Meinung nach den Packager nicht weiter beeinflussen.

Danke schonmal
Stephan

------------------
Wissen ist Macht, nichts wissen macht auch nichts.

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

---

Was den Packager so langsam macht, ist daß Du 12-tausend einzelne Flächen zum Starrkörper zusammenfaßt und dann auch noch 12-tausend einzelne Drucklasten aufbringst. Für den Starrkörper solltest Du die Elemente zu einer einzigen Fläche zusammenfassen und die 12-tausend Einzeldefinitionen komplett weglassen.

Auch für die Lastdefinition solltest Du die tausende Einzelflächen zu einer Fläche zusammenfassen (die tausenden Einzelflächen gar nicht definieren!) und dann die Last mit einer einzigen Lastdefinition aufbringen. Wenn Du von millionenfachen Aufruf der VDLOAD schreibst, vermute ich, daß Du für jedes Element/jede Fläche einen separaten VDLOAD-Aufruf hast und das kostet natürlich. Richtig wäre es, die VDLOAD einmal für die Gesamtfläche aufzufrufen und dann innerhalb der VDLOAD die Differenzierung für einzelne Elemente zu implementieren. In der VDLOAD ist die Größe "curCoords" verfügbar, die Du dazu nutzen kannst. Wenn Du die Last auf Elemente mit nur einem Integrationspunkt aufbringst (ggf. dazu SFM3D3 und SFM3D4R nutzen) kannst Du über curCoords jedem Punkt die richtige Last zuordnen. Aus den den Daten der anderen Simulation kannst Du Dir die nötigen Werte in eine sequentielle Fortrandatei schreiben, die für einen schnellen Zugriff über die curCoords sortiert ist.

Zu kompliziert?
Dann schreibe Dir die Druckdaten aus der anderen Simulation als Temperaturdaten in eine Odb. Definiere Dein Werkzeug mit anisotropem Temperatur-Alpha, nullverschieden nur normal zum Werkstück. Ermittle den notwendigen Wert für Alpha und lies dann die Temperaturdaten ein. Somit sollte sich das Werkzeug gemäß der eingelesenen Daten ausdehnen und Druck aufs Werkstück ausüben.

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

---

hallo femchen,
zunächst mal danke für deine antwort.

nochmal zum gedanken des modells: eine wirkmedium (modelliert als druck) soll von oben das blech in das werkzeug drücken. ich sage das nochmal explizit, weil ich deine letzten zwei sätze nicht ganz verstehe?!

dass mein problem mit den einzeln definierten flächen zusammenhängt habe ich mir schon fast gedacht... allerdings scheint es mir, als würde ich diese definitionen auch benötigen.

zunächst jedoch zu deinem einwand zur vdload: die usersubroutine wird nicht für jedes element aufgerufen, sondern für jedes zeitinkrement (dass bei der expliziten rechnung meines wissens nur von der massenskalierung/schallgeschwindigkeit im medium und der kleinsten elementgröße abhängt) - somit hat die anzahl der flächen keinen einfluss auf die anzahl der aufrufe der vdload - sofern ich nicht irgendwas wesentliches übersehen habe.- die zeitinkremente sind etwa 10^-7s, was bedeutet, dass die vdload 3/10^-7 mal aufgerufen wird (d.h. ca 10^7 aufrufe)...

die idee die drücke an den integrationspunkten anhand der koordinaten zu übergeben ist gut, allerdings wenig praktikabel, da sich das blech verformt und somit die koordinaten der integrationspunkte über der zeit nicht konstant sind.

warum ich überhaupt die vielen flächendefinitionen habe: die beiden simulationsprogramme sollen final online gekoppelt werden, d.h. die in abaqus errechnete deformation des bleches wird an die drucksimulation übergeben, die daraufhin einen step rechnet und die druckwerte in eine restartdatei schreibt, woraufhin abaqus einen step rechnet usw.
ich habe bisher keine möglichkeit gefunden einen druck (in normalenrichtung eines elementes) für jedes einzelne element zu übergeben, ohne den umweg über die surface based load zu gehen. geht man über die koordinaten müsste man ein mapping vornehmen (für das standardmäßig keine funktionalität in abaqus vorgesehen ist).

es wäre nett, wenn du unter diesen gesichtspunkten deinen beitrag nochmal präzisieren könntest.

stephan 

------------------
Wissen ist Macht, nichts wissen macht auch nichts.

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