Anomalie #192
pb loi ISOHYPERBULK3 dans le cas UMAT Abaqus-Herezh
Description
Gérard,
j'ai constaté une différence de résultat entre Herezh et Abaqus-Herezh sur le cas du calcul de joint torique complet (calcul de validation des travaux avec Benoit). La loi ISOHYPERBULK3 a l'air d'être la cause. Mais peut-être que c'est dans le cas précis de ISOHYPERBULK3+calcul axi.
Bref, difficile de savoir par où commencer. J'ai donc essayé des choses simples. En attendant d'étoffer, je préfère entamer la discussion au cas où tu aurais une idée... en espérant m'épargner des tests.
Pas évident de tout décrire ici mes débuts de recherche. J'ai créé une archive avec ce que j'ai commencé à tester. Tu peux commencer par le premier Readme pour prendre connaissance du contenu de l'archive. Ensuite, il y a 2 premiers répertoires de tests (chaque répertoire a son Readme).
Je recopie ici le contenu du premier Readme (mais il faut aller voir le détail des tests dans les autres Readme) :
---------------------------------------------------------------------------
Fichier : resu_Oring_HVH_axi.png
constatation du probleme :cas d un calcul axi de joint torique avec la loi HNBR complete
(hart-smith, maxwell, hysteresis en lois de melanges, dilatation thermique)Sur le graphe resu_Oring_HVH_axi.png, on compare Herezh versus Abaqus-Herezh
et on constate :
=> OK dans le cas d une partie spherique HYPO_ELAS3D
=> NON IDENTIQUE dans le cas d une partie spherique ISOHYPERBULK3Tests dans l ordre chronologique :
1compression_spherique/
cas d une UMAT Abaqus-Herezh appelee par un programme fortran
une compression spherique simple avec tous les ddl bloques par des conditions
=> voir Readme
- comparaison Herezh versus Abaqus-Herezh => OK2dilatation_thermique/
dilatation thermique pure, cas de Herezh seul pour l instant
=> voir Readme- signalement d une erreur dans les sorties de deformation
- questions sur le calcul de la dilatation thermique
---------------------------------------------------------------------------Fichiers
Mis à jour par Gérard Rio il y a presque 6 ans
oui, cela parait un peu étrange, je vais essayer de regarder cela rapidement ...
En tout cas, je pense que tes tests sont pertinents.
Mis à jour par Julien Troufflard il y a presque 6 ans
- Fichier dilatation_thermique.tar dilatation_thermique.tar ajouté
j'ai trouvé le pb je pense.
Les tests précédents ne sont plus utiles. Je te joins ici un test sur le principe d un fichier fortran qui simule une umat Abaqus-Herezh sur une seule itération.
J'ai fait un très long Readme pour comprendre et faire fonctionner le test. Je recopie ici la partie explication en gros du pb :
Dans le cas de la dilatation thermique pure, Abaqus calcule une partie thermique de la deformation
(eps_th). En l absence d autres conditions (ddl et chargements), il en deduit que la partie meca doit
etre egale a la partie thermique au signe pres (eps_meca = -eps_th). Il demarre donc a l equilibre. Comme
eps_meca sera negative, le materiau va reagir et renvoyer une contrainte negative. Contrainte negative
qui va conduire le cube a se dilater pour s equilibrer en l absence d autres chargements.si on prend un materiau HYPO_ELAS3D, on a un bon resultat car il depend de DSTRAN
(partie meca de la deformation). Dans le cas de cet exemple fortran, un bon resultat veut
dire que l UMAT renvoie une contrainte negative d environ -36 MPa.si on prend le materiau ISOHYPERBULK3, on obtient zero contrainte. a priori ISOHYPERBULK3
ne depend pas de DSTRAN pour calculer la variation de volume, donc sans doute il depend
de DFGRD0 et DFGRD1 (gradient de tranfo a t et t+dt). Or, DFGRD0 et DFGRD1 ne distingue pas
la partie meca de la partie thermique. C est un gradient de transfo total (cinematique ?)
Comme le cube demarre a l equilibre (eps_meca + eps_th = 0), on a DFGRD1 = DFGRD0, c est-a-dire
aucune prediction d evolution au global.Mis à jour par Gérard Rio il y a presque 6 ans
L'analyse est bonne, mais en fait dans Herezh, pour les potentiels hyperélastiques, je tiens bien compte de la variation de volume due à la dilatation.
Il faut que l'info relatifs à la variation de volume soit disponible dans la mise en données.
Donc, a priori on devrait avoir quelque chose de correct ...
Bon ... je vais regarder ton fichier
Mis à jour par Julien Troufflard il y a presque 6 ans
dans le .info d'UMAT, j'ai essayé d'ajouter un mot-clé du style :
""""
dilatation_thermique
E_tout 1
""""
mais ça ne change rien
Mis à jour par Gérard Rio il y a presque 6 ans
- % réalisé changé de 0 à 10
bon... avec la nouvelle version de l'osX mojave, le fortran couine, il faut donc que je réinstalle tous les ports de macport... ça va prendre un peu de temps !
à suivre !
Mis à jour par Gérard Rio il y a presque 6 ans
- % réalisé changé de 10 à 70
julien,
j'ai trouvé le bug, mais il y a aussi un pb dans ta mise en données:
- il faut indiquer à herezh la loi thermo qui permet de calculer la dilatation, comme pour un calcul normal (+ le fait d'utiliser la dilatation).
Je vais corriger le bug et se sera dispo dans la prochaine version 6.874
Mis à jour par Julien Troufflard il y a presque 6 ans
Je ne comprends pas pourquoi il faut indiquer une loi thermo dans le .info d'UMAT.
Le principe est que c'est Abaqus qui gère la dilatation thermique. ça pose un souci si il faut indiquer à Herezh une loi thermo dans le .info d'UMAT :
D'une part, cette loi thermo serait légèrement en désaccord avec Abaqus. Abaqus gère la dilatation en envoyant uniquement la partie méca de la déformation dans l'UMAT. Il retranche donc une partie thermique calculée en déformation logarithmique. Tandis que Herezh calcule une dilatation en déformation d'Almansi. En petite déf, on pourrait croire que c'est pas une grande différence. Mais dans le cas d'un gros module de compressibilité, ça va se voir.
D'autre part, il y a pas mal d'options dans Abaqus pour la dilatation thermique. ça va être compliqué et peu robuste de retranscrire ça en Herezh.
De plus, ça me mettrait en difficulté pour les travaux avec Benoit. Je leur ai créé un script qui prépare des fichiers d'UMAT automatiquement. Si en plus il faut gérer cette dilatation, bonjour l'usine.
Mis à jour par Gérard Rio il y a presque 6 ans
Ma réponse concernait le fonctionnement actuel d'Herezh pour lequel la variation de volume n'est pas calculée via le tenseur de déformation, mais directement via les coordonnées.
L'utilisation directe du fonctionnement actuel d'Herezh nécessite bien d'indiquer une loi thermo-physique qui contient un paramètre de dilatation.
Je vais donc corriger le bug pour que cela fonctionne en l'état.
Ensuite si on veut un processus particulier pour la connexion avec Abaqus pour la loi hyperbulk, il faudra que je réfléchisse a implanter une méthodologie particulière qui n'est pas immédiate.
Dans un premier temps, pour suppléer à la loi hyperbulk, dont l'objectif est de retraduire le comportement volumique, l'utilisation de la partie sphérique d'une loi hypoélastique thermo-dépendante est peut-être la bonne solution. J'ai l'impression que le résultat serait équivalent ?
Mis à jour par Julien Troufflard il y a presque 6 ans
ok, je me suis enflammé.
la méthode la plus simple serait de calculer la variation de volume en faisant l'exponentielle de la trace du tenseur de déformation méca (STRAN + DSTRAN). A faire uniquement dans le cas Umat que Herezh repèrerait grâce au fait d'utiliser un élément de type POINT CONSTANT...ou alors créer un nouveau mot-clé du style :
materiau_Umat
E_tout 1
Mis à jour par Gérard Rio il y a presque 6 ans
oui, on pourrait effectivement calculer la variation de volume de cette manière. Mais la difficulté n'est pas là en fait. Dans le cas des potentiels qui utilisent directement V, il me faut également la variation de V par rapport aux invariants de la déformation. Cette variation est différente suivant que l'on utilise la mesure d'Almansi ou la mesure logarithmique (cumulée ou non). J'ai fait des développements théoriques à ce niveau mais aucune implémentation pour l'instant. Il faut donc que je revois les implications d'un nouveau choix de calcul de V, en particulier pour le calcul de l'opérateur tangent, et ensuite que j'implémente cela d'où ma suggestion.
Mis à jour par Gérard Rio il y a presque 6 ans
- % réalisé changé de 70 à 90
Julien,
Le code a été pour prendre en compte la lecture de la dilatation attachée aux éléments via une loi de dilatation introduite dans Herezh. Cela a entraîné plusieurs modifications au niveau de l'algo qui prend en compte la connexion umat. Sur le test que tu as proposés, j'obtiens effectivement des contraintes non nulles:
SIG11 = -53.025070831056944
SIG22 = -53.025070831056944
SIG33 = -53.025070831056944
Le tenseur est sphérique ce qui est cohérent avec la dilatation thermique.
Il faudrait sans doute refaire des tests avec Abaqus pour être sûr que les modifications n'ont pas d'effet de bord... a priori non, mais ...
Je mets à jour dans la version: 6.874
Tiens moi au courant si pb