• Analyse fréquentielle - battery - launchGui

• Reprogrammation complète des méthodes d'analyse fréquentielle (code indébuggeable, bourré de memleaks et de soucis de perfs. 2 méthodes appelables séparément :
  • PowerIterationsFrequencyAnalysisMethod : méthode de la puissance et déflection orthogonale (permet de calculer les quelques premières fréquences propres et vecteurs propres (si demandés)
  • LanczosFrequencyAnalysisMethod : méthode de Lanczos avec réorthogonalisation Graham-Schmidt (option)
• Simplification de l'appel aux options
• Attention : le décalage spectral n'est pas encore permis avec le DSS
• suppression de tous les print_TSC en plein milieu de fichier (soit appel par utilisateur, soit via extracteur)
• exemple : calcul de mise en rotation centrifuge (0→5000 rpms sur 25 pas⇒ 25 analyses fréquentielles) d'une aube avec pied (61170ddl dont 60270 ddls libres). calcul sur 6 threads

Le lanczos ne prend plus que un temps équivalent au temps d'intégration d'1 pas de temps et 1 stockage memoire des matrices K et M (en CSR)!!!

• Interfacage du novueau Lanczos par défaut dans le Super-Element (l'outil d'analyse fréquentielle devrait être défini en dehors)
• ATTENTION : le super-element est buggé :
  • L'analyse fréquentielle est faite sur base de la partition avec les frontières de condensation et non du système libre.
  • ⇒ sur une simulation de poutre encastrée libre dont on condense les 2 extrémités, les modes et fréquences propres sont calculés sur une poutre bi-encastrée et non une isostatique (ce qui change beaucoup les phénomènes observés!!!)

• réécriture de la lecture des options de battery.py en utilisant argparse (au lieu de le faire à la main)
• Pour être consistant avec les arguments linux, les options courtes sont en “-” et les options longues en “–”
• ATTENTION : “-low” devient donc “- -low”
• interfacage complet de nice intercaface de Affinity (pour launch)
• … : tapez battery.py –help pour plus d'info

• Amélioration de l'interface de launchGui (et modification de launch pour adapter)
• Tous les tests de launch/launchGui passent par battery (sauf restart)
• synchronisation de la sorti de battery vers la fenetre de LaunchGui
• utilisation de argparse en remplacement de optparse (deprecated)

ATTENTION : UPDATEZ AUSSI LinuxBin !!!

• LinearSolver : dérive de refCounted
• StrMatrixBase : gestion memoire du solver par refCounted
• Ajout d'un extracteur de numero de noeuds : NumNoeValueExtractor
• chasse aux warnings :
  • TimeStepManager.cpp : correction d'un cast barbare:

 dt /= sqrt((ite-maxNbOfItInAdaptOfTimeStep)*1.0); 
remplacé par 
dt /= sqrt((double)(ite-maxNbOfItInAdaptOfTimeStep));

• MtElementShcuts : initialisation de thickness dans le cosntructeur (thickness = 0.0;)
• OnFileDataMatrix : int → size_t
• MultiProjWire : remplacement des messages en std::cout par des WARNING_MESSAGE
• renaming de forge_remesh.py en forgeRemesh.py (ca évite d'avoir 2 fois les résultats dans la batterie)

• apps.biomec.longBone.boneRepairWithPlate : cas test posant problème si lancé en même temps que trop d'autres tests (si failed en -j 6 ⇒ relancer tout seul)
• apps.remeshing.dCupExtrusion_3 : failed selon les runs et les machines …
• les cas tests de remeshing faisant plusieurs intégrations dans le même metafor sont executés selon le nombre de threads demandé sur la première intégration, mais en nombre de threads automatique sur les autres intégrations (or les méthodes de transfert ne sont pas threads safe!!!)

 
A : oo_meta\mtFrequencyAnalysis\src\PowerIterationsFrequencyAnalysisMethod.h/cpp
A : oo_meta\mtFrequencyAnalysis\src\LanczosFrequencyAnalysisMethod.h/cpp
A : oo_meta\mtFEM\extractors\NumNoeValueExtractor.h/cpp
R : oo_meta\mtFrequencyAnalysis\src\FrequencyAnalysisMethod2.h/cpp
R : oo_meta\mtFrequencyAnalysis\src\FrequencyAnalysisMethod3.h/cpp

A : oo_meta\mtFrequencyAnalysis\tests\matlab\matlabPostPro.py
A : oo_nda\abrawal\toolsBancOnera\freqAnalysis\freqVsPeno.py
A : oo_nda\abrawal\testsBattery\freqAnalysisBancOnera.py
R : 

— Luc Papeleux 2015/03/17