Projet

Général

Profil

Actions

Evolution #395

ouvert

sorties différenciées via des références

Ajouté par Gérard Rio il y a 28 jours. Mis à jour il y a 23 jours.

Statut:
En cours
Priorité:
Normal
Assigné à:
Version cible:
Début:
09/01/2026
Echéance:
01/01/2050 (Échéance dans plus de 23 ans)
% réalisé:

10%

Temps estimé:
Temps passé:

Description

L'idée est de permettre à l'utilisateur de faire une sortie en post-traitement, suivant une différenciation via une référence.
Exemples d'application:
- soit un calcul qui utilise un maillage constitué d'éléments membranes et d'éléments poutre, on veut les contraintes (ou autres grandeurs) qui existent dans les membranes uniquement d'une part, et/ou d'autre part les contraintes qui existent dans les éléments poutres
- soit un maillage qui contient des éléments volumiques qui constituent la raideur de la structure, et des éléments membrane, qui constituent les frontières sur lesquelles sont appliquées les charges externes. Les éléments membranes ont une loi rien, ils n'interviennent pas dans le calcul de la raideur.
En sortie on veut les contraintes (ou autres grandeurs) qui sont associés avec les éléments volumiques uniquement, et/ou on veut les forces externes qui sont associées uniquement avec les éléments membranes.

Mis à jour par Gérard Rio il y a 28 jours

  • Statut changé de Nouveau à En cours
  • Version cible mis à Herezh++2050

Mis à jour par Gérard Rio il y a 27 jours

Question: passage éventuel au nouveau format 4.1 de gmsh:
Après lecture et petite compréhension (difficile) du nouveau format, il semble :
- le format 2.2 est suffisant, le format 4.1 n'apporte pas de nouveautés utilisables (a priori) par Herezh (pour l'instant)
- plusieurs personnes qui utilisent gmsh en post traitement préconisent de garder le format 2.2, plus simple
- gmsh ne prévoit pas de supprimer le format 2.2
- je trouve très peu d'exemples d'utilisation du format 4.1
- le format 4.1 ne semble pas complètement stabilisé

Conclusion: pour l'instant je continue d'utiliser le format 2.2

Réflexion:
Dans les sorties Herezh pour gid et pour gmsh, il y a dans un premier temps, une décomposition de l'ensemble des éléments en sous-maillages: chaque sous-maillage étant relatif à une seule sorte d'éléments.
Du coup, une idée serait d'utiliser cette décomposition et de sortir un fichier .pos par sous-maillage.
Par contre dans tous les cas, il faut changer le stockage des informations aux noeuds.
Actuellement:
- si par exemple on veut extrapoler une contrainte ex: SIG11, on crée un conteneur au noeud pour stocker SIG11, ce qui permet de faire des moyennes et d'avoir les infos pour la sortie.
Dans le cas de sous-maillage, il faut différencier SIG11 pour chaque sous-maillage.

Mis à jour par Gérard Rio il y a 24 jours

  • % réalisé changé de 0 à 10

j'ai fait des tests sur gmsh pour répondre aux questions:
- est-ce que c'est possible d'avoir une liste de noeuds qui comprend des noeuds qui ne sont pas reliés avec un élément : réponse après test: oui c'est possible
- est-ce qu'on peut avoir une liste de tous les noeuds, suivi d'une liste d'éléments restreinte (qui ne concerne qu'une partie de la liste initiale de noeuds) puis les infos à chaque incrément, pour uniquement les noeuds qui concernent la liste restreinte de noeuds: réponse : oui c'est possible

Du coup l'idée serait :
- de sortir un .pos pour chaque sous-maillage, avec les infos par incréments pour uniquement les noeuds concernés par les éléments spécifiques du sous-maillage. La somme des .pos serait alors quasi-équivalente en taille aux fichiers .pos actuel qui globalise actuellement toutes les infos
- la sortie serait automatique: on a pas besoin de définir explicitement des ref particulières se qui simplifie l'utilisation d'Herezh: je vais donc privilégier cette solution.

Mis à jour par Julien Troufflard il y a 23 jours

Proposition :
pour la sortie par sous-maillage, tu as parlé de nommer les grandeurs par exemple SIG11_1 pour le sous-maillage 1, SIG11_2 pour le sous-maillage 2.
Si le but est de sortir par dimension d'élément (les éléments 1D, séparés des éléments 2D, séparés des éléments 3D), que penses-tu d'utiliser le suffixe 1D,2D,3D pour les grandeurs : SIG11_1D, SIG11_2D, SIG11_3D

Question :
la sortie par sous-maillage conduira potentiellement à plusieurs versions d'une même grandeur (par exemple : SIG11_1,SIG11_2 ou SIG11_1D,SIG11_2D). Est-ce que ces grandeurs seront dans le même fichier .pos ou dans des fichiers séparés ?

NB : question que je me pose en prévision de modifier le script hz_visuGmsh.pl => actuellement considère 1 grandeur = 1 fichier .pos => à l'avenir devra peut-être prendre en compte la possibilité de plusieurs grandeurs dans un fichier .pos (option -repair permet déjà de splitter les fichiers ayant plusieurs grandeurs)

Mis à jour par Gérard Rio il y a 23 jours

Oui il y a pas mal de questions qui se posent !!

D'abord une remarque:
actuellement, la sortie gmsh utilise un seul maillage. C'est historique car la première sortie faisait suite à la sortie au format Gid qui utilise un seul maillage. Avec le fait d'avoir plusieurs sous-maillages (un par type d'élément) cela pose un pb car supposons que pour le maillage 1 j'ai 2 sous-maillages : ligne et triangle, pour le maillage 2 : 3 sous-maillages triangle, quadrangle, hexa
lorsque je sors la grandeur SIG11_1 par exemple dans un repère ad hoc, cela va mélanger le SIG11 le long de la ligne pour le maillage 1 et le SIG11 de surface pour le triangle du maillage 2: pas simple de s'y retrouver !
Lorsque je sors SIG11_3: cela ne veut rien dire pour le maillage 1 !
D'autre part, j'ai fait un test et a priori gmsh gère le fait de visualiser conjointement 2 maillages et step différents.

Du coup, je crois que je vais faire évoluer la sortie d'Herezh avec : une sortie par maillage
Un intérêt collatéral sera d'avoir la bonne numérotation pour les noeuds et les éléments pour chaque maillage et le fait de pouvoir visualiser ou non un maillage particulier. Je pourrais même sortir par défaut tous les maillages, ce qui simplifie la sortie par défaut.

sortie SIG11_1D, SIG11_2D, SIG11_3D ?
En fait les sous-maillages ne suivent pas forcément l'ordre 1D, 2D, 3D, est-ce une bonne idée ???
Supposons que l'on ait des éléments quadrangles et triangles linéaires: on aurait 2 sous-maillages:
- pour les quadrangles: on extrapole avec 4 pti aux noeuds, pour les triangles on a 1 seul pti qui est directement recopié aux noeuds. On pourrait dire que c'est mieux de mélanger les valeurs du quadrangle et celles du triangle ? Mais on pourrait dire aussi que c'est mieux de voir ce que l'on obtient avec le quadrangle : a priori plus précis, et ce que l'on obtient avec le triangle, par contre si on superpose les deux posts on aura une discontinuité: mais cette discontinuité est intéressante à regarder ??

Bref... les deux approchent sont intéressantes, je suis plutôt parti sur l'approche : une sortie par type d'élément
ça fait plus de fichiers, dans un cas simple pas de changement, dans un cas de contact : plusieurs fichiers, dans un cas de contact + plusieurs types d'éléments: encore plus de fichiers... mais au moins on a toutes les infos de manière détaillée.
Ensuite on peut peut-être imaginer des scripts qui globalisent si c'est nécessaire ?

Question :
la sortie par sous-maillage conduira potentiellement à plusieurs versions d'une même grandeur (par exemple : SIG11_1,SIG11_2 ou SIG11_1D,SIG11_2D). Est-ce que ces grandeurs seront dans le même fichier .pos ou dans des fichiers séparés ?

a priori on aura un fichier par grandeurs

NB: A priori actuellement je n'ai jamais plusieurs grandeurs dans un même fichier ? si je me trompe peux-tu me donner un exemple ?

Actions

Formats disponibles : Atom PDF

Redmine Appliance - Powered by TurnKey Linux