Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Give nodes, elements, integration points, name instead of number? #45

Open
ahojukka5 opened this issue Oct 16, 2018 · 0 comments
Open
Labels

Comments

@ahojukka5
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant