You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of the FEM packages are "naming" nodes and elements by some running integer j. However, in e.g. Code Aster, each node or element is having a name. By default, nodes are prefixed with N and running number, elements with M and running number.
Advantages
I see a couple of benefits of this kind of naming approach:
Explicit is better than implicit. Currently, we are finding the dof number based on node id number, and this is a somewhat inflexible approach. By having a name, e.g. :coupling_node, we explicitly say that "do not use id number to calculate anything", and an arbitrary dof mapping/handler must be used to find dofs corresponding to that node, dofs[:coupling_node_1].
Give additional information about nodes or elements in their name. For example, we could have :coupling_node_1, :coupling_node_2, and so on. When importing several meshes, if having an integer-type node id, there most likely will happen collisions because same node ids are used in different bodies, and renumbering will be needed anyway. We could prefix nodes and elements in that case, e.g. :body1_N1, :body1_N2, :body2_N1, and so on.
Naming also most likely explicitly describe the type. Now 5 can mean node 5, element 5 or integration point 5. If we have :N5, :E5 and :IP5, it's immediately clear which one is a node, which one is an element and which one is an integration point. Yet one more advantage is how we should handle ABAQUS surfaces, which are defined in ABAQUS using element id + S1 ... S4, and in current JuliaFEM implementation we should figure out some explicit new id number for them. If using names, we could have :E1S1, :E1S2, :E1S3, :E1S4.
ABAQUS is using negative node ids internally, giving hints that they also have been finding the usual positive id range to be insufficient for all needs. For example, if we need to automatically generate internal/virtual nodes or elements during the simulation, we need a private namespace to avoid name collisions. This could be done easily by prefixing automatically generated stuff.
Disadvantages
I cannot find any of them, but probably there is some. At least we cannot calculate anything based on the node id number, no dim*(j-1)+i, where j is node number and i is local dof number, but I think this is actually something what we (should) want.
Changes to parsers
In AsterReader, we can directly assign names to mesh. In code aster meshes, nodes usually are prefixed with N and elements with M, like described above. In AbaqusReader, we just have to give some prefix to nodes and elements.
What do you think?
The text was updated successfully, but these errors were encountered:
Most of the FEM packages are "naming" nodes and elements by some running integer
j
. However, in e.g. Code Aster, each node or element is having a name. By default, nodes are prefixed withN
and running number, elements withM
and running number.Advantages
I see a couple of benefits of this kind of naming approach:
:coupling_node
, we explicitly say that "do not use id number to calculate anything", and an arbitrary dof mapping/handler must be used to find dofs corresponding to that node,dofs[:coupling_node_1]
.:coupling_node_1
,:coupling_node_2
, and so on. When importing several meshes, if having an integer-type node id, there most likely will happen collisions because same node ids are used in different bodies, and renumbering will be needed anyway. We could prefix nodes and elements in that case, e.g.:body1_N1
,:body1_N2
,:body2_N1
, and so on.:N5
,:E5
and:IP5
, it's immediately clear which one is a node, which one is an element and which one is an integration point. Yet one more advantage is how we should handle ABAQUS surfaces, which are defined in ABAQUS usingelement id + S1 ... S4
, and in current JuliaFEM implementation we should figure out some explicit new id number for them. If using names, we could have:E1S1
,:E1S2
,:E1S3
,:E1S4
.Disadvantages
I cannot find any of them, but probably there is some. At least we cannot calculate anything based on the node id number, no
dim*(j-1)+i
, wherej
is node number andi
is local dof number, but I think this is actually something what we (should) want.Changes to parsers
In
AsterReader
, we can directly assign names to mesh. In code aster meshes, nodes usually are prefixed withN
and elements withM
, like described above. InAbaqusReader
, we just have to give some prefix to nodes and elements.What do you think?
The text was updated successfully, but these errors were encountered: