Anomalie #333
problème décalage des sorties ddl étendu dans .maple
Description
Gérard,
encore un souci sur un calcul de bulge. Désolé pour toutes ces sollicitations.
cette fois, il s'agit d'un décalage dans les sorties de type ddl étendu aux noeuds (SIG11, ....). J'ai besoin de ces valeurs pour calculer un angle de Lode.
Les valeurs sont correctes et cohérentes avec ce qui est obtenu dans les fichiers Gmsh. Mais par contre, il y a un décalage de 1 incrément dans le .maple
La donnée à l'incrément 1 est bonne (par comparaison avec Gmsh). Mais la donnée à l'incrément 2 est la même qu'à l'incrément 1. Et ensuite, ce décalage perdure.
J'ai bien détaillé dans le Readme.
Fichiers
Mis à jour par Gérard Rio il y a presque 2 ans
- Statut changé de Nouveau à En cours
- % réalisé changé de 0 à 30
oui, je crois que c'est "normal" vu l'implantation, mais pas forcément ce que l'on cherche !
- les contraintes sont calculées aux pti, et la valeur en sortie suit le calcul qui vient juste d'être effectué
- ensuite les contraintes sont extrapolées aux noeuds pour la sortie en .pos, elles sont alors disponibles pour la sortie en maple.
Le pb est que l'ordre de sortie des infos est: .maple puis .pos
Donc à chaque fois que l'on veut des grandeurs extrapolées aux noeuds, c'est toujours les grandeurs de l'incrément précédent que l'on a au .maple
De mémoire (à confirmer) je suis obligé d'utiliser cet ordre de sortie. Je crois qu'il y a des éléments qui sont calculés pour la sortie maple et qui ensuite sont utilisés pour la sortie .pos
Je crois que j'avais documenté cela dans la doc et qu'il y a déjà un ticket sur le sujet... (à vérifier)
Mis à jour par Julien Troufflard il y a presque 2 ans
Juste pour vérifier, j'ai regardé ce que donnerait un ddl étendu obtenu via une statistique (statistique_sur_RefNoeuds_). J'ai demandé la contrainte Sigma_principaleI sur le noeud 1 et ai sorti cette valeur dans le .maple. On obtient le même décalage que précédemment. Cette fois, c'est normal puisque la logique de cette grandeur est d'être utilisée comme étant un résultat de l'incrément précédent.
En fait, sur cette logique de décalage, en toute rigueur, le cas de la sortie classique sur .maple d'un ddl étendu devrait donner une valeur nulle au premier incrément (valeur initiale à t=0). C'est bien le cas avec statistique_sur_RefNoeuds_. Je me demande bien par quel hasard des tuyaux le ddl étendu "classique" à l'incrément 1 se retrouve avec la valeur de l'incrément 1 (pas de décalage), puis l'incrément 2 se voit passer la valeur de l'incrément 1, etc...
par exemple, on se retrouve avec cette série de valeur par exemple pour Sigma_principaleI au noeud 1 :
temps Gmsh.pos .maple(ddl étendu) .maple(statistique)
1.000000000000e-03 2.05928128405 2.059281284052e+00 0
2.500000000000e-03 3.83818816073 2.059281284052e+00 2.059281284052e+00
4.000000000000e-03 5.30374179826 3.838188160731e+00 3.838188160731e+00
5.500000000000e-03 6.62310896137 5.303741798263e+00 5.303741798263e+00
j'ai mis entre "**" la valeur qui pose question d'un point de vue informatique. La colonne Gmsh est le bon résultat (le vrai résultat de fin d'incrément). La colonne statistique est décalée mais c'est logique et démarre bien à 0 (le vrai résultat de début d'incrément).
La sortie .maple classique d'un ddl étendu est vraiment piégeuse. Jamais l'utilisateur s'attendra à ce décalage. Je ne sais pas si tu prévois de modifier cet aspect. Il faudrait placer la remontée aux noeuds avant les appels de sortie et ne la déclencher que si cela est demandée par un .CVisu Gmsh et/ou .maple.
A voir si tu souhaites dépenser du temps sur cette partie. De mon côté, je vais faire un script qui exploite les fichiers Gmsh pour générer cette sortie sous forme .maple. Si un jour le script devient correct pour être utilisé par un autre utilisateur, je le mettrai sur redmine.
Mis à jour par Julien Troufflard il y a presque 2 ans
bon, je me suis lancé dans un script pour sortir les données aux noeuds en exploitant les fichiers Gmsh.
Je l'ai mis sur redmine https://herezh.irdl.fr/documents/49
a priori, ça fonctionne bien sur ce que j'ai testé.
Je me suis dit au final que ça pouvait être utile. Le principe est de sortir les fichiers Gmsh comme d'habitude (ça permet de visualiser les résultats). Et puis ensuite, on peut passer par le script pour exploiter les fichiers .pos pour post-traiter sur une liste de ref, un noeud, etc... On ne pense pas toujours à tout au niveau des sorties maple. Et souvent, toutes les infos sont déjà dispo dans les fichiers Gmsh. ça évite une redondance des sorties Herezh Gmsh/maple et ça évite aussi de devoir relancer un calcul juste pour pouvoir tracer une courbe.