DEFI_GROUP opérandes MAILLE ou NOEUD disparu de la doc v13 ?

JonathanDESOMBRE

Bonjour,

Étrangement les opérandes pour la définition de groupes à partir d'une liste (extension) ont disparu de la doc de DEFI_GROUP en v13 !

Heureusement, cela fonction encore en v13. Mais cela veut il dire que cela va disparaître ?

MAILLAGE = DEFI_GROUP (reuse = MAILLAGE,


  MAILLAGE = MAILLAGE,
  CREA_GROUP_MA = (_F(NOM = 'E_nT', MAILLE =('M1', 'M2', 'M5', 'M6') ),
                   _F(NOM = 'E_nP', MAILLE =('M3', 'M4', 'M7') ),),
  CREA_GROUP_NO = (_F(NOM = 'N_nT', NOEUD =('N1', 'N2', 'N5', 'N6') ),

_F(NOM = 'N_nP', NOEUD =('N3', 'N4', 'N7') ),),),

Cordialement,

AsterO'dactyle

Bonjour,

L'usage de NOEUD et MAILLE dans les opérateurs est fortement déconseillé.

Ces mots-clefs ne sont donc plus documentés et inutilisables dans l'interface graphique Aster_Study

Un jour, ils disparaîtront complètement.

Utilisez GROUP_NO et GROUP_MA à la place

zhudongyu

AsterO'dactyle Do you konw how to solve this problem .https://forum.code-aster.org/public/d/20388-solved-groupe-de-noeud-poutre-1d-group-of-nodes-1d-beam/7

MC

Bonjour,

Ce serait embêtant de perdre la possibilité d'accéder aux mailles ou aux nœuds en direct. J'ai des bouts de programmes python qui utilisent cette fonctionnalité et c'est très utile (par exemple pour l'application des chargements).

Cordialement,

Michel Cassagnes

jeanpierreaubry

bonjour

MC wrote:
Bonjour,

Ce serait embêtant de perdre la possibilité d'accéder aux mailles ou aux nœuds en direct. J'ai des bouts de programmes python qui utilisent cette fonctionnalité et c'est très utile (par exemple pour l'application des chargements).

Cordialement,

Michel Cassagnes

moi aussi

et je l'ai dejà dit ici

jean pierre aubry

AsterO'dactyle

Bonjour,

On ne peut absolument pas garantir la bijection entre le nom du noeud/maille dans aster et le format de maillage , en particulier MED qui n'a pas de notion de nommage de ces entités.

Qui plus est, dans le cadre du déploiement de la version HPC, il viendra un jour où nous supprimerons ces noms pour des raisons d'efficacité.

C'est donc fortement déconseillé d'utiliser les noms de mailles/noeuds. Mais nous avons conservé la possibilité e le faire pour les plus anciens d'entre nous. On voudrait juste éviter que les nouveaux utilisateurs prennent cette (mauvaise) habitude.

JonathanDESOMBRE

Bonjour,

Merci pour votre retour. C'est pour moi une très grosse contrainte si cette possibilité disparaît. En effet, c'est très très limitant d'avoir à créer à l'avance tous les groupes de toutes les opérations possible d'une grosse étude. Notamment, comme pour les post-traitements et les chargements.

Cordialement,

ThomasDESOZA

Dear all,

Thank you for your feedbacks regarding the aforementioned issue.

We understand the concerns regarding the removal of the NOEUD/MAILLE keywords. The existing scripts as well as the workflows relying on the use of such keywords are numerous. That's why we're not removing these keywords unilaterally. The only step we've taken so far is what one may call a "depreciation". Essentially this doesn't break anything right now.

Removing them from the documentation ensures that they are not used by newcomers and beginners of code_aster as pointed out by AsterO'dactyle. Given their nature they cannot be used in AsterStudy which explains why we've decided to also "hide" them in the code_aster syntax manager (this also explains why they don't appear in the echo of the commands, though we've decided to undo that a few days ago in the development versions).

What happens next is not decided yet. Still, I also strongly discourage the use of these keywords for the same very arguments given by AsterO'dactyle:

[list=*]

the concordance between code_aster internal numbering and mesh format numberings should never be assumed

the internal numbering of nodes/elements has long been the cause of one of the most important performance pitfall of code_aster which we hopefully hope to solve in the years to come

[/list]

We strongly believe in SALOME and are willing to offer through AsterStudy a consistent and complete user-experience. That's why we also encourage to conduct any mesh-related operation (addition of groups of nodes or elements, deforming, etc) using the Mesh module API or the MEDCoupling API.

In the meantime, we'll be listening to the feedbacks of the open-source community on this matter.

Best regards,

TdS

Maggoo

Dear colleagues,

In the process of trying to do with CA everything I do in ANSYS, one of the aims is to be able to change a group of elements on which a fluid pressure is applied. The application would be the simulation of hydraulic seals, in which the contact and pressure surfaces will differ along the simulation steps (fitting, energizing and pressurization).

This process would involve checking which nodes were in contact and forming a second group of elements only with the ones with some node out of contact. This would not involve the direct access to the names of the elements or nodes (a script would decide it based on the actual mesh and contact condition).

The removal of the selection of the elements through the MAILLE command would put me in a very bad situation, should this is what is being planned.

I understand the concerns about the loss of correspondence of names and numbers, but I guess a discretion advice would be enough.

Thank you very much for your attention.

Helio.

Romanschi

Bonjour à tous,
Un certain nombre de cas test utilisent encore les mots clef MAILLE et NOEUD.
Sur la dernière compilation Windows (Simulease Version 9.10.0), ces cas ne peuvent plus être exécutés sans modification des commandes DEFI_GROUP -> CREA_GROUP_MA.
Ce problème peu documenté peut bloquer les nouveaux utilisateurs comme moi-même pendant un certain temps.

Pour le cas test SSLL111A, j'ai modifié la commande DEFI_GROUP de la façon suivante :

Avant :
MAPOU = DEFI_GROUP(
CREA_GROUP_MA=_F(
MAILLE='M1',
NOM='MAILLE_M1'
),
MAILLAGE=MAPOU
)

Après :
MAPOU = DEFI_GROUP(reuse=MAPOU,
CREA_GROUP_MA=_F(GROUP_MA=('POUTRE', ),
NOM='MAILLE_M1',
NUME_FIN=1,
NUME_INIT=1,
TYPE_MAILLE='SEG2'),
MAILLAGE=MAPOU)

En assumant que les éléments sont indexés en commençant par 1, j'ai donc sélectionné le premier élément dans la liste en spécifiant l'intervalle 1 à 1. Dans ce cas précis, j'aurais pu utiliser POSITION="INIT" également.

A noter que cette discussion met bien en garde devant l'incohérence potentielle entre numéros (noms) et ordre des mailles.

Cette solution de contournement m'a permis d'exécuter les calculs sans erreurs.

Est-ce qu'il y a une meilleure façon de contourner le problème pour des cas test?

Cordialement,
Roman Schirmer