Herezh++

ps : concernant ma dernière question, je pense que le problème de divergence avec alpha1=0.03 disparaitra avec le paramètre de régularisation. Si on augmente le pas de temps, le calcul passe. ça veut donc bien dire que c'est un problème de EPS trop petite pour calculer la phase.

1) dans le cas d une dependance a COURBE1D : est-ce que la dérivée est prise en compte dans l'opérateur tangent ?
oui, il suffit de regarder les sources (ex: ligne 2192 à 2215 : méthode Hyper3D::PoGrenobleAvecPhaseAvecVar IsoHyper3DOrgeas2::PoGrenoblePhase_et_var
(const Invariant2QepsCosphi& i_s,const Invariant & inv))

dans le cas courbe nD : veux-tu dire que la dérivée n'est pas prise en compte ?
oui

quelle que soit l'approche, si la variation n'est pas prise en compte, je serai obligé d'abandonner cette solution (le risque de divergence sera trop grand dans un modèle à N points d'intégration sollicités de manière diverses au cours de milliers d'itérations).

ah mon pauvre: qui ne risque rien n'a rien !

2) je crois qu'il faudrait (comme je te l'ai suggéré) essayer de regarder la convexité de la loi ou au moins en avoir une idée. Il y a une petite réflexion théorique à mener mais quelque soit la loi d'hyperélasticité, cela me paraît un passage obligé pour répondre aux questions unicité de solution.
Ce type de loi est très flexible mais la contrepartie est l'absence de convexité possible. Du coup on peut très bien avoir plusieurs solutions pour un état de chargement (ce qui est également possible physiquement) et la conduite de la convergence est alors délicate mais pas impossible: par exemple dans les algo de Newton en limitant l'incrément à chaque itération ...(cf. l'algo général en implicite).

Je vais regarder la fin dès que possible

quelle que soit l'approche, si la variation n'est pas prise en compte, je serai obligé d'abandonner cette solution (le risque de divergence sera trop grand dans un modèle à N points d'intégration sollicités de manière diverses au cours de milliers d'itérations).

ah mon pauvre: qui ne risque rien n'a rien !

pffff... c'est pas le propos d'être fringant ou pas. Le contexte est une loi qui va se faire embarquer dans une loi contrainte plane dans des calculs longs de relaxation dynamique. Si je propose une loi dont l'opérateur tangent est défaillant, c'est très mal parti. Le controle sur l'algo Newton contrainte plane est très limité, les calculs vont planter/stagner des fois oui des fois non, possiblement n'importe où dans le maillage (idéalement après une nuit de calcul). Cette loi combine la flexibilité aux diverses possibilités de trajet tout en étant compatible critère pli. Si elle est ok, je vais l'utiliser tout le temps et elle va se retrouver dans plein d'application (utilisateur aguerri ou calcul boite noire).

Je comprends bien les histoires de convexité, mais d'un certain côté, les paramètres que j'ai à rentrer sont ceux qui permettent de fitter une courbe. Et donc convexité ou pas, ce sont bien ces paramètres que je suis obligé de mettre. Le tout asservi par une relation linéaire dans la dépendance à Lode, ça me parait assez soft et le moins propice à surprises. D'ailleurs, j'avais abandonné cette solution quand j'avais testé l'autre version ISOHYPER3DORGEAS1. Pour le coup, même avec des tests simples, la convergence était difficile. Jamais avec cette version 2 + dépendance linéaire. Une fois le problème petite déformation réglé (régularisation), ça sera pas mal.

D'un autre côté, de mémoire, le coefficient alpha n'est pas le coef le plus critique. Je vais voir ce que ça donne pour l'instant en mettant un coef alpha constant.

vu.

Pour l'instant, je suis très embêté par la partie régularisation. Je contourne cette partie qui ne fonctionne pas encore par une loi des mélanges. ça fonctionne sur certains cas. Mais en fait, c'est très dépendant du pas de temps. Si le pas de temps initial du calcul est assez petit, j'ai des calculs très simples (traction uniaxiale, un seul élément) qui ne convergent pas en contrainte plane. Si je l'augmente, ça passe.

J'ai rien pour le confirmer mais je soupçonne un problème d'opérateur tangent au point de basculement entre une loi 1 sans phase à une loi 2 avec phase (la loi de mélange ne prend pas en compte la fonction de mélange dans le calcul des dérivées). C'est vraiment un point critique en contrainte plane.
Je vais essayer avec une transition smooth pour voir (fonction 1-cos)

La régularisation intervient dans hyper3D sur le calcul des invariants et est ainsi indépendante du potentiel. Donc à ce niveau, la réponse doit-être identique entre orgeas1 et orgeas2.
Par contre la forme de dépendance du potentiel à la phase est différente entre les deux lois.

D'une manière générale si on utilise une régularisation, normalement l'idée est de ne pas utiliser une transition entre deux lois (une sans phase au début et une avec phase après).
Et si on utilise une transition, il la régularisation est peut-être surabondant.

J'ai déjà eu le type de pb que tu observes.
- pour les potentiels (que j'appelle de Grenoble, car issu d'équipes de recherche de Grenoble) il y a souvent un risque pb lorsque l'intensité est très faible et que l'on utilise la phase.
- l'utilisation d'une loi des mélanges est une solution possible
- l'utilisation de la régularisation est une autre solution
Mais l'influence de la taille des premiers pas de charge à toujours une importance prédominante.
Dans mes calculs j'ai toujours réussi à trouver un pas ad hoc, mais souvent il m'a fallu tâtonner pour trouver un bon démarrage.
Ceci étant, j'ai souvent préféré utiliser orgeas1, pour lequel je pouvais facilement contrôler la convexité contrairement à orgeas2.
J'ai développé orgeas2 pour étendre les possibilités d'évolution de paramètres. Par contre comme dit précédemment on peut très bien obtenir alors des potentiels non convexes et donc dans ce cas plusieurs solutions possibles pour une même intensité de chargement.
Il faut alors piloter le passage de ces points à solution multiple ce qui rajoute en complexité.

NB: pour info il y a aussi un coeff défini en dur toujours dans Hyper3D, qui intervient dans les calculs initiaux:
double Hyper3D::limite_inf_bIIb = 36.e-10; // limite en dessous de laquelle on fait une ope spécial

Je l'ai figé, mais sans doute serait-il intéressant de le rendre modifiable car il est utilisé conjointement avec la régularisation (mais pas seulement).
1) Il faudrait rajouter un deuxième mot clé après la régularisation
2) supprimer le fait qu'actuellement il s'agit d'un paramètre static, et le définir comme une variable analogue à la régularisation

j'ai oublié une partie importante de mon message précédent :

pour revenir sur l'aspect que tu évoquais (paramètres qui permet de filtrer les petites valeurs : limite_inf_bIIb, etc...)

j'ai également vu ligne 44 du fichier Hyper3D.cc, la limite suivante :
double Hyper3D::limite_inf_Qeps = sqrt(2)*6.e-5 ;

utilisée notamment ligne 844 :
if ((inv_ret.Qeps >= limite_inf_Qeps)||(avec_regularisation))

mais on voit que toute utilisation de avec_regularisation_ dans le .info squizze ce test, quelque soit la valeur de fact_regularisation)

mais n'empêche, par défaut, la phase n'est pas calculée si Qeps est inférieur sqrt(2)*6.e-5, soit environ 8.5e-5

J'avoue que je suis un peu perdu sur tes demandes ?? qu'est-ce qu'il faudrait que je regarde concernant la régularisation ?
sinon concernant le cos3phi eps, normalement il est accessible au pti via les invariants de la loi hyperélastique ...mot clé "COS3PHI_EPS"

J'ai introduit les modifs suivantes:
- mise en place de la possibilité de définir les deux paramètres de limite inf:
limite_inf_Qeps et limite_inf_bIIb
cf. doc dans Herezh (il faut créer une nouvelle loi en interactif pour avoir la doc)
- sortie dans le .BI à l'incrément 0 de la valeur des paramètres :
régularisation limite_inf_Qeps et limite_inf_bIIb
ce qui permet de vérifier qu'ils ont la bonne valeur

ceci pour les lois: Favier, Orgeas 1 et 2, hyperbulkgene et 3D
- modif des I/O sur fichier .BI et .info

ça fonctionne et je m'aperçois que ton facteur de regularisation n'est pas bien placé dans le .info et donc il n'est pas pris en compte ce qui explique sans doute pourquoi il n'a aucune influence il faut mettre le facteur de regularisation juste avant le mot cle sortie_post_ éventuel donc cela fait dans ton exemple:

MAT_o1 LOI_CONTRAINTES_PLANES

NEWTON_LOCAL  avec_parametres_de_reglage_
        nb_iteration_maxi_  200
        nb_dichotomie_maxi_  10
        tolerance_residu_ 1.e-6
        tolerance_residu_rel_ 1.e-5
        mini_hsurh0_ 0.1
        maxi_hsurh0_ 10.
     fin_parametres_reglage_Algo_Newton_

1. 3K Qs mu1 mu2 mu3 alpha1 alpha2 Qe
   6000. 3.5 55. 1.5 0.1000000000E-05 0.03 0.3000000000E-01 999.0000000 \
   avec_phase
   nQs= -1. gammaQs= 0.142857142857143 \
   nMu1= -1. gammaMu1= -0.0909090909090909 \
   nMu2= -1. gammaMu2= 0.333333333333333 \
   avec_regularisation_ 1000000.

fin_loi_contrainte_plane

dit moi ce que cela donne avec cette mise en données

merci pour les 2 paramètres introduits.

Pour la régularisation, ça fonctionne maintenant pour la loi Orgéas 1.
Par contre, pas évident de savoir où mettre les continuations de lignes. L'écriture que tu as proposée ne fonctionne pas. (NB : je teste sur la version d'avant => 7.014)

C'est cette écriture qui fonctionne :

ISOHYPER3DORGEAS1
  # 3K    Qs    mu1    mu2    mu3                alpha1     alpha2             Qe
  6000.   3.5    55.     1.5     0.1000000000E-05   0.03       0.3000000000E-01   999.0000000  \
  avec_phase \
    nQs=  -1.  gammaQs= 0.142857142857143 \
    nMu1= -1.  gammaMu1= -0.0909090909090909 \
    nMu2= -1.  gammaMu2= 0.333333333333333
  avec_regularisation_  1.e-12

aucune écriture ne fonctionne sauf celle précédente

Bon c'est super pour Orgéas 1. Je vais pouvoir tester cette loi dans des cas plus complexes. ça fait déjà une solution dans le cas d'une dépendance cos3phi linéaire.

Concernant Orgéas 2, je n'ai trouvé aucune écriture qui fonctionne. Est-ce que tu pourrais me préciser à quel emplacement Herezh le cherche ? Et il reste ensuite à savoir où mettre des symboles continuation de ligne.

je ne vais pas reporter ici toutes mes tentatives. Selon les cas, j'ai soit une erreur à la lecture du .info, soit un calcul qui se lance mais qui peine à converger.

essai avec la version suivante qui fonctionne pour moi (avec la nouvelle version, mais normalement cela devrait marcher avec la tienne ?

MAT_o2 LOI_CONTRAINTES_PLANES

NEWTON_LOCAL  avec_parametres_de_reglage_
        nb_iteration_maxi_  200
        nb_dichotomie_maxi_  10
        tolerance_residu_ 1.e-6
        tolerance_residu_rel_ 1.e-5
        mini_hsurh0_ 0.1
        maxi_hsurh0_ 10.
     fin_parametres_reglage_Algo_Newton_

1. 3K Qs mu1 mu2 mu3 alpha1 alpha2 Qe
   6000. 4. 50. 2. 0.1000000000E-05 0.03 0.3000000000E-01 999.0000000 \
   avec_regularisation_ 1000000. \
   avec_phase

Q0s_phi= COURBEPOLYNOMIALE
                debut_coef= 0.875  0.125 fin_coef
    mu01_phi= COURBEPOLYNOMIALE
               debut_coef= 1.1  -0.1 fin_coef
    mu02_phi= COURBEPOLYNOMIALE
                debut_coef= 0.75  0.25 fin_coef \
    avec_regularisation_  1000000.

fin_parametres_avec_phase_

fin_loi_contrainte_plane

non, j'ai répondu un peu trop vite !
l'écriture qui me convient est la suivante, mais il faut la nouvelle version: 7.015
je vais la mettre sur le serveur.

MAT_o2 LOI_CONTRAINTES_PLANES

NEWTON_LOCAL  avec_parametres_de_reglage_
        nb_iteration_maxi_  200
        nb_dichotomie_maxi_  10
        tolerance_residu_ 1.e-6
        tolerance_residu_rel_ 1.e-5
        mini_hsurh0_ 0.1
        maxi_hsurh0_ 10.
     fin_parametres_reglage_Algo_Newton_

1. 3K Qs mu1 mu2 mu3 alpha1 alpha2 Qe
   6000. 4. 50. 2. 0.1000000000E-05 0.03 0.3000000000E-01 999.0000000 \
   avec_regularisation_ 1000000. \
   avec_phase

Q0s_phi= COURBEPOLYNOMIALE
                debut_coef= 0.875  0.125 fin_coef
    mu01_phi= COURBEPOLYNOMIALE
               debut_coef= 1.1  -0.1 fin_coef
    mu02_phi= COURBEPOLYNOMIALE
                debut_coef= 0.75  0.25 fin_coef 
  fin_parametres_avec_phase_
    avec_regularisation_  1000000.

fin_loi_contrainte_plane

ok, je vais regarder.

Il faut que je vois l'implication des 2 autres paramètres que tu as ajouté dans cette nouvelle version.

J'ai constaté quelque chose que j'espère résoudre avec ces 2 nouveaux paramètres.
Avec la version 7.014, quand on enlève la régularisation et que l'on met un pas de temps initial de 0.01 pour éviter les pb, on obtient le même comportement entre les deux lois o1 et o2.

Par contre, si j'enclenche la régularisation sur o1 et que je mets un facteur insignifiant (1e-12, 1e-20, ...), j'obtiens environ 1 MPa de moins qu'avec la loi sans régularisation.

" j'obtiens toujours un résultat inférieur de 1 MPa à ce que je dois obtenir, cf message précédent) "
- au début ou a la fin du calcul ?
- c'est peut-être du au déclenchement du calcul en différence fini qui n'est pas pareil avec ou sans régularisation : cf. le booleen "avec_regularisation" dans le fichier Hyper3D.cc

" Après test, il apparait que la loi MAT_o1 donne un résultat équivalent à MAT_o1_CS. Par conséquent, j'en conclus que si j'enclenche la régularisation sur MAT_o1, Herezh ne tient plus compte de la dépendance à la phase. Et si je supprime la dépendance à la phase sur MAT_o1, il tient compte de la dépendance à la phase "

là je ne comprends pas ?

" Par exemple, si je mets 1e-4, il ne converge pas "
oui, il faut par exemple une régularisation de 0.1 pour une convergence

En fait la régularisation est une technique qui est une alternative à la loi des mélanges. Avec les mélanges, on peut mieux gérer ce qui se passe pour une intensité du déviateur faible mais il faut plus cogiter sur la transition.
Ceci étant, je ne sais pas si la notion de phase est pertinente vis-à-vis de l'expérience pour les faibles valeurs de l'intensité du déviateur des déformations ?? et même si elle est pertinente est-ce c'est un pb de faire une approximation au démarrage du chargement...
Comme on est en hyperélasticité il n'y a pas de mémorisation, c'est simplement un trajet de chargement pour la loi qui ne suivra pas exactement le modèle théorique asymptotique à l'origine.
Par contre c'est mieux que la loi cp et cp2 soit suffisamment robuste.

" De plus, la loi MAT_o2 fait complètement bugger la lecture du .info à écriture égale avec le cas 3D CP. "
- que ce soit avec la loi 1 ou 2, je n'ai pas de pb de lecture ?? avec ton test
- que faut-il faire pour voir le pb de lecture ?

petit commentaire général avant de répondre à tes 4 points en gras :

L'idée générale de ce test est de comparer 2 lois qui sont sensées donner le même résultat. Compte-tenu de la forme des fonctions, la loi Orgéas 1 et Orgéas 2 proposées n'ont pas les mêmes paramètres dans le fichier loi. Mais un calcul rapide des coefs montrerait facilement qu'en fait ces 2 lois ont des coefs identiques pour un même angle de Lode.

ce n'est pas évident de reproduire les divers bugs que je constate. Il faut tester les lois pour s'en rendre compte en variant le pas de temps, la régularisation, en switchant entre loi o1 et o2. Et je ne trouve aucune robustesse dans ces calculs pourtant très simples.

les pb de convergence se passent à faible pas de temps, mais une infime variation peut générer une non convergence ou non. La loi Orgéas 2 semble la moins propice à convergence, avec pourtant une loi de dépendance linéaire tout comme la version Orgéas 1.

ça veut dire que quand on lance un calcul avec une des lois, on obtient un résultat. Ce résultat, on peut l'afficher en lançant le fichier gnu joint avec le répertoire de test (affichage EPS11-SIG11). Ensuite, on change la loi, on lance le calcul, on regarde le changement sur la courbe. Normalement, il ne devrait y avoir aucun changement puisque ces lois sont identiques dans leur dépendance à Lode. Or, je constate des différences.

Ensuite, concernant la convergence, il est étrange que ces 2 lois ne suivent pas la même convergence, puisque leurs lois de dépendance sont équivalentes et très simples (linéaires).

Concernant la régularisation, le rôle de ce paramètre est d'éviter les pb en petite déf et devrait à peu près ne concerner que le premier pas de temps. Il n'est pas question de mettre une valeur trop grande sinon on modifie complètement le résultat (cf le script perl qui montre l'influence sur l'angle Lode). Dans l'idée, je m'attends à mettre 1.e-12, voire 1.e-10. Si on met par exemple 0.1, le comportement n'a rien à voir avec la loi d'orgine.

De plus, dans mon esprit, cette valeur ne devrait pas influencer la convergence d'une loi. Et ce n'est d'ailleurs pas son rôle. Ce qui nuit à la convergence par exemple, ce serait un flip-flop autour d'un seuil (typique d'une loi de mélange par exemple ou autre discontinuité comme une conditionnelle d'un point de vue informatique). Mais dans le cas d'une régularisation, aucune surprise à ce sujet. Tout est régulier. Le cos3phi est borné, donc sans surprise lui aussi. Par exemple, une loi régularisée de Maheo ne pose aucun problème, que ce soit la loi Maheo hyper d'origine ou toutes les versions faites moi-même via une loi hyper_externe_W.

Je ne pense pas qu'il y ait un souci de non convexité ou autre. Il y a peu de variation sur les paramètres avec les dépendances que j'ai mis dans le fichier loi. J'ai voulu tester une loi très simple avec peu de différence entre les 2 extrémités du domaine cos3phi. N'importe quelle combinaison de ces paramètres donnerait une loi de comportement sans phase qui convergerait très bien sur tout type de sollicitation (sur un élément unitaire certes, mais sans souci néanmoins).

L'histoire de ce ticket est un peu la suivante : au début, je pensais juste à une demande d'ajout d'un nouveau paramètre (dépendance sur alpha1).
Ensuite j'ai peu à peu pris conscience des grandes difficultés de convergence de cette loi et du côté aléatoire de cette non convergence. Et je trouve ça surprenant.
Et enfin, mes tests d'aujourd'hui me montrent que parfois Herezh lit mal les paramètres d'entrée (pouvant même complètement zapper la dépendance à Lode).

réponses aux points dans des messages à suivre.

réponse au point 4) sur le bug de lecture sur MAT o2 :

ah oui tu as raison. Avec la nouvelle version 7.015, il n'y a plus ce bug de lecture avec les lois 3D normale (test_3D.info).

- concernant le calcul en différence finie, je pense qu'effectivement il y a un pb et je crois voir où il est, mais je vais revoir les formules théoriques pour être sûr de ce que je fais.
- concernant la régularisation, j'ai aussi une idée: je crois qu'il manque des termes dans les dérivées. En fait ce qui est écrit est une approximation que je croyais suffisante, mais... peut-être que l'approximation n'est pas suffisante. Il faut que je regarde d'abord au niveau théorique.
donc ... à suivre

super!

j'étais en train de errer sur le code source entre IsoHyper3DOrgeas2.cc et Hyper3D.cc
à suivre donc.

bon, en fait ce que je croyais être un pb avec la régularisation, c'était erroné.
Donc le pb à mon avis c'est que quand Qeps et trop petit on coupe les cheveux en quatre et la solution différence finie semble être la bonne solution.
Du coup, régularisation ou pas, je mets en oeuvre la diff finie pour Dabs(inv.bIIb) <= limite_inf_bIIb ceci dans le calcul des potentiels.
Par contre je laisse la possibilité d'utiliser la régularisation dans le calcul des invariants pour éviter les divisions par des nombres très petits pour des valeurs de Qeps très petit.
Bon... à tester
mais j'ai encore qq trucs à éclaircir
àsuivre

merci pour la modif sur différence fini. ça fonctionne très bien. Tous mes tests simples fonctionnent comme prévu et c'est robuste à la valeur ini du pas de temps.
c'est ce que je constate en l'absence de régularisation.

la régularisation reste problématique. J'ai testé avec 1.e-12 (en conjonction avec limite_inf_Qeps_ et limite_inf_bIIb_) :
- les calculs divergent avec Orgéas 2. Est-ce bien dans cette version 7.016 que tu as modifié de manière à ce que Herezh passe en différence fini à petite déf même en présence de la régularisation ?

- la loi Orgéas 1 continue à zapper la dépendance à Lode. Mon hypothèse est que le symbole continuation de ligne après les paramètres de base fait que Herezh cherche le mot-clé avec_regularisation_ et donc passe complètement au-dessus de la partie "avec_phase". Je dis ça parce que la doc indique que le mot-clé avec_regularisation_ doit être placé à la suite des autres paramètres (ce que je comprends comme : "à la suite des paramètres de base")

- j'ai d'autres pb de lecture du .info avec Herezh, mais ça reste accessoire à l'heure actuelle (j'arrive à passer outre). pas trop envie de passer du temps là-dessus actuellement

je suis en train de tester un calcul de Frank avec cette nouvelle version. Malheureusement, il y a un souci mais c'est un calcul plus complexe et long. Je ne peux pas le diffuser ici.
J'aimerais bien reproduire ce bug avec un cas plus simple. Je te tiens au courant (sans doute un autre ticket ou par mail)

non, ce n'est pas dans la version 7.016 que j'ai intégré la régul, ce sera j'espère dans la nouvelle version.

Sinon, concernant la lecture des paramètres, tu peux regarder dans le .BI en rechercher le nom de la loi (au début) on y trouve tous les paramètres lus, ce qui permet de vérifier les valeurs utilisées pendant le calcul.

a suivre

je viens de mettre à jour le dépôt git d'Herezh++ :
https://gitcdr.univ-ubs.fr/rio/Herezh_dev
tu peux regarder les modifs en:
1) en choisissant la branche 7.017
2) en cliquant sur sur le numéro de révision (à coté de "Gérard Rio")
il y a affichage de toutes les modifs avec 2 colonnes: à gauche la version originale, à droite la nouvelle version (sur le navigateur)
3) ensuite tu peux récupérer la nouvelle version avec git

remarque: j'ai utiliser la nouvelle version de codeblock via macport sur le mac et j'ai réussi à tout compiler et lancé l'exécution. Je mettrai les infos sur le roadmad dès que possible

J'ai testé la loi MAT_o2 :

1) avec les param suivants : limite_inf_Qeps_ 5.e-9 limite_inf_bIIb_ 5.e-9 avec_regularisation_ 1.e-12
=> convergence et résultats ok

2) et ensuite (pour désactiver la partie différence fini) avec les param : limite_inf_Qeps_ 1.e-30 limite_inf_bIIb_ 1.e-30
en conjonction avec : avec_regularisation_ 1.e-12, 1.e-10, 1.e-8, 1.e-6, 1.e-4 et 0.1
=> pas de convergence quelque soit la valeur de la régularisation

donc au final, actuellement c'est la méthode de différence finie qui permet la convergence.

Je continue sur le cas de calcul de Frank. J'espère mettre en place un cas plus léger aujourd'hui.

Peut-être hors sujet dans ce ticket, mais juste pour que tu commences à envisager le pb, voici le genre de message d'erreur que j'ai actuellement (contrainte plane et contrainte plane double) :

exemple 1 :

LoiContraintesPlanesDouble::Calcul_et_Limitation2_h_b(..
 **erreur: la deformation eps'_I  0.51387581) est superieur a 0.5, on ne peut pas s'en servir pour mettre a jour la variation de volume 
**>> non convergence sur l'algo de la resolution de (sigma.V_2=0, sigma.V_3=0),
 mail: 1, ele= 29, pti=1 , nb_incr_total=11, nb_iter_total=297, val obtenues:
 eps_P(2,2)= -1.0492879,  eps_P(3,3)= -0.82795204,  eps_P(1,2)= -0.89475882
 precedentes: 0, 0, 0

exemple 2 :

*** pb dans le calcul de la nouvelle epaisseur:  le coef de compressibilite moyen = 2.665736e+11 est par rapport a delta la trace de sigma = 4.3907193e+240 10 fois inferieur !! ce n'est pas normal a priori   on continue sans changer l'epaisseur  ... 
 QuadraMemb::CalEpaisseurMoyenne_et_vol_pti(...) 

J'ai mis à jour la doc pdf et aussi celle dans le code (cf. git) par contre ce ne sera disponible dans l'exécutable que dans les versions à venir.
Peux-tu regarder sur le pdf pour voir si c'est suffisamment explicatif ?

oui pour ma part

sur la forme, j'ai un léger doute sur l'utilisation de la tournure '+=' qui est un symbole informatique. Mais plus concrètement, Latex a toujours eu du mal à faire un symbole + de la bonne taille (souvent trop gros) et le fait d'insérer "+=" dans un environnement "math" via $+=$ provoque un espacement entre le + et le = qui gène la compréhension. En l'occurrence, j'ai eu un peu de mal à comprendre la formule :
<pre><code class="xml">
si V < c alors V+ = c
</code></pre>
au premier coup d'oeil, j'ai cru que le + était collé au V avant de comprendre qu'il s'agissait de l'opérateur +=

bref : je dis pas qu'il faut modifier et publier une nouvelle révision de la doc maintenant.
ça serait moi, je modifierais maintenant dans le latex par des tournures du style V = V + c, histoire que cette modif soit incluse dans une prochaine réactualisation officielle de la doc.

la mise en forme de mon message précédent a complètement vrillé.

je réécris mon message en réponse à ta phrase :
"""
J'ai mis à jour la doc pdf et aussi celle dans le code (cf. git) par contre ce ne sera disponible dans l'exécutable que dans les versions à venir.
Peux-tu regarder sur le pdf pour voir si c'est suffisamment explicatif ?
"""

sur la forme, j'ai un léger doute sur l'utilisation de la tournure '+=' qui est un symbole informatique. Mais plus concrètement, Latex a toujours eu du mal à faire un symbole + de la bonne taille (souvent trop gros) et le fait d'insérer "+=" dans un environnement "math" via $+=$ provoque un espacement entre le + et le = qui gène la compréhension. En l'occurrence, j'ai eu un peu de mal à comprendre la formule :

si V < c alors V+ = c

au premier coup d'oeil, j'ai cru que le + était collé au V avant de comprendre qu'il s'agissait de l'opérateur +=

bref : je dis pas qu'il faut modifier et publier une nouvelle révision de la doc maintenant.
ça serait moi, je modifierais maintenant dans le latex par des tournures du style V = V + c, histoire que cette modif soit incluse dans une prochaine réactualisation officielle de la doc.

la doc est modifiée

concernant la phase, tout est calculé dans Hyper3D (cf. Hyper3D.cc) à partir de la déformation et de la métrique.
en contrainte plane double, il faut regarder: LoiContraintesPlanesDouble.cc et LoiContraintesPlanesDouble_2.cc
en particulier:LoiContraintesPlanesDouble::Mat_tangente_constitutif et LoiContraintesPlanesDouble::Residu_constitutif ou LoiContraintesPlanesDouble::Residu_constitutif_3D( et LoiContraintesPlanesDouble::Mat_tangente_constitutif_3D
c'est là que l'on fait appel à la loi 3D avec constitution de la déformation 3D

Je pense qu'il y a une interaction entre les différents paramètres.
-étape 1) on a des composantes de la def qui sont très petits. Là il y a un test dans le calcul final de la contrainte cf. HyperD.cc ligne 854:

double norm_i_epsBH = epsBH.MaxiComposante(); // norme infinie de la déformation
       if ((norm_i_epsBH < ConstMath::petit)&&(!avec_regularisation))

si le maxi de la composante < 1.e-10 et sans régul : calcul sans phase

- étape 2) on dépasse ConstMath::petit, du coup on appelle le calcul :

Hyper3D::PotentielPhase_et_var(...

Mais dans ce calcul il y a le test:

if (Dabs(inv.bIIb) > limite_inf_bIIb)

Donc on peut imaginer: 2 sous étapes:

2.1 : Dabs(inv.bIIb) < ou = à limite_inf_bIIb : on fait de la différence finie :

2.2 : on est sup : on fait un calcul normal qui correspond peut-être dans ton cas à la première étape

Dans la partie 2.1: je ne calcule pas les dérivées suivant la phase, par contre j'utilise la phase pour le calcul du potentiel ce qui est peut-être problématique car sans régularisation, on peut avoir des angles de phase grands ou petit du à la division par 0, cf:

Hyper3D::Invariant0QepsCosphi Hyper3D::Invariant0Specif(const Invariant & inv)
inv_ret.Qeps = sqrt(2. * inv.bIIb);
double inv_ret_Qeps = inv_ret.Qeps; // init pour être éventuellement modifié
// ensuite avec la régularisation
if (avec_regularisation) {inv_ret_Qeps += fact_regularisation;}
double unsurQeps = 1./inv_ret_Qeps; // pour simplifier
// --- angle de phase
double unsurQeps3 = unsurQeps * unsurQeps * unsurQeps;
double troisracine6 = 3. * sqrt(6.);
inv_ret.cos3phi = troisracine6 * inv.bIIIb * unsurQeps3;
if (inv_ret.cos3phi > 1.) inv_ret.cos3phi=1.;
if (inv_ret.cos3phi < -1.) inv_ret.cos3phi=-1.;

du coup on est peut-être bloqué sur un cos3phi de 1 ou -1 tant que l'on est en diff finie

puis arrive la phase 2.2

- as-tu utiliser la régularisation ?
si ce n'est pas le cas, peux-tu essayer ce qui permettra de passer par un autre chemin dans l'étape 1 et 2.1

. je me demande s'il ne faudrait pas tout simplement calculer le potentiel sans phase en 2.1 ce qui me semble à la réflexion, plus cohérent compte tenu de la succesion de tests actuels ?
. ceci étant avant de changer j'aimerais avoir ton retour avec la régul et peut-être avec tes tests par mail

oups, attention, j'ai inversé les 2 derniers graphes

donc:
- a priori si on veut utiliser la régularisation, il faut choisir une très faible valeur 1.e-10 par exemple sinon on a quelque chose comme une inversion de phase à l'origine. Mais comme au tout début il n'y a pas de phase je trouve cela bizarre. a moins qu'il n'y a pas (ou pas visible) la phase 1) dont je parlais. Dans ce cas on est directement en diff fini et une trop grande valeur du facteur de régularisation peut introduire des choses vraiment pas normal au niveau du calcul de la phase.
tu pourrais mettre un niveau d'affichage à 8 pour la loi 3D pour voir (utiliser la version non fast): cf. void HyperD::Calcul_dsigma_deps (

- si on a de la regul, on a pas la phase 1) dont je parlais, on passe passe potentiellement directement en diff finie et là c'est limite_inf_bIIb qui décide finalement si on utilise la diff finie

- du coup compte tenu de tes remarques, je laisse en l'état avec diff finie utilisant le potentiel avec phase, mais pas de dérivées / à la phase:

J'aurai tendance à garder par défaut: une régul de 1.e-10, un limite_inf_bIIb de 1.e-4 qui est équivalent à un cisaillement de l'ordre de 1.e-2 MPa (ou encore 0.1 bar) ce qui est petit
et mettre le Q_eps lim en cohérence (ce serait en fait de l'ordre de sqrt(2.)*1.e-2: cf. sqrt(2*limite_inf_bIIb)
ce qui n'est pas vraiment ce qui est implanté !

,limite_inf_Qeps(sqrt(2)*6.e-5),limite_inf_bIIb(36.e-10), et pas de régul !

a voir ...