Anomalie #114
Sortie pression_ext
Ajouté par Frank Petitjean il y a plus de 8 ans. Mis à jour il y a plus de 8 ans.
Description
Gérard,
Merci pour ta correction concernant le signe de PHYDRO. Il reste un problème mineure pour la sortie pression_ext que je n'avais pas détecté.
Lorsque l'on fait un calcul avec plusieurs incréments de charge. Les valeurs de pression correspondant à la sortie pression_ext sont identiques pour les 2 premiers incréments, elles augmentent ensuite normalement pour les incréments suivant mais il reste un décalage de 1 incrément. Pour autant la charge est correctement appliquée, ce n'est donc qu'un problème de post-traitement mais il est trompeur...
Fichiers
| phydro_avec_fonction - copie 3.zip (20,1 ko) phydro_avec_fonction - copie 3.zip | Gérard Rio, 11/07/2016 17:38 | ||
| phydro.CVisu (14,4 ko) phydro.CVisu | Frank Petitjean, 11/07/2016 17:54 |
Mis à jour par Gérard Rio il y a plus de 8 ans
Bonjour Frank,
je viens de regarder sur mon exemple test que je te transmets en attaché. Et on a bien une modification de la pression entre le premier et deuxième incrément ?
Peux-tu vérifier ?
Et si le pb persiste, peux-tu mettre ton cas sur le site pour que je regarde.
@bientôt
Mis à jour par Frank Petitjean il y a plus de 8 ans
- Fichier phydro.CVisu phydro.CVisu ajouté
Je n'ai pas été assez précis, c'est dans la sortie maple que le problème apparait.
J'ai ajouté cette sortie et le problème est bien présent.
Je t'envoie mon CVisu pour ton pb.
Mis à jour par Gérard Rio il y a plus de 8 ans
- Statut changé de En cours à Résolu
- % réalisé changé de 0 à 100
oui, je comprends mieux le problème.
En fait voilà ce qui se passe.
1) la pression est calculée au moment de la résolution, aux points d'intégration de surface sur lesquelles elle s'exerce. Donc, c'est une grandeur qui est accessible naturellement aux pti mais pas aux noeuds.
2) lorsque l'on crée le fichier .CVisu, si on demande uniquement des pressions aux noeuds on obtient 0 en sortie, c-a-d qu'il n'y a aucune valeur en sortie ... normal, car ce n'est pas une grandeur disponible aux noeuds.
3) lorsque l'on crée le fichier .CVisu et que l'on demande une sortie gmsh des pressions. Comme gmsh necessite d'avoir des valeurs aux noeuds, Herezh commence par extrapoler les grandeurs des pti aux noeuds avec par défaut une méthode de moyenne. Du coup la pression devient disponible aux noeuds, mais c'est une conséquence de la sortie gmsh. Comme l'appel de la sortie maple s'effectue avant la sortie gmsh, il se trouve que systématiquement, les grandeurs disponibles aux noeuds ont un incrément de retard par rapport à ceux de la sortie gmsh, car ce sont ceux calculées dans le cadre de la sortie gmsh à l'incrément précédent.
Voilà pour l'explication. Par contre je ne sais pas pourquoi on a bien la bonne première valeur à l'incrément 1 ?? on aurait du avoir 0, à voir quand j'aurai un moment.
Pour les préconisations:
- pour avoir les vrais valeurs de la pression, il faut utiliser les valeurs aux pti (valeurs aux éléments) pour lesquelles il n'y a pas de moyenne. Car si on passe par le .maple, c'est a priori plus intéressant d'avoir les vrais valeurs. Normalement, là on ne devrait pas avoir de décalage.
- effectivement actuellement on peut quand même disposer des valeurs aux noeuds mais avec un incrément de retard.
Bon... l'histoire n'est pas finie car je n'ai pas implanté le cas d'une sortie de pression aux pti !!! et il y a une raison, car les pti pour le calcul des efforts de surface .... ne sont pas les mêmes que ceux des pti de calcul de raideur interne. Du coup il n'y a pas de pression aux pti de raideur interne.
Bilan des courses:
- pour l'instant seules les sorties en gmsh sont dispo sans pb de décalage, mais avec la particularité d'un post-traitement de moyennage aux noeuds.
Remarques:
- il est sans doute possible de mettre en place une stratégie pour sortie les bons incréments aux noeuds. Pour l'instant je laisse ce point en suspend.
- il faudrait que je fasse une sortie des efforts aux pti d'application des efforts... actuellement ce n'est pas dispo. A voir si c'est vraiment nécessaire ...
Mis à jour par Frank Petitjean il y a plus de 8 ans
Merci Gérard pour ces précisions très détaillées.
La pression étant appliquée par éléments je comprends que cela concerne les pti, mais pour la résolution du problème d'équilibre, cette pression pas éléments doit bien être, tout d'abord, répartie aux nœuds de chaque élément puis assemblée pour former le vecteur des forces extérieures appliquées au ddl non ? En implicite c'est en tout cas comme cela que ça se passe me semble t-il.
Mis à jour par Gérard Rio il y a plus de 8 ans
Frank,
"La pression étant appliquée par éléments" > par face d'élément> les pti des faces d'élément qui sont donc en général différent de ceux de l'élément
"je comprends que cela concerne les pti,"
" mais pour la résolution du problème d'équilibre, cette pression pas éléments doit bien être, tout d'abord, répartie aux nœuds de chaque élément"
-> pas exactement, en faite on calcule la puissance virtuelle des efforts extérieurs c-a-d : intégrale (pression * normale * vitesse_virtuelle) sur la surface
et c'est le résultat de cette intégrale qui constitue la résultante en chaque noeud. Car on choisit une vitesse virtuelle qui est égale à 1 pour une composante donnée et 0 pour toutes les autres composantes. Du coup, l'intégrale va concerner l'ensemble des faces qui contiennent le noeud concerné et la pression utilisée est exactement celle déterminée à chaque pti de face.
"puis assemblée pour former le vecteur des forces extérieures appliquées au ddl non ? En implicite c'est en tout cas comme cela que ça se passe me semble t-il."
-> ceci est vrai quelque soit l'algorithme. C'est le résultat de la formulation variationnelle du problème d'équilibre.Pour plus d'info, tu peux te référer au document EF0.pdf qui présente la méthode et qui contient les éléments théoriques correspondant exactement à ce qui est implanté dans Herezh.
@bientôt