Herezh++

je propose ce premier cas test à résoudre pour améliorer le contact.

Quelques mots pour résumer le cas test :
- calcul axisyémtrique
- "joint" rectangulaire (E=500, NU=0.45) comprimé dans un logement déformable (type acier E=190000,0.3)
- 2 types de maillages : triangle et quadrangle (linéaire pour les 2 cas)

L'archive jointe (test_contact_AXI_1.tar) contient :
- un fichier Readme qui contient mes notes sur ce cas test
- répertoire maillage_tri/ => maillage triangle (maillage aléatoire)
- répertoire maillage_quad/ => même calcul avec maillage quadrangle (maillage réglé)

à chaque fois, j'ai laissé mes résultats Gmsh. Il y a quelques imprim écran .png pour expliquer (voir Readme). Il y a également un fichier .log pour chaque calcul.

Le fichier Readme contient d'autres infos. Je mets ici quelques points pour préciser les choses et en discuter.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Concernant les paramètres de maillage, j'ai trouvé que :
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
FORCE_CONTACT_NOEUD_MAXI = 1.e+7 permettait de favoriser la convergence et
suffisamment grande pour couvrir nos genres de calcul.
dans la doc Herezh++, il est indiqué par défaut "nombre très grand" pour ce paramètre.
J'ai trouvé cette valeur quelque part dans le code source : double ConstMath::tresgrand = 1.E16;
Donc, ça fait une bonne différence.
Si c'est un bon choix, peut-être vaut-il mieux mettre cette constante :
double ConstMath::unpeugrand = 1.E7;

(ou bien pourquoi pas 1e+8)

- gros questionnement sur l'articulation de PENETRATION_BORNE_REGULARISATION, PENETRATION_CONTACT_MAXI et PENALISATION_PENETRATION.
(le tout dans un TYPE_PENALISATION_PENETRATION de type 4).
Le choix d'un type 4 semble être le seul qui permettent une évolution de la pénalisation au-delà de PENALISATION_PENETRATION. Mais même avec ça, il y a intérêt à ne pas se louper sur PENALISATION_PENETRATION. Donc déjà, il n'y a pas actuellement de méthode "universelle" permettant de prendre en compte tout type de matériaux en contact (et plus généralement, tout type de forces mises en jeu).
Le paramètre PENETRATION_BORNE_REGULARISATION semble être celui qui indique le plus clairement que l'on a pénétré la matière.
Le paramètre PENETRATION_CONTACT_MAXI est celui qui va accélérer la pénalisation si ça pénètre trop.
Pas évident de choisir. Parfois, en changeant d'une décade l'un ou l'autre, ça change complètement le résultat.

Dans mon cas test, je n'ai essayé qu'un jeu de matériau. J'ai volontairement choisi un fort confinement et un coef de Poisson élevé sur le joint. Je commence avec PENALISATION_PENETRATION = 1000. Est-ce que ce sera ok pour tout calcul ? il me faudra le déterminer plus tard en lançant plein de calculs avec matériaux différents (et aussi géométries différentes).

Pour l'instant, je préfère attendre la résolution des problèmes de perte de contact avant de voir ça. Parce que pour l'instant, changer ces paramètres ne permet que de retarder ou accélérer la divergence de mes calculs à cause de pb de détection du contact.

- je me suis dit que le paramètre para_contact--->DISTANCE_MAXI_AU_PT_PROJETE devrait toujours être supérieur au paramètre para_pilotage_equi_global--->NORME_MAXI_INCREMENT. Je ne sais pas si c'est vrai. Si oui, peut-être faut-il faire un lien dans Herezh++ pour modifier automatiquement DISTANCE_MAXI_AU_PT_PROJETE en fonction de NORME_MAXI_INCREMENT (et vice-versa) si l'utilisateur ne les impose pas explicitement tous les deux.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Concernant les bugs de contact :
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Les deux cas de maillage sont intéressants. D'une manière générale, dans les 2 maillages, les noeuds au coin en bas du joint perdent toujours le contact et cela très rapidement.

Ensuite, hors coin, j'ai trouvé un cas intéressant dans le maillage quadrangle. Il y a un noeud qui franchit un noeud maitre sans problème (contact toujours actif d'après NOEUD_PROJECTILE_EN_CONTACT) mais la pénalisation CONTACT_PENALISATION_N est nulle. Il se trouve que le calcul diverge à ce moment-là. Coïncidence ?

Pour le maillage triangle, c'est encore plus intéressant. J'ai trouvé une séquence identique pour 3 noeuds qui n'ont rien à voir (un sur paroi gauche, un sur paroi droite et un en bas). A chaque fois, c'est pareil :
- incrément i : noeud en contact avec un élement maitre
- incrément i+1 : noeud franchit un noeud maitre => le contact est correct d'après NOEUD_PROJECTILE_EN_CONTACT (et CONTACT_PENALISATION_N)
- incrément i+2 : perte totale du contact
quand on regarde la séquence pour chacun des noeuds sous Gmsh, on voit bien que c'est le même phénomène qui se répète.

J'espère d'ailleurs que c'est un peu lié au même phénomène que dans les coins (gestion du contact d'un noeud avec 2 éléments). En espérant qu'en résolvant le pb des coins, ça résout aussi le pb sur les bords.

oui c'est très clair, par exemple pour les éléments triangles il y a perte de contact dans les coins juste devant des noeuds maîtres qui sont reliés à plusieurs éléments (3 par exemples) ce qui pose pb.
En fait deux des éléments ont une frontière maître, le troisième au milieu n'en possède pas et pourtant c'est lui qui potentiellement récupère le noeud esclave.
Supposons que le noeud esclave est juste en face du noeud maître et qu'en fin d'itération il est à l'intérieur de l'élément du milieu... j'ai l'impression que c'est là le pb car la trajectoire du noeud ne passe pas par un élément de frontière.

Je vais un peu attendre pour réagir car je travaille actuellement à compléter la rédaction de la partie théorique du contact avec frottement. Comme c'est un peu compliqué je préfère finir. Normalement c'est bien avancé mais il me reste du travail sur les opérateurs tangents avec sans doute pas mal de répercussion sur l'implantation.

Donc affaire à suivre ! merci pour le test qui est probant.

La partie théorique est ok , elle sera sans doute complétée (modifiée?) lors de l'implantation du glissement.
Maintenant je m'occupe des zones de contact que j'ai qualifié "d'angles morts", ce qui devrait (à confirmer dans la validation) répondre aux pertes de contact lors du passage d'un élément à l'autre lorsqu'il y a un élément intercalé avec uniquement une frontière point en 2D et une frontière point ou ligne en 3D
Une première étape a consisté à définir une stratégie. A priori c'est ok
Cela va demander des ajouts importants :
. avec la création d'éléments frontières supplémentaires (a priori point et lignes) spécifiques qui ne doivent pas se superposer aux éléments actuelles)
. de compléter les algos actuels pour intégrer la présence et l'utilisation des ces frontières supplémentaires

Partie implantation:
- tout d'abord il faut générer des frontières points particulières :
d'où : création et génération de frontières points spécifiques là où elles sont nécessaires en 2D et 3D
: méthode spécifique dans LesContacts,
: c'est ok
- en 3D pour des éléments volumiques il faut également générer des frontières lignes spécifiques
: méthodes spécifiques dans Maillage, LesMaillages, LesContacts,
... en cours

Introduction d'un lissage des normales:
> fonctionne, mais ne répond pas au pb des angles sur le cas test axisymétrique. En fait le fait d'avoir un seul noeud dans les angles avec une géométrie esclave souple et grossière dans l'angle ne semble pas être un bon choix de discrétisation, en tout cas avec les choix que j'ai retenus.
Du coup, une première idée est de séparer le logement maître en 2 partie: les zones latérales qui correspondent aux parois internes d'un tube et le bas qui est modélisé par un plateau inférieur déformable.
Cela permet de gérer a priori correctement l'angle. Ainsi le noeud dans l'angle est en contact simultané avec les parois du tube et avec le fond bas.
L'algorithme qui séquence les phases de recherche de contact a été revu, modifié et adapté... comme il s'agit d'une recherche sans opérateur tangent, la mise au point a été laborieuse.
> mise en de la possibilité de cibler l'affichage d'information de contact sur un élément de contact particulier, un noeud esclave, une frontière d'élément fini etc. ce qui a permis de finaliser l'algo de gestion de recherche de contact ...
Donc au final, dans le cas du test axi cela permet d'aller au bout de la simulation, avec en moyenne 2 à 3 itérations pour la convergence en régime de croisière.

à suivre sur d'autre test et ensuite voir l'extension au 2D pur et 3D

(version 7.010)

Je réveille ce ticket.

Je suis en train de faire le point sur les possibilités de faire du calcul avec contact.
Donc reprise de ce cas test avec la version actuelle 7.034

j'ai commencé par :
- essai de la mise en données de ton dernier message => pénétration un peu partout
- reprise du cas test initial : modifié la pénétration maxi (passée à 1e-3 au lieu de 1e-4)
- testé avec divers paramètres de controle, para_contact et para_pilotage_equi_global => pas d'amélioration

Ensuite, je me suis aperçu que c'était beaucoup mieux en supprimant les paramètres "zone_contact". Seulement une pénétration au coin bas gauche (qui fait quand même planter le calcul au temps 0.7).

Et enfin, un peu au pif, j'ai testé les paramètres "para_calculs_geometriques" que tu avais mis dans ta mise en données.
Et là bingo : le paramètre POINT_INTERNE_PREC_THETAI_INTERNE (par défaut 1e-6) a une grande importance. A partir de 1e-4 ou plus, le calcul passe jusqu'à la fin avec un résultat très joli.

ci-joint un pdf qui illustre mes tests avec quelques visu et explications. Ainsi qu'une archive avec ma mise en données et le résultat Gmsh.

A se demander donc s'il ne vaudrait pas mieux mettre ce paramètre POINT_INTERNE_PREC_THETAI_INTERNE à 1e-4 par défaut dans Herezh. Mais je ne sais pas si ça serait cohérent avec d'autres cas et fonctionnalités Herezh.

Je vais quand même tester d'autres cas pour voir si ça se généralise ou si je suis tombé sur un cas particulier.

exemple qui montre que ça reste sensible.

Le calcul ne passe pas en passant la loi du joint de E=500 NU=0.45 à E=250 NU=0.4

MAT_joint_HYPO HYPO_ELAS3D
#conversion : E=250 NU=0.4
Kc= 1250 mu= 178.571428571429 type_derivee -1
fin_loi_HYPO_ELAS3D

Mais ça passe en mettant :
TYPE_DE_DECOLLEMENT 1 (au lieu de 0)

je joins juste le .info