====== Commit 2007-08-10 ======

===== Modifs =====


==== split mtFEM (à suivre) ====

Le but est, à moyen terme, de séparer ce qui est propre à "Metafor" et le reste. En particulier, l'objet "Domain" doit être indépendant de Metafor pour pouvoir être, plus tard, utilisé avec d'autre type d'analyses (statique-linéaire, lubri, etc, etc).

Dans un premier temps, j'avais supprimé l'appel ''domain.getMetafor()''. ''Domain'' ne dépend donc plus directement de ''Metafor'' mais de sa classe mère ''Analyse''. Il reste donc à supprimer les dépendances indirectes avant de séparer physiquement les classes et créer 2 libs hors de ''mtFEM''.

Passons en revue les objets contenus dans ''Domain'':
  * ''DofSet'': OK, générique puisque contenu dans ''mtKernel''.
  * ''Analysis'': OK (ne dépend pas de ''Metafor'' puisque c'est sa classe mère)
  * ''mtGeo::*'': OK, la géométrie ne dépend plus de ''Metafor'' depuis longtemps.
  * ''LoadingSet'': là, problème: les chargements dépendent de ''Metafor'' pour avoir accès à ''t'', ''dt'' et le numéro du step. Tous les chargements sont inclus dans ''LoadingSet'' parce que cette classe sert aussi de factory... Deux choix possible:
     * garder les dépendances dans les classes ''Loading'' et supprimer la factory => la manière bien pratique de définir des chargement doit être revue et la syntaxe de tous les cas-tests doivent être modifiés.
     * essayer de supprimer les dépendances en définissant une interface minimale dans ''Analysis''. C'est moins beau parce que ça oblige la définition de fonctions du type ''getTimeStep()'' dans ''Analysis'' mais c'est beaucoup plus simple. J'ai donc fait comme ça pour l'instant et il faudra passer au choix numéro #1 si on décide un jour de définir une analyse où le concept de temps n'intervient pas.
  * ''InteractionSet'': là aussi, problème: ''InteractionSet'' inclus les éléments de contact pour faire des boucles dessus dans le cadre de l'initialisation du contact. J'ai déplacé cette routine directement dans ''Metafor''. C'est d'ailleurs ce qui faudrait faire pour la plupart des routines de ce type (relatives au contact, au lagrangien augmenté, etc). __Reste la dépendence via ''Element'' et ''ElementShortcuts'' et ''TimeIntegration''__
  * ''MaterialSet'': ''MaterialSet'' dépend de ''Material'' qui possède un pointeur vers ''Metafor''. j'ai donc transformé ce pointeur en pointeur vers une ''Analysis'' et j'ai ajouté des casts aux endroits où c'était nécessaire. J'ai aussi viré la classe ''MaterialTemplate'' qui n'est plus utilisée.
  * ''MateriallawSet'': OK, pas de dépendance indirecte.
  * ''ElementPropertiesSet'': OK, pas de dépendance indirecte.
  * ''FixationSet'': OK, pas de dépendance indirecte.
  * ''ConnexionSet'': __dépendence via ''StrVector''__.
  * ''EqualityDofConstraintsSet'': dépendence via ''EqualityDofConstraints'' facile à supprimer.


⇒ Il reste donc à régler les dépendances soulignées pour pouvoir splitter la lib en 2.

==== Matériaux ====

  * Suppression de ''prmatChecked'', utilisé dans ''checkPrmat'' pour ne faire le check qu'une seule fois et, malheureusement, pour faire aussi certaines initialisations en début de test. J'ai déplacé les initialisations dans la routine ''initialize''. Celle-ci est appelée 2x pour l'instant: une fois dans Domain:build() et une fois dans ''TimeIntegration::initialize()'' (le deuxième appel est nécessaire parce que certains matériaux dépendent du temps, non encore fixé dans ''Domain::build()''). Il sera nécessaire de déplacer les autres initialisations (éléments, etc) de ''Domain::build()'' vers le ''TimeIntegration::initialize()''
  * Nettoyages divers du code (ajout de mots clefs ''virtual'' dans les ''.h'', suppression des fonctions vides, etc).


===== Fichiers ajoutés/supprimés ======

<code>
mtFEM/MaterialTemplate.h	deleted
mtFEM/MaterialTemplate.inl	deleted
</code>

 --- //[[r_boman@yahoo.fr|Romain BOMAN]] 2007/08/10 08:30//