• 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.

• 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.

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.

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)

• Doc des compteurs de référence des matrices (voir fichier WithCheckRef.h). J'ai transformé une doc d'un 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
 |

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.

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	 

— Romain BOMAN 2007/09/03 09:12