u4.01.13 Nouveautés et modifications de la version 17#

Résumé:

L’objet de ce document est d’offrir une vision globale des modifications de syntaxe et des nouvelles possibilités des commandes de code_aster intervenues au cours du développement de la version 17, c’est-à-dire depuis la version 16.5.

Pour plus de précisions, on consultera la documentation des commandes et les fichiers histor des sous-versions.

Thermique#

  • Opérateur THER_NON_LINE - TRANSITOIRE (#33079 - 17.1)

    La commande THER_NON_LINE est maintenant implémentée côté Python. Certains mots-clés ne sont pas encore pris en charge (séchage, réduction de modèle), dans ce cas l’opérateur Fortran est appelé.

  • Calcul du gradient de température GRAT (#33934 - 17.2)

    On souhaite dispose du gradient de température sous forme d’un champ aux nœud. Ce champ est nécessaire pour calculer les contraintes « relocalisées » à l’issue d’un calcul homogénéisé. Le champ de gradient de température s’appelle GRAT.

  • Extension des calculs disponibles pour HHO (#33950/#33946/#33966/#34394 - 17.2 à 17.3)

    On rend les éléments HHO compatibles avec des calculs thermiques orthotropes et avec un calcul THER_NON_LINE transitoire. On ajoute la possibilité de fournir des variables de commande VARC pour HHO en thermique. Les éléments HHO en thermique sont disponibles à l ordre 0 en thermique.

  • Introduction d’une nouvelle macro-commande CALC_THER_MULT (#33806 - 17.4)

    Cette nouvelle nouvelle macro-commande CALC_THER_MULT permet de réaliser des calculs thermiques avec linéarisation du maillage et pas de temps automatisé. Cette commande calcule l’évolution de la température dans la structure sous de multiples sollicitations thermiques transitoires. Deux réponses thermiques peuvent être prises en compte: réponse thermique à un choc unitaire ou réponse thermique à une sollicitation quelconque venant d’un AFFE_CHAR_THER.

  • Correction des matrices tangentes en thermique non-linéaire: conduction thermique (#34600 - 17.4)

    Les matrices tangentes de la thermique non-linéaire ne conduisent pas à une convergence quadratique même sur des cas très simples. Dans ce développement, on ajoute la prise en compte de la dépendance de la conduction thermique à la température.

  • Nouvel opérateur SECH_NON_LINE (#33112 -17.4)

    Jusqu’à présent les calculs de séchage étaient réalisés avec la commande THER_NON_LINE. Ce développement crée une nouvelle commande spécifique SECH_NON_LINE pour les calculs de séchage, associé aux lois de séchage et produit un nouveau résultat EVOL_SECH possédant un champ SECH avec une composante « SECH ».

Interaction Fluide Structure#

  • Evolution de DEFI_SPEC_TURB (SPEC_CORR_CONV_1-2)/PROJ_SPEC_BASE (#32094 - 17.1)

    Les opérateurs DEFI_SPEC_TURB/ PROJ_SPEC_BASE ne permettaient pas de réaliser un calcul de réponse d’une structure à la turbulence de manière adaptée. Les options disponibles étaient trop restrictives concernant les spectres et longueurs de corrélation. Les évolutions portent sur:

    • la possibilité de définir des longueurs de corrélation et vitesses convectives.

    • la possibilité d’intégrer une longueur de corrélation transversale pour Au-Yang et Corcos.

    • la possibilité de définir des longueurs de corrélation dépendant de la pulsation.

    • la suppression de la corrélation d’Au-Yang car fausse.

  • Relaxer la vérification de la cohérence des formulations IFS (#35153 - 17.4)

    Pour lever en partie la restriction sur la possibilité de mélanger plusieurs FORMULATION en IFS dans le même maillage, on ajoute le mot-clé VERI_FORMULATION_IFS dans AFFE_MODELE.

Lois de comportement#

Nouvelles lois ou améliorations:#

  • Introduction d’une loi de comportement quasi-fragile avec plafonnement en compression: ENDO_LOCA_TC (#32232 -17.1)

    Introduction une nouvelle loi de comportement pour le béton qui couvre la phénoménologie suivante :

    • Endommagement en traction / cisaillement et seuil dédié

    • Ecrouissage en traction identique à ENDO_LOCA_EXP

    • Endommagement en compression et seuil dédié

    • Ecrouissage en compression de type plasticité parfaite asymptotique après une première phase linéaire

    • Les seuils ont une expression analytique (robustesse, efficacité)

    • La contrainte est bornée quelle que soit la direction de chargement

    • Régularisation des points anguleux pour la matrice tangente (comme ENDO_LOCA_EXP)

    • Régularisation visqueuse de l’endommagement

    Le vocabulaire dans DEFI_MATER_GC et DEFI_MATERIAU a été revu. (#34613 -17.3)

  • Loi ENDO_LOCA_TC : modification des régularisations numériques (#34393 - 17.3)

    On évalue les deux paramètres de régularisation (l’un pour « arrondir » la forme du seuil d’endommagement, l’autre pour arrondir la transition traction - compression) de sorte à ce que l’impact sur les contraintes soit du même ordre de grandeur que la précision demandée pour l’intégration du comportement (via RESI_INTE_RELA).

  • Loi ENDO_LOCA_TC - Estimation de l’influence de la viscosité (#34611 - 17.3)

    On introduit la variable interne SIGMVISC, qui évalue l’écart avec la contrainte qu’on aurait pour la même déformation en l’absence de viscosité. On introduit également une autre variable interne, ENDOTOT, qui mesure l’endommagement maximal qu’on peut observer dans l’état courant en parcourant toutes les directions de sollicitations possibles.

  • Intégration du modèle de comportement Cam-Clay modifié via Mfront (#33516 - 17.1)

    Intégration du modèle de comportement Cam-Clay modifié (nommé MCC) via MFront. Il remplacera à terme la loi CAM_CLAY pour gagner en robustesse et en performance pour réaliser des calculs non-linéaires. Cette mise à jour permettra de décliner progressivement des variations de MCC, permettant ainsi des prédictions de plus plus réalistes par rapport aux essais expérimentaux sur sols.

  • Intégration du modèle de comportement Barcelone via MFront (#33678 - 17.2)

    Cette fiche a pour objet l’intégration du modèle de comportement de Barcelone avec MFront, en désactivant parallèlement la version Fortran existante. À terme, cette nouvelle intégration permettra de développer des variations plus sophistiquées du modèle de Barcelone adaptées aux matériaux de type bentonite.

  • Intégration du modèle de comportement CSSM via MFront (#33712 - 17.2)

    Cette fiche a pour objet l’intégration du modèle de comportement CSSM (Critical State Soil Model) via MFront dans Code Aster. CSSM s’appuie sur la combinaison de deux modèles, proches de Cam-Clay modifié et Iwan, pour représenter la phénoménologie des sols, à la fois sous chargements monotones et cycliques (ce que ne parvient pas Cam-Clay modifié ni Iwan à eux seuls).

  • Evolution de la loi DIS_GRICRA (#33519 - 17.2)

    On ajoute dans le matériau DIS_GRICRA, KP qui est la raideur élastique en parallèle (identique pour les 3 directions). Ce discret est mis en // pour éviter des pivots nuls, car DIS_GRICRA peut retourner une matrice tangente nulle.

  • Pour la loi discret DIS_CHOC, prise en compte d’un ressort élastique en parallèle (#34730 - 17.3)

    L’utilisation d’un discret de choc peut amener à des configurations de matrice singulière. Pour contourner ce cas, la pratique est de dupliquer l’élément de support pour ajouter un ressort élastique avec une raideur faible. Ce ressort en parallèle peut maintenant être pris en compte directement dans le comportement DIS_CHOC.

  • Pour la loi discret DIS_CHOC avec frottement et matrice tangente non symétrique (#35026 - 17.4)

    Ce développement a pour objectif de passer à une formulation faisant intervenir une vraie matrice tangente non symétrique pour la loi de comportement DIS_CHOC en présence de frottement de Coulomb, en statique et en dynamique. Cette fiche a donné lieu à une mise à jour des cas tests impactés, et ajouts de nouveaux tests.

  • Pour les lois de discrets, ajout d’un ressort élastique en parallèle (#35027 -17.4)

    Ce développement consiste à ajouter un ressort élastique en parallèle pour l’ensemble des lois de comportement d’éléments discrets (lorsque cela est possible).

  • Enrichissement de la loi DIS_ECRO_TRAC (#32285 -17.4)

    On souhaite modéliser un ressort non linéaire dans la direction axiale et et dans la direction tangentielle. La loi “DIS_ECRO_TRAC” permet de modéliser un ressort élasto-plastique avec une courbe de traction. L’objectif de ce développement d’enrichir cette loi pour l’étendre aux deux directions en même temps: axiale ou tangentielle.

  • Replacement de FONC_DESORP pour la définition des isothermes de désorption dans BETON_DESORP HR = f(C,T) (#33617 - 17.2)

    Le mot-clé ELAS_FO/FONC_DESORP devient BETON_DESORP/FONC_DESORP avec BETON_DESORP nouveau mot-clé de DEFI_MATERIAU. On introduit sous BETON_DESORP d’autres paramètres permettant d’évaluer l’hygrométrie à partir de l’isotherme de Leverett.

  • Développement d’une nouvelle loi de comportement pour le séchage SECH_RFT (#33618 -17.2)

    Une nouvelle loi de comportement relative au séchage a été développée et validée sur les données expérimentales du béton VeRCoRs. Le modèle est RICHARD_FICK_TEMPERATURE (Adia et al., 2020). Ce modèle est à introduire sous forme d’une nouvelle option dite ’SECH_RFT’ du mot clé RELATION dans l’opérateur THER_NON_LINE et sous forme d’un nouveau mot clé de l’opérateur DEFI_MATERIAU.

  • Compléments aux développements de SECH_RFT et BETON_DESORP (#34147- 33620 - 17.4)

    On ajoute à DEFI_MATERIAU/BETON_DESORP le mot-clé UNITE_PRESSION : il permet de choisir l’unité souhaitée pour la pression capillaire PCAP. On ajoute à SECH_RFT, les mots-clés UNITE_TEMPS et UNITE_LONGUEUR. Pour les 4 modélisations de séchage (3D_SECH, 3D_SECH_DIAG, AXIS_SECH et AXIS_SECH_DIAG), on crée deux options de calcul de champs aux points de Gauss : DIFF_ELGA pour le coefficient de diffusion et HYGR_ELGA pour l’hygrométrie.

  • Loi de comportement visco-hyper-élastique ELAS_HYPER_VISC (#34083 - 17.2)

    Introduction d’une loi MFront visco-hyper-élastique ELAS_HYPER_VISC. Ce modèle est adopté pour les élastomères. Il est comparé et validé avec des simulations Abaqus.

  • Modification de la formulation sur le fluage de dessication dans loi BETON_BURGER_FP (#25328 - 17.3)

    Dans la loi BETON_BURGER, le calcul du fluage de dessication était surestimé (modèle de Bazant) lorsqu’il y a des cycles de variations importantes d’humidité. Le fichier Mfront de cette loi a été modifié pour corriger ce point et dans le même temps, un schéma de résolution implicite a été adopté dans cette nouvelle formulation.

  • Intégration du modèle de comportement BURGER_AGEING dans un cadre THM (#33999 - 17.3)

    Le modèle de comportement BURGER_AGEING est disponible dans une version MFront. Le modèle BURGER_AGEING est conçu pour prédire un fluage propre qui est linéaire en contrainte et inclut un effet de vieillissement, contrairement au modèle BETON_BURGER. Le modèle BURGER_AGEING est développé de plus dans le cadre d’une modélisation THHM, du fait de l’influence de la pression capillaire et de la température sur le comportement qu’il prédit au fluage.

  • Loi Hill en Mfront (#34665 - 17.3)

    Introduction d’une loi hyperélastique MFront adoptée pour les mousses compressibles. Il s’agit de la loi de Hill, dont le potentiel s’exprime en fonction des élongations principales et de la variation du volume.

  • Loi MFront pour acier de cuve VISC_ISOT_PLAS (#31499 - 17.4)

    On souhaite capitaliser une loi de comportement MFront isotropique et élasto-viscoplatique nommée VISC_ISOT_PLAS. Ce modèle est adopté pour l’acier de cuve irradié (bainitique). Il est multi-échelle, prend en compte les propriétés de la microstructure, les vieillissements statique et dynamique ainsi que les grandes déformations.

Améliorations de l’interface Mfront/code_aster:#

  • Prise en compte des mot-clés et des variables de commandes par Mfront (#24065/23957 -17.1)

    Les mot-clés RESI_INTE_MAXI et ITER_INTE_MAXI de COMPORTEMENT avaient des valeurs par défaut qui sont désormais supprimés. Ainsi, les paramètres Epsilon et IterMax du fichier Mfront ne sont plus systématiquement écrasés. Les valeurs du fichier MFront ne sont surchargées que si le mot-clé est présent. On renomme RESI_INTE_MAXI et RESI_INTE_RELA en RESI_INTE. Pour la gestion des variables de commandes, on créé une correspondance dans Behaviour_module entre le nom consacré MFront pour chacune des composantes de variable de commande et le nom de composante aster dans le champ de variables externes généré par code_aster. Cela facilite l’ergonomie de l’usage des variables de commande transmises à Mfront via l’interface MGIS.

  • Grandes déformations GREEN_LAGRANGE avec MGIS (#33782 - 17.2)

    Ce développement consiste à brancher des grandes déformations GREEN_LAGRANGE avec MGIS. Dans aster, on utilise DEFORMATION= »GREEN_LAGRANGE » et dans MFront, on utilise: @DSL DefaultFiniteStrain. On restitue la contrainte de Cauchy sig.

  • Utilisation de Mfront possible pour les lois d’interface CZM (#34369 -17.3)

  • Amélioration de l’interface MFront/MGIS : codes d’erreur (#34642 17.3)

    La gestion des codes d’erreur de MGIS/MFront était incorrecte et peut faire croire à tort qu’une LdC n’est pas convergé. On prend en compte les trois codes de retour possible de Mfront pour les convertir dans code_aster.

  • Utilisation les modélisations GRAD_VARI avec des lois MFront (#34627 - 17.3)

    Cette utilisation est maintenant possible et testée sur une loi de von Mises avec écrouissage linéaire isotrope avec une modélisation AXIS_GRAD_VARI

Généralités:#

  • Définition AFFE_MATERIAU en plusieurs morceaux (#33342 - 17.1)

    On peut décomposer en deux appels distincts l’affectation de AFFE_MATERIAU, d’une part, l’affectation des matériaux (AFFE), et d’autre part, l’affectation des variables de commande (AFFE_VARC) en faisant appel au champs matériau déjà défini.

  • Vérification consistance des paramètres élastiques pour la géomécanique (#33602 - 17.1)

    Dans DEFI_MATERIAU, avec mots-clé ELAS et ELAS_FO on ne pouvait saisir que E et nu. Pour de nombreux matériaux (sols, roches, etc), on « connaît » mieux K et G (modules de compressibilité et de cisaillement), ou les deux célérités des ondes P et S : Vp et Vs. Sous ELAS (on ne fait pas pour les fonctions pour le moment), on peut désormais fournir soit (E, NU), soit (K, MU), soit (CELE_P, CELE_S, RHO).

  • Introduction d’un terme d’échange en densité de vapeur ECHANGE_THM_HR en THM (#33856 - 17.2)

    On souhaite introduire une condition d’échange massique (eau et vapeur) à l’interface afin de modéliser de manière plus réaliste des milieux ventilés. La densité de vapeur étant directement reliée à l’humidité relative, cela revient à écrire une condition en humidité relative (qui est généralement l’information dont dispose l’utilisateur). Il s’agit in fine d’une condition mixte non linéaire en paroi. On introduit donc ici un nouveau mot-clé ECHANGE_THM_HR dans AFFE_CHAR_MECA avec GROUP_MA et 3 mots-clé pour définir des coefficients : HR_EXT (pour l’humidité relative extérieur), ALPHA (pour la valeur coefficient d’échange) et PVAP_SAT pour la valeur de la pression de vapeur saturante. Une version dans AFFE_CHAR_MECA_F existe pour pouvoir faire varier PVAP_SAT avec la température et les autres coefficients avec le temps.

  • Introduire le pilotage PRED_ELAS pour la loi de comportement d’interface CZM_LAB_MIX (#34485 - 17.3)

    Le pilotage en question est introduit, sur la base d’un contrôle de l’incrément de la variable de glissement maximal. L’incrément de pilotage est normalisé par le glissement critique delta_c qui est un paramètre matériau (un incrément de pilotage de 1 correspond à un incrément de glissement de delta_c).

  • Introduction du pilotage PRED_ELAS pour la loi VMIS_ISOT_NL (#34190 - 17.3), dans le but de faciliter les calculs d’analyse limite et d’assurer des calculs plus robustes lorsque ce pilotage est déjà employé ailleurs dans la structure (béton armé)

Dynamique linéaire et non-linéaire#

  • Réduction de la consommation mémoire de DYNA_VIBRA (#31151 - 17.1)

    Dans DYNA_VIBRA, on allouait un gros bloc de mémoire en début de calcul. On a amélioré la consommation mémoire en découpant en plusieurs blocs les objets jeveux afin de pouvoir allouer / décharger au fur et à mesure du calcul.

  • Modification du calcul des déplacements irréversibles de la commande POST_NEWMARK (#33544 - 17.1)

    Mise à jour de la manière dont la commande POST_NEWMARK calcule les déplacements irréversibles à partir de l’accélération moyenne. La méthode implémentée (construction d’un signal fictif en accélération, écrêté à la valeur d’accélération critique avant double intégration) donnait moins de satisfaction et semblait moins robuste que l’obtention du signal en vitesse à partir de l’intégration de l’accélération moyenne et écrêtage pour les vitesses inférieures à zéro avant intégration pour obtention des déplacements. L’algorithme est remplacé par une simple intégration en temps de l’accélération moyenne, avec écrêtage à zéro si les valeurs sont inférieures à 0 avant intégration en temps pour obtenir les déplacements.

  • Amélioration des performances de l”étape de projection pour le calcul du facteur de sécurité avec POST_NEWMARK (#33542 - 17.1)

    On restreint le maillage utilisé pour la projection des contraintes aux éléments finis 2D adjacents à la ligne de glissement (étape nécessaire pour le calcul de contraintes de peau SIRO_ELEM sur la ligne de glissement). On permet à l’utilisateur d’effectuer une projection par COLLOCATION de l’opérateur PROJ_CHAMP (dans ce cas, SIEF_NOEU doit être pré-calculé par l’utilisateur). La projection est réalisée pour le champ NOEU, puis le champ des contraintes ELGA est calculé instant par instant.

  • Procédure de découpage automatique de bandes de fréquences en amont d’un CALC_MODES (#33821 - 17.2)

    On introduit une nouvelle commande permettant un découpage automatique en bandes de fréquences équilibrées (i.e., disposant chacune d’un nombre de fréquences propres comparable), en amont d’un calcul modal multi-bandes via CALC_MODES. Il s’agit d’une méthode itérative basée sur une procédure de dénombrement de valeurs propres (test de Sturm disponible dans INFO_MODE), que nous proposons d’implanter. Du fait de son caractère non intrusif, cette méthode prend simplement la forme d’une fonction Python qui renverra à l’utilisateur les bandes de fréquences « optimales » pouvant ensuite être renseignées dans un CALC_MODES.

  • Implantation du schéma HHT sans overshooting dans DYNA_NON_LINE (#33909 - 17.2)

    On réalise l’implantation de la version « No Overshooting » du schéma HHT dans DYNA_NON_LINE. Il s’agit d’adapter la formulation proposée par Kaiping (2008) au cas non linéaire pour l’implanter dans DYNA_NON_LINE, puis d’étudier la présence d’overshooting via plusieurs cas tests élémentaires (en comparant les résultats obtenus à ceux issus du schéma HHT actuellement présent dans DYNA_NON_LINE). Le schéma NOHHT est ainsi disponible dans DYNA_NON_LINE, pour les formulations en déplacement et en accélération.

  • Calcul sismique des réservoirs : pression équivalente EC8/DERESMA (#31186 - 17.2)

    L’approche habituelle pour le calcul de la tenue sismique des réservoirs repose sur l’EuroCode 8 partie 4 (EC8, norme NF EN 1998-4). Les effets du fluide sous séisme sur la paroi du réservoir sont représentés par un champ de pression équivalent défini par la superposition de plusieurs fonctions en coordonnées cylindriques (pour les réservoirs cylindriques verticaux). Ces champs sont ensuite imposés sur la paroi pour permettre une analyse sismique statique équivalente de type push-over. On développe une macro-commande réalisant ce calcul. La macro-commande DEFI_PRES_EC8 produit une formule utilisable dans AFFE_CHAR_MECA/FORCE_COQUE_FO (#33522).

  • Output de la macro-commande MACR_SPECTRE (#33961 - 17.2)

    On change le comportement par défaut de MACR_SPECTRE afin de ne pas imprimer par défaut l’enveloppe des directions horizontales des spectres (notée H).

  • Ajout d’une sortie de maillage raffinée pour l’option VERI_MASSE de POST_NEWMARK (#33996 - 17.2)

    On met à disposition de l’utilisateur le maillage utilisé pour le calcul de la masse glissante dans la commande POST_NEWMARK, en cas d’utilisation de l’option VERI_MASSE.

  • Ajout de la possibilité de prise en compte de la dispersion de régression pour l’estimation de ky dans POST_NEWMARK (#33997 - 17.2)

    L’option de calcul de ky développée dans issue32770 considère une régression linéaire entre le facteur de sécurité et l’accélération moyenne pour une plage comprise entre 0.8 et 1.2 du facteur de sécurité. La valeur d’accélération critique retenue est celle à 3σ de la régression. On donne à l’utilisateur la possibilité de choisir un autre facteur multiplicatif entre 0 et 6 (0 = non prise en compte, 6 = estimation conservatrice à -6σ).

  • Ajout du nom pour GROUP_MA lors du calcul de l”accélération moyenne dans POST_NEWMARK (#34011 - 17.2)

    On fournit en sortie de la macro-commande POST_NEWMARK un nouveau maillage -identique au maillage utilisé pour le calcul dynamique- contenant le groupe de mailles utilisé pour le calcul de la résultante et de la masse glissante (si VERI_MASSE est activé).

  • Optimisation de la macro-commande DYNA_ISS_VARI (#34287 -17.3)

    L’optimisation de la commande a été réalisée suivant 2 axes d’amélioration : Optimisation du calcul de la matrice de cohérence et Optimisation du calcul des valeurs propres et de l’énergie. On note un gain d’un facteur 10 sur un cas test.

  • Opérateur GENE_ACCE_SEISME : correction ZPA (#30484 - 17.3)

    Dans la simulation d’accélérogrammes avec gene_acce_seisme, on souhaite générer des signaux qui possèdent exactement le bon PGA (le ZPA sur le spectre). On ajoute le mot-clé : CORR_ZPA = 'OUI' ou 'NON' (défaut)

  • Loi choc avec flambage DYNA_VIBRA (#34294 17.3)

    On modifie l’opérateur DYNA_VIBRA de manière à rendre la relation FLAMBAGE utilisable avec une loi de flambage générique, donnée sous la forme de trois fonctions, à savoir le seuil de flambage, la raideur et l’amortissement en fonction de l’enfoncement total. Ainsi, les données d’entrée de DYNA_VIBRA/FLAMBAGE sont désormais identiques à celles de la loi de comportement CHOC_ENDO_PENA utilisable dans DYNA_NON_LINE.

  • Opérateur COMB_SISM_MODAL : Ajout méthode ENVELOPPE (#34351 - 17.3)

    Ajout de l’option ENVELOPPE au mot-clé ANALYSE. Cette option d’analyse « Enveloppe » permet de calculer la réponse spectrale d’un système en multi-appui avec un spectre d’enveloppe de tous les spectres d’entrée, pour chaque direction. Le système en multi-appui est considéré comme un système en MONO_APPUI.

  • Opérateur COMB_SISM_MODAL : Nouvelles méthodes de combinaison (#33545 #34054 - 17.3)

    Les méthodes de combinaisons suivantes sont ajoutées dans COMB_SISM_MODAL sous le mot-clef COMB_MODE/TYPE "NRC_GROUPING", "NRC_DSA" et "NRC_TEN_PERCENT".

  • Opérateur COMB_SISM_MODAL : Optimisation programmation, consommation mémoire et performances (#34465-34698-34677 -17.3 - 17.4)

    Amélioration de l’opérateur pour une diminution du temps de calcul La programmation de la macro COMB_SISM_MODAL est revue pour supprimer les doublons, améliorer la lisibilité des blocs, améliorer l’usage des variables et la pythonisation du scripting. La surconsommation mémoire apparaît dans le cas du traitement de l’option ELNO dans COMB_SISM_MODAL: on optimisme le script pour améliorer la consommation.

  • Opérateur CALC_FONCTION / SPEC_OSCI HARMO: ajout option calcul direct (#34798 -17.4)

    L’opérateur CALC_FONCTION permet de calculer des SRO en pseudo accélération par la méthode NIGAM (résolution temporelle) ou HARMO (filtrage en domaine fréquentiel). Pour le mot-clé SPEC_OSCI, on ajoute un nouveau mot-clé PSEUDO = 'OUI' ou 'NON' (défaut = “OUI”), afin de pouvoir calculer l’accélération absolue. Le calcul de l’accélération absolue et de la vitesse relative ne sera possible que avec la méthode HARMO.

  • Evolution de l’opérateur MODE_STATIQUE en groupant les supports (#34760 - 17.4)

    Actuellement l’opérateur MODE_STATIQUE, permet de calculer en MULTI_APPUI les pseudo modes par DDL bloqué, c’est-à-dire : support par support, direction par direction. Dans certains cas industriels avec un nombre très important de supports, on souhaite regrouper les supports. L’objectif de ce développement de calculer les modes statiques par groupe d’appui dans MODE_STATIQUE. Dans MODE_STATIQUE, on ajoute un mot clé CORRELE="OUI"/"NON" sous le mot-clé facteur PSEUDO_MODE. Si CORRELE= »OUI », alors on crée un seul mode par direction active . L’utilisateur doit précisé NOM_APPUI (de longueur <=8) qui va servir à nommer le mode.

  • Amélioration des performances du calcul dynamique transitoire dans REST_GENE_PHYS (#34914 -17.4)

    L’objectif de cette fiche est d’améliorer les performances du calcul dynamique transitoire tout en réduisant au maximum l’utilisation de la mémoire. Dans l’opérateur REST_GENE_PHYS, on ajoute un mot-clé facultatif ENVELOPPE="NORME_MOMENT" ou ENVELOPPE="VALE_ABS". L’activation de ce mot-clé permet de calculer les enveloppes maximales à chaque instant t, au fur et à mesure de l’avancement du calcul de la solution.

  • Evolutions de CALC_MISS avec introduction du chargement mono-appui (#34597 - 17.4)

    Le développement permet l’introduction de l’option EXCIT_MONO. Cette nouvelle option permet de prendre en compte un chargement mono_appui dans CALC_MISS. On introduit également deux autres options: EXCIT_FORC qui prend la place de ACCE_X, ACCE_Y et ACCE_Z et EXCIT_GENE qui prend la place de EXCIT_HARMO. Les options fournies avec PARAMETRE ont été rendus obligatoires que dans les cas où il faut vraiment les utiliser (c’est-à-dire quand on fait appel à MISS3D). Même chose pour VERSION et TABLE_SOL qui servent seulement à Miss3D. On introduit l’option TYPE_EXCIT qui oblige l’utilisateur à rentrer le type d’excitation (temporelle ou fréquentielle). On introduit l’option LIST_FREQ_CALC pour mieux gérer la définition de la liste des fréquences de calcul (pas disponible pour l’option TRAN_GENE). On introduit l’option INTERPOL qui rend plus explicite pour l’utilisateur la possibilité de réinterpoler une fonction temporelle fournie en entrée.

Eléments de structure#

Généralités#

  • Calcul d’un champ EGRU d’efforts généralisés en repère global (#33252/33584 - 17.1)

    Dans la commande MODI_REPERE, un nouveau mot-clé NOM_CHAM_RESU a été ajouté et ne concerne que le champ EFGE_ELNO. Si NOM_CHAM_RESU=EGRU_ELNO est indiqué, alors un nouveau champ nommé « EGRU_ELNO » est créé et contient le champ EFGE_ELNO calculé dans le nouveau repère. La sd resultat du MODI_REPERE contiendra également EFGE_ELNO qui reste inchangé (LE CHAMP INITIAL). Si NOM_CHAM_RESU est omit, alors le comportement initial de MODI_REPERE est conservé et le champ renseigné dans NOM_CHAM se retrouve modifié (écrasé). Ces champs sont utilisables avec l’opérateur COMB_SISM_MODAL.

  • Blocage de la normale dans AFFE_CHAR_MECA (#33329 - 17.1)

    On introduit un nouveau mot-clé DRNOR dans AFFE_CHAR_MECA / FACE_IMPO afin d’imposer des déplacements suivant la normale locale.

  • Amélioration performance de l’opérateur AFFE_CARA_ELEM (#34561 - 17.4)

    On modifie le mot-clé VERIF =[OUI | NON]. ( defaut = OUI). Les vérifications sont maintenant centralisées et le mot-clé VERIF permet de les désactiver si besoin.

Eléments plaques, coques et membranes#

  • Nouveau mot-clé FORCE_COQUE_FO dans AFFE_CHAR_MECA (#33522 - 17.1)

    Ce nouveau mot-clé FORCE_COQUE_FO permet de fournit un chargement dépendants de X, Y, Z , EP (epaisseur), et ou RHO. On évalue ces fonctions dans l’opérateur pour chaque maille. Cette évaluation n’est plus nécessaire à chaque pas de temps comme c’est le cas avec AFFE_CHAR_MECA_F/FORCE_COQUE.

  • Vérification planéité des plaques (#33517 - 17.1)

    La fiche propose de déplacer la vérification de la planéité des plaques (QUAD4) dans AFFE_MODELE au lieu de l’émettre à chaque itération. L’option VERI_PLAN est créée. Elle utilise le même critère de planéité que l’ancien (dans le te). On ajoute le mot-clef VERI_PLAN dans AFFE_MODELE.

  • Définition d’un repère cylindrique pour AFFE_CARA_ELEM / GRILLE_MEMBRANE (#33303 - 17.1)

    Pour déclarer des repères locaux dans AFFE_CARA_ELEM / GRILLE, l’utilisation de VECT_1 ou VECT_2 est pratique et simple. Mais il existe des configurations géométriques qui ne permettent l’usage ni de VECT_1, ni de VECT_2 (repère polaire dans un plan horizontal). Avec le nouveau choix, REPERE='CYLINDRIQUE', ORIGINE et AXE_Z, les vecteurs VECT_1 / VECT_2 peuvent maintenant être exprimés dans le repère cylindrique.

  • Gestion des matrices non-symétriques pour les DKT (#31432 - 17.2)

    On ajoute le traitement du cas des matrices non symétriques pour les éléments DKT.

  • Nouvel élément plaque via la bibiothèque Fenics (#34936 - 17.4)

    Cette fiche traite de l’ajout de la modélisation PLAQ_MITC sur un support QUAD9 (POC sur l’implémentation d’un élément fini avec la bibliothèque Fenics). La modélisation adoptée pour les plaques repose sur la théorie de Reissner–Mindlin, enrichie par une interpolation mixte de type MITC (Mixed Interpolation of Tensorial Components), dans la variante proposée par Durán et Liberman. Cette approche permet de corriger efficacement le verrouillage numérique lié au cisaillement transverse, assurant ainsi une meilleure précision dans la reproduction des déformations, même pour des plaques minces.

Eléments poutres et tuyaux#

  • Gestion Poutres proches de l”axe Z avec GROT_GDEP (#33398 - 17.2)

    Les calculs de poutres en GROT_GDEP, quand celles-ci sont orientées selon l’axe Z ou très proche de Z, ont parfois des difficultés à converger. L’actualisation du repère local des poutres en grands déplacements est en cause. Une solution plus robuste est mise en place pour améliorer la convergence.

  • Ajout de possibilités de definition de l”orientation des sections dans AFFE_CARA_ELEM (#31109 - 17.3).

    Lorsque l’utilisateur utilise MACR_CARA_POUTRE, en sortie il obtient une table avec les caractéristiques mécaniques nécessaires à AFFE_CARA_ELEM. Les caractéristiques nécessaires à AFFE_CARA_ELEM sont toujours celles qui sont calculées dans le repère principal d’inertie. On ajoute plusieurs manières de définir la section de poutre autour de son axe neutre ( possible avec « VECT_Y », « ANGL_VRIL »):

    • VECT_Z : qui est similaire à VECT_Y mais pour définir l’axe z3.

    • VECT_MAIL_Y/VECT_MAIL_Z : qui est similaire à VECT_Y/Z mais qui permet de définir la projection des axes Y/Z du maillage donné en entrée de MACR_CARA_POUTRE. On a donc besoin de l’angle “Alpha” qui est dans la table et qui donne l’orientation du repère principal d’inertie par rapport au repère du maillage.

  • Evolution des données en sortie de MACR_CARA_POUTRE (#31038 - 17.3)

    Ce développement consiste à

    • Modifier les propriétés pour que le ALPHA soit toujours dans le premier cadran.

    • Ajouter les coordonnées du centre de torsion dans le repère du maillage.

  • Ajout d’un chargement PRE_EPSI en repère global pour POU_D_T (#34241 - 17.3)

    On ajoute les mots-clé KN et VECT_N dans AFFE_CHAR_MECA et AFFE_CHAR_MECA_F pour PRE_EPSI. Ce chargement doit s’appliquer aux éléments POU_D_E et POU_D_T. Les fonctions dépendent de l’abscisse curviligne.

  • Ajout d’un post-traitement pour les éléments poutres du champ EFGE_ELNO (#34544 - 17.3).

    Étant donné un RESU de type DYNA, on calcule un champ maximal du même type que EFGE_ELNO. Pour les composantes FX, FY, FZ, on prend la valeur absolue maximale sur l’ensemble des instants du résultat. Pour les composantes MX, MY, MZ, on sélectionne l’instant où la quantité MX² + MY² + MZ² est maximale, puis on considère les valeurs absolues des composantes correspondantes.

  • Amélioration de l’intégration des éléments Tuyaux (#32525 / #34450 / #34557 /#30681 - 17.3) via la sous-intégration des intégrales.

    Parmi les autres développements, on note l’interdiction de MODI_METRIQUE=OUI pour les tuyaux (#34450 17.3), la sous-intégration de la matrice de masse (#34557 17.3) et la reprise des raccords Coque/Tuyau et 3D/Tuyau sont mal écrits dans le cas des grands déplacements. (#30681 -17.3)

  • Refactoring éléments de Tuyau : séparation formulation poutre et coque (#34415 - 17.4)

    Ce développement traite de la reprise de la programmation des éléments tuyaux en essayant de séparer informatiquement la partie poutre (courbe) et la décomposition de Fourier (coque) et en anonymisant au maximum des données d’entrée.

Eléments discrets#

  • Dilatation d’un discret soumis à un champ de température (#33437 - 17.1)

    On souhaite prendre en compte la dilatation thermique des discrets. Les développements concernent seulement les discrets K_TR_D_L (en remplacement des poutres, mêmes DDL). Les déplacements aux noeuds dus à la température pour les poutres est du type α*(T-Tref)*L, et dépend donc de la longueur de l’élément. Les déplacements aux noeuds pour les discrets seront de la même forme et donc dépendront de la longueur du discret. Le coefficient de dilatation « alpha » aura donc la même signification pour les poutres et les discrets.

  • Développement de la méthode des grilles (#34612 - 17.4)

    Cette fiche traite de l’implémentation de la méthode RIGI_GRILLE. Il s’agit d’un nouveau mot-clé dans l’opérateur AFFE_CARA_ELEM. Cette fonctionnalité correspond à une méthodologie utilisée pour déterminer les caractéristiques d’éléments discrets à appliquer au radier à partir de raideurs globales. Cette option est disponible en 3D. Le radier sera modélisé par une surface, les discrets sont des DIS_TR. Il faut distinguer un groupe de mailles pour le radier, à déclarer derrière le mot clé GROUP_MA et les 5 groupes de mailles de type SEG2 à déclarer derrière le mot clé GROUP_MA_SEG2. Ces mailles SEG2 doivent être affecté par des DIS_TR dans AFFE_MODELE. Ces mailles possède chacune un noeud en commun avec le radier, et un noeud sur lequel une LIAISON_SOLIDE sera appliquée par ailleurs.

Métallurgie#

  • Introduction d’un nouveau modèle métallurgique (revenu) (#27307 - 17.1)

    Introduction du phénomène de revenu sur les phases froides (bainite et martensite) dans CALC_META. Les équations reposent sur le modèle de loi de type Johnson-Mehl-Avrami pour la bainite et la martensite. Deux phases sont ajoutées : bainite revenue et martensite revenue. Le revenu agit comme un post-traitement au calcul métallurgique dans CALC_META via le mot-clef facteur REVENU. Des paramètres matériaux dédiés sont définis dans DEFI_MATERIAU/META_ACIER_REVENU : coefficients loi JMA (martensite/bainite), température de revenu, température de maintien.

  • Ajouter DURT_ELNO pour le revenu (#33628 - 17.1)

    On ajoute le calcul de la dureté (DURT_ELNO) pour le cas des phases revenus.

  • Extension restauration ecrouissage modèles cinématique + mixte (#32279 - 17.4)

    L’évolution concerne l’extension du modèle de restauration d’écrouissage aux cas de l’écrouissage cinématique (VMIS_CINE_LINE) et mixte (VMIS_ECMI_LINE).

Mécanique de la rupture#

  • Opérateur POST_BEREMIN - Amélioration des performances (#33415 - 17.1)

    Réécriture partielle de la macro-commande pour la manipulation des champs et l’appel aux commandes aster, pour un gain de temps d’un facteur 1.5 à 5.

  • Compatibilité de DEFI_FOND_FISS avec des HEXA27 (#33804 - 17.2)

    La programmation actuelle est prête pour rendre ces mailles compatibles avec CALC_G. Nous avons ajouté les mailles penta18 et hexa27 aux routines qui gèrent la connectivité dans DEFI_FOND_FIS.

  • Opérateur POST_BEREMIN - utilisation avec loi MFront (#34104 - 17.2)

    Suite à l’interdiction de IMPR_NOM_VARI="OUI" avec MFront, on ne pouvait plus utiliser POST_BEREMIN avec une loi MFront. Dans POST_BEREMIN, on ajoute 2 mots-clés pour donner les indices des variables nécessaires. Le mot-clé LIST_NUME_VARI, qui devra contenir les indices des 2 variables EPSPEQ et INDIPLAS, dans cet ordre, dans le champ VARI_ELGA. Si GDEF_LOG, mot-clé LIST_NUME_SIEF car pour calculer Beremin, on ne prend pas le tenseur des contraintes SIEF mais on prend les contraintes logarithmiques (contraintes T, stockées dans le champ VARI_ELGA).

  • Opérateur POST_BEREMIN: ajout d’un filtre temporel (#34248 - 17.3)

    On ajoute un nouveau mot clé HIST_MAXI dans POST_BEREMIN pour considérer le maximum temporel de la contrainte principale majeure (notée sig_I) sur le transitoire, plutôt que celle instantanée.

  • Opérateur POST_BEREMIN : ajout d’une contrainte seuil (#33185 - 17.3)

    On ajoute la possibilité d’intégrer dans la formulation du modèle de Beremin une contrainte critique seuil, renseignée dans DEFI_MATERIAU/WEIBULL/SIGM_SEUIL, à partir de laquelle le clivage est possible.

  • Opérateur POST_BEREMIN : ajout d’une option de calcul pour la déclinaison industrielle du modèle de Beremin (#34331 -17.3).

    Cette déclinaison industrielle se base sur le calcul d’une densité surfacique de contrainte de Weibull, qui nécessite d’être calculée dans un plan 2D perpendiculaire au front de fissure.

    L’objet de ce développement fiche est de rajouter une option dans POST_BEREMIN, via le mot clé facteur METHODE_2D, permettant de calculer cette densité surfacique de contrainte de Weibull.

  • Opérateur POST_BEREMIN : ajout des paramètres de type WEIBULL (#34327 - 17.3)

    On ajoute les paramètres M, SIGM_REFE, SIGM_CNV, VOLU_REFE et SIGM_SEUIL dans la commande POST_BEREMIN pour faciliter son usage, plutôt que faire appel à DEFI_MATERIAU.

  • Opérateur POST_BEREMIN : filtre en plasticité active optionnel (#34328 - 17.3) et suppression du filtre en plasticité cumulée (#34329 - 17.3)

    Ces développements modifient les filtres utilisés dans l’opérateur POST_BEREMIN.

  • Opérateur POST_BEREMIN : déplacement du mot-clé GROUP_MA sous WEIBULL (FO) et possibilité de le répéter (#34565 - 17.4)

    On modifie la syntaxe de l’opérateur POST_BEREMIN afin de pouvoir calculer la contrainte de Weibull sur plusieurs groupes de mailles au sein d’un même POST_BEREMIN, en répétant le mot-clé WEIBULL (FO).

  • Opérateur POST_BEREMIN : rendre possible l’utilisation d’une correction plastique générique (#34566 - 17.4)

    On donne à l’utilisateur la possibilité de définir directement l’intégrande Sigma_I dans le calcul de la contrainte de Weibull. On ajoute la valeur supplémentaire pour FILTRE_SIGM = « SIGM_CORR ». Et si FILTRE_SIGM ="SIGM_CORR", on doit fournir un concept de type evol_noli contenant à chauqe instant le champ Sigma_I à intégrer SIGM_CORR=un evol_noli.

  • Opérateur POST_BEREMIN : ajout de la dépendance des contrainte seuil et de clivage à la position (#34529 - 17.4)

    On autorise que les contraintes SIGM_SEUIL et SIGM_REFE soient des champs scalaires de type NOEU_NEUT_R. La valeur du paramètre est lue sur la composante X1 de ce champ. Il s’agit de fonctions dépendantes des positions X,Y et/ou Z.

  • Opérateur POST_BEREMIN : ajout de la dépendance de contrainte seuil à la température (#34538 - 17.4)

  • Opérateur POST_BEREMIN : éléments INCO_UPG (#34980 - 17.4)

    Cette fiche vise à mettre au propre l’utilisation de POST_BEREMIN avec les éléments incompressibles UPG en petites déformations. On ajoute l’option SIMY_ELGA pour ces éléments.

  • Opérateur POST_BEREMIN : amélioration de l’ergonomie (#34979 - 17.4)

    Cette fiche vise à rendre plus facile l’utilisation de POST_BEREMIN option METHODE_2D. On ajoute un message d’erreur explicite et clair quand l’utilisateur demande un post-traitement sur des groupes de nœuds/mailles qui ne sont pas présents dans le maillage. On rend optionnel la donnée du front de fissure pour pouvoir traiter des cas où le plan d’intégration est quelconque

  • Opérateur POST_BEREMIN : mise en cohérence des valeurs par défaut (#34981 - 17.4)

    Cette fiche vise à mettre en cohérence les valeurs par défaut et les mots-clés optionnels de POST_BEREMIN avec les recommandations de calcul pour la déclinaison industrielle du modèle de Beremin. On passe la valeur par défaut de HIST_MAXI à « NON ». On rendre optionnel le paramètre SIGM_REFE. Dans le cas où l’utilisateur ne précise pas la valeur de SIGM_REFE, on ne calcule pas de probabilité de rupture. Et on rendre option SIGM_SEUIL dans le cas WEIBULL_FO (valeur par défaut 0 ).

  • Opérateur POST_BEREMIN : ajout d’un nouveau type de seuil (#34982 -17.4)

    On rajoute à POST_BEREMIN un nouveau mot-clé TYPE_SEUIL = "REDUIT" (valeur par défaut) ou "RESTREINT". Par défaut, la contrainte de Weibull est calculée à partir de (max(0, PRIN_3 - SIGM_SEUIL))^m. Dans le cas RESTREINT, la contrainte de Weibull serait calculée par PRIN_3^m restreint à la zone où PRIN_3 - SIGM_SEUIL > 0.

  • Réécriture de la commande POST_KCP pour le calcul de la correction plastique Kcp (#34099 #34311 - 17.3)

    La nouvelle macro-commande POST_KCP intégrera la correction « beta » pour les DSR (cas du défaut semi-elliptique) conformément au RSE-M 2022. On ajoute le mot-clé obligatoire UNITE_LONGUEUR à POST_KCP lorsque l’utilisateur souhaite travailler en millimètres (mm).

  • Rendre compatibles les éléments INCO_UPG avec l’opérateur CALC_G (#33972 - 17.2)

    On corrige le calcul de la densité d’énergie libre pour les éléments incompressibles et le calcul de la contrainte dans le cas de G_EPSI. Désormais, l’opérateur CALC_G est compatible uniquement avec les éléments INCO_UPG (les plus génériques). Une erreur sera émise pour les autres modélisations telles que INCO_UP et INCO_UPO.

  • Opérateur CALC_G: Ajout des termes de courbure pour le calcul des FICs option “K” (#34348 - 17.3)

    Pour améliorer le calcul des FICs dans le cas d’une fissure plane à front courbe, nous introduit de nouveaux champs auxiliaires pour les modes 1, 2 et 3 (Thèse Le Cren et C. Stolz). Ces nouveaux champs prennent en compte la courbure locale de la fissure, permettant ainsi une évaluation plus précise des FICs. Le mot-clé ajouté est FORM_FISS = « ELLIPSE » ou « CERCLE ».

  • Opérateur POST_RCCM - ajout de la contrainte de pointe F dans la table de sortie de POST_RCCM (#34800 - 17.4)

    On ajoute la contrainte de pointe F dans la table de sortie de POST_RCCM pour l’option Pm + Pb.

Modèles THM (Thermo-Hydro-Mécanique)#

  • Modification de la formulation des lois de Fick en THHM (#32248 - 17.3)

    On propose donc de réécrire les flux diffusifs dans le mélange de gaz en massique (modèles HH : LIQU_VAPE_GAZ et LIQU_AD_GAZ_VAPE) avec une écriture beaucoup plus simple et conforme à la littérature.

  • Intégration du modèle BURGER_AGEING dans un cadre THM (#33999 -17.3)

    Cette fiche a pour objet l’intégration du modèle de comportement BURGER_AGEING dans MFront.

Contact#

  • Formulation DIS_CONTACT / DIS_CHOC : Contact dans le repère global (#33438 - 17.1)

    Lorsque l’on souhaite faire du contact avec des discrets (matériau DIS_CONTACT, comportement DIS_CHOC), le contact s’établit dans la direction du discret, avec ou sans frottement dans le plan perpendiculaire. On a donc du contact qui est traité dans le repère LOCAL du discret. L’évolution permet de résoudre le contact dans le repère global du maillage et non plus dans le repère local du discret. L’ajout d’un mot clé dans le matériau DIS_CONTACT permet de définir le type de contact que l’on souhaite CONTACT='COIN_2D'. Ce mot-clé est facultatif et sa valeur par défaut correspond au cas du discret avec contact dans le repère LOCAL :

  • Pour DIS_CONTACT avec CONTACT=”COIN_2D”, ajout du mot-clé PRECISION (#34590 - 17.3)

    Ce mot-clé PRECISION permet de préciser la tolérance pour que le DISCRET en COIN_2D reste dans un plan.

  • Suppression de l’option GAP_GEOM (#33728 - 17.1)

    L’option GAP_GEOM n’a pas d’utilité en pratique dans le calcul du contact. Cette option servait uniquement à tester l’appariement dans les cas-tests. On supprime l’option et toutes ses dépendances.

  • Mise à jour et amélioration de l’appariement des méthodes Python pour le contact (#33736,34349 - 17.3)

    Dans l’opérateur DEFI_CONT, un nouvelle architecture/développement de la partie appariement du contact est faite: - Ré-écriture de l’algorithme PANG - Re-factoring des objets et des méthodes Python qui y sont liés

    Ce développement permet de faire des post-traitements complémentaires sur l’appariement pour le debuggage des études.

  • Introduction du contact/frottement en lagrangien augmenté (#34372 - 17.3) .

    On introduit la possibilité de réaliser des calculs de contact frottant en grands glissements en s’appuyant sur :

    • une approche mortar avec utilisation d’un sous-maillage pour l’intégration numérique représentant qui s’appuie sur l’intersection des mailles maîtres et esclaves

    • une formulation de type Lagrangien augmenté

    • une résolution par une méthode de Newton généralisée

    C’est une formulation mixte où les multiplicateurs sont portés par les nœuds des éléments esclaves en P2P1 en 3D et P2P2 en 2D. Deux formulations sont introduites: une formulation dite classique, de type Alart & Curnier, activée par ALGO_CONT='LAGRANGIEN' et VARIANTE='CLASSIQUE' (les multiplicateurs y sont exprimés dans la base locale de l’élément) et une formulation dite robuste (par défaut), proposée par Poulios & Renard, activée par ALGO_CONT='LAGRANGIEN' et VARIANTE='ROBUSTE'. Les multiplicateurs y sont exprimés dans le repère global.

  • Ajout d’une méthode de pénalisation (#34603 - 17.3)

    On dégrade la formulation en supprimant les multiplicateurs ce qui mène naturellement à une approche pénalisée. Elle hérite donc des caractéristiques de la formulation originelle, à savoir que l’on utilise un unique coefficient de pénalisation pour le contact et pour le frottement. On observe la convergence quadratique observée sur la formulation de Lagrangien augmenté. La formulation est activée par ALGO_CONT= »PENALISATION ».

  • Faire communiquer les zones de contact en hpc (#30552 - 17.3)

    Le but de ce développement est de rendre le contact dans MECA_NON_LINE compatible avec le découpage de maillage.

Post-traitements#

  • Possibilité de restreindre MODI_REPERE par le mot-clé GROUP_MA (#31636 - 17.1)

    Le mot clé GROUP_MA a été ajouté sous MODI_CHAM dans MODI_REPERE (par défaut TOUT= »OUI ») pour restreindre le calcul dans les zones ou le repère a été changé. Uniquement les repères suivants sont impactés: COQUE_*.

  • Opérateur PROJ_CHAMP : PROL_VALE remplace PROL_ZERO (#33278 - 17.2)

    Pour toutes les méthodes pour lesquelles le mot clef PROL_ZERO existe, on le remplace par PROL_VALE. Avec le nouveau fonctionnement, sur les composantes des noeuds des mailles non concernées par la projection si PROL_VALE = xxx ==> on prolonge par xxx, si PROL_VALE est non renseigné ==> on met une valeur NaN.

  • Opérateur CALC_CHAMP option VARC_ELNO et VARC_NOEU (#33830 - 17.2)

    On rajoute une option VARC_ELNO pour les modélisations les plus classiques (3D, 3D_SI, D_PLAN, D_PLAN_SI, C_PLAN, C_PLAN_SI) et quelques éléments de structures (DKT, BARRE, GRILLE_MEMBRANE, DIS_T). Dans la doc de l’option VARC_**** de CALC_CHAMP, on précise en conséquence les précautions d’emploi de cette option.

  • Accès aux valeurs de coordonnées généralisées depuis un résultat de dynamique (#33734 - 17.2)

    Ajouter une (ou plusieurs) méthode(s) permettant d’accéder aux valeurs de coordonnées généralisées (en Python) depuis un résultat de dynamique (e.g., aux déplacements/vitesses/accélérations généralisées depuis un TransientGeneralizedResult). Une telle méthode pourrait prendre la forme d’un getValues() ou toNumpy() pouvant être appelé depuis une classe Python de type « résultat généralisé ».

  • Interpolation des champs d’un résultat (#32348 - 17.2)

    L’objectif est de mettre à disposition en Python et C++ des méthodes permettant l’interpolation linéaire entre champs. L’interpolation entre champs est réalisée avec un wrap de la routine fortran rsinch prévue à cette fin; et ceci afin d’avoir une programmation unique pour l’utilisation en c++ et python. Le nom de la nouvelle méthode est interpolateField dans le python et interpolateFieldOnNodesReal + interpolateFieldOnCellsReal dans le c++.

  • Changement du quantity d’un champ en python (#33968 - 17.2)

    On nomme la méthode setPhysicalQuantity() comme il y a getPhysicalQuantity On renomme aussi changeLocalization en setLocalization. Le développement est fait pour FieldOnNodes, FieldOnCells, SimpleFieldOnNodes, SimpleFieldOnCells.

  • Facilité de manipulation des champs (#16019 - 17.1)

    On peut manipuler les champs avec les opérations élémentaires +, - , * . (Voir par exemple dans zzzz505a)

  • Manipulation des composantes des champs par éléments (#34339,34354 - 17.3)

    Ce développement permet d’écrire simplement des opérations sur les valeurs des champs dans les macro-commandes via l’objet ComponentOnCells. On permet également les opérations sur les valeurs aux noeuds via l’objet “ComponentOnNodes”.

  • Prise en compte de DISTANCE_ALARME dans MACR_LIGN_COUPE (#34460/34536 - 17.3)

    Ajout d’un PROJ_CHAMP par ligne de coupe, afin de pouvoir correctement paramétrer les PROJ_CHAMP en fonction des DISTANCE_ALARME et DISTANCE_MAX de chaque ligne de coupe. Pour des questions de performance, on prend le minimum de DISTANCE_ALARME (respec. DISTANCE_MAX) pour l’ensemble de LIGN_COUPE.

  • Opérateur CALC_PRESSION (#32185 17.3)

    Dans le résultat en sortie de CALC_PRESSION, on a complété le composant CISA dans le champ PRES_NOEU, représentant l’amplitude de densité d’effort tangentiel. Les composants du vecteur de l’effort tangentiel sont stockés dans les composants VX, VY et VZ du champ PRES_NOEU. Ce post-traitement est disponible uniquement sur les modèles 2D.

  • Nouvel Opérateur VERI_FERRAILLAGE et macro-commande POST_VERI_FERRAILLAGE (#34004 #34705 - 17.3)

    La commande VERI_FERRAILLAGE permet d’automatiser le calcul des marges mécaniques de ferraillage sur des éléments de plaque. On ajoute une nouvelle macro-commande python POST_VERI_FERRAILLAGE pour le calcul des diagrammes d’interaction critiques sur des éléments de plaque. L’algorithme à la base est la méthode CAPRA_MAURY pour l’identification de la facette critique pour chaque maille. Les codes de calcul sont l’Eurocode2 et le BAEL91.

  • Ajout du minimum de ferraillage pour maitrise fissuration dans CALC_FERRAILLAGE (#35148 -17.4)

    On souhaite prendre en compte le ferraillage minimal pour la maitrîse de la fissuration dans CALC_FERRAILLAGE: calcul du ferraillage minimal vis-à-vis de la maitrise de la fissuration pour les éléments plaque avec les formules (7.1) de l’EN1992-1-1 et DCONC 4110-1/DN 2200-1 du RCC-CW. On ajoute les mots clés FERR_MIN_FISS et EFFET_ECHELLE à la commande CALC_FERRAILLAGE. On ajoute des nouvelles sorties de la commande CALC_FERRAILLAGE avec les quantités ASMINXI, ASMINXS, ASMINYI, ASMINYS.

  • Introduction d’une nouvelle macro-commande CREA_COUPE (#33807 - 17.4)

    On introduit une nouvelle macro-commande CREA_COUPE permettant d’ajuster les données fournies par l’utilisateur pour créer des coupes unidimensionnelles. La création de coupes est parfois compliquée avec MARC_LIGN_COUPE si un grand nombre de coupes est nécessaire. Cette nouvelle marco-commande permet de prendre en entrée une table, qui est mise à jour pour que les noeuds soient bien positionnés sur la peau du maillage. Via le mot-clé REVOLUTION, on peut créer des coupes supplémentaires par multi-rotation.

  • Création de la commande EXTR_COUPE qui prend en entrée le tableau de sortie de CREA_COUPE (#33810 - 17.4)

    L’objectif de cette nouvelle commande EXTR_COUPE est d’extraire les résultats sur ces coupes en tant que champs de résultats.

  • Permettre à IMPR_RESU de conserver NOM_CAS dans le nom des champs MED (#33808 - 17.4)

    On ajoute d’un mot clé TYPE_RESU avec deux choix "NUME_ORDRE" (par défaut) et "NOM_CAS". Le premier permet de garder le comportement actuel d’IMPR_RESU, tandis que le second permet de d’imprimer le nom du cas au début du nom du champ MED et ainsi de remplacer le nom par défaut donné par code_aster.

  • Ajout de l’option FORC_VARC_ELEM_P à CALC_VECT_ELEM (#349125 - 17.4)

    On rajoute une nouvelle option FORC_VARC dans CALC_VECT_ELEM pour obtenir les forces générés par les variables de commande.

  • Ajout d’option d’extraction avec NUME_ORDRE dans CREA_CHAMP (#34932 - 17.4)

    On ajoute la valeur NUME_ORDRE au mot-clé TYPE_RESU de CREA_CHAMP/EXTR, afin de pouvoir construire un champ indiquant le numéro d’ordre plutôt que l’instant auquel l’extremum est atteint pour chaque entité.

  • Prise compte de NUME_DDL dans LIRE_RESU (#34518 - 17.4)

    On ajoute le mot-clé NUME_DDL à LIRE_RESU et LIRE_CHAMP, pour reconstruire un champ avec les composantes souhaitées.

  • Evolutions de la macro-commande POST_ROCHE (#35056 - 17.4)

    Afin de pouvoir fournir une autre courbe de traction que celle de Ramberg-Osgood à l’étape de calcul de la contrainte vraie, on ajoute le mot-clé TRAC_EPSI (courbe de déformation en fonction de la contrainte). Le mot-clé RCCM_RX est renommé en SIGM_LIM. On ajoute les mot-clés VARIANTE et SIGM_ABAT qui permettent de calculer les critères suivants de nouvelles formulations. Les moments abbatus sont calculés. Ces développements s’accompagnent d’un changement de type de l’objet de sortie et des composantes des champs.

  • Développement de nouveaux paramètres modaux et nouvelle macro-commande POST_MODE (#33662 - 17.4).

    Ce développement permet de:

    • sortir les inerties modales effectives unitaires en rotation

    • sortir des inerties modales effectives unitaires en translation ou en rotation, mais seulement sur un groupe de maille (« locale »)

    • pouvoir trier les modes selon un critère sur ces nouvelles quantités

    Dans l’opérateur CALC_MODES, on ajoute le calcul des inerties modales effectives et des inerties modales effectives unitaires en rotation par rapport au centre de gravité. On ajoute une nouvelle macro-commande POST_MODE. Cette macro commande calcule les masses effectives et inerties de manière « approchée » en mettant des zéros sur la matrice de masse globale pour les noeuds non contenus dans le groupe de mailles fourni. L’approximation réside dans le fait que la contribution des noeuds au bord du groupe intègre aussi ce qui provient des mailles extérieures au groupe connectées à ce même noeud.

Version HPC#

  • Re-équilibrer un maillage en exploitant les chargements (#33789 - 17.2)

    Quand on distribue un maillage pour la première fois, à la lecture donc, on n’a d’autre choix que de ne le faire sur la base de la connectivité. Néanmoins, dans les cas où des relations linéaires sont appliquées entre des ddl, cette information est pertinente et permettrait d’orienter la distribution. On ajoute la possibilité de demander au découpeur de regrouper des groupes de nœuds sur un seul processeur, avec un argument à splitMeshAndFieldsFromMedFile : nodeGrpToGather.

  • Recherche linéaire pour MECA_NON_LINE (#33469 - 17.2)

    On uniformise le comportement de MECA_NON_LINE entre thermique et mécanique. On ajoute le cas de la recherche linéaire MIXTE.

  • Arrêter le calcul MECA_NON_LINE par un nombre de pas de temps (#34072 - 17.2)

    La demande est d’arrêter sans erreur un calcul après N instants calculés, que ces instants soient ou pas dans la liste initiale.

  • Ajout du type de chargement TYPE_CHARGE= »DIDI » dans MECA_NON_LINE (#31797 - 17.3)

  • Ajout de la prise en compte des cartes pour ETAT_INIT/SIGM (#34418 - 17.3)

  • Ajout du critère RESI_REFE_RELA pour MECA_NON_LINE (#33172 - 17.3)

  • Etendre certaines fonctionnalités de PROJ_CHAMP au HPC (#34537 17.3) Seule la projection de champs aux nœuds est supportée.

  • Choisir la valeur du recouvrement (#33695 - 17.3)

    Dans le contexte HPC, le recouvrement est fixé à 1. En lien avec les travaux sur le pré-conditionnement non-linéaire, il est nécessaire de pouvoir choisir une valeur différente. On ajoute un argument facultatif à la fonction ParallelMesh.readMedFile: ghost=1.

  • Chargement EFFE_FOND en HPC (#34910 - 17.4)

    Le chargement EFFE_FOND évalue des quantités géométriques (taille du l’ouverture du tuyau) sur la base du maillage. Cette fonctionnalité est rendue compatible avec le maillage distribué HPC.

  • Commande COPIER (#35035 - 17.4)

    La commande COPIER est maintenant disponible pour le HPC.

Performances#

  • Performances GDEF_LOG (#33694 - 17.1)

    Beaucoup de temps était passé dans « intégration de la loi de comportement » dans le cas GDEF_LOG, même avec un comportement linéaire, notamment dans le calcul des déformations logarithmiques. La factorisation du code permet un gain de :

    • ~20% dans « intégration de la loi de comportement » (ex perf02a)

    • 7% en moyenne sur l’ensemble des tests GDEF_LOG

  • Réduire l’empreinte disque des sorties de DEFI_SOL_EQUI (#33639 - 17.1)

    Réduction de l’empreinte sur disque des fichiers de sortie de la macro-commande DEFI_SOL_EQUI en proposant à l’utilisateur d’enregistrer dans la table enregistrée dans l’unité UNITE_RESU_TRAN uniquement :

    • accélération au champ-libre

    • accélération au rocher affleurant

    • accélération au borehole

    • accélération sur les noeuds inférieurs des couches de la colonne de sol (définis soit via la colonne “M” de la table de sol, soit via le mot-clé COUCHE)

    Pour ce dernier point, l’utilisateur pourra fournir une liste avec les noms des couches où il souhaite obtenir les accélérations (cela peut être utile pour des comparaisons avec le mouvement sismique « within »). On ajoute les mot-clés TOUT_ACCE et LIST_COUCHE_ACCE.

  • Optimisation des performances de REST_GENE_PHYS (#33336 - 17.1)

    Dans les études, les coûts en temps de cet op REST_GENE_PHYS (et de DEFI_BASE_MODALE) étaient disproportionnés par rapport à ceux de CALC_MODES (qui lui bénéficie de 3 niveaux de parallèlisme et des optimisations de longues dates dans le calcul modal et dans MUMPS). Maintenant que ces derniers sont optimisés. On observe des accélérations pouvant aller jusqu’à un facteur 30.

  • Simplification de l’appariement nodal pour LIAISON_GROUP (#33763 - 17.1)

    L’appariement nodal effectué dans LIAISON_GROUP n’était pas optimal. Il y a beaucoup trop de vérifications sans utilité et l’ordre des boucles a été inversé pour gagner en efficacité.

  • Temps de lecture du maillage (#34447 - 17.3)

    On supprime le nommage des noeuds et des mailles dans aster. On réécrit la lecture de maillage LIRE_MAILLAGE au format MED en C++ avec l’interface med dont on dispose déjà. On peut donc valoriser au mieux les améliorations des collections en C++ avec des accès directs en mémoire. Dans l’exemple traité, on passe de 5h à 7min.

Résolution et Solveurs#

  • Industrialisation de MUMPS 5.6.2.2c (#33202 - 17.1)

    Montée de version de MUMPS, de ses prérequis (PARMETIS, METIS, SCOTCH, PT-SCOTCH) ainsi que d’autres dépendances:

    • METIS 5.1.0 ==> version identique mais fourni par ParMETIS

    • MFront 4.1.0 ==> 4.2.0

    • MGIS 2.1-dev ==> 2.2

    • Scotch 7.0.1 ==> 7.0.4

    • Scalapack 2.1.0 ==> 2.2.0 + correction pour utilisation des scalapack MKL si disponibles

    • Mumps 5.5.1_consortium_aster1 ==> 5.6.2.2c

    • PETSc 3.17.1_aster ==> PETSc 3.19.5

    • mpi4py 3.1.3 ==> 3.1.5

    • medcoupling V9_10_0 ==> V9_11_0

    Impact sur les études : On note une amélioration des performances de toutes les simulations code_aster (lorsque couplé avec modification connexe des paramètres slurm : entre X1.6 ET X3 Cette version permet la correction de plusieurs bugs/dysfonctionnements dans MUMPS remontés par les tests.

  • Utilisation de « simples Lagranges » (#33452/33510 - 17.1)

    Pour limiter le nombre de degrés de liberté, on aimerait pouvoir se contenter de multiplicateurs de Lagrange simples. Cela est réalisé pour les commandes STAT_NON_LINE et CALC_PRECONT. Pour les cas de macro-commande CALC_PRECONT, on introduit le mot clé DOUBLE_LAGRANGE=”OUI” ou “NON” pour s’assurer de l’homogénité des choix avec les chargements.

  • Exporter la portion locale d’une matrice ou d’un vecteur vers petsc4py (#33690 - 17.1)

    Dans le cadre des travaux de thèse sur le préconditionnement non-linéaire, on souhaite pouvoir résoudre un problème non-linéaire sur chaque sous-domaine. Pour ce faire, on souhaite exporter la portion locale d’une matrice ou d’un vecteur vers petsc4py. Sur cette base, on pourra construire un solveur non-linéaire sur chaque sous-domaine.

  • Arrêter le calcul STAT_NON_LINE par un nombre de pas de temps (#34051 - 17.2)

    L’idée est de pouvoir contrôler plus finement la liste d’instant d’un calcul statique pour limiter l’empreinte mémoire. On laisse la possibilité à l’utilisateur de contrôler le nombre de pas de temps dans STAT_NON_LINE, quelque soit la longueur initiale de la liste d’instants. On utilise le mot-clé NB_PAS_MAXI dans DEFI_LIST_INST. Si on atteint NB_PAS_MAXI, même si on n’est pas à la fin de la liste de pas de temps donné par l’utilisateur, le calcul s’arrête proprement et archive les données.

  • Développer le solveur non-linéaire RASPEN (#33849 - 17.2)

    Dans le cadre de la thèse de Mehdi ETTAOUCHI sont menés des travaux sur des solveurs non-linéaires fondés sur la décomposition de domaine. On s’intéresse spécifiquement à l’approche Restrictive Additive Schwarz Preconditioned Exact Newton (RASPEN) qui présente de bonnes propriétés de robustesse. Il est implanté dans MECA_NON_LINE.

  • Introduction d’un pré-conditionneur de second niveau dans RASPEN (#34401 - 17.4)

    Dans le cadre d’une thèse sont menés des travaux sur des solveurs non-linéaires fondés sur la décomposition de domaine. On s’intéresse spécifiquement à l’approche Restrictive Additive Schwarz Preconditioned Exact Newton (RASPEN) qui présente de bonnes propriétés de robustesse, introduite dans 17.2, on propose maintenant d’ajouter la possibilité d’utiliser un préconditionneur de 2nd niveau. Son objectif est d’améliorer la scalabilité de la méthode en présence de nombreux sous-domaines.

  • Permettre la découpe du pas de temps avec RASPEN (#35109 - 17.4)

    Pour rendre RASPEN utilisable dans les études, il est ajouté la possibilité de découpe du pas de temps.

  • Ajouter des options dans PETSC/HPDDM (#34931 - 17.4)

    Le but de ce développement est de rajouter des mot-clés sous l’option SOLVEUR pour HPDDM. On rajoute une autre construction du problème grossier avec harmonic_overlap HARMO en plus de geneo GENEO. Il est adapté au problème non-symétrique. Par défaut, le solveur fonctionne avec mode AUTO (défaut): GENEO si matrice SYME sinon HARMO. On permet également de donner le nombre de modes que l’on veut calculer pour le problème grossier (NB_MODE, défaut=30), un seuil pour éliminer les MODES inutiles en relatif par rapport au plus important (SEUIL, défaut=0.0, tous les modes sont conservés).

Informatique#

  • L’opérateur STAT_NON_LINE devient une macro-commande (#33752 - 17.3)

    Pouvoir simplement lancer les tests qui utilisent STAT_NON_LINE avec MECA_NON_LINE afin d’effectuer les bilans pour mettre à jour le périmètre de validation de MECA_NON_LINE. STAT_NON_LINE devient une macro-commande qui appelle le « vrai » STAT_NON_LINE rebaptisé STAT_NON_LINE_FORT. L’appel à MECA_NON_LINE est aussi ajouté à cette macro. Suite à cette intégration, il suffira de changer la valeur d’un booléen dans la macro pour que STAT_NON_LINE appelle MECA_NON_LINE.

  • Opérateurs DEBUT/POURSUITE (#33431 - 17.1)

    Il n’y a plus que la commande DEBUT qui, en mode automatique (MODE= »AUTO », qui est le défaut), initialise le calcul s’il n’y a pas de base et relit une base si elle existe. Avec MODE="DEBUT", on initialise un nouveau calcul même si une base existe. Avec MODE="POURSUITE", on relit la base si elle existe, sinon on s’arrête en erreur. Pour la compatibilité, on conserve POURSUITE équivalent à DEBUT(MODE= »POURSUITE »).

  • Opérateur FIN : Optimiser les tâches (#34113 - 17.2)

    Dans FIN, fermer la base peut prendre un peu de temps. Or ce n’est pas nécessaire si on n’a pas prévu de récupérer la base. Objectif : Gain de temps quand le système de fichiers n’est pas des plus véloces ou quand on lance beaucoup de calculs.

  • Ajouter de l”équilibrage dynamique (#33609 - 17.1)

    Dans le cadre des études où des non-linéarités sont très localisées puis se propagent, il est nécessaire d’équilibrer la charge au cours du calcul. On peut imaginer fournir un champ aux nœuds scalaire qui sera utilisé comme poids par le partitionneur. Ajout du test zzzz155h qui réalise un calcul MECA_STATIQUE et redécoupe le résultat suivant une commande donnée par l’utilisateur. Le calcul utilise un AFFE_CHAR_CINE et un AFFE_CHAR_MECA.

  • Nouveaux maillages dans mesh_builder (#33948 - 17.2)

    Pour des besoins de projection de champs, pouvoir crée facilement les maillages d’un nuage de points ou encore d’une spline 1d. Ajout de 2 nouveaux maillages dans mesh_builder.py : buildPointCloud(coordlist, groups=False, info=1) et buildSpline1D(coordlist, groups=False, info=1)

  • Couplage aster/aster (#34103 - 17.2)

    Ajout de la possibilité de faire du couplage ASTER/ASTER en MPI. Pour cela, on ajoute un objet ExternalCoupling qui permet de faire cela. L’échange des donnés et l’interpolation se fait avec ParaMEDMEM. Le couplage de champs et les conversions se font avec MEDCoupler. Il y a en particulier des méthodes python de conversion simple. PLE est nécessaire pour découper le communicateur en deux sous-communicateurs (un par app). Si PLE est absent, on fait une émulation qui se contente de découper en deux parts égale le communicateur. Cela permet en plus de lancer facilement les tests.

  • Couplage aster/saturne (#34081 - 17.2)

    Plusieurs fiches ont été traitées pour le couplage aster/saturne. On rajoute un objet SaturneCoupling qui hérite de ExternalCoupling. Seules les méthodes set_parameters et run ont été surchargées. Ajout de méthodes sur les champs simples pour faire Import/Export vers MedCouplingField (#34128 - 17.3)

  • Portage sous windows mingw32 (#33476 - 17.2)

    On capitalise les modifications nécessaires pour le portage sous windows en utilisant mingw. La plate-forme est identifiée avec le define ASTER_PLATFORM_MINGW (on a supprimé l’ancien ASTER_PLATFORM_WINDOWS non maintenu).

  • Faciliter l’utilisation de DDT (#33932 - 17.2)

    L’utilisation de DDT en parallèle avec code_aster est qui un module Python est compliqué. On propose d’enrober le lancement pour encourager cet usage.

  • Nouveau module d’intégration des LdC (#33770 - 17.2)

    On engage la rénovation du superviseur des lois de comportement. Constat: les ldC ont besoin d’informations pour travailler, mais celles-ci sont souvent disparates et incomplètes. Par ailleurs, la généralisation des nouvelles procédures (comme la prédiction efficace, issue33631) est difficile du fait de la multiplicité des cas particuliers et du volume conséquent de source (plus de 200 lois). Méthode: on avait introduit il y a plusieurs années, un module et des types dérivés pour gérer les choses communes dans nmcomp/lcxxxx.

  • Expliciter le type integer(kind=8) (#33331 - 17.3)

    On ne force plus la compilation en integer(kind=8). Cela permet d’utiliser, par exemple, les includes de Mumps sans avoir à les modifier lors de l’installation, et donc ce qui permet d’utiliser des versions de Mumps qui viennent de paquets (conda par exemple). Idem pour Med et PETSc.

  • Extension de run_sbatch et run_aster (#34641 - 17.3)

    Ajout des options –run_aster_option=”–save_db” pour forcer la fermeture de la base, même s’il n’y en a aucune en résultat dans le fichier “.export” On ajoute l’option “–run_aster_option” à run_sbatch pour passer des options à run_aster. On ajoute également les options –time_limit et –memory_limit qui viennent surcharger les valeurs du “.export” pour créer le script sbatch et pour être passées à run_aster.

  • Pixi configuration in pyproject.toml (#35160 - 17.4)

    La configuration de pixi est disponible dans le fichier pixi.toml.

  • Améliorer la méthode fix du maillage (#35044 - 17.4)

    On améliore la routine fix pour le maillage (Mesh) qui permet de

    • vérifier la normale sortante pour les faces de bord

    • vérifier le volume positif des cellules

    • merge noeuds doubles

    • merge mailles double

    • optimisation des perfs (sans dégrader la partie lecture et raffinement)

    • optimisation mémoire: utilisation d’entiers courts au maximum. Gain potentiel de 40%

  • Reprogrammation du calcul des déformations (#35080 - 17.4)

    La programmation de l’option EPSP_ELGA est revue pour éviter les duplication à plusieurs niveaux: calcul des déformations totales et calcul des déformations anélastiques provenant des variables de commande.

  • Extension du calcul des déformations inélastiques (#35101 - 17.4)

    La reprogrammation du calcul des déformations est étendu aux options: EPSP_ELGA (déformations plastiques), EPM_ELGA (déformations mécaniques), EPVC_ELGA (déformations anélastiques) et ENER / ETOT / INDI_ERRE: énergies et indicateurs d’erreur.

  • Basculement de l’OS de base en debian 12 (#35068 - 17.4)

  • Montée de version des prérequis : 20251026 (#34454 - 17.4)

    Les nouveaux prérequis sont:

    • medcoupling c3928d335 (9.15 modifiée)

    • asrun 7d7eafcd (future 2025)

    • mfront 5.0.1

    • mgis 3.0.1

    • med 4.2.0

    • petsc 3.24.0

    • python 3.11 avec numpy, scipy, sympy, pandas.

  • Ajout une documentation le lancement de code_aster u1.04.00 (#34576 - 17.4)

Modifications de syntaxe et résorptions#

  • La commande POURSUITE peut ếtre remplacée par DEBUT(MODE= »POURSUITE ») (#33431 - 17.1)

  • Dans la commande CREA_RESU, le mot clé NOM_CHAM est déplacé dans le mot-clé facteur AFFE (#33432 - 17.1)

  • Dans la commande DYNA_NON_LINE, on change la valeur par défaut de AMOR_RAYL_RIGI pour la valeur “ELASTIQUE” (#33825 - 17.1)

  • Le mot-clé ELAS_FO/FONC_DESORP devient BETON_DESORP/FONC_DESORP avec BETON_DESORP (#33617 - 17.2)

  • On change le comportement par défaut de MACR_SPECTRE afin de ne pas imprimer par défaut l’enveloppe des directions horizontales des spectres, notée H (#33961 - 17.2)

  • Dans AFFE_CARA_ELEM, une seule occurence possible pour MASS_AJOU & RIGI_MISS_3D (#34507 17.3)

  • Interdicion de MODI_METRIQUE=OUI pour les tuyaux (#34450 17.3)

  • Suppression dans CREA_MAILLAGE des mots-clés : PREF_MAILLE, PREF_NOEUD et PREF_NUM (#34447 17.3)

  • Suppression du mot-clé NIV_PUB_WEB dans DEBUT (#34633 17.3)

  • Résorption de l’indice de nocivité « pouvoir destructeur » POUV_DEST de INFO_FONCTION (#34175 -17.3)

  • Résorption de l’opérateur CALC_IFS_DNL (couplage Calcium) #32446 17.3

  • Résorption de l’opérateur THER_NON_LINE_MO (#33520 -17.3)

  • Opérateur POST_BEREMIN - déplacement du mot-clé GROUP_MA sous WEIBULL(_FO) (#34565 - 17.4)

  • Opérateur POST_BEREMIN : amélioration de l’ergonomie et mise à jour de nombreux mot(clés) (#34979 #34981 - 17.4)

  • Opérateur CALC_MATE_HOMO : suppression de VECT_NORM (#34898 - 17.4)

    Dans l’opérateur CALC_MATE_HOMO, on supprime le mot-clé VECT_NORM et on utilise l’axe Z par défaut. On rend obligatoire le matériau THER également pour le TYPE_HOMO= »PLAQUE » (#34565 - 17.4)

  • Clarification du traitement de REPERE dans MACR_LIGN_COUPE (#35098 - 17.4)

    Ajout d’un mot clé facultatif REPERE_INIT = « GLOBAL » ou « LOCAL ». Ce mot clé est nécessaire lorsque l’on demande un changement de repère sur un champ ELGA, ELNO ou ELEM (susceptibles d’être exprimés dans le repère LOCAL) afin de lever une erreur si le champ de base n’était pas exprimé dans le repère GLOBAL

  • Suppression de l’évènement COLLISION dans DEFI_LIST_INST (#35029 - 17.4)

  • Opérateur AFFE_CARA_ELEM : Modification du mot-clé VERIF =[OUI | NON] (#34561 - 17.4)

  • Opérateur POST_ROCHE (#35056 - 17.4)

    On supprime de RESU_MECA_TRAN et on renomme de RCCM_RX en SIGM_LIM.