===== Commit 2015-10-08 =====

===== Super-éléments =====
:!: :!: La nouvelle répartition des DDLs évoquée dans mon précédent commit ([[commit:2015:08_28|Commit 2015-08-28]]) n'a finalement pas lieu d'être. :!: :!:

La théorie dit bien que :
  - Calcul des //modes propres à interfaces fixes// -> analyse fréquentielle du modèle fin où **DDLs Retenus = DDLs Fixés**.
  - Calcul des //modes statiques de liaison// -> calcul des déformées de la structure condensée lorsqu'un **déplacement unitaire est imposé en un DDL Retenu** (les autres DDLs Retenus sont fixés à 0), et ce pour tous les DDLs Retenus.

==== SuperElement ====

  * Ajout d'une fonction ''fillMass()'' afin de pouvoir récupérer la matrice de masse du super-élément lorsqu'on fait une analyse fréquentielle d'une structure modélisée avec un super-élément.

<note>Notons que l'on n'avait pas besoin de cette fonction pour récupérer la matrice de masse du super-élément lors du calcul de la matrice jacobienne car on la récupérait via la méthode ''fillCorrectedImplicitDynamicTangentMatrix()'' implémentée dans la classe ''SuperElement''.</note>

==== Correction expression de la matrice de masse====

  * En redéveloppant à la main le calcul des matrices réduites K et M obtenues avec la méthode de Craig-Bampton, je me suis rendue compte qu'il y a avait une erreur dans l'expression du bloc ''MRR'' de la matrice de masse réduite.

<code>
  Original   : MRR = mRR + Psi^T . mCC . Psi + 2 * mRC . Psi
  Correction : MRR = mRR + Psi^T . mCC . Psi + (mRC . Psi)^T + mRC . Psi  
  
     MRR  |  MRN
M = ------------- est la matrice de masse du système réduit (super-élément),
     MNR  |  MNN
     
     mRR  |  mRC
m = ------------- est la matrice de masse du système non réduit (modèle fin),
     mCR  |  mCC
     
R = DDL Retenu, C = DDL Condensé, N = DDLs Mode propre à interfaces fixes,

Psi est la matrice des modes statiques de liaison.
</code>        

  * L'expression de la matrice de masse réduite obtenue avec la méthode de Guyan (condensation statique), qui est identique à la matrice ''MRR'' mentionnée ci-dessus, a également été corrigée.

==== CraigBamptonSuperElementValueExtractor ====
  * Erreur dans la fonction ''extract()'' qui impactait fortement les résultats obtenus en un noeud condensé.

  Original   : locel[j+nbContraintModes]
  Correction : locel[j+nbContraintModes+1]
  
==== ====


  
===== Analyse fréquentielle =====

==== MechanicalMatrices ====

  * La matrice ''freeConstrainedMass'' n'est pas symétrique => correction ''freeConstrainedMass = new StrMatrixBase(false, ...)'' dans la fonction ''fillFreeConstrainedMatrices()''.

==== Fichiers de sortie ====

  * Génération de deux fichiers grâce à une nouvelle fonction ''generateEigenResFiles()'' dans la classe ''FrequencyAnalysisMethod'' :
    - //eigenValues.txt// qui contient le nb de valeurs propres recherchées et les valeurs propores elles-mêmes. Ces résultats peuvent être comparés aux valeurs propres de référence calculées avec la fonction //eigs// de Matlab via le module ''mtFrequencyAnalysis.tests.matlab.matlabPostPro'' (cf. fichier //matlabEigenvalues.txt//).
    - //eigenVectors.txt// qui contient la liste des vecteurs propres associés. Pour cela, des ''StrVector'' sont créés à la volée (i.e., sans clé ''VariantID'', comme par exemple ''RE'') et la fonction ''StrVectorBase::write()'' est utilisée. De cette manière, la valeur du déplacement ''TX'', ''TY'', ou ''TZ'' est associée à un n° de noeud de la DB, ce qui est utile pour faire des comparaisons.

  * Les noms des fichiers qui contiennent les matrices K et M sont maintenant des arguments dans les fonctions ''matlabComputeEigenValues()'', ''matlabComputeAllEigenValues()'' du module ''mtFrequencyAnalysis.tests.matlab.matlabPostPro'' ainsi que dans les fonctions Matlab ''EigenValues()'' et ''AllEigenValues()''. C'est utile, en particulier, lorsqu'on fait l'analyse fréquentielle du super-élément puisque, dans ce cas, 4 fichiers sont générés :
      * 2 fichiers qui contiennent les modes propres à interfaces fixes de la structure et valeurs propres associées (phase de construction du super-élément),
      * 2 fichiers qui contiennent les valeurs et vecteurs propres résultants de l'analyse fréquentielle du super-élément (phase d'utilisation du super-élément).
  
==== Normalisation des modes propres====

  * Les vecteurs propres calculés avec la méthode de Lanczos (cf. ''LanczosFrequencyAnalysisMethod'') sont maintenant normalisés par rapport à la masse : ||x|| = (x<sup>t</sup>Mx)<sup>½</sup>. Notons que cette métrique était déjà utilisée dans la méthode de la puissance (cf. ''PowerIterationsFrequencyAnalysisMethod'').
  * Conséquences sur l'expression des matrices K et M du super-élément (modes propres à interfaces fixes normalisés à la masse) :
    - ''MNN'' = matrice identité de taille N, et
    - ''KNN'' = diag(ω<sub>1</sub>², ..., ω<sub>N</sub>²).

==== Modes de corps rigides ====

  * **Technique du spectral shifting :** Cette technique permet de réaliser l'analyse fréquentielle d'une structure qui présente des modes de corps rigides (e.g., poutre Libre/Libre). La matrice de rigidité associée étant singulière, elle consiste à résoudre le système ''(K - μ M) x = (ω²-μ) M x'', où μ est un scalaire, au lieu du système initial ''K x = ω² M x''. Ce nouveau système est quant à lui inversible, pour un choix judicieux de la valeur μ. Selon Géradin, μ doit être négatif lorsqu'on est en présence de modes rigides.

  * **Valeur du spectral shifting** : J'ai réalisé une étude sur la valeur à prendre en compte lorsque la structure analysée présente des modes de corps rigides. L'étude a été réalisée sur le cas-test ''beam3DFreeSri.py'' du module ''mtFrequencyAnalysis'' (maillage EF fin classique). Ce cas-test consiste en l'analyse fréquentielle d'une poutre 3D Libre/Libre par la méthode de Lanczos. Les résultats obtenus pour chaque valeur de µ testée correspondent aux 10 plus petites fréquences propres du système, et sont comparés à celles calculées avec Matlab. Cette étude a montré que :
    * µ > 0 -> les modes de corps rigides ne sont pas prédits
    * µ < 0 -> les modes de corps rigides sont correctement prédits (valeurs testées : -10, -100, -1000, -1e4, -1e5, -1e6)
    * Plus µ est petit, plus les valeurs propres calculées sont proches de la référence.
    * Plus µ est petit, plus l'algorithme est stable. En effet, pour une même valeur du shift, les résultats obtenus pour 2 calculs successifs peuvent être très différents si le shift est proche de zéro (par valeur négative). Ce phénomène disparaît pour des petites valeurs de µ.
    * La valeur du spectral shifting choisie pour la suite est ''µ = -1e6''.

==== Taux de remplissage des matrices ====

<note> Attention, lorsqu'une analyse fréquentielle est réalisée sur le super-élément, le taux de remplissage des matrices affiché peut être erroné ! En effet, les matrices K et M du super-élément sont des matrices pleines, et des taux de remplissage > à 100% peuvent apparaître (ex : si K est une ''SkyLineMatrix'', l'espace mémoire réservé aux éléments diagonaux est alloué 2 fois, dans ''situ'' et dans ''sitl''). </note>

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

  * Module ''mtFrequencyAnalysis'' :
    - Ajout d'un ''generateEigenResFiles()'' dans le cas-test de base ''beam3DFreeSri.py''
    - Modification de la valeur du //spectral shifting// à µ=-1e6 dans les cas-tests : ''beam3DFreeSriShift.py'', ''beam3DFreeSriDssShift.py'', ''beam3DFreeEasShift.py'', et ''beam3DFreeEasDssShift.py''.

  * Module ''mtSuperElement'' :
    - ''Beam2DFreqAnalysis.py'' et ''Beam3DFreqAnalysis.py'' -> Analyse fréquentielle d'une poutre Encastrée/Libre modélisée avec un super-élément de Craig-Bampton.
    - ''Beam2DFreqAnalysisFree.py'' et ''Beam3DFreqAnalysisFree.py'' -> Analyse fréquentielle d'une poutre Libre/Libre modélisée avec un super-élément de Craig-Bampton.
    - ''Beam2DTri.py'' et ''Beam3DTetra.py'' -> Calcul des vibrations libres d'une poutre Encastrée/Libre modélisée avec un super-élément de Craig-Bampton construit à partir d'un modèle EF fins triangulaire (ou tétrahédrique) et non quadrangulaire (ou hexahédrique) comme les autres cas-tests.

<note important>
Analyse fréquentielle du super-élément : l'affichage des modes propres obtenus n'est pas correct pour l'instant.
</note>

  * Module ''toolbox'' :
    - Ajout d'une variable ''tetra'' dans la fonction ''createCube()'' de ''meshedGeometry3D.py'' qui vaut 0 par défaut et qui permet la construction d'un cube maillée avec des tétrahèdres s'il vaut 1.



===== Fichiers ajoutés/modifiés/supprimés =====
<code>
Modified : oo_meta\mtFrequencyAnalysis\src\FrequencyAnalysisMethod.h
Modified : oo_meta\mtFrequencyAnalysis\src\FrequencyAnalysisMethod.cpp
Modified : oo_meta\mtFrequencyAnalysis\src\LanczosFrequencyAnalysisMethod.cpp
Modified : oo_meta\mtFrequencyAnalysis\src\MechanicalMatrices.h
Modified : oo_meta\mtFrequencyAnalysis\src\MechanicalMatrices.cpp

Modified : oo_meta\mtSuperElement\src\SuperElement.h
Modified : oo_meta\mtSuperElement\src\SuperElement.cpp
Modified : oo_meta\mtSuperElement\src\CraigBamptonSuperElement.cpp
Modified : oo_meta\mtSuperElement\src\CraigBamptonSuperElementValueExtractor.cpp
Modified : oo_meta\mtSuperElement\src\GuyanSuperElement.cpp

Modified : oo_meta\toolbox\meshedGeometry3D.py
Modified : oo_meta\mtMath\CSRMatrix.cpp
</code>

===== Tests ajoutés/supprimés =====
<code>
Added: oo_meta\mtSuperElement\tests\Beam2DFreqAnalysis.py
Added: oo_meta\mtSuperElement\tests\Beam2DFreqAnalysisFree.py
Added: oo_meta\mtSuperElement\tests\Beam3DFreqAnalysis.py
Added: oo_meta\mtSuperElement\tests\Beam3DFreqAnalysisFree.py
Added: oo_meta\mtSuperElement\tests\Beam2DTri.py
Added: oo_meta\mtSuperElement\tests\Beam3DTetra.py
</code>

 --- //[[Claire.Hennuyer@ulg.ac.be|Claire Hennuyer]] 2015/10/08 //