I have prepared a simple shell model. There are two shell plates, one on the top of another. The distance between shells is 2 mm, as is the shell thickness. One shell edge is fixed, and the edge of the other shell is displaced by 1 mm. Between the shells, there is a tied connection.
However, when I apply a nodal load (CLoad) on the slave nodes of the tied connection (the top plate) with an amplitude of 1 N (the magnitude or direction of the force has no effect on the problem):
The problem is very strange since using a distributed load (DLoad) on the slave shell elements works in both cases when the load is applied to the front or back faces of the shells.
As far as I know, the distributed load is converted to nodal loads before the solution, so I am wondering why the CLoad definition does not work.
This is a problem since in PrePoMax traction force, hydrostatic pressure and imported pressure are all internally converted to nodal loads. So in such cases, the tied constraints do not work. If this works in Abaqus (thanks for the test), I assume it is a CalculiX connected bug.
There are some workarounds for this (apart from inverting master/slave assignment you can use tied contact) but I agree that it’s a serious bug. I can ask Guido to take a look at this before a new version of CalculiX is released.
That what i was thinking, it seems tie constraint is not general solution and some specific requirement still needed. For example is in sensitivity to surface definition and node sharing with constraint support due to knot, rigid body and penalty contact in model. I have some experiences, this lead to conflict, unsolved problems or unexpected results by the solver.
I did not really know and sure, maybe this is bug or the limitation itself since tied contact type also available for these similar task to eliminate the problem. It’s need to further investigate the codes of tie constraint implementation.
Even tie constraint is not allowed to be use in shell element, still it has been shown to be working for case without conflict with another constraint or contact in model. Maybe the document need more explanation about the limitation. User need more took test, benchmark and validation to be reporting.
But, it seems to be right. Tied contact type more consistent and predictable, and robust. Also, it can be use for solid, shell and beam element including mixed.
Yes, I am aware of other possibilities. I also checked the manual before posting and found out that a tied connection is not supposed to be used with shell elements. But I thought this part of the manual is outdated since it obviously works in some cases. And since it works for dload, I think there is a bug that prevents it from working with cload.
For tied contact, I had some problems in the past. I was testing it with a frequency step to check if the contact is correctly detected, and the frequency analysis showed that everything is connected. But later static analysis showed rigid body motion. I thought it had to do with the linearization of tied contact in the frequency step, but I did not investigate it further. Using a tied connection worked better for both of these cases: frequency and static.
Maybe the difference between the dload and cload is that the dload is defined on the element surface while the cload is defined on the element node. When Calculix expands the shell element, the dload is correctly prescribed to one or the other outer node (in regard to thickness) of the expanded element, while the cload is prescribed to the middle node (in regard to thickness) or the created knot. In the case of a cload, there might be a problem of determining to which of the outer nodes (in regard to thickness) the load should be prescribed if it cannot be prescribed to the middle node.
Thanks for pointing out an interesting case, it seems some code in tied contact type has been changes. Nonlinear geometry activated by default in previous version but later is not…
Point forces defined in a shell node are not modified if a knot is generated (the reference node of the rigid body is the shell node). If no knot is generated, the point load is divided among the expanded nodes according to a 1/2-1/2 ratio for a shell mid-node and a 1/6-2/3-1/6 ratio for a shell end-node.
I found some notification about concentrated loads, probably knot is generates in this case and make conflict with tie constraint.
I looked into this problem. The structure consists of two layers of shell elements, which are tied together. Let’s define the upper layer to be the one at largest z-values.
the lower side of the upper layer is tied to the upper side of the lower layer
in CLoad.inp the nodes of the upper layer get a force in negative z. When running, warnings are issued in the form:
*WARNING in gentiedmpc:
DOF 3 of node 216 is not active;
no tied constraint is generated
Visualizing CLoad.frd and locating node 216 one discovers that it is a lower node of the expansion of the upper layer.
What happens internally in the code? In gen3delem the shells are expanded into 3D and in subroutine gen3dforc MPC’s are created for the forces in the upper layer in the form:
u1+u2-2*um=0
where 1 is a node on the lower side of the layer, m is the node in which the force is applied and 2 is the node on the upper side, cf. Documentation chapter 10.3 on the expansion of 2D-elements. In the above equation node 1 is the dependent node and cannot be used for other equations. In the structure at stake all expanded nodes on the lower side of the upper layer are thus used (such as node 216) and cannot be used for tying the structures together any more. That is what the warning is saying.
The problem can be solved by switching slave and master in the tie constraint. Doing that, the dependent nodes in the tie constraints are the upper nodes of the lower layer (in which no forces were applied).
By the way, dloads do not lead to any MPC’s and therefore do not cause any trouble here. It is not correct that dloads are replaced by concentrated forces internally. While setting up the system of equations, they lead to contributions to the external forces by evaluating their value at the integration points of the faces they are applied to.
