Comme on peut le voir sur la figure ci-dessous, deux meshPoints (représentés par des points rouges) sont étonnamment absents parmi les meshPoints de la frontière aval d'un groupe utile à la génération d'éléments de contact. La sélection de ce groupe n'est pourtant opérée qu'au moyen d'un simple RangeSelector
selon la direction de profilage. Pire, le nombre de meshPoints de ce groupe est variable selon que le calcul est fait sur le cluster ou bien sur Windows. De là, le nombre d'éléments de contact (ces derniers étant construits à partir des meshPoints du groupe) est variable, m'empêchant d'observer sur Windows les résultats calculés sur le cluster (le nombre d'éléments de contact dans l'archive bfac n'était pas celui attendu).
Figure : Une vue du maillage ALE initial en aval de la dernière station d'outillages – Ligne de profilage en C du CRM.
A la révision 2325 de METAFOR, en raison du développement de la phase de “retour élastique” du modèle ALE, j'ai dupliqué, dans la procédure de génération du maillage initial, le dernier profil issu de la fleur de Copra afin de permettre une coupe du maillage à cet endroit précis. Ce profil était placé en aval de la dernière station d'outils à une distance égale au plus grand rayon d'outil de la station. De cette manière, avec un choix de paramètres par défaut pour le contact, la position longitudinale du profil Copra coïncidait exactement avec l'une des bornes de l'intervalle définissant la sélection du groupe. A l'étape de génération du maillage initial, dans le cas de la ligne à simuler qui nous occupe (une configuration de la ligne de profilage en C du CRM), les nœuds de la section droite, maillée sur base du profil Copra dupliqué, ne sont vraisemblablement pas tous précisément dans un même plan vertical. Certains d'entre eux étaient parfois, selon les machines de calcul utilisées, exclus du groupe pour des écarts de position longitudinale non relevante. Désormais, le profil Copra en question et la frontière aval du groupe ne coïncident plus selon la direction de profilage. Ainsi, on peut espérer que les meshPoints à la frontière du groupe soient définitivement au complet et que l'erreur fatale sur le nombre variable d'éléments de contact soit définitivement éliminée.
Le module materialDataBase.py
est complété avec les paramètres matériaux identifiés rapidement à partir des courbes de traction fournies par le CRM.
La documentation est mise à jour et réécrite au format .docx. Le fichier html de Luc est supprimé puisque obslolète.
A la ligne 83 du module externalProgramPath.py
, j'ai corrigé le nom de clé 'GHOSTSCRIPT' qui était écrit erronément.
Correction du chemin de workspace pour le cas-test apps.remeshing2.semiAuto.beamBendingRotInit
afin que le worskpace soit correctement supprimé en fin de calcul dans la procédure de batterie.
removed : oo_nda.arcelor.doc.copraimport.html removed : oo_nda.arcelor.doc.copraimport_1.png removed : oo_nda.arcelor.doc.copraimport_2.png removed : oo_nda.arcelor.doc.copraimport_3.png added : oo_nda.arcelor.doc.Modèles numériques de profilage Lagrangien et Arbitraire Lagrangien Eulérien.docx renamed : arcelor.tools.copraRF.CpeCre.C-Channel -> arcelor.tools.copraRF.CpeCre.cChannel
added : oo_nda.arcelor.tests.copraLarge.cChannel.copra.cChannel_1.py added : oo_nda.arcelor.tests.copraLarge.cChannel.copra.cChannel_2.py added : oo_nda.arcelor.tests.copraLarge.cChannel.copra.cChannelALE_1.py added : oo_nda.arcelor.tests.copraLarge.cChannel.copra.cChannelALE_2.py added : oo_nda.arcelor.tests.copraLarge.cChannel.steelpro.cChannelALE_1.py added : oo_nda.arcelor.tests.copraLarge.cChannel.steelpro.cChannelALE_2.py
— Yanick Crutzen 2015/09/18