Welcome to the forums. Please post in English or French.

You are not logged in.

#1 Re: Code_Aster usage » Questions with Liaison_DDL » 2021-09-08 10:17:03

Yes you are right. A node doesn't hold any Degree Of Freedom (DDL en français) initially. To get some DOF, the node need to be part of a finite element with physical properties (rod, bar, shell, 3d or discretet element like POI1 with DIS_T or DIS_TR properties).

#2 Re: Code_Aster installation » Code_Aster doesn't quit after the calculus' end » 2020-09-10 08:21:28

I had the same problem. It was because I changed the number of core of my virtual machine and aster didn't catch the change

I had P ncpus 1  in my export file (aster to use 1 core of the cpu) and that was fixed.

#3 Re: Code_Aster usage » ENDO_ISOT_BETON pour DKT » 2020-08-25 07:20:27

Je me permets de faire remonter le sujet quelqu'un de l'équipe code_aster peur le voir.

#4 Re: Code_Aster usage » user-defined element » 2020-08-25 07:16:31

There is this presentation :

code-aster.org/V2/UPLOAD/DOC/Formations/10-finite_element_advanced.pdf

And this documentation code-aster.org/V2/doc/default/en/man_d/d5/d5.02.02.pdf
(tranlated from french to english by a software thus... )


I'm just aware that this exist, I didn't read and study the pointed documents (I just scrolled through them).

#5 Re: Code_Aster usage » Result Discrepancy between Abaqus and Code_Aster » 2020-08-24 09:25:51

I didn't see that you were already using D_PLAN_SI. All kind of MODELISATION are not available with all kind of COMPORTEMENT in code_aster. If ELAS_VIMS_LINE is not available (yet) with D_PLAN_SI, there is no magic solution and you should then use second order elements as you did to get correct result (or use a thiner mesh).

#6 Re: Code_Aster usage » Result Discrepancy between Abaqus and Code_Aster » 2020-08-21 08:19:27

The reduced integration for QUAD4 elements is activated with 'C_PLAN_SI' or 'D_PLAN_SI' modelisation according to R3.06.10. It would be interresing to check the result with this kind of modelisation. Maybe this "feature" is activated by default with Abaqus ?

#7 Re: Code_Aster usage » ENDO_ISOT_BETON pour DKT » 2020-07-31 10:03:11

6) Est-ce ce gênant que les mailles soient trop petites vis à vis de la localisation des dommages ?

7) Est-ce qu'utiliser des éléments quadratiques peut aider?

#8 Code_Aster usage » ENDO_ISOT_BETON pour DKT » 2020-07-31 08:51:51

Voulet2
Replies: 2

Bonjour.

J'ai plusieurs questions sur la mise en oeuvre d'un calcul avec le modèle ENDO_ISOT_BETON et des éléments DKT.

La notice u2.06.10 version15 indique page 21/51 au §4.4 tableau 2 qu'ENDO_ISOT_BETON n'est disponible que pour des éléments 3D massif mais je les utilise pour des éléments `DKT` (2D local, j'imagine donc ?).
1) On est bien d'accord que pour cette loi, l'algorithme de De Borst permet de passer de la 3D à la 2D, non ? Du coup ce serait une erreur de la doc ?

Aussi, j'ai beaucoup de mal à pousser un peu les calculs au delà du pic en traction. J'essaie typiquement de faire passer le cas test SAFE avec le maillage du cast test SDNV114 (avec le même cas de chargement), je ne parviens pas à aller à 25% de ce que peut faire GLRC_DAMAGE. (J'ai bien sûr ajouter des grilles_excentrée mais elles n'ont pas encore plastifié).

Pouvez vous me confirmez que vu que j'utilise des éléments structuraux `DKT`:

2) Il n'est pas possible de jouer sur la longueur caractéristique dans NON_LOCAL de DEFI_MATERIAU car nous ne sommes pas dans une modélisation GRAD_VARI ?

3) Dans ce cas comment se passe la pénalisation pour faire en sorte que le calcul soit plus ou moins dépendant du maillage ? Est-ce qu'il faut que mes mailles aient une taille caractéristique ? Y-a-t-il des recommandations ?

4) Avec Newton-Raphson, il n'est pas possible d'utiliser la recherche linéaire pour des éléments de type DKT, n'est-ce pas ?

5) Y a t'il des bonnes pratiques qui indiquent à partir de camp passer à la matrice sécante ?

Voilà qui est tout.

Merci de mettre Code_aster à disposition. Très bon logiciel.

Bon weekend.

#10 Code_Aster usage » Issue to print results at a specified SOUS_POINT (DKT) » 2020-07-08 11:46:19

Voulet2
Replies: 1

Hi.

I've a plate made of DKT made of  4 layers :

CARA = AFFE_CARA_ELEM(
    MODELE=MO,
    COQUE=_F(
        GROUP_MA='dalle',
        EPAIS=0.16,
        VECTEUR=(1, 0, 0),
        COQUE_NCOU=4,
        INER_ROTA='OUI',
        MODI_METRIQUE='NON',
    ),

Since i've 4 layers i guess i've 2*4 + 1 = 9 integrations points.
I then apply some pressure loads on this plate. Calculation run fine.

Then I would like to calculate the stress at each integration point. I use the following loop for this

RESU = CALC_CHAMP(
    reuse=RESU,
    RESULTAT=RESU,
    CONTRAINTE=('SIGM_ELGA',),
)
liste_couche = [
    1,
    2,
    3,
    4,
]

liste_unite = [
    91,
    92,
    93,
    94,
]
for i, unite in zip(liste_couche, liste_unite):
    res_inf = POST_CHAMP( RESULTAT=RESU, GROUP_MA='dalle', EXTR_COQUE=_F( NUME_COUCHE=i, NIVE_COUCHE='INF', NOM_CHAM=('SIGM_ELGA', ), ), )
    res_moy = POST_CHAMP( RESULTAT=RESU, GROUP_MA='dalle', EXTR_COQUE=_F( NUME_COUCHE=i, NIVE_COUCHE='MOY', NOM_CHAM=('SIGM_ELGA', ), ), )
    res_sup = POST_CHAMP( RESULTAT=RESU, GROUP_MA='dalle', EXTR_COQUE=_F( NUME_COUCHE=i, NIVE_COUCHE='SUP', NOM_CHAM=('SIGM_ELGA', ), ), )
    
    sig_inf = CREA_TABLE(RESU=(_F( RESULTAT=res_inf, NOM_CHAM='SIGM_ELGA', TOUT_CMP='OUI', GROUP_MA='dalle', ), ), )
    sig_moy = CREA_TABLE(RESU=(_F( RESULTAT=res_moy, NOM_CHAM='SIGM_ELGA', TOUT_CMP='OUI', GROUP_MA='dalle', ), ), )
    sig_sup = CREA_TABLE(RESU=(_F( RESULTAT=res_sup, NOM_CHAM='SIGM_ELGA', TOUT_CMP='OUI', GROUP_MA='dalle', ), ), )

    IMPR_TABLE( TABLE=sig_inf, TITRE='sig_inf', UNITE=unite, FORMAT='TABLEAU', FORMAT_R='1PE12.3', )
    IMPR_TABLE( TABLE=sig_moy, TITRE='sig_moy', UNITE=unite, FORMAT='TABLEAU', FORMAT_R='1PE12.3', )
    IMPR_TABLE( TABLE=sig_sup, TITRE='sig_sup', UNITE=unite, FORMAT='TABLEAU', FORMAT_R='1PE12.3', )
    DETRUIRE(CONCEPT=_F(NOM=res_inf, ), )
    DETRUIRE(CONCEPT=_F(NOM=res_moy, ), )
    DETRUIRE(CONCEPT=_F(NOM=res_sup, ), )
    DETRUIRE(CONCEPT=_F(NOM=sig_inf, ), )
    DETRUIRE(CONCEPT=_F(NOM=sig_moy, ), )
    DETRUIRE(CONCEPT=_F(NOM=sig_sup, ), )

Unfortunatly when I check my generated files they are all calculated at SOUS_POINT=1.

Here is a paste of a part of the file corresponding to UNITE=93 where I think I should have SOUS_POINT=3 (or 7 maybe ?)

#TABLE_SDASTER                                                                   
RESULTAT NOM_CHAM          INST          NUME_ORDRE   MAILLE    POINT         SOUS_POINT    COOR_X        COOR_Y        COOR_Z        SIXX          SIYY          SIZZ          SIXY          SIXZ          SIYZ        
res_sup  SIGM_ELGA            3.000E+00            30 M328                 1             1     1.723E+00    -8.686E-01    -8.000E-02     1.925E+04     2.718E+03     0.000E+00    -8.235E+01     3.395E+05    -1.080E+04
res_sup  SIGM_ELGA            3.000E+00            30 M328                 2             1     1.723E+00    -9.648E-01    -8.000E-02     1.940E+04     2.749E+03     0.000E+00    -2.155E+02     3.403E+05    -1.080E+04
res_sup  SIGM_ELGA            3.000E+00            30 M328                 3             1     1.821E+00    -9.648E-01    -8.000E-02     1.947E+04     3.086E+03     0.000E+00    -2.776E+02     3.403E+05    -8.699E+03
res_sup  SIGM_ELGA            3.000E+00            30 M328                 4             1     1.821E+00    -8.686E-01    -8.000E-02     1.931E+04     3.055E+03     0.000E+00    -1.445E+02     3.395E+05    -8.699E+03
res_sup  SIGM_ELGA            3.000E+00            30 M329                 1             1     1.892E+00    -8.686E-01    -8.000E-02     6.626E+03     6.445E+02     0.000E+00     4.566E+01     3.726E+05    -5.423E+03
res_sup  SIGM_ELGA            3.000E+00            30 M329                 2             1     1.892E+00    -9.648E-01    -8.000E-02     6.744E+03     6.681E+02    -1.421E-14     3.604E+01     3.734E+05    -5.423E+03
res_sup  SIGM_ELGA            3.000E+00            30 M329                 3             1     1.989E+00    -9.648E-01    -8.000E-02     6.749E+03     6.924E+02     0.000E+00    -1.177E+01     3.734E+05    -1.983E+03
res_sup  SIGM_ELGA            3.000E+00            30 M329                 4             1     1.989E+00    -8.686E-01    -8.000E-02     6.631E+03     6.688E+02     0.000E+00    -2.156E+00     3.726E+05    -1.983E+03

some part of my export file look like this:

F comm ./comm.comm D  1
F mmed ./mesh_moyen.mail D  20
F mess ./mess.mess R  6
F resu ./sigm_couche1.resu R  91
F resu ./sigm_couche2.resu R  92
F resu ./sigm_couche3.resu R  93
F resu ./sigm_couche4.resu R  94

Is there something i'm doing wrong ?

#11 Re: Salome-Meca usage » Shear/Moment diagrams in ParaVIS » 2020-06-26 11:51:52

Hello.

You may use the filter "plot over line" in paravis. It will display the values you want along a line. (You need to specify the two point that define the line)

#12 Re: Code_Aster usage » Visualizaton differences between DEPL and VMIS using DKT elements » 2020-05-05 15:47:33

Have you postreated the VMIS on a specific layer ?

If this is not the case : DKT elements are some  multi layers elements. You have to post-treat the VMIS stress on a specific layer since the stress field is varying along the thickness of the DKT element.

For exemple :

RESU=CALC_CHAMP(reuse =RESU,
                   RESULTAT=RESU,
                   CRITERE=('SIEQ_ELGA',),
);       

# VMIS on lowest layer
resu2=POST_CHAMP(
    RESULTAT=RESU,
        EXTR_COQUE=_F(
            NUME_COUCHE=1,
            NIVE_COUCHE='INF',
            NOM_CHAM=('SIEQ_ELGA' ),
),

then print resu2

#13 Re: Code_Aster usage » Suggestion to speed-up nonlinear analysis » 2020-04-20 07:59:15

Hello.

corra wrote:

The COEF_MULT is already quite high, leading to a number of steps which is reasonable in the ascending branch

If I'm not misatking, smaller the COEF_MULT is, faster is the analysis. Did you try a run with a smaller value ?

#14 Re: Code_Aster usage » Repères utilisateurs en MED avec IMPR_RESU et Aster V14 » 2020-04-16 08:29:31

Bonjour monsieur Aubry.

Merci pour l'aide (et merci pour toutes ces années d'aide sur le forum ! Vous allez pouvoir ouvrir une brasserie avec ces litres de bière qu'on vous doit). En effet un nouveau mot clé apparaît avec code_aster V14 : IMPR_CONCEPT()

IMPR_CONCEPT(
        CONCEPT = (
            _F(CHAM_MATER=MATER,),
            _F(
                CARA_ELEM=CARA,
                REPERE_LOCAL='ELNO',
                MODELE=mo,
            ),
        ),
        UNITE=81,
        INFO=1,
        FORMAT='MED',
);

#15 Re: Code_Aster usage » Composite Analysis - Results in Ply Coordinate System - Failure Index » 2020-04-14 15:26:36

Hi.

The Tsai-Hill criterion is no more avaibale in code_aster. (I'm not a developper of code_aster but I've seen this information on the forum some time ago.) You have to extract the stresses or deformation on each ply and compute it "by hand".

#16 Re: Code_Aster usage » cumulating the value of previous time-step in a userdefine variable » 2020-04-07 13:21:23

こんにちは, bonjour,

you can define some python function and call them using FORMULE()

Maybe the following should work (I have not tested):

T_begin=100;
Temperature=T_begin;

def cumul_temp(t):
    Temperature=Temperature+100*t
    return Temperature


FM_react = FORMULE(NOM_PARA=('TEMP'),
           VALE='cumul_temp(TEMP)',
);

See the documentation U4.31.05 §4.5

EDIT: maybe FM_react = FORMULE(NOM_PARA=('INST'),VALE='cumul_temp(INST)',); would work better since INST is the step of your calculation.

#17 Re: Code_Aster usage » ABNORMAL_ABORT: Unknown key words: ADAPTATION » 2020-04-07 07:54:33

Hi. Could you share your .comm file ? The documentation U4.34.03 p. 5/17 states that the keyword ADAPTATION is enable only if the keyword METHOD=‘CAR’ is written (by default METHOD='MANUAL')

Note: 'CAR' is supposed to be 'AUTO' as in AUTOMATIC as I can see in the french documentation. Unfortunately the automatic translation translated AUTO ("car" in french) by 'CAR'.

#18 Code_Aster usage » Repères utilisateurs en MED avec IMPR_RESU et Aster V14 » 2020-04-06 17:01:53

Voulet2
Replies: 2

Bonjour,

Avant j'utilisais :

IMPR_RESU(FORMAT='MED',
          CONCEPT=_F(CARA_ELEM=cara,
          REPERE_LOCAL='OUI',
          MODELE=model,),);

de code-aster.org/V2/spip.php?article621 pour obtenir une visualisation des repères utilisateurs dans Salome.

Je découvre que l'utilisation de CONCEPT a disparu dans la version v14 de code aster si je compare u7.05.21 V13 et u7.05.21 V14.

Quelle est la méthode recommandé en 2020 obtenir ces informations, s'il vous plait ?

#19 Re: Code_Aster usage » Contraintes dans le repère matériau » 2020-04-06 16:47:37

Bonjour.

Je ne vais pas beaucoup t'aider car je n'ai pas de linux sous la main pour ouvrir tes fichiers mais es-tu sûr que les contraintes données ne sont pas dans le repère locale ?

J'imagine que t'as des éléments plaques DKT dont on renseigne les directions principales avec VECTEUR ou ANGLE_REPE dans un AFFE_CARA_ELEM genre:

CARA=AFFE_CARA_ELEM(MODELE=MO,
                    COQUE=(_F(GROUP_MA='voile',
                              EPAIS=0.2,
                              VECTEUR = (0,1,0),
                              INER_ROTA='OUI',),),
);

Ici la direction principale "X" de mes éléments coques correspond à la direction global Y ( car VECTEUR = (0,1,0),).

Extrait de U4.42.01 §8.3.4 wrote:

Les mots clés ANGL_REP ou VECTEUR permettent de renseigner le repère « utilisateur » en chaque élément de coque. C’est dans ce repère que sont exprimées par exemple les contraintes dans la coque ou les efforts généralisés [U2.01.05].

Et dixit §1.6.1.1 de U2.01.05, les contraintes en mode plaques sont exprimés dans le repère utilisateurs et :

U2.01.05 p 32/57 wrote:

Si l'on souhaite dépouiller ses résultats dans un autre repère que le repère utilisateur, il faut utiliser la commande MODI_REPERE .

smile

#20 Re: Salome-Meca usage » Problème de convergence"Traction Gousset-cornière" » 2019-09-11 04:24:22

jeanpierreaubry wrote:

dans le fichier message nous pouvons lire

Sur les 15350 mailles du maillage PlgCorBo, on a demandé l'affectation de 13212, on a pu en affecter 13212

il manque 2138 maille
un certain de nombre de surface n'ont sans doute pas été affecté au modèle

ensuite
un examen plus détaille du maillage du boulon montre des incohérences dans la définition des surfaces  bln_haut et bln_bas amenant à un maillage erroné
voir l'image attachée

quelque chose ne va pas dans les opérations booléennes

avec cela il y a beaucoup de raison simplistes pour que le calcul ne puisse aboutir

Je vois en effet, c'est comme si Gmsh avait maillé deux fois cette surface. Je vais essayer de faire un maillage plus propre. Je posterai les résultats de l'analyse ici. Vous utilisez quelles options de visualisation sous gmsh pour obtenir une telle vue ?

Je commence à être gêné de vous solliciter/embêter autant sur ceux ridicule problème.

en effet ça rique de couter quelques coups à boire lors d'une rencontre à venir !!!!!!!!!!!!!!!

Mais ce serait avec un immense plaisir, on pourrait discuter conception de voilier. Est-ce que vous accueillez des stagiaires à la Machine ?Je cherche un stage !

#21 Re: Salome-Meca usage » Problème de convergence"Traction Gousset-cornière" » 2019-09-10 07:33:54

Merci. Corrigé:
boulon

Mais toujours un problème de surblocage. Je commence à être gêné de vous solliciter/embêter autant sur ceux ridicule problème. big_smile

#22 Re: Salome-Meca usage » Problème de convergence"Traction Gousset-cornière" » 2019-09-10 06:07:34

Merci pour votre réponse monsieur Aubry, je pense qu'on va y arriver, à l'usure.

Pour l'intersection de mes deux GROUPE_MA, cela représente les surfaces de contact de ma plaque et de ma corniere vis-à-vis du fût du boulon qui traverse les deux. (Voir image ci-dessous) Est-ce gênant de faire du contact avec un GROUP_MA qui contient des mailles qui n'appartiennent pas toutes les deux au même corps ?groupe_ma

Qu'à cela ne tienne, j'ai transformé cette zone de contact en deux zones de contacts (une pour 'corTrou', une pour 'plqTrou'). J'ai quand même dû modifier mes les rôle maitre-esclaves quelques fois pour faire en sorte qu'il n'y ait pas des noeuds en commun dans plusieurs zones eslaves différentes. Ce que je ne comprends pas c'est que j'ai l'impression que le SANS_GROUP_NO ne fonctionne dans le concept "contact2" qui est commanté dans le .comm que je joins il ya

        _F(#3
            GROUP_MA_ESCL='blnFut',
            GROUP_MA_MAIT='plqTrou',
            ALGO_CONT='PENALISATION',
            ALGO_FROT='PENALISATION',
            SANS_GROUP_NO='noeu_bnl_fut_haut',
            COEF_PENA_CONT=40000,
            COEF_PENA_FROT=4000,
            COULOMB=0.1,),
        _F(#4
            GROUP_MA_ESCL='bln_haut',
            GROUP_MA_MAIT='corDessu',
            SANS_GROUP_NO='noeu_bnl_fut_haut',
            ALGO_CONT='PENALISATION',
            ALGO_FROT='PENALISATION',
            COEF_PENA_CONT=40000,
            COEF_PENA_FROT=4000,
            COULOMB=0.1,),

et j'obtiens:

   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   ! <S> Exception utilisateur levee mais pas interceptee.                            !
   ! Les bases sont fermees.                                                          !
   ! Type de l'exception : error                                                      !
   !                                                                                  !
   ! Les zones de contact numéro 3 et numéro 4 ont 40 noeuds communs à leurs surfaces !
   ! esclaves : c'est interdit.                                                       !
   ! Conseil :                                                                        !
   !  - changez vos surfaces de contact.                                              !
   !  - pour la méthode LAC, il faut désactiver le lissage                            !
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

alors que j'ai bien pris soins d'enever les 40 noeuds commun entre blFut et bln_haut en ayant crée le groupe _F(NOM='noeu_bnl_fut_haut',INTERSEC=('bln_haut','blnFut',),). Je ne comprends donc pas où est-ce que je me trompe.

Comme dis, j'ai inversé les roles maitre esclave jusqu'à ce que le calcul commence, malheureusement, j'ai encore un surblocage selon x (au niveau d'un noeud du boulon) que je ne comprends pas, et j'ai pourtant enfin mis mes 3 ressorts en des points différents comme vous pouvez le voir :
3_ressorts_lineaires

Qu'en pensez-vous ?

Merci pour votre aide.

#23 Re: Salome-Meca usage » Problème de convergence"Traction Gousset-cornière" » 2019-09-09 16:01:50

Merci pour votre réponse.

J'ai rajouté les ressorts linéaires comme vous me l'indiquez.

Malheureusement je ne comprends plus trop ce qui se passe avec mes surfaces de contact. J'ai le message

   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   ! <S> Exception utilisateur levee mais pas interceptee.                            !
   ! Les bases sont fermees.                                                          !
   ! Type de l'exception : error                                                      !
   !                                                                                  !
   ! Les zones de contact numéro 2 et numéro 3 ont 40 noeuds communs à leurs surfaces !
   ! esclaves : c'est interdit.                                                       !
   ! Conseil :                                                                        !
   !  - changez vos surfaces de contact.                                              !
   !  - pour la méthode LAC, il faut désactiver le lissage                            !
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

J'ai pourtant bien pris le soin de créer un GROUP_NO qui est la DIFFE des deux groupes esclaves de la zone 2 et 3, puis je l'ai précisé dans SANS_GROUP_NO, mais cela ne semble pas être pris en compte. En inversant le maitre et l'esclave, ça parvient à tourner, mais mon ressort se plaint de surblocage selon X.

Je suis un peu confu.

Je joins mon code. Merci pour votre aide.

#24 Re: Salome-Meca usage » Problème de convergence"Traction Gousset-cornière" » 2019-09-08 11:47:02

Bonjour monsieur Aubry.

J'ai essayé de modéliser ce problème de mon côté: j'ai un problème de matrice mal définie (un surblocage selon X d'un noeud du boulon visiblement) dès le 1er pas de temps et je ne comprends pas pourquoi.
J'ai mis des jeux entre chacune des pièce et j'ai retenue les pièces (corniere et boulon) qui "flottent" dans le vide avec des K_TR_D_L. Du coup je ne vois pas comment mon boulon peut avoir des problème de surblocage, vu qu'il n'est retenu qu'avec un ressort (noeud encastré hors du modèle  à noeud du boulon via SEG2  K_TR_D_L ) avec des raideurs de 10.

Pourriez-vous me dire ce qui cloche dans ma modélisation, s'il vous plait ?

Je vous joins le .geo, les .med, le .comm, le .astk et le .export dans l'esprit du style de travail que vous enseignez avec votre livre. (le meilleur style possible).

Aussi, quand j'ai créé avec GMSH le groupe volumique de ma cornière "corniere", j'ai créé un groupe surfacique "force" (face de la cornière sur laquelle j'applique FORCE_FACE). J'ai au début fait un AFFE_MODEL => 3D sur "corniere" (qui contient ma surface "force" du coup). Quand j'ai appliqué ma contrainte mécanique sur "force" j'ai été surpris que le code me dise que les mailles de mon groupe "force" ne faisaient pas partie de mon modèle. J'ai donc ajouté "force" à AFFE_MODEL 3D. Est-ce que ce comportement est normal ?Est-ce du au fait que GMSH met des TRIA3 en surface de chaque volume et du coup il faut préciser aussi que c'est TRIA3 font partie des mailles "3D" ? (J'espère que ma question n'est pas trop obscure...)

Merci d'avance.

#25 Re: Salome-Meca usage » Problème de convergence"Traction Gousset-cornière" » 2019-09-06 06:57:39

Je précise que je suis loin d'être expert. J'ai tenté:

contact=DEFI_CONTACT(
    MODELE=Modele,
    FORMULATION='CONTINUE',
    ALGO_RESO_GEOM='POINT_FIXE',
    REAC_GEOM='CONTROLE',
    NB_ITER_GEOM=10,
    ALGO_RESO_CONT='NEWTON',
    FROTTEMENT='SANS',
    ZONE=(
        _F(
            GROUP_MA_ESCL=('Cont_cor_plg', ),
            GROUP_MA_MAIT=('Cont_plg_cor', ),
            ALGO_CONT='PENALISATION',
            COEF_PENA_CONT=40000,
            RESOLUTION='OUI',),
        _F(
            GROUP_MA_ESCL=('Cont_cor_boul', ),
            GROUP_MA_MAIT=('Cont_boul_cor', ),
            ALGO_CONT='PENALISATION',
            COEF_PENA_CONT=40000,
            RESOLUTION='OUI',),
        _F(
            GROUP_MA_ESCL=('Cont_cor_ecr', ),
            GROUP_MA_MAIT=('Cont_ecr_cor', ),
            ALGO_CONT='PENALISATION',
            COEF_PENA_CONT=40000,
            RESOLUTION='OUI',),
        _F(
            GROUP_MA_ESCL=('Cont_plg_tet', ),
            GROUP_MA_MAIT=('Cont_tet_plg', ),
            ALGO_CONT='PENALISATION',
            COEF_PENA_CONT=40000,
            RESOLUTION='OUI',),
        _F(
            GROUP_MA_ESCL=('Cont_plg_boul', ),
            GROUP_MA_MAIT=('Cont_boul_plg', ),
            ALGO_CONT='PENALISATION',
            COEF_PENA_CONT=40000,
            RESOLUTION='OUI',),
    ),
);

Mais apparemment :

Les zones de contact numéro 1 et numéro 2 ont 50 noeuds communs à leurs surfaces esclaves : c'est interdit.
Conseil :
	- changez vos surfaces de contact.
	- pour la méthode LAC, il faut désactiver le lissage

Y aurait-t'il des nœuds communs entre 'Cont_cor_plg' et 'Cont_cor_boul' ? C'est curieux, vu que ce sont deux maillages différents. Ce sont logiquement des noeuds différents mais superposés non ?