Hallo,
heute habe ich die Glühbirne als Beitragsicon benutzt. Die steht laut Hilfe für Tipps und Tricks.
Es gibt nämlich etwas, was ich schon länger mit euch teilen möchte. Ich bin daher auf eure Meinung zum folgenden Tipp sehr gespannt.
Wenn man mit APDL in Ansys FE-Modelle programmiert, die mehrere Materialien, Elementtypen, Real Constants und Sections enthalten, wird die klassische Durchnummerierung von Eigenschaften unübersichtlich und bei Änderungen fehleranfällig.
Besser ist es anstatt Zahlen für die Eigenschaften aussagekräftige Parameternamen zu verwenden. Bspw.:
Code:
et,et_solid,solid185
wobei et_solid ein skalarer Parameter ist, den man vorher definieren muss.
Wenn ich dann später im Code ein Volumen vernetzen möchte, muss ich nicht mehr lange überlegen, welche Nummer denn der entsprechende Elementtyp hatte, sondern verwende direkt den einfach zu merkenden Parameternamen:
Code:
type,et_solid
Diese Vorgehensweise hat den weiteren Vorteil, dass Änderungen nur an einer Stelle im Code gemacht werden müssen.
Für viele mag diese Vorgehensweise nichts Neues sein. Und es ist auch so. APDL ist ja dafür gedacht mit Parametern zu arbeiten. Wir sind jedoch noch nicht am Ende angekommen.
Parameternamen zu benutzen ist schon besser als die reine Zahlenangabe. Ich muss aber immer noch Parameter definieren und ich muss darauf achten, dass sie sich nicht gegenseitig überschreiben. Überschreiben kann nämlich sehr leicht bei vielen Codezeilen passieren oder dann, wenn ich Code zwischen unterschiedlichen Makros hin und her kopiere.
Ich brauche also eine Methode zur Definition von Eigenschaften, die mich unabhängig vom Rest des APDL-Codes macht.
Meine Methode, die ich seit Jahren benutze, ist einfach und kompakt:
Code:
et_solid=etyiqr(0,16)
et,et_solid,solid185
Durch die Verwendung der APDL Inquiry Function ETYIQR wird die nächste zur Verfügung stehende Elementtypnummer dem Parameter ET_SOLID zugewiesen. Diesen Parameter verwende ich dann sowohl zur Definition des Elementtyps als auch in den Befehlen der LATT, AATT, VATT und TYPE.
Ab jetzt ist es egal, ob ich neue Elementtypen in meinen Code hinzufüge, oder ob ich Codeabschnitte in andere APDL-Makros mit Copy-Paste einfüge. Solange ich eine Einheitliche Namensgebung verwende, bin ich auf der sicheren Seite. Ab jetzt kann ich in Namen statt Zahlen denken, was dem menschlichen Gehirn eher geläufig ist.
Hier noch ein paar Beispiele zur einheitlichen Namensgebung:
Code:
et_mass=etyiqr(0,16) ! point mass
et,et_mass,mass21,,1et_beam=etyiqr(0,16) ! beams linear
et,et_beam,beam188,0,0,2
et_shell=etyiqr(0,16) ! shells linear
et,et_shell,shell181
et_solid=etyiqr(0,16) ! solids linear
et,et_solid,solid185
Aber wie sieht es mit den anderen Eigenschaften aus: Materialien, Real Constants und Sections? Hierfür gibt es auch entsprechende Inquiry Functions. Hier ein paar Beispiele:
Code:
! Material definition steel
mp_steel=mpinqr(0,0,16)
mp,ex,mp_steel,210e9
mp,nuxy,mp_steel,0.3
mp,dens,mp_steel,7850! Real constant for dummy mass element
rc_m=rlinqr(0,16)
r,rc_m,mass
! quadrilateral full profile
sc_beam1=sectinqr(0,16)
sectype,sc_beam1,beam,rect
secdata,20*mm,50*mm
secoffs,user,0,25*mm
Ich hoffe dieser Tipp war für euch interessant und freue mich auf eure Meinung bzw. Verbesserungsvorschläge.
Viele Grüße
Alex
------------------
MESHPARTS
Tuning Your Simulation
www.meshparts.de
[Diese Nachricht wurde von MESHPARTS am 04. Apr. 2014 editiert.]
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP