Table of Contents

Commit 2015-07-24

Commit profilage Copra - Phase de retour élastique

L'objectif de ce commit est la finalisation des développements des modèles numériques de profilage au terme du projet STEELPRO, avec une attention toute particulière à la phase terminale de la modélisation du procédé, à savoir le calcul du retour élastique sur le produit fini. De toute évidence, le calcul précis du retour élastique du produit fini est d'une importance capitale pour la mise en forme de matériaux à haute limite d'élasticité, tel que visé dans les objectifs du projet de recherche.

Contexte et motivations

Nos modèles ALEs de profilage étant dépourvus, une fois le régime stationnaire établi en fin de simulation, d'une opération de découpe du côté sortie machine, le retour élastique du produit fini était généralement mesuré sur une section droite dans la zone de sortie, située à une distance inter-tête en aval de la dernière station d'outillages. Cette section de mesures était extraite directement sous l'effet de l'emprise des outillages de la machine et des conditions aux limites imposées à la frontière Eulérienne aval (voir figure ci-dessous).

Dans la modélisation Lagrangienne du procédé de profilage, une fois le profilé complètement libéré des outillages de la machine, le calcul s'achève sur une phase destinée à relaxer autant que possible que les contraintes induites par les conditions aux limites artificielles (nécessaires à l'extraction du profilé de la machine). Au cours de cette phase finale, un jeu de conditions aux limites isostatiques est adopté. Cette phase additionnelle dite de retour élastique — non implémentée dans nos modèles ALEs — permet de s'assurer que le produit fini est quasiment totalement libre de forces externes et, en conséquence, de capturer précisément le retour élastique.

En conséquence des méthodologies différentes expliquées ci-dessus, les résultats ALEs et Lagrangiens de la section droite finale du profilé, tout comme les mesures de vrille, de cintrage longitudinal, etc. ne pouvaient, en l'état, être rigoureusement comparés. Nous ne pouvions, à ce stade, confirmer avec certitude l'exactitude des résultats ALEs obtenus avec le choix de procédure poursuivi. En définitive, se dispenser, dans nos modèles ALEs, de l'opération de découpe en aval de la machine et d'un jeu de conditions aux limites isostatiques pouvait nuire à la comparaison objective des résultats.

De plus, il est important de préciser que la phase de retour élastique a pu démontrer son rôle décisif dans un modèle Lagrangien d'un cas-test industriel complexe. En effet, suite à cette phase finale de retour élastique, le profilé développe, selon ce modèle Lagrangien, un défaut de vrille très notable. Cette observation vient donc renforcer le besoin d'une phase additionnelle équivalente dans nos modèles ALEs de profilage.

Implémentation d'une phase de retour élastique

Cette fonctionnalité très attendue dans nos modèles ALEs de profilage est rendue techniquement possible depuis la révision 2293 de METAFOR. Elle est l'objet premier de ce commit. Pour l'implémentation de la découpe, il suffit en effet d'appliquer la désactivation d'éléments par stages sur le tronçon de maillage à l'intérieur de la machine. De cette manière, le tronçon en sortie est définitivement isolé des outillages de la machine. Pour ce faire, dans la procédure de génération du maillage initial, la section droite finale de Copra est dupliquée à une distance aval égale au plus grand rayon d'outils de la dernière station. Cela permet de rendre plus aisée la récupération des points géométriques nécessaires à l'application des conditions aux limites. Dans le jeu de données, la définition des conditions aux limites isostatiques est empruntée directement du modèle Lagrangien. L'utilisateur a dès lors à sa disposition toutes les options du modèle Lagrangien pour redéfinir les conditions aux limites au besoin. Toutes les interactions de contact sont désactivées puisqu'elles ne sont, à ce stade du calcul, plus d'aucune utilité. Le redémarrage du calcul est opéré en formalisme Lagrangien. Enfin, mentionnons que des éléments d'amortissement sont utilisés.

Figure 1. Solution ALE stationnaire avant découpe. Figure 2. Solution finale après découpe.

En ce qui concerne la modélisation Lagrangienne, la phase de calcul du retour élastique est revue. Au cours de cette phase finale, des éléments d'amortissement sont introduits en raison des vibrations transitoires provenant du changement de conditions aux limites. Ensuite, les paramètres numériques du schéma d'intégration sont adaptés pour cette phase.

Les cas-tests de profilage comprenant une phase finale de retour élastique s'écrivent sous la forme de cas-tests par enchaînement vu les nécessaires changements des paramètres numériques du schéma d'intégration temporelle, voire de formalisme. Deux fichiers de jeu de données sont nécessaires : le premier fichier (son nom se terminant par “_1”) est dédié à la simulation du profilage en elle-même, alors que le second fichier (son nom se terminant par “_2”) enchaîne avec le calcul du retour élastique dans les conditions décrites ci-dessus.

Modifications des jeux de données de profilage Copra

Ci-dessous, j'ai dressé une liste non exhaustive des modifications dans les jeux de données des modèles de profilage Copra :

Jeu de données du modèle Lagrangien

Jeu de données du modèle ALE

copraImportUtilities.py

importCopra.py

Les indices des objets géométriques sont renumérotés pour permettre l'importation de la ligne de profilage en C du CRM (STEELPRO). Cette ligne comporte en effet un plus grand nombre de galets par station que permis originellement par l'importation dans les modèles numériques.

utilitiesCopra.py

Répertoire CpeCre

Le répertoire CpeCre est réorganisé et enrichi avec les lignes de profilage du CRM et des corrections sur les lignes originales du bavolet et du channel de Copra :

Nouveaux cas-tests de profilage dans la batterie

Divers

toolbox/abaqus.py

J'ai ajouté une option pour récupérer au besoin la position courante au lieu de la position initiale des points du maillage. C'est une option nécessaire pour les extracteurs de l'analyse de racks du CRM.

toolbox/battery.py

Le nettoyage du workspace de la batterie a posé quelques problèmes avec les nouveaux cas-tests de profilage écrits sous la forme d'enchaînement.

Dans le cas où le chemin de répertoire du workspace défini dans le jeu de données contient un point comme séparateur, aucun fichier _init_.py n'est écrit dans ce répertoire, ce qui n'est pas sans poser problème pour charger le fichier Python résultant de la traduction des fichiers .cpe/.cre.

En revanche, dans le cas où le chemin de répertoire du workspace contient comme séparateur le symbole underscore, le fichier _init_.py est généré comme attendu et l'ouverture du fichier python en question ne pose dès lors aucun problème. Néanmoins, le workspace de la batterie n'était pas nettoyé avec cette seconde méthode.

Dans le système de batterie, le nettoyage du workspace est désormais automatiquement opéré dans le cas particulier de cas-tests par enchaînement, si le nom du répertoire suit la convention recommandée (séparateur dans le chemin du workspace = underscore). Par conséquent, j'ai modifié tous les cas-tests de type “complex” dans la batterie ainsi que ceux comportant le mot clé “workdir” de manière à ce que le chemin de répertoire du workspace ne contienne plus aucun point comme séparateur.

Pour un nettoyage correct du workspace de la batterie, dans le cas précis d'une série de cas-tests par enchaînement, le chemin du workspace écrit dans le jeu de données doit dès à présent contenir le symbole underscore au lieu du point comme séparateur.

Il n'est pas inutile de rappeler que, selon les “règles de bonnes pratiques”, les noms de fichier et de répertoire ne contiennent aucun symbole underscore, sauf dans le cas précis d'une série de fichiers par enchaînement.

Notez que :

Fichiers ajoutés/supprimés

 
moved : arcelor.tools.copraRF.CpeCre.Channel.cpe/cre -> arcelor.tools.copraRF.CpeCre.C-Channel.Copra.Channel.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.Copra.ChannelSt2.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.Steelpro.125_r2.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.TFE.L120_R2DEG_E1.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.TFE.L120_R2DEG_E03.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.TFE.L120_R2PIQ_E1.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.TFE.L120_R2PIQ_E03.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.TFE.L120_R05DEG_E1.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.TFE.L120_R05DEG_E03.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.TFE.L120_R05PIQ_E1.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.TFE.L120_R05PIQ_E03.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.TFE.L360_R2DEG_E03.cpe/cre
added : arcelor.tools.copraRF.CpeCre.C-Channel.TFE.L360_R05DEG_E03.cpe/cre
added : arcelor.tools.copraRF.CpeCre.bavoletSt6.cpe/cre
added : arcelor.tools.copraRF.CpeCre.bavoletSt6St11.cpe/cre
added : .cpe/cre de lignes confidentielles

Tests ajoutés/supprimés

 
renamed : arcelor.tools.copraRF.profilageCopra.py -> arcelor.tools.copraRF.copraRollForming.py
renamed : arcelor.tools.copraRF.profilageCopraALE.py -> arcelor.tools.copraRF.copraRollFormingALE.py
added : arcelor.tests.copraLarge.comptesRendusMeca.bavolet_1.py
added : arcelor.tests.copraLarge.comptesRendusMeca.bavolet_2.py
added : arcelor.tests.copraLarge.comptesRendusMeca.bavoletALE_1.py
added : arcelor.tests.copraLarge.comptesRendusMeca.bavoletALE_2.py
added : arcelor.tests.copraRF.bavoletMovTools.py
added : arcelor.tests.copraRF.springback.U6ALE_1.py
added : arcelor.tests.copraRF.springback.U6ALE_2.py
added : arcelor.tests.copraRF.springback.U6SymLR_1.py
added : arcelor.tests.copraRF.springback.U6SymLR_2.py
added : arcelor.tests.copraRF.minWorkingExample.U6.py
added : arcelor.tests.copraRF.minWorkingExample.U6ALE.py
added : cas-tests confidentiels
removed : cas-tests confidentiels

Yanick Crutzen 2015/07/24