commit:2007:08_10
Table of Contents
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 dansmtKernel.Analysis: OK (ne dépend pas deMetaforpuisque c'est sa classe mère)mtGeo::*: OK, la géométrie ne dépend plus deMetafordepuis longtemps.LoadingSet: là, problème: les chargements dépendent deMetaforpour avoir accès àt,dtet le numéro du step. Tous les chargements sont inclus dansLoadingSetparce que cette classe sert aussi de factory… Deux choix possible:- garder les dépendances dans les classes
Loadinget 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 typegetTimeStep()dansAnalysismais 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:InteractionSetinclus 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 dansMetafor. 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 viaElementetElementShortcutsetTimeIntegrationMaterialSet:MaterialSetdépend deMaterialqui possède un pointeur versMetafor. j'ai donc transformé ce pointeur en pointeur vers uneAnalysiset j'ai ajouté des casts aux endroits où c'était nécessaire. J'ai aussi viré la classeMaterialTemplatequi 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 viaStrVector.EqualityDofConstraintsSet: dépendence viaEqualityDofConstraintsfacile à supprimer.
⇒ Il reste donc à régler les dépendances soulignées pour pouvoir splitter la lib en 2.
Matériaux
- Suppression de
prmatChecked, utilisé danscheckPrmatpour 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 routineinitialize. Celle-ci est appelée 2x pour l'instant: une fois dans Domain:build() et une fois dansTimeIntegration::initialize()(le deuxième appel est nécessaire parce que certains matériaux dépendent du temps, non encore fixé dansDomain::build()). Il sera nécessaire de déplacer les autres initialisations (éléments, etc) deDomain::build()vers leTimeIntegration::initialize() - Nettoyages divers du code (ajout de mots clefs
virtualdans les.h, suppression des fonctions vides, etc).
Fichiers ajoutés/supprimés
mtFEM/MaterialTemplate.h deleted mtFEM/MaterialTemplate.inl deleted
— Romain BOMAN 2007/08/10 08:30
commit/2007/08_10.txt · Last modified: by 127.0.0.1
