Snap-fit contact snagging problem


I have a simple snap-fit model where I’m struggling with contact behavior. The problem is that right after reaching the block, there is some snagging and the beam starts bending way too much:

I’ve tried many things: making the beam shorter and thicker, modifying the slope angle (at first it was 45 deg, now it’s 30 deg), changing Young’s modulus in both ways, reducing contact friction, changing the radius/chamfer (initially, it was a chamfer) size and so on. The result above is the best I got so far.

What’s interesting, there’s no such behavior when I test this case in Abaqus. There it either doesn’t converge when reaching the sharp edge at the top of the beam’s tip or runs to completion (with general contact or a trick with contact pairs that I will describe later) but the deformation is always correct (it just slides with no such large bending as if it was stuck right after establishing contact):


The trick that I used in Abaqus to make it work without general contact is that I added one more contact pair of Node to surface type and selected the node set with nodes on that problematic top edge as a slave. This is how one can handle such tricky contact cases without resorting to general contact which supports all the different combinations of surfaces/edges by default.

I’m running out of ideas for further changes to make it work in CalculiX and I would appreciate if someone could take a look at it. Here are the files: Dropbox - Snap-fit issue - Simplify your life

do you get same results using C3D8I elements? you know that one of the biggest difference is element formulation between CCX and ABQ

Yeah, I’ve tried them first and then used C3D8R since they are default and working very well in Abaqus. I’ve tried with a more refined mesh of the beam as well.

Unfortunately, contact handling is very different too - Abaqus has many tricks to deal with even the most problematic cases. I suspect that’s the issue here but I haven’t found a way to fix it in CalculiX yet.

how can it be ccx declares this increment as converged? there is no gravity, dx at time=0.1 at the base is bigger than the gap…

I was able to solve easily without any special trick with CCX/Mecway, but I move the small part in opposite as your model, but phisically is the same.


1 Like

:ok_hand: :ok_hand: :ok_hand:

these rules work most of the time

mathematically is the same, physically is different, as any small deviation would show.

Interesting approach but it doesn’t work for me:

snap-fit 2

Maybe it’s a matter of some other differences between our models.

I think I met all these rules but there’s a tricky contact condition here. At least at the top of the beam’s tip but CalculiX shows strange behavior even before that.

P.S. Those master-slave assignment rules are from ANSYS and the one regarding stiffness seems to be off since we advise the opposite - master should belong to a stiffer/rigid body.

1 Like

but is what it says, master/target is the stiffer one. Or you meant the opposite?

It’s the opposite in the belt example:

Less Stiff Surface
Master (Target)

the text says the opposite :rofl:. It’s a Schrodinger’s advice.

Attached the second version, now moving the big part as your model.


1 Like

Yeah, it’s better to fix the image when sharing this note in the future.

I wonder what makes it work. You don’t have rigid body constraints, the block is deformable. There’s an amplitude but it’s the same as the default step. I’ll try some of your settings then.


surface behavior is not hard, should be the same, but maybe is not…

Yes, I’ve noticed that and will try it next.

I already fixed the picture, and modified it above in the post.

Calculated K should be 0.5*(E_stiff+E_less_stiff)/L_char, in your case is 2000 MPa/0.234mm = 8547 N/mm^3 MUCH MUCH less the hard value

It’s better with a deformable block and contact stiffness of 10000 but there’s still some initial “dynamic” behavior and the block ends up above the beam:

snap-fit 3

Ohhh, Mecway makes a trick that add an extra empty step to the models with contacts to keep the contact stiffness constant during the step!!! We don´t see that step in the interface, but is in the input file passed to the solver:


I have tryed removing that extra step and then there are some issues in the contact, similar to your last animation.

Look in my input files that extra step, and copy all the cards to your Prepomax model by means of the CCX input deck editor.

Right, I’ve noticed that dummy step in your input file but didn’t know it was added for this purpose:


I included the same in my model but it didn’t help.

snap-fit dummy step