Rigid-body constraint convergance problems

I was solving a larger shell model using a rigid-body constraint and could not solve the problem successfully when I used the NLGEOM setting. I was able to determine that the rigid-body constraint was causing convergence problems. I was able to reduce the larger model to a model of only three shell quadrilateral elements for the comparison with the solid approach. It turns out that the equivalent solid model does not have any convergence problems. So, it might be that my approach to shell modelling is somehow wrong or that the rigid constraint works differently for shell and solid models. It makes the use of rigid body constraint almost unusable for the shell models and NLGEOM.

The solid model (Solid.inp) is a plate of dimensions x: 30; y: 10; z: 1; meshed with three C3D20 elements. The material has elastic properties of E = 200000 and a Poisson’s ratio of 0. The node-set (a) is fixed (d), the node-set (b) has a prescribed displacement of 0.01 in the displayed direction (e), and the node-set © is used in the rigid body constraint (f). The constraint uses the reference nodes “Ref node” and “Rot node” positioned on the centre of the rightmost face of the model (x, y, z: 5, 30, 0.5). This solid model can be solved using NLGEOM in 3 iterations. Moving the reference nodes around does not affect the solution.

The shell model (g) (Shell.inp) is a plate of dimensions x: 30; y: 10; z: 0; meshed with three S8 elements. Everything else is the same. The reference nodes are positioned at x, y, z: 5, 30, 0. With the default settings for the NLGEOM incrementation, the problem cannot be solved. If the reference nodes are moved around, this affects the convergence of the solution (it should not!). At the reference nodes positioned at x, y, z: 5, 24.5, 0 the solution converges with the default incrementation but uses much larger number of increments.

So what is wrong with the rigid-body constraint? Any suggestions, ideas?

The .inp files:

Solid model: https://www.dropbox.com/s/e4j46ygxeatu94i/Solid.inp?dl=0
Shell model: https://www.dropbox.com/s/hzciamw00xagoof/Shell.inp?dl=0

I’ve also found that *RIGID BODY and *COUPLING don’t work consistently with shell and beam elements. I think it’s something to do with the MPCs conflicting. Generally, any features that use MPCs don’t work reliably with shells.

Thanks for the answer. I can imagine it can be a problem combining all the different MPCs and that is why I tried to make the example as simple as possible. If my understanding of the code is correct, the shell finite elements are expanded in bricks. So in this case, where all elements lie in a plane, the resulting mesh should contain no knots (angle smaller than 0.5°, the same thickness, and the same offset) and should be the same as the solid mesh. So I thought the rigid body constraint should work.

Yea that confused me too but I seem to remember Guido saying that shells always have knots now, not only if they’re at steep angles. Not to sure about that though.

I did not try the *Coupling yet but that is really unfortunate. I found this problem for the Nlgeom option only. Does it cause problems even for linear cases? How do you solve such problems in CalculiX then?

*** deleted my previous comment, due to inconsistency

  • displacement bc only, not work
  • add cload at reff. nodes combine with displacement bc, work with some limitation values
  • cload only, not work

hi @Matej

alternatively, you could solve these problem using coupling keywords. solved fast by 3 iteration only, as can be seen in attachment picture below.



thanks for the answer. I thought of testing it so thank you for doing it. I am afraid that this is not a universal solution since Victor wrote that there are also problems with the *Distributing keyword.

I will have to try it out to see how it works. Did you have any experience with *Distributing cousin problems?


did not know @vicmw is talking about, are for *coupling keywords only or it’s all coupling features also? i did not see any simple example problems has posted.

in my previous analysis cases ran, some versions of CCX (2.13) doesn’t work properly if the boundary conditions are rotational (e.g concentered moment/torque) with *coupling keywords type distributing.

in case translation bc’s and using solid element, all coupling features gave expected results and works properly. also i was tried for face of edge shell element. for CCX version 2.12 is works normally also for rotational bc’s, need to be review for the latest versions.

to be generalize i look the possibilities using coupling features with *distributing keywords, since it has weight factors. i need to try and take many cases to validates further.

benefit of using coupling features rather than rigid body are avoidance of over constrained conditions and additional infinity stiffness. it’s exist on the face or node groups of element being considered.


Ok, thanks for the answers. I am still bothered by the *RIGID BODY, NLGEOM and shell combination. Maybe I will look into it in more detail.

i found it works when rotational node is removed, document says let the solver generated internally. but results are bit different from previous, and took more iterations. need a solved known problems to verify.

Yes, that is something that I was also able to determine. In the case, where the reference node is not defined by the user, it is automatically determined by the CalculiX since it should not affect the result. But unfortunately it affects the result. And that is a problem that cannot be disregarded.