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 deMetafor
puisque c'est sa classe mère)mtGeo::*
: OK, la géométrie ne dépend plus deMetafor
depuis longtemps.LoadingSet
: là, problème: les chargements dépendent deMetafor
pour avoir accès àt
,dt
et le numéro du step. Tous les chargements sont inclus dansLoadingSet
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 typegetTimeStep()
dansAnalysis
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 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 viaElement
etElementShortcuts
etTimeIntegration
MaterialSet
:MaterialSet
dépend deMaterial
qui possède un pointeur versMetafor
. j'ai donc transformé ce pointeur en pointeur vers uneAnalysis
et j'ai ajouté des casts aux endroits où c'était nécessaire. J'ai aussi viré la classeMaterialTemplate
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 viaStrVector
.EqualityDofConstraintsSet
: dépendence viaEqualityDofConstraints
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é danscheckPrmat
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 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
virtual
dans 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: 2016/03/30 15:23 by 127.0.0.1