Metafor

Mechanism0DInteraction + Divers

• Essayant de refaire tourner des calculs d'il y a 2 ans de Techspace, les éléments de masse concentrée n'étaient plus générés. En creusant, certain modèles de la batterie ne généraient pas (plus), non plus, ces éléments de masse.
• Depuis toujours la génération des éléments sur base du mécanisme “father” de Oofelie pose problèmes, plus encore quand il s'agit d'éléments 0D (masse concentrée, élément de damping de Romain). Qui plus est, c'est contre-intuitif (avec la notion de Group en tant qu'ensemble de noeuds).
• Ne trouvant pas rapidement la cause de la disparition de mes éléments de masse, j'ai décidé d'implémenter une Mechanism0DInteraction qui génère les éléments de mécanismes 0D (mass concentrées / dampingElement) sur base des meshPoints du (des) GObjects (objet géométrique maillé, groupe, …) pushés dans l'interaction
• Au niveau des tests, la seule modification est l'obligation de remplacer FieldApplicator par Mechanism0DInteraction

• ne comprenant pas l'intérêt de la ligne “using Interaction::generateElements;” copiée dans toutes les définitions de classe dérivant d'interaction, ayant googlé (voir ici) et ressorti mon Stroustrup pour me rendre compte que c'était une bidouille nécessaire parce qu'on a plusieurs fonctions virtuelles avec le même nom, mais pas les mêmes arguments.
• Dans le cas présent, les deux fonctions en questions ne faisant pas du tout la même chose, garder le même nom n'est pas nécessaire (et donc un petit renaming de fonction a permis de supprimer la redéclaration des fonctions generateElements de la classe Interaction.
• “Interaction::generateElements(const ElementID &type)” → “Interaction::generate(const ElementID &type)”

• Correction des la commandes de contrôle des fpe (_control87) générant
  • soit une exception (_EM_ZERODIVIDE et _EM_OVERFLOW)
  • soit pas d'exception (_EM_UNDERFLOW, _EM_INEXACT, INVALID, _EM_DENORMAL)
• la batterie windows –fpe donnant 51 cas tests failed (avis à ceux qui veulent débugger entre autre des matériaux). Une fois ces tests passés, il faudra se poser la question des exceptions _EM_INVALID & _EM_DENORMAL
• les commandes linux ont aussi été modifiées, le mécanisme étant différent (feenableexcept), mais pas encore testées (36.15 qui n'en veux…)

• Ajout de parasolid dans l'installeur linux
• Ajout des librairies de compilateur non natif (icc ou un gcc recompilé) dans l'installeur
• Déplacement de la génération des “pyc” au plus bas de la procédure d'installation

• Ajout de la configuration centos (ma virtual box pour générer une version pour GDTech)
• launch : définition des RUNMETHOD dépendant de l'os (isUnix)

• $Id$ : j'ai encore corrigé entre 50 et 100 tags $Id$ dans des fichiers (h/cpp/py)!!!
• Déplacements de 5 cas tests en dynamique de oo_meta/apps/qs vers oo_meta/apps/imp
• Définition de la fonction sendFlushToCPP dans mtViz.i (redirection des flux dans l'interface graphique)

Adding: oo_meta\mtElements\mechanisms\Mechanism0DInteraction.cpp  text/plain
Adding: oo_meta\mtElements\mechanisms\Mechanism0DInteraction.h  text/plain

Moved: oo_meta\apps\qs\ddrawing.py -> oo_meta\apps\imp\ddrawing.py
Moved: oo_meta\apps\qs\forceDriven.py -> oo_meta\apps\imp\forceDriven.py
Moved: oo_meta\apps\qs\forceDriven3d.py -> oo_meta\apps\imp\forceDriven3d.py
Moved: oo_meta\apps\qs\nine.py -> oo_meta\apps\imp\nine.py
Moved: oo_meta\apps\qs\nineALE.py -> oo_meta\apps\imp\nineALE.py
Moved: oo_meta\apps\qs\paleDyn.py -> oo_meta\apps\imp\paleDyn.py
Moved: oo_meta\apps\qs\ddrawing.py -> oo_meta\apps\imp\ddrawing.py
Moved: oo_meta\apps\qs\ddrawing.py -> oo_meta\apps\imp\ddrawing.py

— Luc Papeleux 2017/02/23