Anomalie #240
Erreur lecture .info avec zone_contact
Ajouté par Frank Petitjean il y a plus de 4 ans. Mis à jour il y a plus de 4 ans.
Description
Bonjour Gérard,
Herezh détecte une erreur lors de la lecture du .info que je ne comprends pas :
- erreur dans la construction de la zone de contact 1 on ne trouve pas le noeud 292 parmi les noeuds potentiellement esclave !
J'ai vérifié mes référence qui sont ok. Je ne comprends pas ce message d'erreur.
Peux-tu m'éclairer s'il te plait.
Merci
Fichiers
| modele.CVisu (8,85 ko) modele.CVisu | Frank Petitjean, 09/05/2020 14:23 | ||
| modele.info (12 ko) modele.info | Frank Petitjean, 09/05/2020 14:24 | ||
| plan_sym.her (2,52 ko) plan_sym.her | Frank Petitjean, 09/05/2020 14:24 | ||
| maillage.her (94,9 ko) maillage.her | Frank Petitjean, 09/05/2020 14:24 | ||
| modele.info (12,1 ko) modele.info | Frank Petitjean, 09/05/2020 15:57 | ||
| maillage.her (94,7 ko) maillage.her | Frank Petitjean, 09/05/2020 15:57 |
Mis à jour par Frank Petitjean il y a plus de 4 ans
- Fichier maillage.her maillage.her ajouté
- Fichier modele.info modele.info ajouté
En limitant la zone de contact à 1 noeud j'ai repéré les noeuds qui posent problème. Mon maillage comporte volontairement des éléments quadrangle superposés. Les noeuds sur la frontière du maillage et appartenant à 2 éléments superposés entraine cette erreur de contact.
Si j'ajoute la commande fusion_elements_superposes_ le calcul démarre.
Ci-joint le test avec un seul noeud (N_bord1_contact 288) avec plantage. Si dé-commente fusion_noeuds, renum et fusion_elem le calcul passe.
Est-ce normal ou est-ce une faille de Herezh !!!
Mis à jour par Gérard Rio il y a plus de 4 ans
- Statut changé de Nouveau à En cours
- % réalisé changé de 0 à 50
Bonjour Frank,
je n'ai pas regardé tes fichiers, mais le fonctionnement que tu décris est normal... dans l'état actuel.
En effet, les noeuds potentiellement esclave sont ceux qui appartiennent à une frontière. Or les frontières sont les éléments qui n'apparaissent pas en double. Dans le cas d'éléments superposés, les frontières potentielles disparaissent du fait de leur détermination automatique.
Donc, en résumé
- avec le mode actuel de détermination automatique des frontières, le fonctionnement que tu observes est normal,
- il n'est pas possible de définir une frontière particulière qui ne rentre pas dans le cadre du calcul automatique de frontière.
Maintenant, une solution serait peut-être de pouvoir introduire des frontières spécifiques...
. est-ce que c'est la meilleur solution ?
. est-ce qu'il y a d'autre solutions potentielles ?
. quand est-il avec les autres codes ?
qu'en penses-tu ?
Mis à jour par Frank Petitjean il y a plus de 4 ans
Bonjour Gérard,
Merci pour ce retour. Je suis justement en train de négocier avec Anne-Sophie un report de livraison d'Omher à cause de ce problème...
Je comprends en effet que les noeuds appartement à des éléments superposés ne peuvent pas être considérés comme appartement à une frontière. Bin oui, pas malin l'animal ! Comme souvent je suis à la frontière(moi aussi !) des spécificité de Herezh (et bien en dehors des codes commerciaux !).
Les éléments double sont ceux des rubans 2D et du film qui sont physiquement superposés. Comme ruban et film ont des lois particulières j'ai par simplicité considéré 2 éléments superposés.
Je vais donc m'adapter sans te demander encore des évolutions. Je peux pour ces éléments doubles définir une loi des mélanges avec les 2 lois film + ruban et un ratio d'épaisseurs. Il me semble que cela doit être parfaitement équivalent en terme EF.
Qu'en penses-tu ?
Frank
Mis à jour par Gérard Rio il y a plus de 4 ans
oui pour les efforts dans le sens des rubans, par contre pour le comportement 2D du film,cela va être un peu différent... à voir si c'est problématique en fonction des éléments membranes en jeux.
Néanmoins, je pense qu'il va falloir que j'entre une possibilité pour l'utilisateur d'ajouter des frontières: qui pourraient mêmes être des frontières internes...
Bon ... à suivre
Mis à jour par Frank Petitjean il y a plus de 4 ans
Bonjour Gérard,
Je confirme la gestion des conditions limites latérales avec contact et pénalisation variable (pour l'instant en fonction des itérations) fonctionne du feu de dieu. Avec mes structures très souples c'est au fond beaucoup plus naturel d'intervenir en force plutôt quand déplacement. En mode "debug" je vois bien que cela laisse plus de liberté au maillage de trouver une forme équilibrée. J'applique quand même en fin de calcul des CLL mais cela joue très peu sur la forme (un peu sur les contraintes ortho quand même). Nous avions eu cette intuition sur l'intérêt du contact fin 2019 mais il nous manquait le pilotage par fonction nD.
Sur le cas compliqué des BPL, même avec un maillage présentant des éléments très fin sur les bords et aux pôles, le fuseau se lobe joliment sans aucune distorsion.
Gérard, mon cher collègue, je me fais tout caressant pour te demander si tu peux ajouter la possibilité d'inclure des référence de nœuds quelconques dans la liste des nœuds esclaves. Sans cela mes modèles de BP avec calottes (utilisés actuellement pas Anne-Sophie) ne tournent pas !
La dernière version d'Omher avec toutes ces nouveautés est attendue d'ici la fin du mois de mai...
La grande communauté des calculateurs de ballon stratosphériques se joint à moi pour te remercier chaleureusement :-))
Frank
PS. Je m'occupe de ta demande de cloture des tickets que j'ai ouvert sur d'autres sujets.
Mis à jour par Gérard Rio il y a plus de 4 ans
Merci pour ces bonnes nouvelles !
oui, l'ajout est cours.
L'idée est que toute définition particulière de zone de contact entraîne la prise en compte de cette zone complètement, indépendamment des frontières calculées automatiquement par Herezh.
à suivre !
Mis à jour par Gérard Rio il y a plus de 4 ans
- % réalisé changé de 50 à 80
Frank,
La version V 6.942 intègre maintenant le fait de pouvoir déclarer explicitement une zone de frontière de contact.
a priori le calcul passe avec tous les contacts.
Mais il faut sans doute revoir les paramètres de contact et/ou de CLL pour avoir une qualité attendue du résultat.
Peux-tu regarder et me tenir au courant ...
Mis à jour par Frank Petitjean il y a plus de 4 ans
Bonjour Gérard,
Mais quelle célérité ? Tu n'as pas du aller à la messe ce matin ;-)
J'attends la mise à jour d'Herezh et je regarde ça.
Merci
Mis à jour par Frank Petitjean il y a plus de 4 ans
Gérard,
Le contact est bien détecté et traité. Merci pour cet ajout.
Il me reste à réussir à faire converger mes calculs !
Frank
Mis à jour par Gérard Rio il y a plus de 4 ans
- Statut changé de En cours à Résolu
- % réalisé changé de 80 à 100