===== Commit 2013-05-14 =====

Abrawal + Divers


===== Abrawal =====

** Bancs UCL ** 
  * Ajout des tests représentatifs des 2 bancs UCL : 
    * Banc d'abradabilité (reshaping du banc TA) basé sur un principe similaire à celui de Sulzer d'une lame tournant à haute vitesse venant user une plaque (courbe ou plane) d'abradable en translation.
    * Tribomètre : système pion - disque avec un pion en lame de tournevis et un disque recouvert d'abradable
  * C'est juste un premier modèle : maintenant faut le faire tourner et analyser le comportement ...

  * Modification des initialisations de l'abradable 
    * robustification des tests d'initialisation ovale pour un abradable en cylindre de révolution (l'ovalisation était déjà dispo depuis la version 1712)
    * Ajout d'usure en "bord" des abradables en side classiques (coons) : sinon on risque de générer des chocs àla prise de contact

** Extractors **
  * Ajout de 2 extracteurs de moment de forces : 
    * MomentValueExtractor : calcul une composante (X, Y ou Z) du moment des forces par rapport à un point de l'espace
    * Moment2AxeValueExtractor : Calcul le moment des forces autour d'un axe (le couple quoi !!!)
  * Ajout d'un incRef/decRef sur le GObject Target de ''NodalValueExtractor''




 ===== Divers =====
** NortonHoffPHypoMaterial ** 
  * Correction d'un bug pervers dans le ''NortonHoffPHypoMaterial'' (Attention il y a un ''P'') : 
    * La batterie plantait sous windows au moment de la désallocation mémoire 
    * Le test dans Metafor.exe / Metafor_d.exe ne plantait pas / Les batterie Linux ne montraient pas d'erreur
    * Il n'est pas possible de lancer la batterie sur une version debug de Metafor
    * Les outils de debug memoire (valgrind, intelInspector) n'ont pas montré de solution évidente
    * Finalement, je me suis souvenu qu'on pouvait lancer Metafor au travers de Python via les anciennes commandes load('apps.qs.cont2'), meta(), quit() en Release et en Debug
    * Le bug : 
      * Yves a ajouté un GKState spécifique à son matériau : ''NortonHoffPHypoGpkState''
      * à chaque utilisation du matériau, il caste bien le ''MechanicalGKState *'' en ''NortonHoffPHypoGpkState *'' (static cast vu que tout doit être bon, on ne va pas vérifier à chaque fois que la classe est du bon type)
      * Malheureusement il a oublié de dériver la fonction ''allocGKState()'' définissant le type d'objet à allouer (donc il allouait un ''HypoGpkState'' en lieu et place du ''NortonHoffPHypoGpkState'')
      * Malheureusement 2 : le ''NortonHoffPHypoGpkState'' ne rajoutant que 2 doubles à sa classe mère, le débordement mémoire n'écrasait rien d'important (sauf manifestement des info relatives au destructeur)
     * Conclusion : il faut qu'on mette en place un système de vérification au runtime de la bonne allocation des GP/GKStates (via un Dynamic Cast n'intervenant qu'1 fois ou en définissant une macro sur les Static Casts des matériaux qui deviendraient dynamiques en debug par exemple). 
     * Tout autre idée, à discuter, pour fiabiliser le process est la bien venue (et si qqn veut s'en charger, il est aussi le bien venu)


** PythonOneParameterFunction - PythonDirectorOneParameterFunction ** 
  * Dans mes recherches relatives à la problématique ''NortonHoffPHypoMaterial'' une question s'est posée sur la gestion memoire des ''PythonOneParameterFunction'' qui est une classe où Romain avait implémenté "à la main" un mécanisme similaire au mecanisme de director lorsque celui ci n'était pas encore fiable/utilisable/implémenté (biffer la mention inutile) dans Swig.
  * On s'est donc posé la question de savoir si il n'y avait pas une interaction entre la gestion memoire "à la main" et le director (ce n'était finalement pas ca la cause du chmilblick)
  * On s'est aussi posé la question de la pertinence de la classe ''PythonOneParameterFunction '' maintenant que le mécanisme de director fonctionne et est plus en phase avec l'esprit orienté objet
  * Conclusions : 
    * PythonOneParameterFunction : n'est plus une classe director (retour à l'état avant vers 1721)
    * PythonDirectorOneParameterFunction : nouvelle classe Director de OneParameterFunction (dérivez vos 4 fonctions selon l'usage: evaluate, computeDerivation, computeIntegration(t1), computeIntegration(t0,t1) )
    * Les tests fluidMaterial.tests.kP_NH et mu_NH sont réécrit en utilisant cette methodologie de même que le test apps.ale.pyReZoner (utilisation de la fonction dans un mailleur)
    * Si quelqu'un a le courage de modifier les +-150 tests utilisant PythonOneParameterFunction... 
    * bonus : ''PythonOneParameterFunction'' ne nécessitant plus de lui appliquer un %pythonappend __disown__, on gagne quelques leaks (qu'on reperdra quand on passera aux ''PythonDirectorOneParameterFunction''...) 
   
** ''OneParameterFunction'' **
  * Suppression de l'operateur ''[]'' redondant avec la fonction evaluate (et pouvant preter à confusion)
  * Propagation dans les 3-4 classes utilisant cet operateur (principalement mailleurs)

 ===== Fichiers ajoutés/supprimés =====
<code> 
A \oo_meta\mtFEM\extractors\MomentValueExtractor.h/cpp
A \oo_meta\mtFEM\extractors\Moment2AxeValueExtractor.h/cpp
A \oo_meta\mtMath\PythonDirectorOneParameterFunction.h/cpp
R 
</code>
===== Tests ajoutés/supprimés =====
<code>
A oo_nda\abrawal\toolsBancsUcl
A oo_nda\abrawal\toolsBancsUcl\bancAbradabiliteUcl.py
A oo_nda\abrawal\toolsBancsUcl\postBancAbradabiliteUCL.m
A oo_nda\abrawal\toolsBancsUcl\tribometreUcl.py
A oo_nda\abrawal\toolsBancsUcl\postTribometreUcl.m
A oo_nda\abrawal\testsBattery\bancUcl20rev_alpha08Peno1e3.py
A oo_nda\abrawal\testsBattery\triboUcl20rev_alpha08Peno1e3.py
R 
</code>

 --- //[[L.Papeleux@ulg.ac.be|Luc Papeleux]] 2013/05/14 //