====== Commit 2007-09-03 ======
===== Modifs =====
==== Nettoyage des shortcuts d'éléments ====
* ''ElementShcuts'' => ''MtElementShcuts''.
* Création d'une clase de base ''ElementShcuts''.
* Chaque interaction possède un pointeur vers le shortcut de ses éléments (qui n'est pas encore utilisé).
* ''MES_*'' => ''*'' (p.expl ''MES_STIFFANALYTIC'' => ''STIFF_ANALYTIC''). Que voulait dire "''MES''"? "MetaElement Shortcut", bien-sûr - ne cherchez pas le rapport avec la valeur d'une propriété d'élément.
Le but ici est de mettre les shortcuts dans l' ''Interaction'' pour supprimer les variables statiques qui nous ennuyent dans le cas du parallèle ou même simplement lorsqu'on veut lancer 2 tests à la suite dans le même interpréteur.
==== Nettoyage du source de l'élément ====
* J'ai créé des instanciations explicites de chaque élément dérivant de ''VolumeElement'' (transformation des '';inl'' en ''.hpp''). Ca permettra à terme, d'alléger les "includes" du ''.h''. On pourra aussi, éventuellement, importer les namespaces ''mtGeo'' et ''mtMath'' dans l'espace de nom global; ce qui simplifiera l'écriture.
==== Transfert de propriété des objets python ====
Dans le commit précédent, j'avais été confronté au problème de copie de gros objets (''AleMethod'') lors de la lecture du jeu de données. Cette manière de procéder (création d'un objet, configuration puis copie) est utilisée un peu partout dans Metafor mais possède plusieurs désavantages que j'ai déjà détaillés précédemment.
Je continue donc à supprimer ces copies en utilisant le mécanisme, nommé ''DISOWN'', offert par SWIG. Par exemple, la fonction ''addProperty'' d' ''Interaction'' pourra s'écrire à terme (ce n'est pas encore fait):
prp = ElementProperties(Volume2DElement)
intset(99).addProperty(prp) # transfert de propriété vers le C++
prp.put (MATERIAL, 1) # <= la ref est toujours valable!
prp.put (STIFFMETHOD, STIFF_NUMERIC)
prp.put (CAUCHYMECHVOLINTMETH, VES_CMVIM_SRIPR)
Il n'y aura plus de copie de ''prp'' et, conéquence directe, on pourra modifier ''prp'' après le ''addProperty'' et les modifications seront répercutée au ''prp'' donné à l' ''Interaction''.
Cependant, il existe des cas où on crée une propriété et on la "copie" dans plusieurs interactions (cas de plusieurs interactions de contacts où on a les mêmes propriétés de frottement par exemple. Dans ce cas, si on applique brutalement le mécanisme ''DISOWN'', la propriété va être supprimée 2x en sortie de Metafor. J'ai donc décidé avec Luc de programmer un compteur de référence pour gérer correctement ce cas (nouvelle classe ''RefCounted'').
Actuellement, le compteur est codé et les classes ont été modifiées (''ElementProperties'' n'est plus une instanciation de ''Properties'' mais en dérive) mais le compteur n'est pas encore actif.
==== Amélioration de la modularité python ====
J'ai déplacé toutes les initialisations contenues dans ''main.cpp'' de Metafor vers les modules concernés. Par exemple, c'est ''mtMath'' qui initialise PetSc, ''mtFEM'' qui affiche la bannière violette, ''mtKernel'' qui vérifie la licence, etc. Conséquence directe: les modules sont également initialisés lorsqu'on travaille avec ''python.exe'' au lieu de ''metafor.exe''. Outre ce dernier point très intéressant pour garantir une modularité exemplaire de Metafor au cours du temps, ce nouveau système permet par exemple de vérifier toujours la licence (et oui! jusqu'aujourd'hui, il était inutile de désassembler le code pour contourner la licence, il suffisait simplement de lancer ''python'' et d'importer ''wrap'')
Autre truc assez cool: la destruction des singletons de chaque module est programmée également dans python avec un ''Py_AtExit''. Ces destructeurs sont donc appelés automatiquement à la fermeture du programme. Ceci permet de vérifier plus facilement que le programme ne possède aucun memory leak.
Je suis même allé plus loin avec, dans la tête, l'idée de donner à Metafor l'aspect d'un **package python complet**: j'ai ajouté une série d'initialisations dans ''wrap/_init_.py'' qui permettent de ne plus se tracasser du chargement des DLLs des modules (le ''PATH'' ou ''LD_LIBRARY_PATH'' ne doit plus être spécifié). Tout ce qui reste à faire, pour utiliser ''python.exe'' au lieu de ''metafor.exe'' est de s'assurer que ''wrap'' est dans son ''PYTHONPATH'' (celui-ci peut même être non spécifié si on lance ''python'' à partir du répertoire ''oo_meta''.
E:\dev\test>set PYTHONPATH=%PYTHONPATH%;e:\dev\oo_meta
E:\dev\test>python
Python 2.5.1 (r251:54863, Aug 20 2007, 12:42:04) [MSC v.1400 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import wrap
LicenseManager : 1 restrictions
MACLimitedLicense : authorized MAC = 00-E0-81-57-57-05
# #
## ## ###### ##### ## ###### #### #####
# # # # # # # # # # # # #
# # # ##### # # # ##### # # # #
# # # # ###### # # # #####
# # # # # # # # # # #
# # ###### # # # # #### # #
(Revision 212M)
powered by Oofelie, Python and Swig, Vtk, Qt and Nurbs++
init _mtMaterialLaws
27 new laws.
init _mtMaterialLaws shadow
init _mtMaterials
2 new laws.
27 new materials.
0 new elements.
init _mtMaterials shadow
init _mtElements
46 new elements.
init _mtElements shadow
init _mtALE
7 new elements.
init _mtALE shadow
>>>
... et en plus, c'est en couleur, même si on ne le voit pas ici...
Seul problème: les commandes de base (''meta'', ''vizu'', etc) ne sont pas directement accessibles. Pour régler ce problème, on peut utiliser le système d'initialisation de python:
set PYTHONSTARTUP=e:\dev\oo_meta\.pythonrc.py
On spécifie un fichier d'initialisation qui sera lu à chaque démarrage __interactif__ de python. J'ai commité un ''.pythonrc.py'' qui importe ''toolbox.utilities'' (usage facultatif).
__Remarque:__ Vous pouvez, bien sûr, continuer à utiliser l'exécutable ''metafor.exe'' qui a les avantages suivants sur ''python.exe'':
* Interface graphique
* Import automatique des commandes de base (l'équivalent du ''.pythonrc.py'')
* Utilisation automatique de ''python25.dll'' recompilé par nos soins avec vs 2005 dans le cas d'une installation "utilisateur" (la version officielle est compilée avec .NET 2003)
* debug facilité (inutile d' "attacher" le debugueur au process ''python_d.exe'')
==== Ajout d'un peu de doc ====
* Doc des compteurs de référence des matrices (voir fichier ''WithCheckRef.h''). J'ai transformé une doc d'un [[http://metafor.ltas.ulg.ac.be/oldsite/commit/ARCHIVES/2005/06_02.html|ancien commit]] au format DoxyGen.
* doc dans SWIG: en tapant par hasard ''help'', j'ai vu qu'on pouvait avoir de l'aide sur la plupart des objets python. SWIG utilise ce système pour générer de la doc sur chaque objet généré à partir du C++. J'ai ajouté une option dans les "''*.i''" qui permet de voir le prototype de chaque fonction dans cette doc:
Essayez par exemple:
from wrap import *
help(LoadingSet)
et vous obtiendrez pas mal d'infos intéressantes:
class LoadingSet(LoadingSetBase)
| Proxy of C++ LoadingSet class
|
| Method resolution order:
| LoadingSet
| LoadingSetBase
| wrap.mtKernel.PhySet
| wrap.mtGlobal.VirtualObject
| __builtin__.object
|
| Methods defined here:
|
| __del__ lambda self
|
| __getattr__ lambda self, name
|
| __init__(self, *args)
| __init__(self, Domain dom) -> LoadingSet
|
| __repr__ = _swig_repr(self)
|
| __setattr__ lambda self, name, value
|
| define(*args)
| define(self, UserNo _node, ObjectID _typePo, Lock _comp, double _ampl,
| OneParameterFunction _fun, LoadingType _typ=EX_TOTAL) -> Loading
| define(self, UserNo _node, ObjectID _typePo, Lock _comp, double _ampl,
| OneParameterFunction _fun) -> Loading
| define(self, UserNo _node, ObjectID _typePo, Lock _comp, double _ampl,
| MultiParameterFunction _fun, KeyList f2,
| LoadingType _typ=EX_TOTAL) -> Loading
| define(self, UserNo _node, ObjectID _typePo, Lock _comp, double _ampl,
| MultiParameterFunction _fun, KeyList f2) -> Loading
|
| define_rad(*args)
| define_rad(self, UserNo _node, ObjectID _typePo, Lock _comp, UserNo _pt1
| UserNo _pt2, double _ampl, OneParameterFunction _fun) -> Loading
|
| define_rot(*args)
| define_rot(self, UserNo _node, ObjectID _typePo, Lock _comp, UserNo _pt1
| UserNo _pt2, bool _useVelocity, double _ampl,
| OneParameterFunction _fun) -> Loading
|
===== Attention =====
Vérifiez qu'un ''python'' correct est dans votre ''PATH'' pour pouvoir exécuter la batterie. Idem sous Unix: vérifier que ''python'' fonctionne et vous retourne bien le python utilisé par Metafor! J'ai eu le problème sur gaston où le ''python'' que j'avais dans mon ''PATH'' merdouillait parce qu'il avait été compilé avec une version 3.3 de GCC et qu'il supportait assez mal de charger des modules compilés avec GCC 4.2.
===== Fichiers ajoutés/supprimés ======
File Text status Property status
mtFEM/MtElementShcuts.cpp added (+)
mtFEMBase/ElementShcuts.cpp added
mtGlobal/RefCounted.cpp added
mtFEM/MtElementShcuts.h added (+)
mtFEMBase/ElementShcuts.h added
mtGlobal/RefCounted.h added
mtElements/volumes/Tm2VolumeElement.hpp added
mtElements/volumes/Tm2VolumeElement_common.hpp added (+)
mtElements/volumes/Tm2VolumeElement_io.hpp added (+)
mtElements/volumes/VolumeElement.hpp added
mtElements/volumes/VolumeElement_ale.hpp added (+)
mtElements/volumes/VolumeElement_common.hpp added (+)
mtElements/volumes/VolumeElement_io.hpp added (+)
mtElements/volumes/VolumeElement_mec.hpp added (+)
mtElements/volumes/VolumeElement_ther.hpp added (+)
mtElements/volumes/Tm2VolumeElement.inl added
mtElements/volumes/VolumeElement.inl added
mtFEM/MtElementShcuts.inl added (+)
mtGlobal/RefCounted.inl added
.pythonrc.py added
mtFEM/ElementShcuts.cpp deleted
mtMain/staticObjects.cpp deleted
mtFEM/ElementShcuts.h deleted
mtMain/staticObjects.h deleted
mtElements/volumes/Tm2VolumeElement_common.inl deleted
mtElements/volumes/Tm2VolumeElement_io.inl deleted
mtElements/volumes/VolumeElement_ale.inl deleted
mtElements/volumes/VolumeElement_common.inl deleted
mtElements/volumes/VolumeElement_io.inl deleted
mtElements/volumes/VolumeElement_mec.inl deleted
mtElements/volumes/VolumeElement_ther.inl deleted
mtFEM/ElementShcuts.inl deleted
--- //[[r_boman@yahoo.fr|Romain BOMAN]] 2007/09/03 09:12//