# Snap-fit contact snagging problem **URL:** \ **Category:** Analysis issues\ **Created:** [May 16, 2024, 2:49pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277 "2024-05-16T14:49:09Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Calc\_em](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@Calc\_em](https://calculix.discourse.group/u/Calc_em)\ **Post date:** [May 16, 2024, 2:49pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/1 "2024-05-16T14:49:09Z")
Hi, 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: ![snap ppm](https://global.discourse-cdn.com/free1/uploads/calculix/original/2X/7/7eec759f7cfb59c136da397ce5c8b6f5292541d5.png) 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): ![snap-fit_abq](https://global.discourse-cdn.com/free1/uploads/calculix/original/2X/5/5e2e50fe9baf07f5a5071ff4a5f5fbf7366c5267.gif) 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](https://www.dropbox.com/scl/fo/lbvysgv737235g97hwbs7/ADWXEK795Q-C2fBVkGSDtJo?rlkey=bygdwzw6rjkjdoagdirhqm9fb&st=cqwplfnq&dl=0) ---
**Author:** ![JuanP74](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@JuanP74](https://calculix.discourse.group/u/JuanP74)\ **Post date:** [May 16, 2024, 4:11pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/2 "2024-05-16T16:11:03Z")
do you get same results using C3D8I elements? you know that one of the biggest difference is element formulation between CCX and ABQ ---
**Author:** ![Calc\_em](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@Calc\_em](https://calculix.discourse.group/u/Calc_em)\ **Post date:** [May 16, 2024, 4:34pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/3 "2024-05-16T16:34:20Z")
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. ---
**Author:** ![JuanP74](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@JuanP74](https://calculix.discourse.group/u/JuanP74)\ **Post date:** [May 16, 2024, 5:29pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/4 "2024-05-16T17:29:08Z")
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… ![imagen](https://global.discourse-cdn.com/free1/uploads/calculix/original/2X/b/bdb130d06caed6e3355df5ca1ce6afa975cc2e35.png) ---
**Author:** ![SergioP](https://yyz2.discourse-cdn.com/free1/user_avatar/calculix.discourse.group/sergiop/32/10_2.png) [@SergioP](https://calculix.discourse.group/u/SergioP)\ **Post date:** [May 16, 2024, 5:31pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/5 "2024-05-16T17:31:16Z")
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. ![SNAP_FIT_01](https://global.discourse-cdn.com/free1/uploads/calculix/original/2X/1/1d14480795736f8be2a6c1f3bd71b311db183150.gif) > **[SNAP\_FIT\_01.inp](https://drive.google.com/file/d/1lSmpNVH5Qqxk73cATK7mQC_Gb-NieypR/view?usp=sharing)** > > Google Drive file. ---
**Author:** ![JuanP74](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@JuanP74](https://calculix.discourse.group/u/JuanP74)\ **Post date:** [May 16, 2024, 5:45pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/6 "2024-05-16T17:45:48Z")
👌 👌 👌 these rules work most of the time ![imagen](https://global.discourse-cdn.com/free1/uploads/calculix/original/2X/2/2ddf564c67217bbe4544423ce432a4d71c9b79ad.jpeg) ---
**Author:** ![JuanP74](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@JuanP74](https://calculix.discourse.group/u/JuanP74)\ **Post date:** [May 16, 2024, 5:48pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/7 "2024-05-16T17:48:25Z")
> [@SergioP](#): > > phisically is the same. mathematically is the same, physically is different, as any small deviation would show. ---
**Author:** ![Calc\_em](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@Calc\_em](https://calculix.discourse.group/u/Calc_em)\ **Post date:** [May 16, 2024, 6:02pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/8 "2024-05-16T18:02:40Z")
> [@SergioP](#): > > 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. Interesting approach but it doesn’t work for me: ![snap-fit 2](https://global.discourse-cdn.com/free1/uploads/calculix/original/2X/3/3efcc6ecba959d7fc90d61d4af8caa27aa26e41b.gif) Maybe it’s a matter of some other differences between our models. > [@JuanP74](#): > > these rules work most of the time 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. ---
**Author:** ![JuanP74](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@JuanP74](https://calculix.discourse.group/u/JuanP74)\ **Post date:** [May 16, 2024, 6:06pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/9 "2024-05-16T18:06:52Z")
but is what it says, master/target is the stiffer one. Or you meant the opposite? ---
**Author:** ![Calc\_em](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@Calc\_em](https://calculix.discourse.group/u/Calc_em)\ **Post date:** [May 16, 2024, 6:08pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/10 "2024-05-16T18:08:44Z")
It’s the opposite in the belt example: > Less Stiff Surface > Master (Target) ---
**Author:** ![JuanP74](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@JuanP74](https://calculix.discourse.group/u/JuanP74)\ **Post date:** [May 16, 2024, 6:10pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/11 "2024-05-16T18:10:08Z")
the text says the opposite 🤣. It’s a Schrodinger’s advice. ---
**Author:** ![SergioP](https://yyz2.discourse-cdn.com/free1/user_avatar/calculix.discourse.group/sergiop/32/10_2.png) [@SergioP](https://calculix.discourse.group/u/SergioP)\ **Post date:** [May 16, 2024, 6:11pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/12 "2024-05-16T18:11:10Z")
Attached the second version, now moving the big part as your model. ![SNAP_FIT_02](https://global.discourse-cdn.com/free1/uploads/calculix/original/2X/b/b2dd01ce2a32616c217c06d1e76488ed221ce708.gif) > **[SNAP\_FIT\_02.inp](https://drive.google.com/file/d/1BbW9S1nv0de7Jr0y6IICnY1tJwgWh7FQ/view?usp=sharing)** > > Google Drive file. ---
**Author:** ![Calc\_em](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@Calc\_em](https://calculix.discourse.group/u/Calc_em)\ **Post date:** [May 16, 2024, 6:14pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/13 "2024-05-16T18:14:45Z")
> [@JuanP74](#): > > the text says the opposite 🤣. It’s a Schrodinger’s advice. Yeah, it’s better to fix the image when sharing this note in the future. > [@SergioP](#): > > Attached the second version, now moving the big part as your model. 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. ---
**Author:** ![JuanP74](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@JuanP74](https://calculix.discourse.group/u/JuanP74)\ **Post date:** [May 16, 2024, 6:16pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/14 "2024-05-16T18:16:05Z")
```auto *SURFACE BEHAVIOR,PRESSURE-OVERCLOSURE=LINEAR 1000000000000 ``` surface behavior is not hard, should be the same, but maybe is not… ---
**Author:** ![Calc\_em](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@Calc\_em](https://calculix.discourse.group/u/Calc_em)\ **Post date:** [May 16, 2024, 6:19pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/15 "2024-05-16T18:19:01Z")
Yes, I’ve noticed that and will try it next. ---
**Author:** ![JuanP74](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@JuanP74](https://calculix.discourse.group/u/JuanP74)\ **Post date:** [May 16, 2024, 6:19pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/16 "2024-05-16T18:19:42Z")
> [@Calc\_em](#): > > better to fix the image when sharing this note in the future. I already fixed the picture, and modified it above in the post. ---
**Author:** ![JuanP74](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@JuanP74](https://calculix.discourse.group/u/JuanP74)\ **Post date:** [May 16, 2024, 6:29pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/17 "2024-05-16T18:29:57Z")
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 ![imagen](https://global.discourse-cdn.com/free1/uploads/calculix/original/2X/d/deb18489cb2d4512e05917e69121c87b9d85f81d.png) ---
**Author:** ![Calc\_em](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@Calc\_em](https://calculix.discourse.group/u/Calc_em)\ **Post date:** [May 16, 2024, 6:56pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/19 "2024-05-16T18:56:59Z")
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](https://global.discourse-cdn.com/free1/uploads/calculix/original/2X/7/7e54a25eee858f10260f358b8ef04933b4b2612c.gif) ---
**Author:** ![SergioP](https://yyz2.discourse-cdn.com/free1/user_avatar/calculix.discourse.group/sergiop/32/10_2.png) [@SergioP](https://calculix.discourse.group/u/SergioP)\ **Post date:** [May 16, 2024, 7:05pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/20 "2024-05-16T19:05:55Z")
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: ![image](https://global.discourse-cdn.com/free1/uploads/calculix/original/2X/2/2d00d3562f8da31c3e114ecadf7a201401d10912.png) 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. ---
**Author:** ![Calc\_em](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@Calc\_em](https://calculix.discourse.group/u/Calc_em)\ **Post date:** [May 16, 2024, 7:20pm UTC](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277/21 "2024-05-16T19:20:44Z")
Right, I’ve noticed that dummy step in your input file but didn’t know it was added for this purpose: ```auto *STEP *STATIC,TIMERESET *EL FILE ENER *END STEP ``` I included the same in my model but it didn’t help. ![snap-fit dummy step](https://global.discourse-cdn.com/free1/uploads/calculix/original/2X/2/250f7bd791853e6f69e67ad74404318de1d6f68c.gif) > **[Snap-fit\_dummy\_step.inp](https://www.dropbox.com/scl/fi/tqazy88k5ukxhhyp8w6cg/Snap-fit_dummy_step.inp?rlkey=34pqks3zc2abn11m643g8cyup&st=opu7anwl&dl=0)** > > Shared with Dropbox [Next page](https://calculix.discourse.group/t/snap-fit-contact-snagging-problem/2277.md?page=2)