===== Commit 2016-11-08 =====

Robustification batterie (-fpe)
Elimination des blas dans systèmes petite taille
Simplification interface FrequencyAnalysis

===== Robustification batteries =====
Suite à la découverte d'une division par 0 dans le matrices de raideur numériques, j'ai rendu possible l'execution de la batterie avec l'option "fpe" (cad sans laisser au processeur la possibilité de gérer les divisions par 0, sqrt(neg), ... à travers des "NotANumber" "NaN"):
<code> 
metafor -fpe
metafor_d -fpe
python battery.py --fpe
python battery.py --debug --fpe 
</code>

La batterie ne passe pas entièrement en "-fpe" (pas encore tout corrigé), et sous linux, la batterie ne démarre même pas en "-fpe" => à corriger...

Le lancement de tests instables en debug et avec l'option "-fpe" m'a permis de retrouver bon nombre de bugs : 

==== MechanicalTimeIntegration::getThermalTheta() ====
  * le paramètre Theta est celui du schéma d'intégration "Point milieu généralisé" utilisé en thermique.
  * Lors de la suppression des MDE/MDR, la valeur par défaut est passée de 1.0 à 0.0 (or dans la matrice de raideur tangente numérique, on divise la vitesse nodale par ''getThermalTheta()'' )
  * la valeur par défaut (quand on n'utilise pas ce schéma) est remise à 1.0

==== ''mtMath::LineSearch'' ====
  * Correction du ''LineSearch'' de Romain : le test de sortie sur valeurs confondues a été déplacé juste avant calcul de la nouvelle valeur test (on évite ainsi un risque de division par 0.)

==== ''mtMaterial::PlasticCriterion'' ====
  * Remplacement du LineSearch à 2 points nécessitant le calcul des dérivées (pas très fiables les dérivées proche de la solution), par celui de Romain : classe ''LineSearch'' (à 3 points sans calcul de dérivées)

==== "ContinuousAnisoDamageEvpIsoHHypoMaterial" / "ContinuousDamageEvpIsoHHypoMaterial" : ====
  * Ces matériaux, font une résolution étagée de l'endommagement et de la plasticité via un poitn fixe : 
    * On résoud la plasticité à endo "d" constant 
    * On adapte la valeur de l'endo.
  * Or, il existait un test sur la valeur de l'endommagement (0 <= d < 1) en entrée de la boucle de Newton-Raphson sur le paramètre d'endo 'd', mais pas à l'intérieur. On se retrouvait donc parfois en cours de processus avec des valeurs de l'endommagement d >= 1 (ce qui n'est pas permis et entraine selon les cas, division par zéro ou racine carré de nombre négatif)
  * Un test sur la validité de la valeur de l'endo a été ajouté à l'intérieur de la boucle NR sur la valeur de l'endommagement 'd'. Si en cours de calcul 'd > dMax', on impose 'd = dMax' et vérifie la variation de d
    * si elle est croissante => la solution est dMax et on sort de la boucle
    * si elle est décroissante => c'est le NR qui a débordé du domaine admissible, on le relance sur base de la variation calculée à partir de 'd=dMax'
  * Cette correction permet de supprimer les tests failed de monosMaterials2

==== ''EvpIsoHDamageHypoMaterial'' :  Implémentation Gurson de Laurent Adam ====
  * Initialisation de l'incrément de plasticité "$\Gamma = 1.0e-4$" au lieu de "$\Gamma = 0.0$" qui induisait des divisions par 0.
  * Optimisation (to do) : "$\Gamma = GK.getGamma();$"
  * Remplacement de l'inversion du système de 5 équations à 5 inconnues suivie de la multiplication par le vecteur de déséquilibre, par un "directSolve"
  * Permutation des équations du système : Lorsque le système visco-plastique (Perzina) est dégénéré en plastique, le premier terme sur la diagonale du système à résoudre était 0. Un solveur de Gauss-Jordan avec pivot permettrait aussi de solutionner le problème (mais n'est pas actuellement dispo dans Metafor). L'équation risquant de dégénérer est déplacée en 5ème position du système (pivotage à priori de l'équation à risque)...
  * réduction des paramètres du schéma : 
  * #define IT_GAMMA_MAX 20 (200 par défaut)
  * #define MAXTRIAX 100.0 (5000.0 auparavant => fait exploser le cosh)
  * Grace à ces corrections, 
    * les monosMaterials2 passent désormais en Matrice de raideur semi-numérique (analytique au niveau de l'élément, numérique au niveau du matériau)
    * plus de failed 

==== PowerIsotropicHardening ====
  * la loi PowerIsotropicHardening nécessite une résolution itérative qui peut ne pas converger (souvent pour cause de valeur d'entrée $\overline{\varepsilon}^{vp}$ non physique, mais difficilement détectable).
   
$$
\sigma_{vm}= P_1 \left[ P_2 \sigma_{vm} + P_3 \overline{\varepsilon}^{vp} \right] ^{P_4}
$$

  * => ajout de gardien en cas de non convergence et envoie de l'exception  ''MaxIteReachedException();''induisant la division par 3 de la taille du pas de temps ...

==== SpectralOperations3D ====
  * ajout de tests sur les valeurs d'entrée des fonctions :
    * ''inv''
    * ''invSquare''
    * ''invSqrt''
    * ''squareRoot''
    * ''squareLog''
    * ''DSquareLog''
    * ''DSqrt''
    * ''DinvSqrt''
    * ''DinvSquare''
  * Actuellement, en cas de valeur d'entrée non valide, la fonction renvoie 0 (faut il un autre choix ? si quelqu'un a une idée ...)
  * 
==== To Do : suppression de ''computeInitialYieldingStress'' ====
  * la fonction ''HypoMaterial::computeInitialYieldingStress'' avait pour but de calculer la limite de plasticité dynamique en début de pas de temps pour calculer l'énergie dissipée. Or depuis que l'on a implémenté le calcul de la limite élastique dynamique (prenant en compte les aspects visco-plastiques), pour les écrouissages isotriopes, cette manière de faire est obsolète. => à remplacer par ''getMatFields(GPM0, IF_DYNAMIC_YIELD)''
  * Mais la fonction est encore nécessaire en evpMixtH
  * De manière générale, cette fonction est utilisée pour calculer la dissipation plastique (''IsoHypoMaterial::computeDissipatedEnergy''), via une seule méthode quel que soit le matériau.
C'est cette fonction ''computeDissipatedEnergy'' qui doit remonter dans chaque matériau et particularisée à chaque modèle matériau...


==== Blas : ====
  * Afin de pouvoir mixer la parallélisation via tbb pour les boucles principales, sans avoir de conflit avec les threads Blas, il est nécessaire de supprimer l'appel aux blas dans les fonctions appelées dans les boucles élémentaires.
  * Qui plus est, ces opérations étant généralement faites sur des petits vecteurs/petites matrices, l'utilisation des blas n'amène pas de gain de performances (l'intérêt des blas est principalement pour les grands système)
  * L'utilisation des blas reste évidemment intéressante dans les opérations de solveur (bien que même le skyline ne les utilises pas), d'analyse fréquentielle, ... Tout ce qui se fait au niveau du système global
=> il faut identifier les fonctions appelées au niveau global et les interfacer différement ...
    * Matrix::operator+=(Matrix & B) : remplacement de ''daxpy'' par l'opération + sur le stock
    * Matrix::operator-=(Matrix & B) : remplacement de ''daxpy'' par l'opération - sur le stock
    * Matrix::addBlas(Matrix & B, double factor=1.0) : nouvelle fonction interfacant ''daxpy'' : A += fact*B
    * Matrix::operator*=(double e) :  remplacemenet de ''dscal'' par l'opérateur * sur le stock
    * Matrix::factorn : remplacement de la fct ''daxpy'' pas des operations directes sur les valeurs
    * Matrix::factornBlas : Ancienne implémentation utilisant la fct ''daxpy'' 
    * Matrix::factorBlas(double precision) : idem Matrix::factor mais appelant factornBlas
    * mtMath::dyadic (Vector &A, Vector &B) :  remplacement de la fct ''dger''
    * mtMath::dyadicBlas(Vector &A, Vector &B) : ancienne implémentation utilisant ''dger''
    * SymMatrix::ADAt : suppression de la fonction ''ddot''
    * SymMatrix::ldltfactor(double relPrec) : suppression de la fonction ''ddot''
    * SymMatrix::cholfactor() : suppression de la fonction ''ddot''

  * To be continued (nécessite aussi un état des lieux des fonctions pouvant bénéficier des blas)
===== FrequencyAnalysis =====
  * Unification des interfaces ''FrequencyAnalysisValueExtractor'' et ''FrequencyAnalysisObjectiveFunction'' : 
    * Construction & configuration de l'objet que l'on veut calculer
    * passage à la ValueExtractor ou ObjectiveFunction 
    * permet la suppression des enum, la multiplication des fonctions de passage de variables
<code>
    freqAna = LanczosFrequencyAnalysisMethod(domain)
    freqAna.setNumberOfEigenValues(p['nbEigenVal'])
    freqAna.setSpectralShifting(p['spectralShifting'])
    freqAna.setComputeEigenVectors(True)
    freqAna.setComputeErrors(True)
    freqAna.setVerbose(p['verbose'])
    freqAna.setSymmetrizeK(False)
    
    if p['useDss'] == True :   
        try:
            freqAna.setSolver(DSSolver())
            print "OK : DSSolver found"
        except NameError:
            print "DSSolver not found. Use of default skyline instead"
            pass
    # Value Extractor
    freqAnaVE = FrequencyAnalysisValueExtractor(freqAna)    
    vm.add(no, freqAnaVE ,name)   
    # Objective Function
    freqAnalyFObj = FrequencyAnalysisObjectiveFunction(no, freqAna)
</code>
  * Ecriture de la doc user "frequencyAnalysis" [[doc:user:frequencyanalysis:use|]] (faut encore faire la doc scientifique)
  * 
===== mtWear =====
  * Correction des properties dans les WearMaterial (WEAR_ALPHA -> WEAR_ALPHA2) (thanks to Yanick)
==== InMemoryDataMatrix::interpolateRow ====
  * Pour améliorer l'initialisation de l'épaisseur d'abradable , j'ai ajouté une fonction pour les InMemoryDataMatrix permettant de récupérer les valeurs d'une matrice interpolée en fonction d'un vecteur d'abscisse. La fonction renvoie une ref vers un InMemoryDataVector
  * Dans le cas des tests d'interaction aube/carter, lors d'une première simulation, on calcule la déformation centrifuge de l'aube fonction de la vitesse de rotation du moteur (X(omega), R(omega)) en tout point de la tête d'aube.
  * Pour générer un carter pour la simulation d'interaction à une vitesse donnée (omega0), on a besoin de X(omega0) et R(omega0).
  * nb : la gestion mémoire de cette fonction est à vérifier (la fonction génère un MemoryLeak!!!). Idem pour les fonctions ''getRow(size_t indexI)'' et ''getColumn(size_t indexJ)''.

===== Divers =====
==== Opti ====
  * Ajout (yanick) de la possibilité de faire des analyses paramétriques en "execfile" (et plus uniquement en "meta")
==== CMake ====
  * Ajout de la config "win64-vs2012-student.cmake"
==== chkrep.py ====
  * Ayant noté que certains fichiers n'étaient pas tagué correctement dans SVN, j'ai reutilisé l'utilitaire de Romain "chkrep.py" qui détecte et corrige des problèmes de codage de fichiers (eol, props, format...).
  * IL EST INDISPENSABLE DE BIEN CONFIGURER TOUTES MACHINES A PARTIR DESQUELLES VOUS ALLEZ COMMITTER (windows ET linux): [[devel:svnconfig|]]
==== $Id$ ====
  * Beaucoup de fichiers avait une entête $Id$ "écrite à la main", avec erreur de syntaxe, ... 
  * rappel : dans un nouveau fichier, il suffit d'écrire ''$Id$'' (pas ''$Id: $'' ) et svn se charge automatiquement de compléter l'entête...


===== Fichiers ajoutés/supprimés =====
<code>
Adding: oo_meta\CMake\win64-vs2012-student.cmake  text/plain
Adding: oo_meta\mtFrequencyAnalysis\src\FrequencyAnalysisObjectiveFunction.cpp  text/plain
Adding: oo_meta\mtFrequencyAnalysis\src\FrequencyAnalysisObjectiveFunction.h  text/plain
Adding: oo_meta\mtFrequencyAnalysis\src\FrequencyAnalysisValueExtractor.cpp  text/plain
Adding: oo_meta\mtFrequencyAnalysis\src\FrequencyAnalysisValueExtractor.h  text/plain
Deleting: oo_meta\mtFrequencyAnalysis\src\FrequencyValueExtractor.cpp  
Deleting: oo_meta\mtFrequencyAnalysis\src\FrequencyValueExtractor.h  
</code>
===== Tests ajoutés/supprimés =====
<code>
Adding: 
Deleting: 
</code>

 --- //[[L.Papeleux@ulg.ac.be|Luc Papeleux]] 2016/11/08 //