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:
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:
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:
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:
But what about the other properties : materials, real constants and sections? They also have appropriate Inquiry Functions. Here are a few examples:
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
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