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: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.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 TimeIntegrationMaterialSet: 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.
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()virtual dans les .h, suppression des fonctions vides, etc).mtFEM/MaterialTemplate.h deleted mtFEM/MaterialTemplate.inl deleted
— Romain BOMAN 2007/08/10 08:30