Contact doesn't converge with no load

Contact with no load and all parts fully constrained sometimes doesn’t converge and ends with *ERROR: increment size smaller than minimum. The true solution might be all zero but nonetheless, is there a way to make that work without changing the meaning of the model?

https://mecway.com/zero.inp

I’m wondering if CCX uses a convergence criterion that requires some force or displacement to exist or change. I can’t see anything in *CONTROLS that looks helpful.

Hello,
Could you clarify - how many iterations(calculation time) to the error.
Also, not clear this moment:

*STATIC
1,1,0,0

please try

*STATIC
1,1

It seems to have taken about 1000 iterations or a couple of minutes to eventually fail.

Same happens with 1,1 instead of 1,1,0,0.

Excuse me but I have not enough experience for that task.

Hi,

without load the problem may not be well defined. Looking at the *.sta, *.cvg and the displacements may help to understand the problem.

Guido

Thanks Guido. Physically, it seems to be valid. Just 2 cubes touching each other with contact and both fixed in place. It also solves OK if you change one of the *BOUNDARY nodes from 0 to 0.01 (and move it to the *STEP section). So it feels like this should be able to solve but perhaps mathematically it’s not well defined.

Actually, this is just a workaround for another issue which maybe you can shed some light on. Contact stiffness changes throughout the first step and that can give unexpected results in models where the stiffness value is important during the step, not just at the end. I’m not sure if that’s a bug or intentional? I’m trying to work around it by putting this kind of “do nothing” first step before the real step that has loads.

Hi,

the spring stiffness constants are only changed (decreased) if there are problems with convergence. As far as I remember, this is only done at the start of the iterations, i.e. in the final iterations the user-defined value is restored and the result at the end of the increment should be fine. A step consists of one or more increments, so you can can get correct results within a static step by using more increments.

Best Greetings,

Guido

It doesn’t seem to behave that way. Here’s an example where the result is correct at the first and last increment of a step but, in the middle, it behaves as if the contact stiffness is reduced.

Inp file:

*NODE
1,0,0,0
2,1,0,0
3,1,1,0
4,0,1,0
5,0,0,1
6,1,0,1
7,1,1,1
8,0,1,1
9,0,1,0
10,1,1,0
11,1,2,0
12,0,2,0
13,0,1,1
14,1,1,1
15,1,2,1
16,0,2,1
*ELEMENT,TYPE=C3D8,ELSET=Default
1,1,2,3,4,5,6,7,8
2,9,10,11,12,13,14,15,16
*MATERIAL,NAME=Material
*ELASTIC,TYPE=ISOTROPIC
200000000000,0
*SOLID SECTION,ELSET=Default,MATERIAL=Material
*BOUNDARY
1,1,3,0
2,1,3,0
5,1,3,0
6,1,3,0
11,1,,0
11,3,,0
12,1,,0
12,3,,0
15,1,,0
15,3,,0
16,1,,0
16,3,,0
*SURFACE,NAME=contact_faces(2)
2,S3
*SURFACE,NAME=contact_faces
1,S5
*CONTACT PAIR,INTERACTION=SI_1,TYPE=SURFACE TO SURFACE
contact_faces(2),contact_faces
*SURFACE INTERACTION,NAME=SI_1
*SURFACE BEHAVIOR,PRESSURE-OVERCLOSURE=LINEAR
100000

*STEP,NLGEOM=YES,AMPLITUDE=STEP
*STATIC,DIRECT
0.5,2
*CLOAD
11,2,-2500
12,2,-2500
15,2,-2500
16,2,-2500
*NODE FILE
U
*END STEP

Solution:

Time, displacement in y at node 9:
0.5, -0.1 (correct)
1.0, -0.167
1.5, -0.183
2.0, -0.1 (correct)

Hi,

I could reproduce the problem. I will have a look at it.

Best Greeting and thanks,

Guido

Thanks a lot Guido! This has been a real tricky one.

Hi,

now I know the exact line causing the effect: the line running

springarea(2,igauss)=clear/(1.d0-theta)

in gencontelem_f2f.f (about line 578). I am not sure, whether I want to limit its execution to iinc=1 (the first increment). It seems to help convergence in some examples. I will have a closer look at the start of the new year.

best greetings,

Guido

1 Like

Fantastic. Thanks for figuring this out! Maybe it can at least be an option?

Similar issue still exists in 2.19 release.