===== Commit 2016-06-13 =====

Améliorations de la structure des super-éléments dans Metafor.

L'objectif est de pouvoir appliquer une **précontrainte** sur le modèle FEM à partir duquel le super-élément est ensuite construit. Le cas de la **construction d'un super-élément à une vitesse donnée non nulle** nous intéresse tout particulièrement dans le cadre du projet Abrawal.

Les étapes de création et d'utilisation ont donc été modifiées par rapport à ce qui a été initialement proposé au commit précédent ([[http://metafor.ltas.ulg.ac.be/dokuwiki/commit/04_07|Commit du 07 Avril 2016]]).

===== Modifications apportées à la nouvelle structure =====

==== Précontrainte et création d'un super-élément ====

Typiquement, le jeu de données dans lequel le super-élément est créé consiste en un calcul de mise en rotation centrifuge du modèle FEM classique. Lorsque la vitesse cible est atteinte, i.e. à la fin du calcul, la création du super-élément est lancée via une **fonction objective**. Notons que la construction d'un super-élément à vitesse nulle (i.e., n'ayant subit aucune précontrainte) peut être lancée directement dans le fichier de création .py, ou via une fonction objective également.

<note> Dans l'objectif de pouvoir construire un **super-élément à vitesse variable** (cf. //[Sternchüss et al., 2006]// et //[Legrand et al., 2011]//), il serait plus efficace de balayer une gamme de vitesses et de lancer la création d'un super-élément à différentes vitesses lors du même calcul.

Pour l'instant, **1 calcul** = construction d'un (ou plusieurs) super-élément(s) à **1 vitesse donnée**, cependant cela est possible en créant un ''PythonValueExtractor''.</note>

La précontrainte du modèle et la création d'un super-élément se déroulent de la manière suivante :
  - //Construction du modèle FEM :// création des différentes interactions, en s'assurant que le domaine associé au futur super-élément soit défini par __une interaction au moins__
    - Par ex, dans le cas d'une condensation du pied d'une aube par un super-élément, le modèle FEM sur lequel repose la construction du super-élément doit au moins contenir un ''FieldApplicator'' pour les éléments constituant le pied.
  - //Création de groupes de nœuds RETENUS// qui serviront à l'utilisation du super-élément pour l'application de conditions aux limites => **Peut être fait au moment de la création ou de l'utilisation**, mais c'est plus facile au moment de la création car on a accès à la géométrie du modèle FEM.
  - //Création de groupes de nœuds CONDENSES// pour lesquels on souhaite extraire une donnée au moment de l'utilisation (ex : déplacement selon X) => **Doit être fait au moment de la création**.
  - Définition de la //mise en rotation centrifuge// (schéma d'intégration, conditions aux limites, vitesse de rotation, etc.)
  - //Appel à la fonction objective// **createSuperElement** -> 1 appel à la fonction createSuperElement = création d'1 super-élément

Pour rendre possible la création d'un super-élément sur un modèle précontraint, il a fallu :
  - créer un nouveau DofFlag, et
  - modifier les MechanicalMatrices, en conséquence.

==== Implémentation d'un nouveau DofFlag ====

  - Ajout d'un nouveau flag ''belongingToSuperElem'' dans la classe ''DofFlags'', en plus du flag ''fixed'' :
    * Il permet d'identifier les DDLs qui appartiennent au domaine du futur super-élément parmi tous les DDLs du modèle FEM si ''belongingToSuperElem = true'' (DDLs associés aux noeuds rouges sur la Fig. 1). De cette manière, il est possible de récupérer les blocs des matrices k et m du modèle FEM associés à ces DDLs uniquement nécessaires au calcul des matrices réduites du SE.
    * Le flag vaut ''false'' par défaut, et est fixé à ''true'' grâce à la commande ''setSuperElementNodes''
    * A ce stade de la création du super-élément, les DDLs tels que''belonginToSuperElem = false'' (DDLs associés aux noeuds noirs sur la Fig. 1) n'ont pas d'intérêt.
  - Implémentation d'une nouvelle classe ''BelongingToSEDofsSet'', écrite de manière similaire à ''FixationSet'', qui permet de gérer les flags ''belongingToSuperElem'' des DDLs du modèle.

{{ :commit:futur:poutre_encastree_libre-2.png?nolink&500 |}}

==== Modifications des MechanicalMatrices ====

  * Grâce à ces deux flags, 4 partitions ont pu être créées dans la connexion de ''MechanicalMatrices'', permettant ainsi d'écrire les matrices k et m associées au modèle FEM sous la forme de 16 blocs :

{{ :commit:futur:blocsnouvellepartition.png?nolink&600 |}}

  * Parmi les DDLs appartenant au super-élément (i.e., tels que ''belongingToSE = true''), les DDLs Retenus sont donc identifiés en imposant ''fixed = true'' grâce à la fonction ''setRetainedNodes'' (DDLs associés aux noeuds bleus dans la Fig. 2). Il est donc possible de récupérer les différents blocs kRR, mRR, kRC, mRC, etc. pour le calcul des matrices de rigidité et de masse réduites du SE.

{{ :commit:futur:poutre_encastree_libre-3.png?nolink&500 |}}

  * Notons que pour un calcul correct des MechanicalMatrices, il est nécessaire de calculer les forces internes via la fonction ''forcesComputation''.

  * Des nouvelles fonctions ''updateInter'' dans ''StrMatrixBase'', et ''generalForceInter'' dans ''StrVector'' ont du être implémentées afin de calculer correctement les différentes matrices et vecteurs intervenant dans MechanicalMatrices.\\ => Calcul **uniquement** sur les éléments appartenant aux interactions qui définissent le futur super-élément. Les fonctions par défaut, ''update'' et ''generalForce'', parcourent toutes les interactions.

  * Notons que cette nouvelle définition des ''MechanicalMatrices'', et donc cette nouvelle décomposition en 4 partitions, est également utilisée lors d'un calcul d'analyse fréquentielle sur un modèle FEM classique. Un flag booléen ''thereIsBelongingToSEDofs'', dont la valeur est fixée en fonction du nombre de DDLs dont belonginToSuperElem = true, a donc été mis en place afin de différencier ces deux cas.

==== Création du super-élément à vitesse non nulle ====

La création proprement dite du SE, dans l'état précontraint, se décompose en plusieurs étapes :
    * Création de l'interaction ''Guyan/CraigBamptonSuperElementInteraction'' n°<no>, qui ne sera pas ajoutée à l'interactionSet du domain.
    * Définition du nb de modes propres à interfaces fixes (Craig-Bampton) -> ''setNumberOfEigenValues''
    * Association du domaine FEM à l'interaction créée -> ''setDomain''.
    * Fixation de ''superElemBuiltFlag'' à ''False'' -> ''setSuperElemBuiltFlag''
    * Association de toutes les interactions qui définissent le futur SE à l'interaction ''Guyan/CraigBamptonSuperElementInteraction''. Le but est de calculer correctement les différents blocs des matrices k et m du modèle FEM, sur lesquelles le calcul des matrices réduites K et M est basé -> ''addInteraction'' puis ''setSuperElementNodes''

<note>Les matrices k et m du modèle FEM, à partir desquelles les matrices réduites vont être construites, prennent en compte le raidissement centrifuge du à la mise en rotation préalable du modèle FEM.</note>

    * Détermination des nœuds **Retenus** -> ''setRetainedNodes''
    * Création du fichier de sauvegarde ''superElement<no>.py'' qui sera exécuté lors de l'importation du super-élément -> ''createPyFileForSuperElemUse'' \\ => Le n°<no> est le UserNo de l'interaction "super-élément" qui sera créée au moment de l'utilisation du SE ; à chaque n°<no> correspond 1 super-élément.
    * Sauvegarde des groupes de noeuds RETENUS dans le fichier ''superElement<no>.py'' -> ''groupsNodesToSave''
    * Création de l'objet ''Guyan/CraigBamptonSuperElement'' -> ''generateElements()''
    * Calcul des matrices réduites et sauvegarde du super-élément -> ''computeSuperElement()''
    * Mise à jour des flags ''belongingToSuperElem'' à ''false'' dans le cas où un autre super-élément est construit dans le même calcul -> ''clearSuperElementNodes()''
    * Sauvegarde des valeurs des modes statiques de liaison et des modes propres à interfaces fixes (Craig-Bampton) des DDLs Condensés dans le fichier ''superElement<no>.py'' -> lancée via la construction des ''Guyan/CraigBamptonSuperElementValueExtractor'' => **Doit être fait après computeSuperElement()** car le super-élément créé doit avoir été ajouté à l'elementSet de l'interaction.

==== Sauvegarde du super-élément ====

Le super-élément ainsi construit est sauvegardé dans le sous-dossier **<currentWorkDirectory>/Creation** au travers des **deux** fichiers de sortie suivants :
  * **step_SE_<no>.gz** -> fichier binaire qui contient toutes les données du super-élément construit :
    * Nombre de noeuds
    * Nombre de DDLs
    * Matrice réduite K
    * Matrice réduite M
    * Nombre de modes statiques de liaisons (= nombre de DDLs Retenus)
    * Modes statiques de liaisons
  * **superElement<no>.py** -> fichier python qui sera exécuté au moment de l'importation du super-élément
    * Définition d'une classe ''SuperElementImporter'', dans le même esprit que ''BaconImporter'' pour l'importation de maillages provenant de Samcef.
    * ''setIndex'' -> mise en place d'un index dans l'objectif de pouvoir importer plusieurs fois le même super-élément (i.e., à partir du même fichier de sauvegarde) puis d'appliquer une transformation géométrique différente à chaque super-élément importé (ex : construction d'un modèle de roue aubagée complète à partir d'un seul super-élément pâle créé, importation et rotation du super-élément en fonction de la position de l'aube).
    * ''readGroupsNodes'' -> sauvegarde des groupes de nœuds Retenus.
    * ''execute'' -> sauvegarde des positions et des UserNo des nœuds Retenus.
    * ''modesValuesGroup<No><Nature><Variant>'' -> sauvegarde des valeurs des modes statiques de liaison et des modes propres (dans le cas Craig-Bampton) pour la composante (<Nature>,<Variant>) de chaque nœud appartenant au groupe n°<No>.

==== Utilisation du super-élément créé ====

Les différentes étapes à réaliser dans le jeu de données pour utiliser le super-élément précédemment créé sont les suivantes :
  * Importation du super-élément stocké dans le sous-dossier **<currentWorkDirectory>/Creation** via la classe python ''SuperElementImporter'' :
    * Création des groupes de nœuds retenus précédemment stockés.
    * Création des noeuds du super-élément (meshpoint) via la nouvelle fonction ''defineSE'' implémentée dans la classe ''mtGeoPointSet''.

<note>La fonction **defineSE(no, x, y, z)** est définie comme suit :\\ -> Création et ajout au pointSet si pas de meshpoint ayant no comme UserNo,\\ -> Récupération s'il existe déjà un meshpoint ayant no comme UserNo dont les coordonnées sont identiques à (x, y, z).\\ \\ Notons que le cas où un meshpoint ayant le même numéro existe déjà mais dont les coordonnées sont différentes de (x, y, z) n'est pas géré pour l'instant.</note>

<note>Le UserNo des noeuds du SE est défini à partir du UserNo dans le modèle FEM + un index.</note>

    * Création du volume (resp. de la side) géométrique dont le UserNo correspond au numéro du fichier de sauvegarde (i.e., au UserNo de l'interaction SE).
    * Création de la cellule élémentaire associée au super-élément via :<code> mesh.define(UserNo, CELL_SE_VOLUME, SEVolume, vecSuperElementPoints)</code> où ''SEVolume'' correspond au volume géométrique sur lequel va reposer la cellule élémentaire, et ''vecSuperElementPoints'' correspond au vecteur des points topologiques de la cellule, i.e. les noeuds retenus.
  * Création de l'interaction ''Guyan/CraigBamptonSuperElementInteraction'', qui sera ajoutée à l'interactionSet du domaine cette fois-ci. Notons que le UserNo associé doit correspondre au même numéro qu'à la création, i.e. le numéro du fichier de sauvegarde, afin de pouvoir charger le SE.
  * Définition du nb de modes propres (Craig-Bampton)
<note> Pour plus de sécurité, le nb de modes propres devrait être lu dans le fichier de sauvegarde... à faire.</note>
  * Fixation de ''superElemBuiltFlag'' à ''True'', cette fois-ci
  * Définition du type d'élément via addProperty(Volume2DElement ou Volume3DElement)
<note> On fait comme ça pour l'instant, mais un nouveau type d'élément, au même titre que VolumeElement ou ShellElement, devra être créé. On pourra ainsi définir les propriétés des éléments de l'interaction super-élément via ''prp = ElementProperties(Guyan) ou ElementProperties(CraigBampton)''.</note>
  * Association du support géométrique (''SEVolume'' ou ''SESide''), créé lors de l'importation du super-élément, à l'interaction via un ''push''.
  * Définition des conditions aux limites via les groupes de noeuds Retenus, du type d'intégration et tous les paramètres classiques de calcul.
  * Ajout d'extracteurs au ValuesManager :
    - l'extraction de données en un noeud **Retenu** se fait via un ''DbNodalValueExtractor'', et
    - l'extraction de données en un noeud **Condensé** se fait via les fonctions ''modesValuesGroup<No><Nature><Variant>'' dans lesquelles un extracteur ''Guyan/CraigBamptonSuperElementValueExtractorUse'' est créé et est ajouté au valuesManager.
  * Les résultats obtenus avec le modèle contenant le super-élément sont stockés dans le sous-dossier **<currentWorkDirectory>/Use**.


<note important>Attention, pas d'erreur générée dans le cas où le type de super-élément ou le nombre de modes propres dans le cas CB fixées dans le jeu de données "utilisation", ne correspondent pas à ceux du super-élément créé !</note>
===== Cas-tests mtSuperElement =====

  * Ajout de nouveaux cas-tests d'analyse fréquentielle d'une poutre 3D libre-encastrée modélisée en deux demi-poutres pour tester des modèles mixtes FEM/SE, mais aussi des modèles SE/SE : ''Beam3DFreqAnalysisCBCB'', ''Beam3DFreqAnalysisGCB'', ''Beam3DFreqAnalysisCBFem'', etc. Toutes les combinaisons possibles ont été testées et ajoutées à la batterie.
  * Le cas-test ''Beam3DFYAmp'' qui teste le super-élément de Craig-Bampton pour des grandes amplitudes de vibration a été repassé en SRI, car il a beaucoup de mal à converger en EAS (3557 step en EAS au lieu de 800 en SRI), et prend beaucoup de temps pour la batterie.\\ => //Voir si c'est normal//.
  * Problème au niveau de la destruction lorsqu'on utilise un **DSSolver** pour tous les cas-tests avec super-élément de Craig-Bampton\\ => //Pas encore réglé//.

===== Cas-tests abrawal =====

Modification des cas-tests ''bladeCasingEngagementFSEGuyan'' et ''bladeCentrifugeLoadBSECraig'' de la batterie :
  * Le fichier de création ''..._1.py'' correspond à la mise en rotation centrifuge du modèle FEM complet via un shéma quasi-statique puis à la création d'un super-élément pâle (dans le cas FSEGuyan) ou pied (dans le cas BSECraig) lorsque la vitesse a été atteinte.
  * Les fichiers d'utilisation ''..._2.py'' ont été mis en FAILED volontairement car des modifications doivent encore être faites.
    - Calcul de la déformation centrifuge (la raideur étant déjà prise en compte) -> calcul des forces centrifuges appliquées aux noeuds Retenus au moment de la construction du super-élément, puis application de ces forces aux noeuds Retenus en tenant compte des éléments FEM classiques attachés au SE, qui eux sont mis en rotation de manière classique via l'''initialBalancing'' et les propriétés ''OMEGA''.
    - Prise en compte de l'amortissement dans le super-élément (amortissement structural). Les premiers tests effectués sur le banc18ER où la pâle (sans pied) a été condensée (sauf une couche d'éléments en contact avec l'abradable) ont montrés qu'il faudra gérer l'amortissement du super-élément.
===== Fichiers ajoutés =====
<code>
Added: oo_meta\mtFEMBase\BelongingToSEDofsSet.h
Added: oo_meta\mtFEMBase\BelongingToSEDofsSet.cpp
</code>

===== Cas-tests ajoutés/renommés =====
<code>
Renamed: mtSuperElement\tests\Beam2DCompTX_FX_1.py -> Beam2DCompTXFX_1.py
Renamed: mtSuperElement\tests\Beam2DCompTX_FX_2.py -> Beam2DCompTXFX_2.py
Renamed: mtSuperElement\tests\Beam2DCompTX_FY_1.py -> Beam2DCompTXFY_1.py
Renamed: mtSuperElement\tests\Beam2DCompTX_FY_2.py -> Beam2DCompTXFY_2.py
Renamed: mtSuperElement\tests\Beam2DCompTY_FX_1.py -> Beam2DCompTYFX_1.py
Renamed: mtSuperElement\tests\Beam2DCompTY_FX_2.py -> Beam2DCompTYFX_2.py
Renamed: mtSuperElement\tests\Beam2DCompTY_FY_1.py -> Beam2DCompTYFY_1.py
Renamed: mtSuperElement\tests\Beam2DCompTY_FY_2.py -> Beam2DCompTYFY_2.py
Renamed: mtSuperElement\tests\Beam3DCompTX_FY_1.py -> Beam3DCompTXFY_1.py
Renamed: mtSuperElement\tests\Beam3DCompTX_FY_2.py -> Beam3DCompTXFY_2.py
Renamed: mtSuperElement\tests\Beam3DCompTY_FX_1.py -> Beam3DCompTYFX_1.py
Renamed: mtSuperElement\tests\Beam3DCompTY_FX_2.py -> Beam3DCompTYFX_2.py

Added:  mtSuperElement\tests\Beam3DFreqAnalysisCBCB_1.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisCBCB_2.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisCBFem_1.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisCBFem_2.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisCBG_1.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisCBG_2.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisFemCB_1.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisFemCB_2.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisFemG_1.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisFemG_2.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisGCB_1.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisGCB_2.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisGFem_1.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisGFem_2.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisGG_1.py
Added:  mtSuperElement\tests\Beam3DFreqAnalysisGG_2.py

Added: oo_meta/mtSuperElement/tests/tools/postObjectiveFunctions.py
Added: oo_meta/mtSuperElement/tests/tools/utilities.py

Added: oo_nda/abrawal/banc18ER/tools/bladeCentrifugeLoadBuildSE.py
</code>

 --- //[[claire.hennuyer@ulg.ac.be|Claire Hennuyer]] 2016/06/13//