Dans le cadre de la simulation en formalisme ALE du procédé de profilage de type continu, une fois la solution stationnaire calculée, la partie du maillage dans la zone de sortie (en aval) se doit d'être libérée de l'emprise de la machine et des conditions aux limites imposées à la frontière eulérienne aval (flux de matières imposé). En effet, la découpe dans la zone de sortie et le calcul du retour élastique suite à cette découpe sont des opérations finales indispensables dans nos modèles numériques. L'idée, pour ce faire, est de désactiver des éléments de l'interaction afin d'isoler la partie en sortie de la machine.

Bref, cette révision de METAFOR supporte l'activation et/ou désactivation d'éléments d'interaction par stages en prévision du prochain commit Copra. Ce dernier permettra, entre autres, d'enchainer la simulation en formalisme ALE du profilage avec le calcul du retour élastique en formalisme Lagrangien après la désactivation des éléments finis à l'intérieur de la machine.

Quatre possibilités d'implémentation ont été envisagées :

1. Redéfinir spécifiquement la méthode setStage(Stage &stage) de la classe FieldApplicator au sein du jeu de données Python du modèle de profilage. Bien que la désactivation d'éléments sur base d'un critère géométrique soit simple à implémenter, cette approche ne permet aucune autre perspective d'usage et est donc écartée.
2. Compléter la classe Activable par les méthodes deactivate(Stage *stage, Group *group) et activate(Stage *stage, Group *group). De toute évidence, ce choix d'implémentation ouvre la porte à l'activation et la désactivation sous cette forme pour les classes Loadings, Rezoner et DofFlagCmd. Elles seraient dès lors à définir. Cette méthode peut aussi paraître confuse pour l'utilisateur : sous la forme app.deactivate(), nous écrivons explicitement une désactivation d'interaction alors que l'interaction est en fait bien active et contient des éléments partiellement désactivés.
3. Dériver la classe Group de Activable. Toutefois, nous amenons une dépendance cyclique entre les modules mtGeo et mtFEMBase que nous ne pouvons résoudre. De plus, conceptuellement, un groupe dans METAFOR se définit par ses meshPoints et non ses éléments. Cette implémentation ne traduit donc pas une activation/désactivation d'un ensemble d'éléments dans METAFOR qui est l'objet de ce commit. Enfin, la désactivation de meshPoints ou d'entité géométrique n'a pas lieu d'être.
4. L'implémentation finalement retenue est d'enrichir la classe Interaction avec les deux méthodes ci-dessous. Ainsi, la nouvelle fonctionnalité est restreinte aux seules interactions et son intégration est regroupée en un seul endroit du code.
   • activateElementsFromGroup(Stage *stage, mtGeo::Group *grp)
   • deactivateElementsFromGroup(Stage *stage, mtGeo::Group *grp).

Deux cas-tests validant la nouvelle fonctionnalité sont ajoutés dans la batterie.

Depuis que la batterie contient quelques cas-tests exécutés en parallèle, nous avons pu remarquer qu'il n'était plus possible de lancer un cas-test de type enchaînement (c'est-à-dire comportant en son nom le caractère underscore suivi d'un chiffre) et a fortiori avec le script launch.py puisque ce dernier est une interface pour battery.py. Concrètement, une commande du type : python battery.py rerun apps.complex.tay2dExpRes_2 ne lançait pas à nouveau le cas-test. Ce dernier était en effet purement ignoré et aucun fichier .res correspondant n'était regénéré.

Pour corriger le problème, l'attribut self.lasts de la classe Battery est réinitialisé après la première boucle sur les modules exécutés en parallèle. Ainsi, un cas-test de type enchaînement n'est plus ignoré lors de la seconde boucle sur les modules exécutés en série.

Suite à cette correction, le comportement de launch.py en particulier n'était toutefois pas conforme à nos attentes. En effet, si nous considérons un cas-test par enchaînement, seul le cas-test encodé précisément dans l'interface de launch.py était ajouté dans la liste des cas-tests de type execfile. Les autres cas-tests de la même série étaient dès lors exécutés pour leur part automatiquement avec la classique commande meta(). Désormais, la détection d'une série de cas-tests par enchaînement est ajoutée dans launch.py de la même manière que dans battery.py. Dans ce cas précis, le chemin du module suivi d'un astérisque est ajouté à la liste des chemins exécutables de l'objet battery. Dans la méthode runModule() de battery.py, la méthode find() de Python est désormais remplacée par la méthode fnmatch() qui permet de prendre en compte dans la recherche le métacaractère “*” tel que sous Unix.

Toutefois, du point de vue de Luc, la possibilité de lancer un unique cas-test de type enchaînement devrait être permise avec launch.py (comme c'était originellement le cas, i.e. avant que launch.py ne devienne une interface de battery.py ?). En d'autres termes, la série complète ne devrait pas être lancée si l'utilisateur ne le demande pas. Pour ce faire, Luc propose d'éliminer la détection automatique des séries de cas-tests par enchaînement dans battery.py et de traiter ces derniers avec une liste de répertoires définie a priori. Cette idée n'est, à ce stade, pas implémentée. Néanmoins, il n'est pas inutile de rappeler que launch.py, depuis qu'il est une interface de battery.py, lance uniquement les cas-tests pour lesquels un fichier .res associé ne peut être trouvé dans le répertoire du module. Ainsi, la série complète n'est pas nécessairement lancée.

Dans le fichier AleMethod.ccp, la méthode ALE est désormais effectivement initialisée dans le cas où elle n'est pas active (enabled()). Cela permet de passer du formalisme ALE au formalisme Lagrangien lors d'un restart. Un cas-test est ajouté dans la batterie pour le valider.

Le fichier spring.cmake est mis à jour conformément au fichier thorgal.cmake. Luc a installé les librairies CGAL sur la station spring. Les batteries peuvent à nouveau être lancées sans problème sur spring.

 
A : apps.complex.aleCoin3d_3.py
A : apps.qs.poutre2dCutEp2.py

— Yanick Crutzen 2015/06/12