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.

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.

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.

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

• Le fichier profilageCopra.py est désormais renommé copraRollForming.py.
• Des éléments d'amortissement sont définis et activés uniquement lors de la phase dite de retour élastique. A cette fin, le nouveau paramètre dampingSPRING_FC permet de fixer le paramètre multiplicateur de la valeur de la force du matériau d'amortissement.
• Suppression du nombre de threads (boucles et solveur DSS) fixé par les paramètres des jeux de données. Une option permet désormais d'activer ou désactiver l'assemblage en parallèle des vecteurs et matrices structuraux.
• Une option permet le choix d'un solveur symétrique ou non-symétrique.
• Le paramètre itma permet de choisir le nombre d'itérations mécaniques max.
• Les paramètres de simulation sont écrits dans un fichier .m en fin de simulation.
• Une option permet d'écrire des résultats dans des fichiers .ascii à partir des archives bfacs.
• Une option permet d'écrire des résultats dans un fichier texte et dans un fichier Abaqus.
• Ajout du solveur MUMPS dans le choix de solveurs.

• Le fichier profilageCopraALE.py est désormais renommé copraRollFormingALE.py.
• Renversement de la visualisation par rapport à un plan vertical de symétrie.
• Ajout de la phase de “retour élastique” entraînant la désactivation des éléments finis en amont du profil n+1, la désactivation de toutes les interactions de contact, l'application de conditions aux limites isostatiques, l'introduction d'éléments d'amortissement et enfin la résolution en formalisme Lagrangien.
• Le profil n de la fleur est dupliqué une fois supplémentaire dans la génération du maillage initial.
• Ajout de l'option du solveur symétrique ou non-symétrique.
• Ajout de l'option de calcul parallèle pour l'assemblage des vecteurs et matrices.
• Ajout du solveur MUMPS dans le choix de solveurs.

• Option permettant d'ouvrir les outils (dans les directions transverses à la direction de profilage) dans le cas de problèmes de contact rencontré avec le formalisme Lagrangien (amplitude du déplacement, intervalle de temps, la direction X et/ou Y).
• Gestion plus complète des conditions aux limites.
• Réécriture des extracteurs, notamment les extracteurs pour l'analyse de racks du CRM (exportation des résultats METAFOR vers Abaqus).

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.

• Renumérotation des indices des objets géométriques pour la même raison que ci-dessus.
• Le profil de la fleur Copra est désormais ajouté dans chacune des planches 3D de stations.

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 :

• Les différentes lignes de profilage en C sont désormais regroupées dans un répertoire commun. Ce dernier contient un exemple Copra, la ligne expérimentale du CRM construite sous le projet STEELPRO (voir figure ci-dessous) et des lignes de profilage récupérées dans les archives de TFEs (voir figure ci-dessous).
• Les lignes confidentielles sont également regroupées dans un seul répertoire.
• bavoletSt6St11.cpe/.cre : cas-test Copra modifié pour résoudre des problèmes de contact.
• ChannelSt2.cpe/.cre : cas-test Copra modifié pour résoudre des problèmes de contact.

• Ajout d'un cas-test ALE avec calcul du retour élastique après découpe en sortie machine.
• Ajout d'un cas-test Lagrangien avec phase de retour élastique en sortie machine.
• Ajout d'un cas-test Lagrangien avec outils mobiles dans les directions transverses X et Y.
• Le répertoire copraRF/minWorkingExample comprend 2 “minimal working examples” Lagrangien et ALE. Ces derniers contiennent les commandes élémentaires d'un jeu de données de profilage. Ils se destinent à entamer l'apprentissage des modèles de profilage Copra.
• Ajout dans copraLarge d'un répertoire contenant les jeux de données des cas-tests Lagrangien et ALE du bavolet qui correspondent aux papiers Comptes Rendus Mécanique et CSMA 2015.
• Ajout dans copraLarge d'un répertoire regroupant tous les cas-tests confidentiels Lagrangien et ALE nécessaires à l'écriture du rapport.
• Suppression des premiers jeux de données des cas-tests confidentiels.

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.

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.

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 :

• les batteries connaissent actuellement une hausse drastique de leur temps CPU.
• le cas-test apps.bQs.contactTetra a planté sous Windows.

 
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

 
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