In the following example, I have two separate shell meshes, green and beige. Both meshes consist of S8 shell elements. The node-set 1 is used for a fixed boundary condition. The node-set 2 is used to apply a concentrated load of 1 in the negative z-direction (a force of 1 is working on each node in the set). Node-sets 3 and 4 are used for a symmetry boundary condition where the displacement in the x-direction and the rotations about the y and z-axis are equal to 0. The node-set 4 is a copy of the node-set 3 without two middle nodes of the middle finite elements of the green mesh.
I tried to run the simulation without the symmetry boundary condition (result a), with the symmetry boundary condition applied to the node-set 3 (result b) and with the symmetry boundary condition applied to the node-set 4 (result c).
It is obvious that the simple symmetry boundary condition applied to all the side nodes (node-set 3) does not work for the green mesh. The results a) and c) are similar but not exactly the same. I thought that the nodes where the finite elements are connected are causing problems but it turns out that the middle nodes of the middle finite elements are the ones preventing the deformation of the model. Very strange.
Is there any explanation for this? Is there any way to better understand how shell finite elements work in CalculiX in order to not waste time testing out each possible combination of keywords? Or are there some bugs in the code?
no drilling rotation should be prescribed, unless all rotational degrees of freedom are set to zero in the node.
So I guess you might try using *TRANSFORM to eliminate all the drilling-oriented rotation constraints but I wouldn’t be too hopeful. At the nodes between elements, there might not be any correct way unless you make the elements curved so they have a common normal at their shared nodes.
I’ve seen it fail (don’t remember how) with all 6 DOF of an edge constrained to 0. It seems to depend on the geometry in some unpredictable way. The workaround was to constrain only displacement DOFs and use the mesh to arrange them so they effectively constrained rotation of the structure.
The problem I do not understand is that when only the common nodes are kept in the node-set and the midside nodes are removed it works (result c). I was expecting the common nodes where the knots are created to course problems but it turns out that it is not so. So the midside nodes are causing problems here. And in the midside nodes, there are no knots.
If the midside nodes are extruded first into top and bottom midside node, then we have 2 nodes belonging to a solid FE with 3 degrees of freedom. And there should be no problem with rotational degrees of freedom. As stated earlier if you remove the rotational constraint it also works (but the results, in general, are not ok). So it is a combination of the rotational supports and midside nodes?
It is just that such behaviour can probably be circumvented in many cases but it makes use of shell finite elements in CalculiX very questionable. Since it is so strange I would think that there must be some sort of bug or some mistake in the CalculiX code? Were you able to talk about this with developers?
I did try the *Transform as you suggested but without success. I am not even sure how to position the coordinate system since I do not know what is housing the problems.
even curves being refine/smooth and the element used are linear shell, still all results shown not as expected. seems all problems arise are due to rotational dof’s of node were it need to be restrained in local coordinates system (shell element) not in global.
The result you got is the one that got me into testing. I thought that in the process of expanding the shell elements into the solid elements first the expansion is made and then all the constraints are added. And that knots are created if certain conditions are met (angle). But If that would be the case, it would not be possible to create a shell with a rotational support. The expanded solid elements (linear) are missing the midside nodes.
So now I believe that the knots are created for all the nodes of the shell elements. For corner and midside nodes. And then we have a problem which @vicmw described. So, theoretically, I should be able to compute the knot directions and use the *TRANSFORM. But I failed. Can somebody that knows the details shed some light on this shell behaviour (@dhondt)?
The shells are expanded and only where needed knots are created. If shells are
e.g. used for a flat plate supported on all 4 sides, all supports are hinges (=
external edges). If the user suppresses the rotation (dof 4 to 6) knots are
created.
However, internal edges of the shell surface are supposed to be stiff, i.e. no
internal hinges, So if you model a sharp roof, the top of the roof will be
stiff. If you want a hinge there, your need to model two seperate meshes and
link them by MPC’s connecting the translational dofs.
my opinion is that the element locks. If you change to S8R it improves very very slightly…
as far as I can understand from the ccx manual the elements do not have any locking prevention formulation, only hourglass control,…not sure I do not know the formulation details in ccx very well.
this is an old treads, hopefully it’s not to disturbing anyone. i’m only try to seek some alternates to the problems.
pictures bellow are using US3 element for similar cases. i did not yet to verify and compared to 3d solid element, but it seems not a problem and shown as expected.
i refers the documentation, still not a general solutions since these element type has limitation e.g linear elastic, small deformation, isotropic, etc.
