---

Bei mir ist folgendes Problem aufgetreten:

Ich habe eine Geometrie mit ABAQUS/CAE erzeugt und diese anschließend vernetzt. Als ich die Ergebnisse der Rechnung angeschaut habe, ist mir aufgefallen, dass die Knotennummerierung in ein und demselben PART variiert. Ich habe das ganze auch mit verschiedenen Elementtypen und Geometrien kontrolliert. Das Resultat bleibt: Bei Quad-Elementen beginnt  die Nummerierung in manchen Regionen in der unteren rechten Ecke des Elements, in anderen dagegen oben rechts.

Das sieht dann ungefähr so aus:

4  3    2  1

1  2    3  4
Das ist nur eine Möglichkeit  Die übrigen beiden Varianten kommen auch vor!

Das hat bei isotropen Materialien keine Relevanz, aber bei orthotropen Materialien möchte ich ja im Input-File keine unterschielichen Material-Orientierungen einfügen für Elemente gleichen Materials. Ist ja logisch, dass ohne einer zusätzlichen Drehung der lokalen Koordinaten der verdrehten Elemente gewaltige Fehler auftreten bzw. die Ergebnisse in den einzelnen Elementen unterschiedlich ausgewertet werden müssen. Spannung in 1-Richtung bei Element A wäre dann mit Spannung in 2-Richtung bei Element B zu vergleichen.
Zur Info: Ich arbeite mit ABAQUS 6.5.1
Habe nur ich das Problem? Ich konnte zumindest noch keinen Eintrag hier dazu finden. Im Programm selbst hat man ja meiner Meinung nach keinen Einfluß auf die Knotennummerierung. Mit "Edit Mesh" lassen sich m.M. nach nur die Koordinaten der Knoten verändern. Bei komplexeren Bauteilen bzw. zahlreichen Modellen aufgrund geometrischer Abweichungen macht es eigentlich zu viel Arbeit die Knotennummerierung im Input-File per Hand zu ändern. Wenn es mit ABAQUS grundsätzlich nicht funktioniert darauf Einfluß zu nehmen - was ich mir eigentlich bei der Verbreitung dieser Software nicht vorstellen kann - würde ich mich freuen, wenn mir jemand nen "besseren" Präprozessor vorschlagen könnte.

Danke schonmal!

[Diese Nachricht wurde von cellerry am 05. Aug. 2007 editiert.]

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

---

Für die Materialorientierung spielt die Knotennummerierung und -konnektivität keine Rolle. Schau' dir mal im Manual an wie (orthotrope) Materialeigenschaften definiert und auf die Elemente zugewiesen werden.

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

---

Das habe ich wie folgt gemacht:

*ORIENTATION, name=..., DEFINITION=OFFSET TO NODES
4, 3, 1
2, 0.
*SOLID SECTION, elset=..., orientation=..., material=...
1.,

Durch die Knotennummern (hier 4,3,1) habe ich das lokale Koordinatensystem eindeutig bestimmt. Wenn sich aber die Nummerierung der Knoten verändert - also die Knotennummern bezüglich der einzelnen Elemente sich vertauschen -, verdrehen sich ja die lokalen Koordinatensysteme auch. Das sieht man auch deutlich, wenn man in der " Visualization" sich die Materialorientierung anzeigen lässt. Ich hoffe ich habe nichts falsch verstanden.

[Diese Nachricht wurde von cellerry am 06. Aug. 2007 editiert.]

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

---

Hallo Mustaine,

da muss ich jetzt aber mal eine Zusatzfrage stellen. Im Manual finde ich die folgenden Zeilen:

Zitat:

---

Defining orthotropic elasticity by specifying the engineering constants

Linear elasticity in an orthotropic material is most easily defined by giving the “engineering constants”: the three moduli , , ; Poisson's ratios , , ; and the shear moduli , , and associated with the material's principal directions.

---

Danach folgt die Matrizendarstellung fuer diese Moeglichkeit. Wenn man nun fuer das Material keine Orientierung vorgibt, dann gibt es noch waehrend des inputfile- processing einen Fehler, dass keine "principle directions" vorgegeben wurden und diese fuer die "engineering constants" Option benoetigt werden.
Weist man eine globale Orientierung zu, dann klappt das auch alles. Aber in einem Bauteil, wo Kontaktprobleme in Kombination mit richtungsorientierten Materialeigenschaften (z.B. faserverstaerkt) berechnet werden und so die Normalspannungen auf den Elementflaechen auszuwerten sind, sollten Elementkoordinatensysteme definiert werden.
Das ist ja auch soweit kein Problem. Die Option "OFFSET TO NODES" bei "*ORIENTATION" macht dies ja, allerdings sind fuer die lokalen Elementorientierungen 3 Punkte anzugeben, welche pro Element ausgewertet werden. Ein Punkt ist der Ursprung des lokalen CSYS, einer definiert die X- Achse und einer einen Punkt in der lokalen XY- Ebene. Diese Punkte werden ueber die lokalen Knotennummern definiert. Wenn nun ein Element von der Standartnummerierung abweicht -- z.B. also oben rechts in der Ecke beginnt und nicht unten links -- dann ist das Elementkoordinatensystem logischerweise verdreht. In diesen Koordinaten sind aber die Materialien orientiert. Und selbst wenn dies nicht der Fall ist, stellt sich ein Problem bei der Auswertung, wenn Spannung S22 in lokalen Koordinaten in einem Element eine horizontale Komponente darstellt und zwei Elemente weiter eine vertikale.

Ist dieses Problem verstaendlich???
Ich bin gerade dabei herauszufinden, ob es ein Versionsproblem ist und in Vers. 6.6 bereits behoben wurde. Dazu kann ich jedoch im Moment noch nichts weiteres beisteuern.

Was sagst du dazu Mustaine? Eine Materialorientierung fuer die "engineering constants" muss (zumindest im *.inp file) vorgegeben werden oder?

------------------
==========
==  Dingsen  ==
==========

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

---

Normalerweise wird bei *Orientation der Parameter DEFINITION=COORDINATES verwendet, worauf ich mich in meiner Antwort auch bezogen habe. Ansonsten habt Ihr recht. Bei DEFINITION=OFFSET TO NODES spielt die Knotennummerierung eine Rolle.

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

---

Gut, dass jetzt zumindest das Problem deutlich ist. Habe allerdings noch nicht gehört, dass andere dieses Problem der Knotennummerierung haben.
Fakt ist, dass ich den Befehl DEFINITION=COORDINATES nicht nutzen kann/will, da somit ebenfalls Sprünge in den Ergebnissen auftreten. Die Ergebnisse sollen sich alle auf eine vergleichbare X-Achse beziehen, d.h. bei einer Nummerierung wie hier zu sehen:

4  3

1  2

sollen Knoten 1 und 2 immer auf der X-Achse liegen. Da die daraus resultierende X-Achse für mein Netz NICHT für jedes Element gleich ist, sollen die Elemente die gleiche Knotennummerierung haben.

Falls sich das Problem meinerseits klärt, werde ich es hier posten. Bis dahin, wäre ich für jeden Hinweis dankbar!

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

---

Wenn deine Materialrichtung immer in Richtung der x-Achse zeigen soll, kannst du doch DEFINITION=COORDINATES nehmen. Dann kann dir die Knotenkonnektivität egal sein.

Oder habe ich dich falsch verstanden? Kannst du mal einen Screenshot von deinem Bauteil anhängen und daran erklären was du machen möchtest?

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

---

Mesh.JPG

War in dem Sinne ein Missverständnis bzw. Schreibfehler von mir. Auf meiner lokalen X-Achse sollen Knotenpunkt 1 und 4 liegen. Allerdings kommt das auf das gleiche da LOKAL nicht zwangsläufig GLOBAL ist. Siehe Screenshot!

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

---

Im Prinzip wäre dein Ansatz schon der korrekte. Man koppelt die Richtung des Materials pro Element an eine Elementkante.

Da dass hier aber Aufgrund der beschriebenen Problematik nicht zu klappen scheint, würde ich als Näherungslösung für die Elemente links oben das gedrehte Koordinatensystem und für die anderen Elemente das globale Koordinatensystem als Referenz bei DEFINITION=COORDINATES vorgeben.

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

---

Okay! Habe meine ersten Rechner auch alle mit dieser Näherungslösung gemacht. Also für Bereiche bei denen die Winkel in etwa gleich sind jeweils ein lokales Koordinatensystem definiert, bei geraten Elementkanten dann jeweils auf das globale bezogen. Ich denke auch, dass der Fehler nicht so riesig sein wird, dachte aber, dass es dafür doch eigentlich eine wirkliche Lösung gibt. Falls jemandem dazu noch etwas einfällt, bitte posten!

Danke erstmal!

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

---

Ich mühe mich zurzeit ebenfalls mit der Materialorientierung ab.

Mein Ziel ist es dass die Materialorientierung an die Elementkanten gekoppelt ist. Sodass z.b. bei Biegung die Materialorientierung in der Elementebene bestehen bleibt und nicht aus der Elementebene hinaustritt.

Über Definition=Offset to Nodes leuchtet mir alles ein. Frage mich dabei aber ob das lokale KKS sich mitdreht. Aber ich habe im CAE keinerlei Möglichekeit dies zu "definieren". Oder irre ich mich da?

Danke im Voraus.

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

---

Wenn du mit NLGEOM rechnest und bei Solids nicht isotrop, bewegt sich das lokale Elementkoordinatensystem mit den Elementen mit.

All' das was hier diskutiert wurde dreht sich um die Frage wie man die Anfangsorientierung definiert.

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