Projet

Général

Profil

Actions

Evolution #399

ouvert

Problème lors de l'utilisation de contrainte_mises en pondération

Ajouté par Victorien CLEMENT il y a 3 mois. Mis à jour il y a environ 11 heures.

Statut:
En cours
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
28/07/2026
Echéance:
% réalisé:

70%

Temps estimé:

Description

Bonjour,

Depuis les dertnières fois, j'ai pas mal fait évoluer la simulation en modifiant la façon dont on pondérait les différentes contributions. L'objectif est de n'avoir qu'un unique jeu paramètres matériaux et de pondérations pour modéliser deux essais distincts : un essai de compression libre (compression d'une bague entre deux plateaux sans aucune restriction radiale) et un essai de compression in-situ (compression d'une bague dans un montage complètement fermé imitant un presse étoupe de vanne).

Afin de réaliser cela, j'ai modifié la façon dont l'on abordait les pondérations :
  • Avant : pilotage utilisant V_vol pour les parties sphériques ET le déviatoriques
  • Maintenant : pilotage avec une valeur "sphérique" pour la partie sphérique et une valeur "déviatorique" pour la partie déviatorique. Pour cela j'ai utilisé ce qui était dispo dans la doc d'HEREZH soit spherique_eps et def_duale_mises . A partir de là j'ai obtenu des simulations prometteuses mais je suis encore en cours d'ajustements.

En voulant continuer mes tests j'ai voulu tester d'autres valeurs potentiels dans la doc d'HEREZH et je suis tombé sur sphérique_sig et contrainte_mises. Mon problème est que je n'arrive pas à utiliser contrainte_mises. Qui en soit fait parti dans la doc de la même sous-section que les autres valeurs cités "90.2 Pondération via une ou plusieurs fonctions de grandeurs locales type ddl étendus". J'ai introduit dans mon fichier de la façon suivante (comme les autres valeurs qui elles fonctionnent parfaitement) :

les_grandeur_ponderation= contrainte_mises AuPti_  fin_grandeur_ponderation_
    deb_fonct_ponder=   courbe_hyper_devia    fin_fonct_ponder_

Le calcul tourne jusqu'au bout mais à chaque incrément j'obtient :
LoiAdditiveEnSigma::CalculGrandeurTravail(.... 
 erreur, le type de proportion  contrainte_mises n'est pas disponible  pour l'instant au point d'integration !

J'ai joints à ce ticket mon dossier de travail actuel, voici le détail de son arborescence (sachant que le problème que je viens d'énnoncer à principalement été mis en avant dans le dossier 1_Libre ):
  • 0.1_Maillages : regroupe les différents maillages utilisés pour les deux essais
  • 0.2_Donnees : regroupe les courbes expérimentales
  • 0.3_Lois : regroupe le fichier contenant les pondérations communes
  • 1_Libre : modélisation de l'essai de compression libre
    • 2_Figures : les différentes figures tracées
    • Libre_hyper.info : fichier principal
    • Libre_hyper.CVisu : fichier CVisu correspondant
    • graphite.info : lois de comportement
    • gnu1 : fichier gnuplot pour tracer les figures
  • 2_Insitu : modélisation de l'essai de compression in-situ
    • 2_Figures : les différentes figures tracées
    • Essais_contact.info : fichier principal
    • Essais_contact.CVisu : fichier CVisu correspondant
    • graphite.info : lois de comportement
    • gnu1 : fichier gnuplot pour tracer les figures

Version d'HEREZH : HZpp-x86_64.AppImage / HZppfast-x86_64.AppImage - V 7.057


Fichiers

8_Article.zip (3,6 Mo) 8_Article.zip Victorien CLEMENT, 28/07/2026 11:29
Simu_contact_article.zip (34 Mo) Simu_contact_article.zip Victorien CLEMENT, 03/09/2026 18:54
Essais_simulations.zip (6,14 Mo) Essais_simulations.zip Victorien CLEMENT, 02/10/2026 13:52
step_72.png (17,4 ko) step_72.png Victorien CLEMENT, 02/10/2026 13:52
step_66.png (12,8 ko) step_66.png Victorien CLEMENT, 02/10/2026 13:52
step_63.png (11,7 ko) step_63.png Victorien CLEMENT, 02/10/2026 13:52
step_62.png (14 ko) step_62.png Victorien CLEMENT, 02/10/2026 13:52
12_Article_tests.zip (6,34 Mo) 12_Article_tests.zip Victorien CLEMENT, 20/10/2026 14:10
25_cont _radiale.png (59,7 ko) 25_cont _radiale.png Victorien CLEMENT, 20/10/2026 14:19
25_cont_radiale.png (59,7 ko) 25_cont_radiale.png Victorien CLEMENT, 20/10/2026 14:21

Mis à jour par Gérard Rio il y a 3 mois

  • Statut changé de Nouveau à En cours

Bonjour,
je vais regarder, mais il y a 2 pb:
- pour l'instant, les appimages ne fonctionnent plus, car j'ai intégré des nouvelles fonctions systèmes qui ne sont pas supportées avec ma version linux qui génère les appimage. Par contre c'est possible de recompiler les nouvelles sources via un make automatique. Tout est sur le gitea d'Herezh. (je pense remettre à jour les appimages mais ce sera après les vacances scolaires)
- actuellement je suis en vacances. Je réponds pour notifier que j'ai bien vu la demande. Par contre je ne serai réellement opérationnel qu'à partir du 24 aout (ou peut-être un peu avant)... d'ici là si je peux je regarderai mais je ne peux rien garantir...
Affaire à suivre ...

Mis à jour par Gérard Rio il y a environ 2 mois

  • Tracker changé de Anomalie à Evolution
  • % réalisé changé de 0 à 30

J'ai introduit la possibilité d'utiliser la contrainte de Mises dans la pondération de la loi additive ainsi que dans la loi des mélanges.
Il faut noter la particularité suivante:
- les invariants de contrainte sont calculés après la loi de comportement donc après l'utilisation de la pondération pour une loi avec pondération.
Du coup, à la première itération du premier incrément en implicite ou au premier incrément en explicite, les invariants sont nulles et il faut en tenir compte dans le type de fonction utilisée.
Ensuite pour les autres itérations et autres incréments c'est toujours les invariants du précédent calcul de contraintes, qui sont utilisés.
A priori, la conséquence est que cela peut entraîner des instabilités dans la convergence (ou des divergences), mais ce n'est pas forcément systématique, en particulier si les variations de la pondération sont faibles sur un incrément, l'impact sur la convergence peut être négligeable... bref il faut tester.
Sur le fichier transmis, ça fonctionne sans pb.
Je mets à jour les versions osX: version >= 7.064

Mis à jour par Gérard Rio il y a environ 2 mois

J'ai mis en place une version appimage avec vérification qui devrait fonctionner sur un linux récent.
Mais il faut essayer pour voir si c'est cohérent avec les lib linux installées par défaut sur ta machine.
Normalement cette version embarque toutes les bibliothèques spécifiques à Herezh, et est donc directement exécutable (comme les précédentes version appimage)

Mis à jour par Gérard Rio il y a environ 2 mois

  • % réalisé changé de 30 à 70

Il y a maintenant également une version fast 7.064, qui contient l'ajout et qui doit fonction sur linux.

Mis à jour par Victorien CLEMENT il y a environ 2 mois

Merci Gérard pour ces mises à jours, la 7.064 et la 7.065 tournent sans issus sur ma VM débian.
J'ai pu tester l'ajout de la contrainte_mises dans la pondération de la loi additive ainsi que dans la loi des mélanges avec succès.

Suite à ce ticket, et avant l'ajout des nouvelles versions, j'ai continué de mon côté à essayer de peaufiner mes simulations mais j'ai rencontré quelques soucis.

Pour contexte, essayer de simuler deux essais en parallèle s'est vu très complexe et très lent, du coup je me suis concentré sur l'essai in-situ (bague encastrée dans un montage). De plus, pour me rapprocher de l'expérimental, les dimensions du joints font que le joint n'est pas en contact avec la chemise ni la tige à t=0. Suite à de nombreuses tentatives, j'ai réussi à trouver un jeu de paramètres matériaux et pondérations qui me convient. A ce moment là, afin d'avoir des simulations plus rapides, je simulais avec 1 élément QUAD_AXI QUADRACOMPL pour la tige, 1 élément QUAD_AXI QUADRACOMPL pour le joint et 1 élément QUAD_AXI QUADRACOMPL pour la chemise. Ayant un jeu de paramètres matériaux me convenant, je me suis suis concentré sur le maillage afin de faire correspondre également les déformations de la chemise avec mes résultats expérimentaux. C'est à partir de ce moment où j'ai eu des soucis. J'ai commencé avec un joint en 4x4 éléments QUAD_AXI QUADRACOMPL, la traverse à 3x40 éléments QUAD_AXI QUADRACOMPL et la tige à 1 élément QUAD_AXI QUADRACOMPL sans succès, la simulation diverge autour des t=0.14-0.15 après le contact avec la chemise mais avant le contact avec la tige. Afin de réaliser des tests je suis revenu avec différents maillages et ai observé différents résultats :
  • tige 1x1 élément, chemise 1x1 élément, joint 1x1 élément : OK
  • tige 1x1 élément, chemise 1x1 élément, joint 1x2 éléments : OK
  • tige 1x1 élément, chemise 1x1 élément, joint 1x4 éléments : OK
  • tige 1x1 élément, chemise 1x1 élément, joint 2x1 éléments : OK
  • tige 1x1 élément, chemise 1x1 élément, joint 4x1 éléments : OK
  • tige 1x1 élément, chemise 1x1 élément, joint 2x2 éléments : avec les paramètres que les autres essais ça plante après le premier contact et avant le second. En passant la précission de 10-3 à 10-2 ça a fonctionné
  • tige 1x1 élément, chemise 1x1 élément, joint 4x4 éléments : avec les paramètres que les autres essais ça plante après le premier contact et avant le second. En passant la précission de 10-3 à 10-1 le calcul a fonctionné mais la simuilation n'a plus trop de sens (le joint se déforme bizarrement)
  • tige 1x1 élément, chemise 3x40 élément, joint 1x1 élément : OK (avec précision 10-3)
  • tige 1x1 élément, chemise 3x40 élément, joint 1x4 éléments : non
  • tige 1x1 élément, chemise 3x40 élément, joint 4x4 éléments : non

Sachant que pour les simulations qui fonctionnement, j'ai pu systématiquement observer des ralentissement entre le moment du contact du joint avec la chemise et le moment du contact du joint avec la tige. Pas au moment des contact mais plus entre les deux contact.

J'ai essayer de jouer sur différents paramètres du contact mais grand succès.

J'ai mis en pièce jointe 2 dossiers de travail :
  • 8_Article : avec chemise 1x1
  • 9_Article_dense : avec chemise 3x40

Mis à jour par Victorien CLEMENT il y a 18 jours

Bonjour Gérard,

Depuis mon commentaire précédent j'ai essayé de tester de nouvelles choses en utilisant la V 7.068 comme pas mal de ont évolué depuis la V 7.065 que j'utilisais.

Comme ce qui m'intéresse est d'augmenter la résolution du maillage du joint, les simulations que j'ai testé ce sont concentrés sur tige en 1x1 élément, chemise en 1x1 élément et joint en 1x1/1x4/4x1/4x4 élément(s) afin de multiplier plus rapidement les simulations avant de repasser avec la chemisse plus détaillée.
Pour rappel, afin de me racoler aec l'expérimental j'ai pris les dimpensions réelles d'un joint soit Di=30.12 / De=45.86 / h=7.97 dans un montage avec Di=30.00 / De=46.00 .

Du coup, lors de mon travail pour obtenir la loi de comportement actuelle, j'ai fait un sorte de prendre en compte quand est-ce que les contacts latéraux devaient se produire, surtout le second, comme dans l'expérimental. En général dans les simulations j'observe systématiquement le 1er contact latéral sans trop de soucis (au diamètre extérieur). par contre entre le 1er contact (au diamètre extérieur) et le second (au diamètre intérieur), dès que j'ai plus de 1 élément dans le joint j'ai un ralentissement très marqué dans les cas avec joint 1x4/4x1 mais une fois le second contact en place se stabilise un peu et avance mieux jusqu'à la décharge où là n'y a plus aucun soucis, et le cas avec le joint en 4x4 ou le calcul plante systématiquement entre les deux contacts. En regardant avec GMSH RESIDU_GLOBAL, avant le ralentissement/zone d'arrêt la visualisation est assez stable jusqu'au ralentissement où globalement les résidus partent dans tous les sens jusqu'à la décharge.

Une autre chose que j'ai réalisé est de regarder les commentaires des contacts pour voir si je pouvias extraire des données intéressant entre des calculs qui marche (joint 1x1/1x4/4x1) et celui qui ne marche pas (joint 4x4). Avec les paramètres que j'avais j'ai pu observé que dès le l'incrément 1 HEREZH me détectais le contact des 2 faces du joints alors que ces faces ne sont pas en contact au démarrage mais avec 0N de réaction. En jouant sur DISTANCE_MAXI_AU_PT_PROJETE j'ai réglé cela mais ça n'a rien changé au soucis d'au-dessus.

Enfin j'ai essayer de regarder l'influence du modèle sur tout ça en enlevant certaines contributions. En global, le modèle tourne tout le temps même avec le joint en 4x4 et la chemise détaillé (chemise_spe - 4x30 éléments avec maillage densifié à hauteur du joint) dès que l'on enlève l'hystéresis déviatorique (HYSTERESIS_3D).

Mis à jour par Gérard Rio il y a 16 jours

bonjour Victorien,
j'ai fait quelques essais:
- calcul avec une loi élastique essai1 :
- contact ok
- convergence ok

calcul avec la loi hyper avec un K 200 : essai2
- contact ok
- convergence ok

calcul avec: ISOHYPERBULK_GENE + ISOHYPER3DORGEAS1 sans pondération: essai3 -> OK
idem + HYSTERESIS_BULK -> OK
idem + HYSTERESIS_3D -> ok
donc la somme des lois sans pondération -> ok
reste donc à étudier le rôle des pondérations
à suivre ...

Mis à jour par Gérard Rio il y a 15 jours

Bonjour Victorien,
suite...

calcul avec une pondération constante:
. sur les parties sphérique : on garde la valeur initiale
. sur les déviatorique: proportion == 1
-> ok
idem en utilisant les fonctions de pondération proposées -> non convergence
On a:
- une partie hyperélastique sphérique pilotée par une fonction dépendant de Spherique_eps:
courbe_hyper_spher COURBEPOLYHERMITE_1_D
Debut_des_coordonnees_des_points
Coordonnee dim= 3 0.540 0.5600 0.000
Coordonnee dim= 3 -0.000 0.1200 -0.400
Fin_des_coordonnees_des_points
et une partie hyperbulk pilotée dépendant de Spherique_eps :
courbe_hyste_spher COURBEPOLYHERMITE_1_D
Debut_des_coordonnees_des_points
Coordonnee dim= 3 -0.540 0.4500 0.0000
Coordonnee dim= 3 -0.000 0.0100 -0.400
Fin_des_coordonnees_des_points

avec :
courbe_hyper_spher_2 COURBEPOLYHERMITE_1_D
Debut_des_coordonnees_des_points
Coordonnee dim= 3 -0.540 0.5600 0.000
Coordonnee dim= 3 -0.000 0.1200 0.
Fin_des_coordonnees_des_points
courbe_hyste_spher_2 COURBEPOLYHERMITE_1_D
Debut_des_coordonnees_des_points
Coordonnee dim= 3 -0.540 0.01 0.0000
Coordonnee dim= 3 -0.000 0.0100 -0.
Fin_des_coordonnees_des_points

et les autres courbes constantes (= 1.), --> ok
avec :
courbe_hyper_spher_2 COURBEPOLYHERMITE_1_D
Debut_des_coordonnees_des_points
Coordonnee dim= 3 -0.540 0.5600 0.000
Coordonnee dim= 3 -0.000 0.1200 -0.4
Fin_des_coordonnees_des_points

ça diverge !
avec courbe_hyper_spher == 1 (une constante)
et courbe_hyste_spher_2 COURBEPOLYHERMITE_1_D
Debut_des_coordonnees_des_points
Coordonnee dim= 3 -0.540 0.45 0.0000
Coordonnee dim= 3 -0.000 0.01 -0.4
Fin_des_coordonnees_des_points
--> ok  
idem pour hyste_sphérique et
avec courbe_hyper_spher 0.56
---> diverge
on reprend courbe_hyper_spher  1. (qui convergeait)
et on ajoute courbe_hyper_devia
--> converge mais un peu laborieusement à la fin
idem + courbe_hyste_devia
--> convergence sans pb
mon analyse: 
Les problèmes de convergence proviennent de l'équilibre entre les parties sphérique et déviatorique de la loi de comportement.
Finalement dans mon dernier test, j'utilise la loi initiale avec pour seule modif, la courbe de pilotage de la partie sphérique courbe_hyper_spher que je mets à 1. donc je lui donne une grosse importance comparée à la valeur proposée initialement:
Coordonnee dim= 3 -0.540 0.5600 0.000
Coordonnee dim= 3 -0.000 0.1200 -0.400
d'ailleurs si je mets une valeur constante 0.56 là ça converge alors qu'avec des valeurs constantes 1. pour les parties déviatoriques ça divergeait.
C'est donc l'équilibre entre sphérique et déviatorique qui a changé/
Et avec une valeur de 0.12 (contrairement à 0.56), là ça diverge: il n'y a plus assez de sphérique pour converger.

Donc le découpage en contributions élémentaires qui est proposé dans Herezh est intéressant et très pratique mais il y a des limites: il faut un minimun d'équilibre entre sphérique et déviatorique pour que l'équilibre mécanique puisse se faire.
Là on voit une manifestation numérique: non convergence, mais c'est bien possible que cela représente également une limite de la modélisation du comportement physique.
Peut-être que pour être plus précis, il faudrait étudier la loi seule de manière isolée avec des sollicitations du type :
- traction simple
- cisaillement simple
mais surtout:
- traction à plusieurs niveaux de confinement fixé (qui est représenté ici par la dépendance à Spherique_eps == l'intensité de la partie sphérique)
- idem pour le cisaillement
etc.
et dans chaque cas regarder l'évolution des contraintes et ou déformations, pour voir si ces évolutions paraissent logiques (intuitivement physiques ?)

NB: dans la loi, les fonctions d'intensité augmente avec la diminution de Spherique_eps. Si la résistance sphérique diminue, cela va accentuer la variation négative de Spherique_eps donc augmenter les fonction multiplicative du coup cela devrait contribuer à augmenter la résistance sphérique. On peut donc imaginer qu'un équilibre puisse se faire mais il y a beaucoup de chose qui varient en même temps ! d'où l'intérêt d'essayer de séparer et d'analyser l'influence des différentes contributions.

Mis à jour par Victorien CLEMENT il y a environ 11 heures

Bonjour Gérard,

Tout d'abord merci encore pour l'échange en visio de l'autre jour, ça m'a débloqué complètement et tout fonctionne. Le problème venait effectivement du manque d'équilibre entre les parties sphériques et déviatoriques.

En travaillant les données de sortie, je suis tombé sur un point qui m'intrigue. En voulant tracer la position en y des noeuds de la surface extérieur de ma bague en fonction de la force rapporté à ces noeuds (pos_y[de chaque noeud]=f(reaction_normale[à chaque noeud]) j'obtiens la figure suivante (figure n°25 dans le dossier 2_Figure du dossier que je partage). Les noeuds au milieu des faces des éléments quadratiques montrent une force drastiquement supérieure à celle des noeuds autour. La somme de toutes les forces à chaque noeud correspond bien à ce que je peux observer via le torseur de réaction mais l'allure de la courbe me semble illogique.

Actions

Formats disponibles : Atom PDF

Redmine Appliance - Powered by TurnKey Linux