Anomalie #100
Pb sortie maple / pb numéros incréments avec _suite_point_info_ / pb dilatation thermique avec version 6.752
Description
Dans cette demande, j'ai constaté 3 pb :
1) problème de sorties .maple pour les torseurs de réaction
2) erreur dans les numéros d'incréments à cause de l'utilisation de suite_point_info
3) problème avec dilatation thermique suite à introduction de la thermique dans la version 6.752
**remarque : pour le problème 1) et 2), j'ai utilisé la version 6.749 pour éviter le problème 3).
Je fais un calcul avec contact : écrasement d'un cylindre entre 2 plateaux
**remarque : le 3ème plateau de nom plateau_fond.her ne sert à rien dans cet exemple mais est présent dans le calcul. Le contact avec le plateau plateau_fond.her est remplacé par un blocage Z du cylindre.
C'est un calcul pas si compliqué que ça mais qui utilise simultanément plusieurs aspects : contact type 4, plusieurs maillages, suite_point_info, dilatation thermique.
---------------------------------------
Problème maple (version 6.749)
---------------------------------------
J'obtiens des réactions nulles sur le plateau du bas (tous ddl bloqués) et le plateau du haut (déplacement imposé suivant -y et x et z bloqués)
Je pense que le problème vient de l'utilisation de plusieurs maillages, car les réactions pour le maillage 1 (le cylindre) ne sont pas nulles. Par contre, celles-ci sont étranges (parfois nulles, parfois non nulles), à mon avis le contact type 4 et/ou suite_point_info sont en cause.
ci-joint une archive .tar contenant le calcul et un fichier gnuplot pour visualiser les réactions
---------------------------------------
Problème Gmsh (version 6.749)
---------------------------------------
l'utilisation de suite_point_info crée un décalage dans les numéros d'incréments, ce que Gmsh n'apprécie pas. Cet exemple prétend converger en 45 incréments alors qu'en réalité, il en a fait 47 (chaque nouveau suite_point_info redémarre avec le numéro d'incrément précédent)
---------------------------------------
Dilatation thermique (version 6.752)
---------------------------------------
J'ai un très grand nombre d'affichages concernant la thermique (s'affiche a priori pour chaque point d'intégration à chaque itération).
""""""
debug Deformation::DeformationThermoMecanique(
etc...
""""""
Fichiers
Mis à jour par Gérard Rio il y a plus de 8 ans
- Statut changé de Nouveau à En cours
- % réalisé changé de 0 à 30
- Temps estimé mis à 10.00 h
---------------------
1) correction de l'affichage "debug Deformation::DeformationThermoMecanique("
c'était un message de mise au point que j'ai oublié ... pour l'implantation de la thermique
2) au début du calcul, il n'y a pas de convergence car le type de critère par défaut n'est pas
adapté au calcul. Par défaut il s'agit d'un critère qui s'appuit sur un équilibre relatif.
Or les efforts internes et externes sont très faible (e-8), donc il vaut mieux utiliser
par exemple la norme:
NORME min(Res,Res/Reaction)
Dans ce cas un premier calcul sera ok (ce qui correspond finalement à la réponse linaire
tangente).
3) si l'on veut s'arrêter avant le suite info normalement on met
-fin_point_info_
or Herezh n'en tient pas compte !! -> correction : maintenant il en tient compte !!
donc le simple fait de mettre
-fin_point_info_
dans le fichier d'entrée fait que le reste du fichier .info n'est pas lu ... c'est quand même
mieux
4) Dans le cas d'un seul calcul:
-> on s'apperçoit qu'il n'y a pas de sortie de réaction également.
Explication: les réactions aux noeuds proviennent actuellement du calcul du second
membre qui cumule les puissances internes virtuelles ou dit d'une autre manière équivalente
les forces généralisées internes et les forces généralisées externes.
Pour un noeud sans ddl bloqué, l'ensemble des forces = 0. Pour un noeud avec un ddl cinématique
bloqué, on connait toutes les forces internes et externes sauf celle correspondant au ddl bloqué
c-a-d la réaction.
Comme la somme doit-être nulle, on en déduit que la réaction = - les forces connues, calculées
à la fin du déplacement.
Voilà pour la théorie.
Dans le cas du contact déformable-déformable. Si on repère le groupe de noeuds en contact
le torseur correspondant à ces noeuds est non nul et correspond au torseur de réaction.
Si on fait une sortie mapple de ces noeuds, actuellement Herezh couine car la référence correspondante
aux noeuds en contact n'est pas référencé comme un groupe de noeud ayant des ddl bloqués.
Donc ce n'est pas la bonne méthode (actuellement) pour sortir la réaction.
NB: j'ai un peu amélioré le message du couinage pour qu'il soit plus explicite.
a) première méthode permettant de récupérer les forces de contact après la fin du calcul
si en fin de .info on indique:
resultats #pas_de_sortie_finale_
COPIE 0
fin_point_info
c-a-d que l'on commente le "pas_de_sortie_finale_"
on obtient en sortie un fichier .cont qui contient pour chaque élément de contact:
- la force de contact au noeud projectile
- les forces de réaction réparties sur les noeuds de la facette
NB: cette méthode marche pour du bi-déformable comme pour du déformable-rigide
Bon... j'ai fait des modifs pour que cela fonctionne correctement car il y avait des pb
il faut donc considérer la version >= 6.753
à suivre ...