Contacts diverge with rigid bodies and truss

Hello,
my structure has a supporting rod between two ball joint points. I modeled the end point supports with rigid bodies and added a 2-node truss T3D2 element between the rigid bodies displacement ref nodes. Rotational ref nodes were left unsupported.

The model worked fine in 2.21 WIN until I added to another location in the model a real pin and eye structure with no friction contact pair. The contact initiates strange behavior to the rod endpoint: iteration diverges with exponential speed, largest residual forces in iterations 1 to 4:
4.75, 55981.14, 279227704.05, 2904529554385.34, always in one of the rod end points, and result is cutbacks with same sequence.

However final error printed by solvers at the end of iterations is in magnitude of 4E-13, which sound well acceptable to me, but solution is not accepted by high RESID.FORCE % and CORR. DISP %.

I am a bit lost with this behavior. Is is a question of my model missing some solver control, or is my model including something that’s mathematically forbidden, e.g. to have both rigid bodies with truss elements and contacts in same model? I have tested both Pardiso and PaStiX solvers, same effect.

Can’t you share the model ? CalculiX has convergence issues when shells are used together with rigid body constraints and Nlgeom. You could try with solids instead of trusses.

SPRINGA is a good alternative to T3D2 unless you need thermal stress. It’s a pure 2-node element not expanded to solids and avoids the associate MPC problems.

If that 4E-13 error is from Pastix, it doesn’t really correspond with nonlinear convergence, just convergence of the linear iterations.

Is everything properly constrained against rigid body motion? You don’t need to constrain the ROT NODE if the other nodes are sufficiently constrained. Try FREQUENCY analysis to detect 0-Hz (or better, 0 strain energy density, thanks @Disla) rigid body modes if unsure.

it seems truss element in CalculiX required to add rotational restraint in longitudinal axes (torque) to make it stable. Even for simple linear static analysis, a spurious movement may be shown.

Heartfelt thanks for you all giving guidance. I tried the model with SPRINGA elements, it sounded easiest since no rotation constrain are needed. Model started to work immediately, producing expected results.

The issue, as I understand it, is in the expansion of Truss to a solid block, which creates new nodes that are not attached to the ref node at all, so the entire Truss element is totally free floating. Without the trusses the model also become a free mechanism and none of the solvers were capable to solve it.

Good to hear it’s working. It’s true that truss elements’ new nodes are separate, but they’re normally connected to their original nodes by MPCs, which also constrain rotation about the element’s axis so you get the expected behavior for a truss element. Maybe in this case, the MPCs couldn’t be applied because they conflicted with the rigid body’s MPCs. There might have been warnings about that in amongst all the other messages.