version 16.4 contact

jacob

Hello, what happened with contact in version 16.4?

Why do I get this error,

L'algorithme de Newton a échoué lors de la projection du point de coordonnées ║
[1,0]<stdout>: ║ (-538.151403,-55.444273,76.281255) ║
[1,0]<stdout>: ║ sur la maille 0. ║
[1,0]<stdout>: ║ Erreur de définition de la maille ou projection difficile.

for older versions like 15.4. and 16.2 there is no problem.

Guillaume_G

Hello,

I am fighting with the same problem using 16.4 and 17 versions. I am not sure if the problem appeared in 16.4, I can not check with older versions because I need certain features from latest versions.

It is happening with QU4 elements and never with TRI3 elements. Reviewing the code, it seems that the problem occurs during the pairing procedure with continuous contact. The procedure relies on the projection of the slave node onto master elements and uses a Newton algorithm. Maybe the fact that TRI3 elements are strictly flat is making convergence easier.

Replacing in bibfor/cont_pair/mmnewt.F90 the line 159

if (type_elem .ne. 'QU4' .and. type_elem .ne. 'QU8') then

if (type_elem .ne. 'QU8') then

is improving the situation by a lot. Now it converges most of the time with QU4 elements, but still randomly crashes in some cases where nothing seems to justify it. I assume there was a reason why the part of the code considering local curvature was not activated for QU4 elements, so the modification suggested above is likely not making the subroutine 100% correct.

It would be great if someone that knows this part of the code better could suggest a change to make it possible to work with QU4 elements without random crashes.

jacob

Yes, I also found out later that tor tria as target it works for my case.
However for simple 3d beams with all hexa contact worked even for q4, for both contact and target. So it seems for planar q4 it works.

Where do I found bibfor/cont_pair/mmnewt.F90 if I have only .sif container?

Guillaume_G

jacob You would need to download the source code and compile yourself if you want to make changes

AsterO'dactyle

Hello,

We've also detected some problems recently.
It seems to be due to a change in version 16.3.1, linked to developments for the HPC version.

Guillaume_G

AsterO'dactyle Thank you. Can you indicate the exact commit where the problem was introduced ? Do you already know what would need to be changed in which file to solve the issue ?

jacob

Hello,
I recently tried version 17.4 but contact still does not work. For 16.2 no problem. Nobody is using contacts?

vishwas

Hi,
I am much into contact friction.
I want to look at your case with this issue. Could you share the model?

Regards
Anirudh

jacob

There is some problem with pairment for some meshes

url=https://forum.code-aster.org/public/assets/files/2026-04-18/1776539055-320945-mesh.7z

jacob

url=https://forum.code-aster.org/public/assets/files/2026-04-18/1776548642-655326-mesh.7z

ML_3 converges with 16.2 in 29 iteration and with 16.4 - Échec de l'appariement de contact lors de l'actualisation géométrique en Newton généralisé.

ML_2 converges with 16.2 in 35 iterations and with 16.4 in 20!

So it might be worth taking the time to make the mesh work for newer versions..

vishwas

Hello,
It looks similar to a 3 point bend test which I did a while back.
I have a few observations regarding your meshes.
Mesh.med is bad for analysis. I believer you used "allow quads" in NetGen Parameters which makes it generate a mix of quad and tri elements on punch half cylinder. Also It creates Pyramid elements in punch which are bad for convergence.
The half cylinder(punch ) is a sweepable body and any other software will recommend swept mesh with base face as a quad dominated mesh. Or choose an all tetra mesh like in ML_2.med or ML_3.med

I don't have access to old version of CA(like 16.2) I ran it with simvia-17.4.0
Regarding comm file:
YOu used FORCE_NODALE on F_1. In my view, FORCE_NODALE is very unstable way to push the cylinder down on rectangular beam. I believe If the mesh density is not uniform like a perfect grid (as is case here on F_1which has tri3 element), we might get inplane moments with FORCE_NODALE which can cause convergence issues.
If your ultimate aim is to push down cylinder vertically while making contact with long beam, I prefer use imposed displacements with AFFE_CHAR_MECA(or better yet AFFE_CHAR_CINE). So changing to
load = AFFE_CHAR_MECA(DDL_IMPO=_F(DX=0.0,
DZ=0.0,
DY =-10,
GROUP_MA='F_1'),
MODELE=MODEL)

The simulation converges for any value of DY (10 , 20 ,30 etc) imposed on F_1.
Next I changed timestepping to be 10 increments until 1 sec.
I changed ALGO_CONT and ALGO_FROT from PENALISATION to STANDARD and it converged fine. STANDARD is better than PENALISATION in terms of accuracy.
I swapped Master and Slave surfaces. Simulation works well for both ML_2 and ML_3 meshes.

ave faces.

I don't quite understand your pre_proccess Stage0. The result in paraview are difficut to guess. are you requesting Material assignment on faces?

Could you explain a bit.
Attaching modified command file for stage_1_load here:

stage-1-load.txt

4kB

Regards
Anirudh

jacob

I tried to reproduce the error on something simple, that's why I created this kind of meshes.

No, I used
force_1 = 1000
f_1 = -force_1 / (A_1 * 1) # the area A_1 is computed in the preprocess, so the load will be exactly 1000 N, even if the size of the cylinder changes.

Force = AFFE_CHAR_MECA(FORCE_FACE=_F(FY=f_1,

                                 GROUP_MA=('F_1', )),

                   MODELE=MODEL)

I am not trying to solve this simple simulation, just comparing contact behavior in different versions.