Anomalie #300
loi HYSTERESIS_BULK : comportement non attendu et non convergence
Description
Gérard,
voici le test pour la loi d'Emilie.
caractéristiques du calcul :
- calcul axi sur un joint charge/décharge
- loi Emilie page 105/106 modèle 1
il y a un fichier gnuplot (gnu) pour visualiser écrasement-contrainte. Selon le déplacement imposé utilisé (1.175mm ou 0.96mm), il faut changer la valeur de la variable U_max en début de fichier.
problème 1 :
le comportement obtenu ne ressemble pas tout à fait à celui montré dans la thèse page 106 figure 6.3 courbe bleu premier graphe (modèle 1). Comme dit cet après-midi, c'est peut-être à cause du chargement qui n'est pas le même (12% d'écrasement dans la thèse contre presque 15% dans l'exemple ici avec déplacement 1.175mm)
seule modif réalisé par rapport à la version d'Emilie : utilisation de la variable V_vol au lieu de x dans la définition un_argument= des fonctions nD dans fichier fct_nD_ponderation_CD.hz_courbe
problème 2 :
non convergence du calcul si on met le déplacement imposé égal à 0.96mm (pour se limiter à un écrasement de 12%).
L'erreur affichée est du type :
-----------------------------
Erreur1 au niveau du pilotage de Runge Kutta, le nouvelle increment qu'il faudrait utiliser = 4.5729981e-15 est plus petit que le minimum autorise: 5.7731597e-15
Algo_edp::Pilotage_kutta(..
estime_erreur= 0 mail: 1, ele= 16, pti=1 > probleme dans la resolution de l'equation constitutive avec Runge Kutta integration impossible, due aux precisions demandees, on doit augmenter ces precisions , (3) utilisation avec succes de la linearisation
----------------------------
il y a également ce warning :
-----------------------------
warning il semble que l'on ait une inversion sur liste secondaire puis coïncidence avec liste principale avec
Hysteresis_bulk::Gestion_pointeur_coïncidence(...
-----------------------------
et encore ce warning :
-----------------------------
** warning dans le calcul de la contrainte a t+dt, on trouve une valeur de pression P= (-16) > a la saturation = 16
->arbitrairement on limite a la saturation
----------------------------
et aussi :
-----------------------------
Erreur1 au niveau du pilotage de Runge Kutta, le nouvelle increment qu'il faudrait utiliser = 4.9004459e-15 est plus petit que le minimum autorise: 5.7731597e-15
-----------------------------
Fichiers
Mis à jour par Julien Troufflard il y a environ 3 ans
pour la loi Emilie p105/106, je parlais de son manuscrit de thèse bien évidemment
Mis à jour par Julien Troufflard il y a environ 3 ans
autre détail :
le calcul est composé de deux steps (avec un suite_point_info)
pour le second step, il y a cet affichage Herezh à chaque incrément :
======== fin module de visualisation par fichiers de points au format maple ================ fin du module de visualisation format Gmsh ========cet affichage n'apparait au step 1. Ce n'est pas gênant mais a priori cet affichage intempestif n'est pas normal.
Mis à jour par Julien Troufflard il y a environ 3 ans
Gérard,
j'ai essayé de réduire complètement les différences entre le calcul d'Emilie et le mien. J'ai repris son calcul, appliqué exactement l'historique de déformation de son joint (même pas de temps, application directe des déplacements qu'elle avait obtenu).
Et donc, si j'applique exactement le même trajet de déformation qu'Emilie, j'obtiens exactement le même comportement qu'elle. Le fonctionnement de la loi n'a donc pas bougé entre la version Emilie (v6.809) et la version que j'utilise (v6.990).
Informatiquement parlant, il n'y a finalement pas de problème. C'est la loi qui doit être très sensible mais ce n'est pas l'objet de ce ticket.
Il reste donc les divers bug et warning, à voir si c'est normal ou à solutionner.
Mis à jour par Gérard Rio il y a presque 3 ans
- Statut changé de Nouveau à En cours
- % réalisé changé de 0 à 20
Bonjour Julien,
concernant la sensibilité de la convergence :
- cela provient du calcul de l'hystérésis.
- en regardant les sorties de commentaire et les algo, j'ai l'impression que cela provient de certain tests qui sont trop draconiens. Mais compte tenu de l'imbrication de l'ensemble des calculs... ou plus simplement de la complexité de l'ensemble, ce n'est pas facile de fixer une stratégie d'où beaucoup de paramètres de réglage possibles que j'ai mis à disposition.
a) Dans le cas de l'utilisation de R-K la résolution s'effectue en explicite et l'algo contrôle la prévision d'erreur.
b) au départ
(cf. void Hysteresis3D::CalculContrainte_tdt(double & phi_2_dt,Tableau<double>& indicateurs_resolution),
...
case 5: case 6:// cas d'une résolution par intégration explicite par du kutta
...)
on commence par calculer la dérivée initiale, puis on appelle alg_edp.Pilotage_kutta qui appelle Runge_Kutta_step45 qui fait une prédiction explicite d'une valeur de contrainte à t+2./7.*delta t et ensuite appelle Hysteresis3D::Sigma_point qui a pour objectif de calculer la nouvelle dérivée au point prédit.
Or, avant de calculer la dérivée, Hysteresis3D::Sigma_point vérifie que la valeur de la nouvelle contrainte est bien inférieur à la limite de saturation. sinon -> erreur , et c'est cette vérif qui ne passe pas.
Lorsque l'on met un niveau de commentaire de 6, on voit que qu'il s'agit d'un pouillem ...
Mais on peut relâcher cette vérif:
cf. le code:
//modif : 1 juin 2014
// on vérifie que l'amplitude de la contrainte transmise, n'est pas supérieure à la saturation
// on fait la vérification sur le delta, car si on est sur une branche non initiale, on peut très bien
// dépasser le Qzero, localement, mais ce sera invalidé ensuite avec l'algo de coincidence
if ( QdeltaSigma > (Qzero*depassement_Q0*wBase))
{erreur = 1;
if (Permet_affichage() > 5)
cout << "\n QdeltaSigma =" << QdeltaSigma << " au lieu de "<< (Qzero*depassement_Q0*wBase)
<< " Hysteresis3D::Sigma_point " << endl ;
}
else // sinon on continue
{ erreur = 0;
On voit qu'il y a le paramètre : depassement_Q0 qui par défaut == 1
Donc j'ai fait un essai avec dans les paramètres de réglage:
depassement_Q0_ 1.0001
en me disant que c'était cohérent avec le calcul qui est effectué avec une erreur absolue de 1.e-4, cf. la mise en données:
cas_kutta_ 5 erreurAbsolue_ 1.e-4 erreurRelative_ 1.e-3#5
Dans ce cas, le calcul s'effectue (sur tes fichiers déposés) directement sans pb.
Donc j'ai l'impression que le paramètre depassement_Q0_ est intéressant à tester quand il y a un pb.
Il faut aussi augmenter le niveau de commentaire (en débug de préférance) pour essayer de comprendre ...
Enfin, le code est bien documenté au niveau des erreurs, ça peut-être utile de s'y référer.
Si tu peux essayer sur tes simul et me faire un retour, je suis preneur
Mis à jour par Gérard Rio il y a presque 3 ans
- % réalisé changé de 20 à 60
concernant l'affichage des infos, c'est cohérent avec ce que je voulais afficher, car le fait de continuer l'algo via suite info, correspond finalement à un nouveau calcul.
Cependant j'ai rajouté la possibilité de supprimer l'affichage via l'ajout aux paramètres spécifiques d'algorithme d'un niveau d'affichage de -1
Cela fonctionne également avec un paramètre > 0 mais dans ce cas il y a affichage du maxi de ddl pour l'itération (donc une info de plus)