Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations IDS on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Robust and flexible definition of properties

Status
Not open for further replies.

meshparts

Mechanical
Feb 17, 2005
490
Hello,

There is something I wanted to share with you for some time. So I'm very curious about your opinion on the following tip.

When programmed with APDL in ANSYS FE models that contain multiple materials, element types, real constants and sections, the classic numbering of properties can get cluttered and changes are error-prone.

Instead of using numbers for the properties it’s better to use meaningful parameter names. For example:

Code:
et,et_solid,solid185

where et_solid is a scalar parameter that must be defined beforehand.

If I want to mesh a volume later in the code, I do not have to think twice about what number to use for the corresponding element type, but use directly the easy-to-remember parameter names:

Code:
type,et_solid

This procedure has the additional advantage that changes have to be made at only one location in the code.

For many this approach may be nothing new. And this is true. APDL is indeed intended to work with parameters. But we have not yet come to the end.

Using parameter names is better than just numbers. But I still I have to define parameters and I have to make sure that they do not overwrite each other. Overwriting happen namely very easily in many lines of code or when I copy code between various macros back and forth.

So I need a method of defining properties that make me independent of the rest of the APDL code.
My method, which I use since years, is simple and compact:

Code:
et_solid=etyiqr(0,16)
et,et_solid,solid185

By using the APDL Inquiry Function ETYIQR the next available element type number is assigned to the parameter ET_SOLID. This parameter then I use both for the definition of the element type as well as for the commands LATT , AATT , VATT and TYPE .

As of now it does not matter if I add new element types in my code or if I insert sections of code in other APDL macros using copy-paste. As long as I use the same naming convention, I'm on the safe side. From now on I can think of in names instead of numbers, what for the human brain is more common.

Here are a few examples for the naming convention:

Code:
et_mass=etyiqr(0,16) ! point mass
et,et_mass,mass21,1

et_beam=etyiqr(0,16) ! beams linearly
et,et_beam,beam188,0,0,2

et_shell=etyiqr (0,16) ! shells linearly
et,et_shell,shell181

et_solid=etyiqr (0,16) ! solids linear
et,et_solid,solid185

But what about the other properties : materials, real constants and sections? They also have appropriate Inquiry Functions. Here are a few examples:

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

I hope this tip was interesting for you and look forward to see your opinions and suggestions for improvement.

Regards
Alex


MESHPARTS
Tuning Your Simulation
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor