Problem of contact pairing in recent versions of code_aster

vishwas

Hello,
I have made an observation that contact algorithms in recent version of code_aster(>17) cause an error if the contact surface is of type QU4 or QU8,
That means any contact with linear Quads or Quadratic faces cannot be done.
For example I did a rubber band simulation a while back. It has the master surface as QU8 (inner surface of band).

In the original code, it looks like any contact face with QU4 or QU8 element is discouraged from contact.
Any version of code_aster( v17 or later) is not able to proceed beyond 0.05s.
It always gives these errors:

POINT A PROJETER : 50.505900000000004 -1.2369969209103522E-014 49.409999999999656
MAILLE QU8 8
NOEUD 1
(X,Y,Z) -51.786803709197521 14.340879821529821 63.109744767836183
NOEUD 2
(X,Y,Z) -52.764713144825073 8.3723093276893480E-009 63.112345642251270
NOEUD 3
(X,Y,Z) -52.839778158514640 8.3546126996040750E-009 49.772373941798719
NOEUD 4
(X,Y,Z) -51.853596890383699 14.342136603086663 49.771489469932455
NOEUD 5
(X,Y,Z) -52.519297115749133 7.1868547426364255 63.111749377672318
NOEUD 6
(X,Y,Z) -52.797293288978921 8.3711590985341090E-009 56.442402811568570
NOEUD 7
(X,Y,Z) -52.590938735891264 7.1873134059410981 49.772491922650062
NOEUD 8
(X,Y,Z) -51.816818928772314 14.341096018806532 56.440475805052827
KSI : 0.64222249421726885 0.94785303893367268
ALPHA : 1.0000000000000000

and run stops with this error:
<Erreur> Échec de l'appariement de contact lors de l'actualisation géométrique en Newton généralisé.

Even v18(latest) fails.

But I was able to solve it till 1s with a recompiled version(>v17) where this change was made in mmnewt.F90
From
(type_elem .ne. 'QU4' .and. type_elem .ne. 'QU8')
to
(type_elem .ne. 'QU9')

This change is not guaranteed to work in every case and may randomly fail. If QU4 and QU8 are not permitted in DEFI_CONTACT, then we cannot use quadratic elements(or linear quads) for continue method of contact analysis. Defining mortar contact through LAC may help but as pointed somewhere, LAC contact is not yet able to benefit from MPI parallelism.
How can the latest version solve this problem? and if not then what is being done to address this code change issue?
Also, I believe its more a problem of extracting surface normals .The results look valid from modified version. So, why change a piece of code that works well?

Thanks and regards
Anirudh Nehra

nicolas_p

The problem is fixed in v17.5 and v18.1.

Before v17, an error during projection was not intercepted and continue with error. Now there is a clean error but you can loose robustness but we try to improve it

There is no MPI benefit with contact (CONTINUE or LAC)

vishwas

Hi,
Thank you for responding.
As I understand it, if the QU4 or QU8 surface nodes are out of plane, there shouldn't be an error to determine surface normals now which was the hack I did in the recompiled/modified version.

Also, you said contact computation doesn't benefit from MPI. That means adding more cores in simulation with contact using mpi_nbcpu doesn't reduce computation time?

Regards
Anirudh

nicolas_p

This is not a problem of normal, this is problem of convergence of a local Newton

MPI can reduce time for contact like for other simulation. I say that contact routine does not use MPI. MPI is used in other part like solver or elementary computations

vishwas

Ok thank you for clarification.

vishwas

Hello,
This is not solved. I still get this kind of error with contact. One side is quadratic mesh while other is linear like below.

[1,3]<stdout>: Courbure ? F
[1,3]<stdout>: [1,3]<stdout>: MAILLE [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: KSI [1,3]<stdout>: ALPHA : [1,3]<stdout>: Courbure ? F
[1,3]<stdout>: [1,3]<stdout>: MAILLE [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: KSI [1,3]<stdout>: ALPHA : [1,3]<stdout>: Courbure ? F
[1,3]<stdout>: [1,3]<stdout>: MAILLE [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: KSI [1,3]<stdout>: ALPHA : [1,3]<stdout>: Courbure ? F
[1,3]<stdout>: [1,3]<stdout>: MAILLE [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: NOEUD [1,3]<stdout>: [1,3]<stdout>: KSI [1,3]<stdout>: ALPHA : [1,2]<stdout>: Courbure ? F
[1,2]<stdout>: [1,2]<stdout>: MAILLE [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: KSI [1,2]<stdout>: ALPHA : [1,2]<stdout>: Courbure ? F
[1,2]<stdout>: [1,2]<stdout>: MAILLE [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: KSI [1,2]<stdout>: ALPHA : [1,2]<stdout>: Courbure ? F
[1,2]<stdout>: [1,2]<stdout>: MAILLE [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: KSI [1,2]<stdout>: ALPHA : [1,2]<stdout>: Courbure ? F
[1,2]<stdout>: [1,2]<stdout>: MAILLE [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: NOEUD [1,2]<stdout>: [1,2]<stdout>: KSI [1,2]<stdout>: ALPHA : What is wrong POINT A PROJETER : 9.5073317616778036E-002 6.0000000000000470E-003 3.3599462423808180E-002
QU8 8
1
(X,Y,Z) 9.6130418478459892E-002 8.0736823820920633E-003 2.3367823756289475E-002
2
(X,Y,Z) 9.4828328146634971E-002 8.0716257065711408E-003 2.3357559624895698E-002
3
(X,Y,Z) 9.4830490464304570E-002 6.2289418968920502E-003 2.3610285678319611E-002
4
(X,Y,Z) 9.6110934440600149E-002 6.2383267486121469E-003 2.3647006479215513E-002
5
(X,Y,Z) 9.5478955861498641E-002 8.0711137773372341E-003 2.3359766842106829E-002
6
(X,Y,Z) 9.4829320833744790E-002 7.1476927323832588E-003 2.3494772694809596E-002
7
(X,Y,Z) 9.5468165488586373E-002 6.2291885293625001E-003 2.3619383088099678E-002
8
(X,Y,Z) 9.6123257665289424E-002 7.1541824359063729E-003 2.3514142910856819E-002
: -3.4440490634658136 3.4790681631305245
9.1642330592891952E-002
POINT A PROJETER : 9.5073317616778036E-002 6.0000000000000470E-003 3.3599462423808180E-002
QU8 8
1
(X,Y,Z) 9.6130418478459892E-002 8.0736823820920633E-003 2.3367823756289475E-002
2
(X,Y,Z) 9.4828328146634971E-002 8.0716257065711408E-003 2.3357559624895698E-002
3
(X,Y,Z) 9.4830490464304570E-002 6.2289418968920502E-003 2.3610285678319611E-002
4
(X,Y,Z) 9.6110934440600149E-002 6.2383267486121469E-003 2.3647006479215513E-002
5
(X,Y,Z) 9.5478955861498641E-002 8.0711137773372341E-003 2.3359766842106829E-002
6
(X,Y,Z) 9.4829320833744790E-002 7.1476927323832588E-003 2.3494772694809596E-002
7
(X,Y,Z) 9.5468165488586373E-002 6.2291885293625001E-003 2.3619383088099678E-002
8
(X,Y,Z) 9.6123257665289424E-002 7.1541824359063729E-003 2.3514142910856819E-002
: -3.4440490634658136 3.4790681631305245
9.1642330592891952E-002
POINT A PROJETER : 9.5073317616778036E-002 6.0000000000000470E-003 3.3599462423808180E-002
QU8 8
1
(X,Y,Z) 9.6130418478459892E-002 8.0736823820920633E-003 2.3367823756289475E-002
2
(X,Y,Z) 9.4828328146634971E-002 8.0716257065711408E-003 2.3357559624895698E-002
3
(X,Y,Z) 9.4830490464304570E-002 6.2289418968920502E-003 2.3610285678319611E-002
4
(X,Y,Z) 9.6110934440600149E-002 6.2383267486121469E-003 2.3647006479215513E-002
5
(X,Y,Z) 9.5478955861498641E-002 8.0711137773372341E-003 2.3359766842106829E-002
6
(X,Y,Z) 9.4829320833744790E-002 7.1476927323832588E-003 2.3494772694809596E-002
7
(X,Y,Z) 9.5468165488586373E-002 6.2291885293625001E-003 2.3619383088099678E-002
8
(X,Y,Z) 9.6123257665289424E-002 7.1541824359063729E-003 2.3514142910856819E-002
: -3.4440490634658136 3.4790681631305245
9.1642330592891952E-002
POINT A PROJETER : 9.5073317616778036E-002 6.0000000000000470E-003 3.3599462423808180E-002
QU8 8
1
(X,Y,Z) 9.6130418478459892E-002 8.0736823820920633E-003 2.3367823756289475E-002
2
(X,Y,Z) 9.4828328146634971E-002 8.0716257065711408E-003 2.3357559624895698E-002
3
(X,Y,Z) 9.4830490464304570E-002 6.2289418968920502E-003 2.3610285678319611E-002
4
(X,Y,Z) 9.6110934440600149E-002 6.2383267486121469E-003 2.3647006479215513E-002
5
(X,Y,Z) 9.5478955861498641E-002 8.0711137773372341E-003 2.3359766842106829E-002
6
(X,Y,Z) 9.4829320833744790E-002 7.1476927323832588E-003 2.3494772694809596E-002
7
(X,Y,Z) 9.5468165488586373E-002 6.2291885293625001E-003 2.3619383088099678E-002
8
(X,Y,Z) 9.6123257665289424E-002 7.1541824359063729E-003 2.3514142910856819E-002
: -3.4440490634658136 3.4790681631305245
9.1642330592891952E-002
POINT A PROJETER : 9.5073317616778036E-002 -5.9999999999999568E-003 3.3599462423808180E-002
QU8 8
1
(X,Y,Z) 9.6110934471916654E-002 -6.2383284050202218E-003 2.3647006389278410E-002
2
(X,Y,Z) 9.4830490479352214E-002 -6.2289435620186146E-003 2.3610285757234849E-002
3
(X,Y,Z) 9.4828328141434742E-002 -8.0716273042020417E-003 2.3357559398609905E-002
4
(X,Y,Z) 9.6130418494800335E-002 -8.0736839664686672E-003 2.3367823505178919E-002
5
(X,Y,Z) 9.5468165506043298E-002 -6.2291901915622373E-003 2.3619383079102212E-002
6
(X,Y,Z) 9.4829320833422132E-002 -7.1476943673451799E-003 2.3494772584544726E-002
7
(X,Y,Z) 9.5478955870713977E-002 -8.0711153715588898E-003 2.3359766613296092E-002
8
(X,Y,Z) 9.6123257692228903E-002 -7.1541840738732106E-003 2.3514142762605030E-002
: -3.4435756297720617 -3.4788391611544949
9.1645695895647916E-002
POINT A PROJETER : 9.5073317616778036E-002 -5.9999999999999568E-003 3.3599462423808180E-002
QU8 8
1
(X,Y,Z) 9.6110934471916654E-002 -6.2383284050202218E-003 2.3647006389278410E-002
2
(X,Y,Z) 9.4830490479352214E-002 -6.2289435620186146E-003 2.3610285757234849E-002
3
(X,Y,Z) 9.4828328141434742E-002 -8.0716273042020417E-003 2.3357559398609905E-002
4
(X,Y,Z) 9.6130418494800335E-002 -8.0736839664686672E-003 2.3367823505178919E-002
5
(X,Y,Z) 9.5468165506043298E-002 -6.2291901915622373E-003 2.3619383079102212E-002
6
(X,Y,Z) 9.4829320833422132E-002 -7.1476943673451799E-003 2.3494772584544726E-002
7
(X,Y,Z) 9.5478955870713977E-002 -8.0711153715588898E-003 2.3359766613296092E-002
8
(X,Y,Z) 9.6123257692228903E-002 -7.1541840738732106E-003 2.3514142762605030E-002
: -3.4435756297720617 -3.4788391611544949
9.1645695895647916E-002
POINT A PROJETER : 9.5073317616778036E-002 -5.9999999999999568E-003 3.3599462423808180E-002
QU8 8
1
(X,Y,Z) 9.6110934471916654E-002 -6.2383284050202218E-003 2.3647006389278410E-002
2
(X,Y,Z) 9.4830490479352214E-002 -6.2289435620186146E-003 2.3610285757234849E-002
3
(X,Y,Z) 9.4828328141434742E-002 -8.0716273042020417E-003 2.3357559398609905E-002
4
(X,Y,Z) 9.6130418494800335E-002 -8.0736839664686672E-003 2.3367823505178919E-002
5
(X,Y,Z) 9.5468165506043298E-002 -6.2291901915622373E-003 2.3619383079102212E-002
6
(X,Y,Z) 9.4829320833422132E-002 -7.1476943673451799E-003 2.3494772584544726E-002
7
(X,Y,Z) 9.5478955870713977E-002 -8.0711153715588898E-003 2.3359766613296092E-002
8
(X,Y,Z) 9.6123257692228903E-002 -7.1541840738732106E-003 2.3514142762605030E-002
: -3.4435756297720617 -3.4788391611544949
9.1645695895647916E-002
POINT A PROJETER : 9.5073317616778036E-002 -5.9999999999999568E-003 3.3599462423808180E-002
QU8 8
1
(X,Y,Z) 9.6110934471916654E-002 -6.2383284050202218E-003 2.3647006389278410E-002
2
(X,Y,Z) 9.4830490479352214E-002 -6.2289435620186146E-003 2.3610285757234849E-002
3
(X,Y,Z) 9.4828328141434742E-002 -8.0716273042020417E-003 2.3357559398609905E-002
4
(X,Y,Z) 9.6130418494800335E-002 -8.0736839664686672E-003 2.3367823505178919E-002
5
(X,Y,Z) 9.5468165506043298E-002 -6.2291901915622373E-003 2.3619383079102212E-002
6
(X,Y,Z) 9.4829320833422132E-002 -7.1476943673451799E-003 2.3494772584544726E-002
7
(X,Y,Z) 9.5478955870713977E-002 -8.0711153715588898E-003 2.3359766613296092E-002
8
(X,Y,Z) 9.6123257692228903E-002 -7.1541840738732106E-003 2.3514142762605030E-002
: -3.4435756297720617 -3.4788391611544949
9.1645695895647916E-002
with aster? The cylinder simply push onto tube. Calculix takes like 5 mins but aster never goes past 0.1s (with any formulation, 3D, 3D_SI, Standard, Penalisation, even LAC fails)

Regards
Anirudh

SantiagoMR

Hi Anirudh, sorry I don't have a solution or help for your issue, but since this post is recent, I wanted to jump in and share my related problem.

I`m currently using code_aster 17.4.0, running in parallel with MPI (4 processes). (from salome_meca-lgpl-2025.1.0-1-20251026-scibian-12)

Context: DEFI_CONTACT(FORMULATION='CONTINUE', ALGO_RESO_CONT='POINT_FIXE', ALGO_RESO_GEOM='POINT_FIXE', ZONE=_F(ALGO_CONT='STANDARD', APPARIEMENT='MAIT_ESCL', FROTTEMENT='SANS', NORMALE='MAIT', ...)), used inside a STAT_NON_LINE on a model assembled via ASSE_MAILLAGE/non-coincident meshes (other interfaces in the model are tied separately with LIAISON_MAIL).

In my case, the simulation converges—it already did in the previous version of Code_Aster—but I took advantage of this new version to rerun the case and test it.

Two issues observed, without having changed anything else relative to an otherwise equivalent configuration:

1) .mess flooded with projection traces

The .mess file gets flooded with blocks like this, apparently on every Newton iteration and for every contact point evaluated, without requesting INFO=2 or any explicit debug output:

 Courbure ? F
 POINT A PROJETER :    5.2243212178379244E-003   3.1458602833516840E-003   1.3997448338566529E-003
 MAILLE             QU4                         4
   NOEUD                     1
    (X,Y,Z)   5.2623337084227312E-003   3.0784130424458579E-003   1.1999735148488181E-003
   NOEUD                     2
    (X,Y,Z)   5.2123004120221044E-003   3.1620009120655389E-003   1.1999734894381513E-003
   NOEUD                     3
    (X,Y,Z)   5.2123004730726501E-003   3.1620008063228911E-003   1.3999690674168612E-003
   NOEUD                     4
    (X,Y,Z)   5.2623337670902586E-003   3.0784129366068363E-003   1.3999690959771089E-003
 KSI   :    0.0000000000000000        0.0000000000000000     
 ALPHA :    1.0000000000000000

This looks like an internal debug trace from the master/slave projection algorithm (APPARIEMENT), which seems to stay active under MPI even without a high log level. The .mess file reaches tens of thousands of lines just from this, which makes it very hard to follow the actual computation (residuals, Newton iterations, time-step cuts).

Question: is this a known behavior of CONTINUE contact under MPI? Is there a keyword to disable these projection traces specifically (without losing the rest of the INFO=1 output), or is this a log level that should only show up in debug and stays active by mistake in parallel?

2) CONT_NOEU field missing from the result under MPI

With contact active in the same STAT_NON_LINE, the CONT_NOEU field does not appear in the exported MED file (checked in ParaView), while with IMPR_RESU(RESU=_F(RESULTAT=...), UNITE=...) (no specific NOM_CHAM) I expected to find it as usual, without having changed anything else in the .comm.

Question: is the computation/storage of CONT_NOEU disabled or incomplete under MPI + FORMULATION='CONTINUE' in this version? Is a specific keyword needed (in CALC_CHAMP, DEFI_CONTACT, or IMPR_RESU) to force it in parallel?

Thanks in advance for your contribution, and I hope the post gets more visibility!

Santiago

vishwas

SantiagoMR
Hi,
Thank you for you response.
But I want to share some insights.
This is the result from calculix for the same simulation. It uses C3D8(linear hex), and solved in 168s. Same mesh same boundary conditions and simple contact definition. Shows correct elasto plasticity(true stress vs strain) taken into account.

I manually copied traction curve inside .comm file because this did not work even till 0.1s
CTRAC = LIRE_FONCTION(
NOM_PARA='EPSI',
PROL_DROITE='CONSTANT',
UNITE=21
)
code_aster cannot go past 0.6s with 6 MPI_NBCPU. It seems contact doesn't use MPI parallelism.
Also I think iterations tend to get slower as time progresses.
Employing all contact methods( REAC_GEOM= AUTO/CONTROL, NB_ITER_GEOM=1, ALGO=STANDARD/PENALISATION/LAC) doesn't work with GDEF_LOG/SIMO_MIEHE and VMIS_ISOT_TRAC. Only works with VMIS_ISOT_LINE. Swapping master/slave surf did not work.
Changing to QUAD elements(tube) and using 3D_SI also did not work .
even using COQUE_SOLIDE and more 4 elements through thickness did not work.
One more finding- COQUE_SOLIDE does not work with LAC method. The COQUE_SOLIDE GROUP_MA_SURF is declared as non valable by code_aster.(don't know why). Apart from this found many cases of abnormal abort without any message provided. later I found out that DECOUPE_LAC GROUP_MA_SURF cannot have any BC(like DX=0 etc. on them)
On top of that there were again pairing errors as indicated above.
Edit: it worked somehow.

Regards
Anirudh

vishwas

Hello @SantiagoMR
I took a look at your questions.
1) as far as I know, the projection output log shows up automatically and one can't do anything to enable or disable it. The best you can do to avoid too much output is
run_aster file.export --only-proc0
2) CONT_NOEU must be available by default in IMPR_RESU without any modification. It shows up as seperate compsum when you open .rmed file. I never found it missing under Continue contact formulation. Please check your command file as well as code aster version. V17 should produce it.
3)I think we need more and updated information regarding contact working especially LAC. It is very undocumented. IF we assign COQUE_SOLIDE to a mesh group, the mesh faces cannot be assigned DECOUPE_LAC under CREA_MAILLAGE. The code says the mesh is not valable for LAC method.
Also if you put a BC ON LAC GROUP_MA_surf, code will crash with no info.
4) still very limited info regarding above projection error which was said to have been fixed. Anyway I tried with a modified version with QUA4 and QUA8 elements removed in Contactpairing.F90 but it still produced same error.
5) Compared to calculix, code aster contact is more sensitive to mesh sizing, aspect ratio etc. It is also sensitive to RESI_GEOM. for example resi_geom of 0.05 instead of 0.01 can cause divergence. The time taken by aster was 23 minutes while calculix took 3 mins for same mpi_nbcpu.
6)I copied CTRAC from a testcase and named it stress-strain-curve.txt assigning it a unit. and used it like in code above using LIRE_FUNCTION But it caused divergence very early. So probably it wasn't read correctly. Then I copied values under DEFI_FONCTION inside .comm file which seems to have worked.

Regards
Anirudh

SantiagoMR

vishwas

Hi Vishwas,

Thanks for taking the time to reply!

Thanks, I'll keep that in mind. My issue very similar to yours: contact between two cylindrical surfaces (cylinder-on-cylinder) with a similar log output.
You are completely right. I made a beginner's mistake by putting the initial non-linear solve (without contact) and the subsequent non-linear contact step into a single IMPR_RESU command. Separating into them distinct output commands with unique result names fixed the issue.

Regarding your query: I don't have experience alless with shell finite element models, so I for being of more help there. However, give the combined complexity of geometric, material, and contact non-linearities, have you considered essay slow dynamic formulation (DYNA_NON_LINE)? While it't won't solve the speed comparison against CAELinux (and might even increase time time), it could help stabilize the problem and improve convergence.

AsterO'dactyle

Hello AsterO'dactyl,

Thank you for the clarification!

I am some getting used to the newer stable and development versions of Code_Aster. I previously linked on the older 2021 MPI build because it was workingably for my workflow. However, given the recent updates and made improvements by the EDF team, I'm now testing the latest builds on my local machine (though of course, that comes with updating my .comm files and adapting deprecated features).

My current working version was downloaded directly from the official Code_Aster website. To access bugfix updates like 17.4.20, should I source them directly from the GitLab tags repository ()?

AsterO'dactyle

Hello

1/ Issues with the projection (including displays) were fixed in versions 17.4.20 and 18.0.21
3/ The LAC formulation and the COQUE_SOLIDE elements will be removed from the code. For the former, the new methods (DEFI_CONT operator + MECa_NON_LINE) replace it (in particular, they allow for friction).
The COQUE_SOLIDE element does not function correctly and, in fact, has never been certified for nuclear applications. It is certain that it does not work with the LAC method because COQUE_SOLIDE is based on a HEXA9, and DECOUPE_LAC cannot process HEXA9s. We are attempting to develop a new, more conventional MITC-type plate element.
6/ This is very strange; there is likely an error on your end, as using DEFI_FONCTION is strictly equivalent to using LIRE_FONCTION. Please check PROL_DROITE and PROL_GAUCHE maybe ?

AsterO'dactyle

Access to changelog (named "histor" in our old vocabulary since 1989 😉 )

https://gitlab.com/codeaster/changelog/

For instance, for projection: commit efc28c0a904b38dac1ba53b2038791bb4a2454fd

vishwas

Hello
Thank you for your response.
Even if I switch sides for COQUE_SOLIDE (selecting internal faces without DECOUPE_LAC conditions) I get the same error.
And i find it usually better to select outside faces of a tube for COQUE_SOLIDE. But with this error, COQUE_SOLIDE doesn't seem to work with LAC.
But Certainly it should not be removed as it seemed very promising (no mesh dependence, large deformation support, good for non linear buckling with thin walls etc.)

To @SantiagoMR
How do you say CAELinux is faster? isn't its backend driven by code_aster? Or some other open source software.
I will try with DYNA_NON_LINE but there are too many vibrations at low frequency which diverge solution. Do you know what coefficient to be selected for damping parameters ?
Also how do I search with this hash. I tried finding files but returned no result.

Regards
Anirudh

SantiagoMR

Hi vishwas

My apologies for the confusion earlier! I meant CalculiX, not CAELinux (which, as you pointed out, is just a distribution that includes Code_Aster anyway). My previous comment was more of a qualitative observation regarding runtimes, but I completely get what you mean about "CalculiX taking 5 minutes while Aster gets stuck at 0.1s".

That stall usually happens during the setup phase or when DYNA_NON_LINE struggles to converge right at the beginning due to un-damped low-frequency vibrations.

To stabilize the solution and get past those low-frequency oscillations, adding Rayleigh damping is usually the best approach. In Code_Aster, Rayleigh damping is defined as:

C = alpha * K + beta * M

Where the coefficients alpha and beta are calculated based on two target frequencies (w1 and w2 in rad/s) and a damping ratio (xi):

alpha = (2 * xi) / (w1 + w2)

beta = (2 * xi * w1 * w2) / (w1 + w2)

xi (Damping ratio): A typical starting value for steel structures in literature is 0.02 (2%).
w1, w2: The frequency range (in rad/s) you want to damp out, particularly the low-frequency modes causing the divergence.

In Code_Aster, you define these parameters inside DEFI_MATERIAU under the ELAS keyword:

MATERIAU = DEFI_MATERIAU(
    ELAS=_F(
        E=E,
        NU=NU,
        RHO=RHO,
        AMOR_ALPHA=alpha_val,  # Multiplies Stiffness (K) = 1e-6 
        AMOR_BETA=beta_val,    # Multiplies Mass (M) =  1.05
    ),
    TRACTION=_F(SIGM=TRAC),
)

Important Caution: Be very careful with the notation! In classic FEA literature, alpha typically multiplies Mass and beta multiplies Stiffness (C = alphaM + betaK). In Code_Aster, AMOR_ALPHA multiplies Stiffness (K) and AMOR_BETA multiplies Mass (M). Getting them swapped will cause the solver to diverge almost immediately (speaking from painful past experience!).

I recommend double-checking the DEFI_MATERIAU documentation (u4.43.01) for your specific version to confirm the exact parameter definitions.

Hope this helps in DYNA_NON_LINE!

vishwas

Hi,
Thanks for reply. I will look into it soon.
However I want to share some more finding. I think ALGO_CONT='PENALISATION' performs poorly in comparison to calculix. Not only the iterations and run time high, but also there is significant interpenetration between master and slave surfaces.

One can see this result till 0.4s after which solver diverges.
On top of that, I specified PENE_MAXI = 1e-5 but it was not respected in output. The first converged step had Contact penetration as 2.3e-05. It increased to order of 1e-04 in subsequent converged time steps.
However calculix solved it very fast and one can see almost nil penetration above in calculix output.
In case of calculix:
The penetration COPEN parameter is max of the order of 2e-06 using hard surface to surface contact. But even for LInear surface to surface contact, COPEN is around 1e-05.
It makes me wonder is there some room for improvement of PENALISTION algorrithm in CONTINUE method.

Regards
Anirudh

AsterO'dactyle

Hello

The CONTINUE method is no longer being developed. We’re making a few bug fixes—such as the pairing issue—because some parts are shared with the new DEFI_CONT operator, but nothing new is being added.

vishwas

Hello,
Thanks for the reply.
If CONTINUE method not being developed/improved then I hope the new DEFI_CONT should be more powerful/robust and use MPI much better than the old DEFI_CONTACT?
Also I think only linear elements(tetra hexa) are well tested in aster for contact studies. Any other elements like Quadratic/ HEXA27/ 3D_SI /Coque_Solide etc are only added for simple cases and not rigorously tested under huge meshes or non-linear effects. C3D20R is the equivalent of 3D_SI in calculix but very robust. I don't know how 3D_SI performs.
Same may be applicable for Mixed formulations like 3D_INCO, 3D_INCO_UPG and behaviors like VMIS_Jonhnson_cook etc. makes me wonder if they work well enough undare large non linear studies.

Regards
Anirudh

AsterO'dactyle

Hello,

DEFI_CONT is an evolution of DEFI_CONTACT, designed for large-scale distributed HPC in conjunction with new operators also dedicated to HPC (such as MECA_NON_LINE). It is a more robust formulation than the CONTINUE and LAC methods in that it is a true mortar method (it also features a true penalty term, and lays the groundwork for Nitsche-type methods). Mortar method is a technically challenging problem. Making curved surfaces intersect in any 3D space, whilst ensuring optimal HPC efficiency, remains a complex problem.
There are few tests involving quadratic surfaces (curved or otherwise) for two reasons:
1/ The great practical difficulty in performing intersections of curved meshes
2/ Theoretical convergence difficulties (inf-sup stability for mixed formulations) which are still the subject of publications in litterature. This explains, for example, the popularity of Nitsche-type methods (which are primal) or recent work by the German school on contact with a deformable third body.
I think that 3D_SI is equivalent to Calculix’s C3D20R (or ABAQUS’s C3DR, for example).
Apart from the specific case of Nitsche, DEFI_CONT has no restrictions on the underlying finite elements (INCO_* or 3D_SI) or the constitutive laws. However, the problem of structural elements (beams, plates, shells) remains largely unaddressed.

AsterO'dactyle

For DEFI_CONT:

https://hal.science/hal-05658136

vishwas

Hi,
Thanks for the reply.
All I am saying is that the algorithm of contact has to be more robust and fast. For example I did the same simulation in cast3m. It took the same mesh and used Augmented Lagrange between contacting surfaces.
Not only it solved the above step(cylinder pushing onto tube) but I could rotate one end of tube to introduce serious buckling in tube while maintaining contact with cylinder. And it solved with quadratic hypothesis in under 1 hour. Here is the link

Why 3d_SI doesn't work here or why code_aster has problems with quadratic elements are questions here.

Regards
Anirudh