Ceci est un gros commit: ne mettez pas à jour sans avoir un peu de temps à y consacrer

Pour ceux qui se fient aveuglément à Luc, lisez au minimum les paragraphes “Conséquences” de chaque section.

L'idée est de définir les propriétés matériaux/éléments/lois dans les libs qui les utilisent. Par exemple, les paramètres EAS doivent être logiquement définis à côté des EAS, les propriétés SABCA à côté des lois/matériaux SABCA.

Quelques subtilités:

• Certaines propriétés sont utilisées dans des libs ne contenant ni matériaux, ni éléments (VISCO_NUM pour le LoadAdaptationManager). D'autres concernent l'ALE qui est mis (pour l'instant) en vrac dans mtFEM. Enfin, certaines propriétés sont utilisées par plusieurs lib (ELASTIC_MODULUS est utilisé par les elems grandes défos et par XFEM (mtIntelSig). En conséquence, toutes les propriétés n'ont pas quitté mtFEM.
• Certaines libs contiennent plusieurs types de propriétés. Par exemple mtMaterials contient des propriétés matériaux (logique) mais aussi quelques propriétés de type MaterialLaw pour la gestion du critère de plasticité. Même situation pour mtSabca qui contient des lois et un matériau.

Au niveau du C++, il y a un petit problème d'initialisation de variables statiques à travers des DLLs à cause de templates. En quelques mots:

• Les templates d'une DLL ne sont pas exportés parce qu'ils sont généralement “inline”.
• Exception: lorsqu'ils sont explicitement instanciés. Cependant, même dans ce cas, il se peut que ces templates soient conçus pour que certaines fonctions membres soient inline.
• Conséquence, les templates ne sont pas exportés dans l'interface d'une DLL. En général, ce n'est pas un problème. Une fonction qui veut accéder à une interface template d'une DLL crée alors une instanciation locale et tout marche bien (on récolte juste un warning 4251 avec le visual).
• Si, maintenant, le template manipule des variables statiques dans des fonctions inline, le template est réinstancié mais pas les variables statiques. Ce qui provoque alors une erreur au link.
• Malheureusement pour nous, PropertyID (classe de base des propriétés) tombe exactement dans ce cas de figure.

Seule solution (d'après cet article): instancier le template de telle sorte que les fonctions inlines ne seront jamais instanciées en dehors d'où on le veut. En pratique, ça veut dire transformer quelques .inl en .hpp et faire une instanciation explicite dans un seul fichier.

Conséquence:

from wrap import * n'importe plus ni mtSabca, ni mtThixo, ni mtIntelSig

Il est donc nécessaire, dans tous les tests utilisant des matériaux SABCA, Thixo ou XFEM de les importer manuellement. Ceci pour insister sur le caractère “additionnel” de ces modules.

from wrap import *
from wrap.mtThixo import *
...

J'ai simplifié la manière dont les variables globales (codes _ID des objets, Locks, codes de propriétés, etc) sont interfacés avec python. Au lieu d'utiliser un mécanisme compliqué qui va relire les singletons lors du chargement des modules python (voir routines addToPyDict et initIDList dans _mtGlobal), j'ai simplement inclus les fichiers de déclaration de ces varaibles dans les fichiers *.i moulinés par SWIG. C'est beaucoup plus simple d'autant plus que j'ai trouvé un moyen pour éviter le contournement de cvar programmé auparavant (via le mot clef %immutable). Autre avantage, chaque module peut définir des variables globales qui sont alors correctement encapsulées dans le module python.

L'idéal serait de faire ça également avec les codes d'éléments mais c'est un peu plus compliqué parce que ces codes correspondent à des factories sous python et à des éléments en C++. Une solution serait de mettre les noms des factories en majuscule (VOLUME2DELEMENT pour Volume2DElement). On pourrait ainsi simplifier grandement l'initialisation des éléments.

C'est à ce niveau que j'ai merdouillé et que j'ai par erreur défini 2x la variable PYTHONCURVE_ID (une fois dans mtPython et une fois dans mtGeo). Cette erreur que j'ai mis 3 jours complets à trouver à coup de strace et valgrind n'apparait que sous Unix avec gcc. Côté SuSE, le symptôme est simple: les MKL freezent en sortie (on ne récupère jamais la main après un run – ce qui a fait planter ma batterie). Côté Debian, le gcc fournit une chouette erreur très drôle: “double free or corruption (fasttop)”. Avec le recul, je trouve que ce message était suffisamment clair mais j'ai suspecté à tort les MKL parce que l'exécutable linké sans les BLAS ne posait pas de problème, aussi bizarre que ça puisse paraitre…

Conséquence:

Les propriétés (matériaux, élémentaires, etc) spécifiques à une lib (aujourd'hui mtThixo, mtSabca et mtIntelSig en plus de mtMaterials, mtMaterialLaws, mtElements) s'ajoutent au niveau de cette lib dans le fichier d'entête. Par exemple une propriété Thixo s'ajoute dans mtThixo/mtThixo.h et mtThixo/mtThixo.cpp.

Il s'agissait de supprimer:

• La dépendance mtFEM ⇒ mtElements au travers des extracteurs relatifs au contact. j'ai donc déplacé 2 extracteurs relatifs à l'élément de contact dans mtElements. Conséquence: le ValuesManager ne les connait plus et il faut les définir à la main (mais c'est pas plus mal)

curves.defineNbOfNodesInContact(4, 1)

devient donc

curves.define(4, NcValueExtractor(domain, 1))

et

curves.defineContactGapMax(15, 1)

devient

curves.define(15, GapMaxValueExtractor(domain, 1))

• La dépendance mtFEM mtElements à travers le PostStep de l'ALE (retablissemnt d'une config équilibrée au niveau des contacts). J'ai créé une interface virtuelle nommée PostStep et une nouvelle classe ContactPostStep. Celle-ci est assignée à l'ALE par un add. Cette méthode récupère la propriété de l'objet C++ si bien que python ne le désallouera jamais (voir les détails dans Module mtALE). En clair, ça donne, par exemple:

pst = ale.getPostStep();
pst.add(intset(2))

devient

poststep = ContactPostStep()
ale.add(poststep)
poststep.add(intset(2))     # avant ou après le ale.add!

Conséquence:

Les objets qui apportent une fonctionnalité très spécifique doivent être définis dans des modules spécifiques de haut niveau. Les liens des classes de base vers ces objets peuvent se faire dans le fichier de données python. Exemple: je veux définir un extracteur très spécifique à un élément qui utilise un matériau Thixo ⇒ je le définis dans mtThixo en suivant l'interface définie dans mtFEM.

Modifiez vos (nombreux) tests ALE qui ne sont pas dans la batterie pour la nouvelle gestion mémoire…

J'ai supprimé la dépendance PetSc/MKL avec toutes les libs incluant mtMath. Vous pouvez donc supprimer les répertoires d'include correspondants à ces 2 libs dans tous les projets utilisant mtMath.

Conséquence:

Il serait très utile de virer les “includes” inutiles dans le projet de Luc. Quelqu'un d'autre que lui peut s'en charger.

Qui a dit, “…de toutes façons, il va le refaire après à sa sauce” ?

C'est une conséquence directe du point précédent: il est possible de lancer metafor à travers un interpréteur python traditionnel:

Config:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/boman/dev/oo_meta/lib
PYTHONPATH=$PYTHONPATH:/home/boman/dev/oo_meta/lib

Utilisation:

boman@clifton:/home/boman/dev/oo_meta>python
Python 2.4.4 (#2, Apr  5 2007, 18:43:10)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from toolbox.utilities import meta
>>> meta('apps.qs.cont2')
apps.qs.cont2
Meshing Line 1...
Meshing Point 1...
Meshing Point 2...
Meshing Line 3...
Meshing Point 3...
...

L'exécutable metafor n'apporte “que” la visu, l'import de quelques modules au démarrage (toolbox.utilities), et la définition du PYTHONPATH pour les modules complémentaires (oo_nda).

Remarque de dernière minute:

Sous gcc, les dynamic_cast, RTTI et autres joyeusetés de ce type ne fonctionnent pas par défaut entre bibliothèques dynamiques chargées avec dlopen (ce que fait python quand on fait un import). Pour l'instant, j'ai contourné le problème en linkant l'exécutable metafor avec toutes les DLLs, même celles qui sont directement inutiles (par exemple mtALE qui utilise des dynamic_cast et exceptions). En faisant ça, la résolution des symboles relatif au RTTI se fait correctement dès le démarrage du programme (les libs ne sont plus chargées par dlopen parce qu'elles ont été directemnt liées par ld - on peut le vérifier par ldd ./metafor). La solution semble être de configurer le dlopen après l'ouverture de python avec un sys.setdlopenflags, comme le montre cet article… ce que je ferai dès le prochain commit.

Bien sûr, Visual et cxx d'OSF n'ont pas ce problème. Python pur peut donc être utilisé uniquement sur ces deux plateformes actuellement.

On poursuit ici le même but: clarifier les interfaces et séparer les libs d'une de l'autre. Au final, on aimerait avoir, pour chaque DLL, une lib C++ du type mtMachin.dll et un module d'interface python du type _mtMachin.pyd. Aujourd'hui, certaines libs sont mal nommées (_mtViz.pyd interface mtQt.dll et non mtViz.dll)

Contient les classes d'extension “python” telles que la PythonCurve et l'interpréteur python customisé pour Metafor.

Contient les codes de propriétés des MaterialLaws.

Contient les codes de propriétés des Materials.

Contient les codes de propriétés élémentaires ainsi que certaines classes telles que FieldApplicator et les autres interactions spécifiques à Metafor.

Contient les codes du matériau thixo et des lois associées.

Contient les codes du matériau SABCA et des lois associées (répertoire oo_nda/sabca/wrap).

Contient l'élément XFEM et autres larateries (répertoire oo_nda/intelSig/wrap).

Contient les crasses ALE et autres bomaneries.

Conséquence:

Une solution Visual avec 42 projets!

J'ai séparé l'ALE de mtFEM pour faire un essai de module additionnel qui contient autre chose que des éléments/matériaux/lois. Pour y arriver, j'ai créé une classe AleMethodBase qui contient l'interface minimale avec TimeIntegration. J'ai ensuite dérivé cette classe dans le nouveau module (classe AleMethod).

A ce moment, un problème se pose: la création de AleMethod ne peut plus être faite à partir de Metafor puisque Metafor ne connait pas ce type d'objet mais juste l'interface. J'ai donc, dans un premier temps, ajouté une fonction copy pour donner à l'analyse un objet AleMethod dans le jeu de données python, un peu comme on fait dans la géométrie. Cependant, copy, comme son nom l'indique, fait une copie de l'objet qu'on lui donne. Il faut donc obligatoirement que tous les constructeurs par copie soient écrits ; ce que j'ai commencé à faire sans aller jusqu'au bout parce que cela rend le source énorme. De plus, le copy pose un très gros problème: l'objet initial (et donc son type) est perdu dès qu'on appelle copy. De plus, la référence vers l'objet initial est toujours présente mais n'est pas liée à la copie. En clair:

ale = AleMethod(metafor)
metafor.copy(ale)
ale.enable()                      # <= n'agit pas sur la copie!
ale_copy = metafor.getAleMethod()
ale_copy.enable()                 # <= plante car ''ale_copy'' est de type ''AleMethodBase''!

Pour rappel, le copy est utilisé uniquement parce que si on fait un “bête” set, python pense que ale lui appartient et appelle son destructeur quand la variable n'est plus référencée en python. En clair:

ale = AleMethod(metafor)
metafor.setAleMethod(ale)
ale.enable()                      # OK
del ale                           # <= glups python vient de detruire l'ale de Metafor...

ce dernier del est implicite quand le code est à l'intérieur d'une fonction qu'on quitte.

La solution est de faire en sorte que le C++ récupère la propriété de ale et que python n'essaye plus de le détruire. Pour ce faire, on a la variable thisown que j'avais découvert pour “gérer” les fenêtres VizWin:

ale = AleMethod(metafor)
ale.thisown=0
metafor.setAleMethod(ale)
ale.enable()                      # OK
del ale                           # OK, ne vire que la shadow class

On est arrivé à notre but mais c'est franchement moche. Il faudrait donc, pour bien faire, que SWIG se charge de faire un thisown=0 tout seul comme un grand. Bien sûr, ça a été prévu et il faut alors simplement utiliser le typemap SWIGTYPE *DISOWN qui consiste à simplement nommer sa variable DISOWN dans le source de

  AleMethodBase &setAleMethod(AleMethodBase *DISOWN);

et ça marche. Il reste cependant un problème esthétique:

ale = AleMethod(metafor)
metafor.setAleMethod(ale)

On a un peu l'impression de se répéter: metafor est spécifié dans le constructeiur d' AleMethod et puis on le lie explicitement au même objet la ligne suivante. On pourrait même imaginer un gars tordu qui spécifie 2 objets metafor différents… bref, c'est vraiment pas idéal…

On pourrait donc imaginer de faire le setAleMethod dans le constructeur et le lien serait effectué directement à la création mais malheureusement, le typename DISOWN ne fonctionne pas avec les constructeurs. J'ai également essayé toutes sortes d'options (%delobject, %feature(“action”), etc) qui agissent sur le code des wrappers sans succès. Pour finir, je m'en suis sorti avec la nouvelle commande %pythonappend qui permet d'ajouter du code directement dans les shadow classes. J'ai donc ajouté le thisown=0 à ce endroit et, au final, on peut écrire:

ale = AleMethod(metafor)    # ale.thisown est mis à 0!
ale.enable()
del ale                     # détruit la shadow classe uniquement

Conséquence:

Je crois qu'il serait très utile d'étendre ce système à toutes les opérations qui nécessitent aujourd'hui une copie. Ca nous permet non seulement d'économiser de la mémoire (tous les objets ne sont plus en double), du temps (celui de la copie), du code (certaines classes n'ont plus besoin de copy constructor) et des erreurs (voir ci-dessous):

prp = ElementProperties(Volume2DElement)
prp.put (MATERIAL, 1)
interaction.addProperty(prp)
prp.put (STIFFMETHOD, MES_STIFFNUMERIC)    # trop tard! la raideur sera analytique!

Changement de noms suite à des instanciations explicites:

• PropertyID.inl ⇒ PropertyID.hpp (mtKernel)
• ElementIDListTemplate.inl ⇒ ElementIDListTemplate.hpp (mtGlobal)

Modification des macros de base:

• CLASSCOMMON_H ⇒ BASIC_OBJECT (macro utilisée dans tous les objets non virtuels pour leur donner leur nom)
• AOBJECT_COMMON_H ⇒ ABSTRACT_OBJECT ( = BASIC_OBJECT + le lien avec l' _ID de l'objet et , éventuellement son set)
• VOBJECT_COMMON_H ⇒ VIRTUAL_OBJECT ( = ABSTRACT_OBJECT + le constructeur virtuel getClone)

J'ai créé un nouveau script permettant de vérifier l'état des fichiers textes d'une version des sources et, bien sûr, de rattraper la sauce si quelque chose ne va pas. Deux aspects sont vérifiés: les caractères EOL et les svn:props.

Il s'agit juste de faire un unix2dos sur tous les fichiers. L'intérêt du script réside dans la possibilité de faire une simulation et ne rien modifier (avec le flag -show).

chkrep.py [-show] eol

et hop:

checking LF in e:\dev\oo_meta
...
e:\dev\oo_meta\mtElements\shells\BoundaryDgShellFirstDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\BoundaryDgShellNineNodeSecondDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\BoundaryDgShellSecondDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\BoundaryDgShellSixteenNodeThirdDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\DgShellElShcuts.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\DgShellFirstDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\DgShellNineNodeSecondDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\DgShellSecondDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\DgShellSixteenNodeThirdDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\DgShell_mec.inl has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\LinearShellElement.h has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\LinearShellElShcuts.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\LinearShellFirstDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\LinearShellNineNodeSecondDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\LinearShellSecondDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\LinearShellSixteenNodeThirdDegreeElement.cpp has Unix-style EOL
e:\dev\oo_meta\mtElements\shells\LinearShell_mec.inl has Unix-style EOL
...

chkrep.py [-show] props

corrige les props de tous les fichiers texte pour qu'ils définissent tous svn:mime-type: text/plain, svn:eol-style: native, svn:keywords: Id. Les deux premiers permettent une gestion automatique des EOL Unix ⇔ Dos. Le dernier demande à SVN de remplir le code $Id$ à chaque commit.

Pendant mes 3 jours de debug sous Unix, j'en ai profité pour modifier les makefiles Unix. La nouvelle architecture est beaucoup plus simple et plus modulaire: l'idée est d'avoir une série de Makefiles génériques dans le répertoire oo_meta/makefiles. Ceux-ci s'incluent les uns les autres pour éviter les coupés/collés pourris.

• makefiles/Makfelie_common.in: la base de la base. Ce makefile contient tout ce qui faut pour compiler de C++, mouliner du Qt avec moc/uic et créer des wrappers SWIG. les dépendances sont également gérées. Il est également possible de fournir des sous-répertoires additionnels à compiler (dans le cas ou le source de la future lib est splitté en plusieurs endroits).
  • makefiles/Makfelie_lib.in: la base pour la génération des libs
    • makefiles/Makfelie_static.in: makefile paramétré pour une lib statique (.a) - actuellement Nurbs++ uniquement.
    • makefiles/Makfelie_shared.in: makefile paramétré pour une lib dynamique (.so) - actuellement tout le reste y compris wrappers python.
  • makefiles/Makfelie_exe.in: makefile paramétré pour un exécutable (actuellement metafor uniquement)

Le makefile de la racine de oo_meta ne fait plus rien mis à part une redirection vers les sous-makefiles et quelques opérations de nettoyage.

Enfin, pour chaque lib, on a un makefile qui définit les dépendances. Par exemple (cas de mtKernel):

LIBNAME    = libmtKernel.so
OO_BASEDIR := $(shell cd .. ; pwd)
LIBDIR     := $(OO_BASEDIR)/lib
INC_FLAGS  := -I$(OO_BASEDIR) -I$(OO_BASEDIR)/mtGlobal \
             -I$(OO_BASEDIR)/mtKernel -I@OOFELIE_DIR@/oeKernel \
             -I$(OO_BASEDIR)/mtMath -I@OOFELIE_DIR@/oeMath
LD_FLAGS   = @LD_FLAGS@ -L$(LIBDIR) -lmtMath -lmtGlobal -lm

DEPLIB = @OOFELIE_DIR@/oeKernel

include $(OO_BASEDIR)/makefiles/Makefile_shared

On voit clairement (non?) que mtKernel dépend de mtMath et mtGlobal au niveau des libs. On voit aussi que le source est séraré dans le répertoire courant et dans @OOFELIE_DIR@/oeKernel qui est le repository Oofelie.

Remarque: Cette nouvelle méthode nous permettrait par exemple d'avoir plusieurs exécutables en parallèle utilisant tous nos libs dynamiques.

• J'ai supprimé les warnings provenant de SWIG et les quelques uns qui restaient dans le code C++.
• Au niveau du visual, je vous conseille d'ajouter dans votre projet “Properties/C++/Advanced/Disable specific Warnings” = 4244. Ca supprime un warning du runtime SWIG, impossible à supprimer autrement.

Conséquence:

Votre projet peut compiler “tout vert” en Warning level 3 sous VS 2005.

Créez les nouvelles DLL, vérifiez vos répertoires d'includes et vos dépendances… et c'est fini!

Si vous avez des problèmes:

• Vérifiez que les libs contenant des matériaux, éléments ou lois sont bien linkées sans supprimer les symboles non référencés (onglet “Linker/Optimization/References” - voir ci-dessous):

• Il est inutile de linker l'exécutable Metafor avec ces libs. Elles se chargent dorénavant dynamiquement au runtime comme en rêvait Igor . Notez (voir figure ci-dessous) que j'ai laissé des infos de debug pour vous faciliter la création du projet. Ce sera retiré au prochain commit.

• Si vous doutez sur un dépendance entre lib, regardez les Makefiles Unix (nommés Makefile.in).

_mtALE	added	 
_mtElements	added	 
_mtFEMBase	added	 
_mtMaterialLaws	added	 
_mtMaterials	added	 
_mtPython	added	 
_mtThixo	added	 
mtALE	added	 
_mtFEMBase/initFEMBaseShadow.cpp	added	 
mtALE/AbscisseCurveReZoner.cpp	added (+)	 
mtALE/AleMethod.cpp	added (+)	 
mtALE/AngleReZoner.cpp	added (+)	 
mtALE/AnisotropicLimiter.cpp	added (+)	 
mtALE/ArcCurveReZoner.cpp	added (+)	 
mtALE/AreaPullReZoner.cpp	added (+)	 
mtALE/AuxiliaryMeshBuilder.cpp	added (+)	 
mtALE/AuxiliaryVelMeshBuilder.cpp	added (+)	 
mtALE/BarthLimiter.cpp	added (+)	 
mtALE/BcInteraction.cpp	added (+)	 
mtALE/BlendedReZoner.cpp	added (+)	 
mtALE/BoundaryCell.cpp	added (+)	 
mtALE/BoundaryReZoner.cpp	added (+)	 
mtALE/BPointReZoner.cpp	added (+)	 
mtALE/ContactConvectionProblem.cpp	added (+)	 
mtALE/ContactConvector.cpp	added (+)	 
mtALE/ContactPostStep.cpp	added	 
mtALE/ConvectionFieldApplicator.cpp	added (+)	 
mtALE/ConvectionProblem.cpp	added (+)	 
mtALE/ConvectionStep.cpp	added (+)	 
mtALE/Convector.cpp	added (+)	 
mtALE/CurveAuxMeshBuilder.cpp	added (+)	 
mtALE/CurveVelMeshBuilder.cpp	added (+)	 
mtALE/EdgeFluxElement.cpp	added (+)	 
mtALE/EquipotentialReZoner.cpp	added (+)	 
mtALE/EulerianReZoner.cpp	added (+)	 
mtALE/FacetFluxElement.cpp	added (+)	 
mtALE/FieldUnknown.cpp	added (+)	 
mtALE/FieldUnknownAccessImplementor.cpp	added (+)	 
mtALE/FluxElement.cpp	added (+)	 
mtALE/Giuliani2DReZoner.cpp	added (+)	 
mtALE/Giuliani3DReZoner.cpp	added (+)	 
mtALE/GodunovCell.cpp	added (+)	 
mtALE/GodunovConvector.cpp	added (+)	 
mtALE/GodunovEdgeFluxElement.cpp	added (+)	 
mtALE/GodunovFacetFluxElement.cpp	added (+)	 
mtALE/GPConvectionProblem.cpp	added (+)	 
mtALE/GPointFieldApplicator.cpp	added (+)	 
mtALE/GreenGaussStencil.cpp	added (+)	 
mtALE/InitialFieldCreator.cpp	added (+)	 
mtALE/InriaCell.cpp	added (+)	 
mtALE/IsoParametricReZoner.cpp	added (+)	 
mtALE/IterativeReZoner.cpp	added (+)	 
mtALE/LagrangianReZoner.cpp	added (+)	 
mtALE/Laplacian2DReZoner.cpp	added (+)	 
mtALE/Laplacian3DReZoner.cpp	added (+)	 
mtALE/LastStepReZoner.cpp	added (+)	 
mtALE/LeastSquareStencil.cpp	added (+)	 
mtALE/Limiter.cpp	added (+)	 
mtALE/LinearRecCell.cpp	added (+)	 
mtALE/LinearRecEdgeFluxElement.cpp	added (+)	 
mtALE/LinearRecFacetFluxElement.cpp	added (+)	 
mtALE/LockUnknown.cpp	added (+)	 
mtALE/LockUnknownAccessImplementor.cpp	added (+)	 
mtALE/MeshBuilder.cpp	added (+)	 
mtALE/MeshPointDetector.cpp	added (+)	 
mtALE/mtALE.cpp	added	 
mtALE/NodalConvectionProblem.cpp	added (+)	 
mtALE/NodalFieldApplicator.cpp	added (+)	 
mtALE/OptiReZoner.cpp	added (+)	 
mtALE/PostStep.cpp	added (+)	 
mtALE/ReZoner.cpp	added (+)	 
mtALE/ReZoner2D.cpp	added (+)	 
mtALE/ReZoningStep.cpp	added (+)	 
mtALE/ReZoningType.cpp	added (+)	 
mtALE/SplineCurveReZoner.cpp	added (+)	 
mtALE/Stencil.cpp	added (+)	 
mtALE/Tm2DReZoner.cpp	added (+)	 
mtALE/Tm3DReZoner.cpp	added (+)	 
mtALE/Unknown.cpp	added (+)	 
mtALE/UnknownAccessImplementor.cpp	added (+)	 
mtALE/UpdEulerCurveReZoner.cpp	added (+)	 
mtElements/boundaries/NcValueExtractor.cpp	added (+)	 
mtElements/GapMaxValueExtractor.cpp	added (+)	 
mtFEM/AleMethodBase.cpp	added	 
mtPython/mtPython.cpp	added	 
mtThixo/mtThixo.cpp	added	 
_mtFEMBase/initFEMBaseShadow.h	added	 
mtALE/AbscisseCurveReZoner.h	added (+)	 
mtALE/AleMethod.h	added (+)	 
mtALE/AngleReZoner.h	added (+)	 
mtALE/AnisotropicLimiter.h	added (+)	 
mtALE/ArcCurveReZoner.h	added (+)	 
mtALE/AreaPullReZoner.h	added (+)	 
mtALE/AuxiliaryMeshBuilder.h	added (+)	 
mtALE/AuxiliaryVelMeshBuilder.h	added (+)	 
mtALE/BarthLimiter.h	added (+)	 
mtALE/BcInteraction.h	added (+)	 
mtALE/BlendedReZoner.h	added (+)	 
mtALE/BoundaryCell.h	added (+)	 
mtALE/BoundaryCellElShcuts.h	added (+)	 
mtALE/BoundaryReZoner.h	added (+)	 
mtALE/BPointReZoner.h	added (+)	 
mtALE/ContactConvectionProblem.h	added (+)	 
mtALE/ContactConvector.h	added (+)	 
mtALE/ContactPostStep.h	added	 
mtALE/ConvectionFieldApplicator.h	added (+)	 
mtALE/ConvectionProblem.h	added (+)	 
mtALE/ConvectionStep.h	added (+)	 
mtALE/Convector.h	added (+)	 
mtALE/CurveAuxMeshBuilder.h	added (+)	 
mtALE/CurveVelMeshBuilder.h	added (+)	 
mtALE/EdgeFluxElement.h	added (+)	 
mtALE/EquipotentialReZoner.h	added (+)	 
mtALE/EulerianReZoner.h	added (+)	 
mtALE/FacetFluxElement.h	added (+)	 
mtALE/FieldUnknown.h	added (+)	 
mtALE/FieldUnknownAccessImplementor.h	added (+)	 
mtALE/FluxElement.h	added (+)	 
mtALE/FluxElementShcuts.h	added (+)	 
mtALE/FluxGaussPoint.h	added (+)	 
mtALE/Giuliani2DReZoner.h	added (+)	 
mtALE/Giuliani3DReZoner.h	added (+)	 
mtALE/GodunovCell.h	added (+)	 
mtALE/GodunovCellElShcuts.h	added (+)	 
mtALE/GodunovConvector.h	added (+)	 
mtALE/GodunovEdgeFluxElement.h	added (+)	 
mtALE/GodunovFacetFluxElement.h	added (+)	 
mtALE/GPConvectionProblem.h	added (+)	 
mtALE/GPointFieldApplicator.h	added (+)	 
mtALE/GreenGaussStencil.h	added (+)	 
mtALE/InitialFieldCreator.h	added (+)	 
mtALE/InriaCell.h	added (+)	 
mtALE/InriaCellElShcuts.h	added (+)	 
mtALE/IsoParametricReZoner.h	added (+)	 
mtALE/IterativeReZoner.h	added (+)	 
mtALE/LagrangianReZoner.h	added (+)	 
mtALE/Laplacian2DReZoner.h	added (+)	 
mtALE/Laplacian3DReZoner.h	added (+)	 
mtALE/LastStepReZoner.h	added (+)	 
mtALE/LeastSquareStencil.h	added (+)	 
mtALE/Limiter.h	added (+)	 
mtALE/LimiterType.h	added (+)	 
mtALE/LinearRecCell.h	added (+)	 
mtALE/LinearRecCellElShcuts.h	added (+)	 
mtALE/LinearRecEdgeFluxElement.h	added (+)	 
mtALE/LinearRecFacetFluxElement.h	added (+)	 
mtALE/LockUnknown.h	added (+)	 
mtALE/LockUnknownAccessImplementor.h	added (+)	 
mtALE/MeshBuilder.h	added (+)	 
mtALE/MeshPointDetector.h	added (+)	 
mtALE/mtALE.h	added	 
mtALE/NodalConvectionProblem.h	added (+)	 
mtALE/NodalFieldApplicator.h	added (+)	 
mtALE/OptiReZoner.h	added (+)	 
mtALE/PostStep.h	added (+)	 
mtALE/ReZoner.h	added (+)	 
mtALE/ReZoner2D.h	added (+)	 
mtALE/ReZoningStep.h	added (+)	 
mtALE/ReZoningType.h	added (+)	 
mtALE/SplineCurveReZoner.h	added (+)	 
mtALE/Stencil.h	added (+)	 
mtALE/StencilType.h	added (+)	 
mtALE/Tm2DReZoner.h	added (+)	 
mtALE/Tm3DReZoner.h	added (+)	 
mtALE/Unknown.h	added (+)	 
mtALE/UnknownAccessImplementor.h	added (+)	 
mtALE/UpdEulerCurveReZoner.h	added (+)	 
mtElements/boundaries/NcValueExtractor.h	added (+)	 
mtElements/GapMaxValueExtractor.h	added (+)	 
mtFEM/AleMethodBase.h	added	 
mtGlobal/IDListTemplate.hpp	added (+)	 
mtKernel/PropertyID.hpp	added (+)	 
_mtALE/mtALE.i	added	 
_mtElements/mtElements.i	added	 
_mtFEMBase/mtFEMBase.i	added	 
_mtMaterialLaws/mtMaterialLaws.i	added	 
_mtMaterials/mtMaterials.i	added	 
_mtPython/mtPython.i	added	 
_mtThixo/mtThixo.i	added	 
_mtALE/Makefile.in	added	 
_mtElements/Makefile.in	added	 
_mtFEMBase/Makefile.in	added	 
_mtMaterialLaws/Makefile.in	added	 
_mtMaterials/Makefile.in	added	 
_mtPython/Makefile.in	added	 
_mtThixo/Makefile.in	added	 
makefiles/Makefile_exe.in	added	 
mtALE/Makefile.in	added	 
mtMain/Makefile.in	added	 
mtALE/AleMethod.inl	added (+)	 
mtALE/BoundaryCellElShcuts.inl	added (+)	 
mtALE/FluxElementShcuts.inl	added (+)	 
mtALE/GodunovCellElShcuts.inl	added (+)	 
mtALE/InriaCellElShcuts.inl	added (+)	 
mtALE/LinearRecCellElShcuts.inl	added (+)	 
mtALE/Stencil.inl	added (+)	 
chkrep.py	added	 
_mtFEM/initFEMShadow.cpp	deleted	 
_mtGlobal/initGlobalShadow.cpp	deleted	 
_mtKernel/initKernelShadow.cpp	deleted	 
mtFEM/ale/AbscisseCurveReZoner.cpp	deleted	 
mtFEM/ale/AleMethod.cpp	deleted	 
mtFEM/ale/AngleReZoner.cpp	deleted	 
mtFEM/ale/AnisotropicLimiter.cpp	deleted	 
mtFEM/ale/ArcCurveReZoner.cpp	deleted	 
mtFEM/ale/AreaPullReZoner.cpp	deleted	 
mtFEM/ale/AuxiliaryMeshBuilder.cpp	deleted	 
mtFEM/ale/AuxiliaryVelMeshBuilder.cpp	deleted	 
mtFEM/ale/BarthLimiter.cpp	deleted	 
mtFEM/ale/BcInteraction.cpp	deleted	 
mtFEM/ale/BlendedReZoner.cpp	deleted	 
mtFEM/ale/BoundaryCell.cpp	deleted	 
mtFEM/ale/BoundaryReZoner.cpp	deleted	 
mtFEM/ale/BPointReZoner.cpp	deleted	 
mtFEM/ale/ContactConvectionProblem.cpp	deleted	 
mtFEM/ale/ContactConvector.cpp	deleted	 
mtFEM/ale/ConvectionFieldApplicator.cpp	deleted	 
mtFEM/ale/ConvectionProblem.cpp	deleted	 
mtFEM/ale/ConvectionStep.cpp	deleted	 
mtFEM/ale/Convector.cpp	deleted	 
mtFEM/ale/CurveAuxMeshBuilder.cpp	deleted	 
mtFEM/ale/CurveVelMeshBuilder.cpp	deleted	 
mtFEM/ale/EdgeFluxElement.cpp	deleted	 
mtFEM/ale/EquipotentialReZoner.cpp	deleted	 
mtFEM/ale/EulerianReZoner.cpp	deleted	 
mtFEM/ale/FacetFluxElement.cpp	deleted	 
mtFEM/ale/FieldUnknown.cpp	deleted	 
mtFEM/ale/FieldUnknownAccessImplementor.cpp	deleted	 
mtFEM/ale/FluxElement.cpp	deleted	 
mtFEM/ale/Giuliani2DReZoner.cpp	deleted	 
mtFEM/ale/Giuliani3DReZoner.cpp	deleted	 
mtFEM/ale/GodunovCell.cpp	deleted	 
mtFEM/ale/GodunovConvector.cpp	deleted	 
mtFEM/ale/GodunovEdgeFluxElement.cpp	deleted	 
mtFEM/ale/GodunovFacetFluxElement.cpp	deleted	 
mtFEM/ale/GPConvectionProblem.cpp	deleted	 
mtFEM/ale/GPointFieldApplicator.cpp	deleted	 
mtFEM/ale/GreenGaussStencil.cpp	deleted	 
mtFEM/ale/InitialFieldCreator.cpp	deleted	 
mtFEM/ale/InriaCell.cpp	deleted	 
mtFEM/ale/IsoParametricReZoner.cpp	deleted	 
mtFEM/ale/IterativeReZoner.cpp	deleted	 
mtFEM/ale/LagrangianReZoner.cpp	deleted	 
mtFEM/ale/Laplacian2DReZoner.cpp	deleted	 
mtFEM/ale/Laplacian3DReZoner.cpp	deleted	 
mtFEM/ale/LastStepReZoner.cpp	deleted	 
mtFEM/ale/LeastSquareStencil.cpp	deleted	 
mtFEM/ale/Limiter.cpp	deleted	 
mtFEM/ale/LinearRecCell.cpp	deleted	 
mtFEM/ale/LinearRecEdgeFluxElement.cpp	deleted	 
mtFEM/ale/LinearRecFacetFluxElement.cpp	deleted	 
mtFEM/ale/LockUnknown.cpp	deleted	 
mtFEM/ale/LockUnknownAccessImplementor.cpp	deleted	 
mtFEM/ale/MeshBuilder.cpp	deleted	 
mtFEM/ale/MeshPointDetector.cpp	deleted	 
mtFEM/ale/NodalConvectionProblem.cpp	deleted	 
mtFEM/ale/NodalFieldApplicator.cpp	deleted	 
mtFEM/ale/OptiReZoner.cpp	deleted	 
mtFEM/ale/PostStep.cpp	deleted	 
mtFEM/ale/ReZoner.cpp	deleted	 
mtFEM/ale/ReZoner2D.cpp	deleted	 
mtFEM/ale/ReZoningStep.cpp	deleted	 
mtFEM/ale/ReZoningType.cpp	deleted	 
mtFEM/ale/SplineCurveReZoner.cpp	deleted	 
mtFEM/ale/Stencil.cpp	deleted	 
mtFEM/ale/Tm2DReZoner.cpp	deleted	 
mtFEM/ale/Tm3DReZoner.cpp	deleted	 
mtFEM/ale/Unknown.cpp	deleted	 
mtFEM/ale/UnknownAccessImplementor.cpp	deleted	 
mtFEM/ale/UpdEulerCurveReZoner.cpp	deleted	 
mtFEM/extractors/GapMaxValueExtractor.cpp	deleted	 
mtFEM/extractors/NcValueExtractor.cpp	deleted	 
mtFEMBase/ElementPropertyIDs.cpp	deleted	 
mtFEMBase/MaterialLawPropertyIDs.cpp	deleted	 
mtFEMBase/MaterialPropertyIDs.cpp	deleted	 
_mtFEM/initFEMShadow.h	deleted	 
_mtGlobal/initGlobalShadow.h	deleted	 
_mtKernel/initKernelShadow.h	deleted	 
mtFEM/ale/AbscisseCurveReZoner.h	deleted	 
mtFEM/ale/AleMethod.h	deleted	 
mtFEM/ale/AngleReZoner.h	deleted	 
mtFEM/ale/AnisotropicLimiter.h	deleted	 
mtFEM/ale/ArcCurveReZoner.h	deleted	 
mtFEM/ale/AreaPullReZoner.h	deleted	 
mtFEM/ale/AuxiliaryMeshBuilder.h	deleted	 
mtFEM/ale/AuxiliaryVelMeshBuilder.h	deleted	 
mtFEM/ale/BarthLimiter.h	deleted	 
mtFEM/ale/BcInteraction.h	deleted	 
mtFEM/ale/BlendedReZoner.h	deleted	 
mtFEM/ale/BoundaryCell.h	deleted	 
mtFEM/ale/BoundaryCellElShcuts.h	deleted	 
mtFEM/ale/BoundaryReZoner.h	deleted	 
mtFEM/ale/BPointReZoner.h	deleted	 
mtFEM/ale/ContactConvectionProblem.h	deleted	 
mtFEM/ale/ContactConvector.h	deleted	 
mtFEM/ale/ConvectionFieldApplicator.h	deleted	 
mtFEM/ale/ConvectionProblem.h	deleted	 
mtFEM/ale/ConvectionStep.h	deleted	 
mtFEM/ale/Convector.h	deleted	 
mtFEM/ale/CurveAuxMeshBuilder.h	deleted	 
mtFEM/ale/CurveVelMeshBuilder.h	deleted	 
mtFEM/ale/EdgeFluxElement.h	deleted	 
mtFEM/ale/EquipotentialReZoner.h	deleted	 
mtFEM/ale/EulerianReZoner.h	deleted	 
mtFEM/ale/FacetFluxElement.h	deleted	 
mtFEM/ale/FieldUnknown.h	deleted	 
mtFEM/ale/FieldUnknownAccessImplementor.h	deleted	 
mtFEM/ale/FluxElement.h	deleted	 
mtFEM/ale/FluxElementShcuts.h	deleted	 
mtFEM/ale/FluxGaussPoint.h	deleted	 
mtFEM/ale/Giuliani2DReZoner.h	deleted	 
mtFEM/ale/Giuliani3DReZoner.h	deleted	 
mtFEM/ale/GodunovCell.h	deleted	 
mtFEM/ale/GodunovCellElShcuts.h	deleted	 
mtFEM/ale/GodunovConvector.h	deleted	 
mtFEM/ale/GodunovEdgeFluxElement.h	deleted	 
mtFEM/ale/GodunovFacetFluxElement.h	deleted	 
mtFEM/ale/GPConvectionProblem.h	deleted	 
mtFEM/ale/GPointFieldApplicator.h	deleted	 
mtFEM/ale/GreenGaussStencil.h	deleted	 
mtFEM/ale/InitialFieldCreator.h	deleted	 
mtFEM/ale/InriaCell.h	deleted	 
mtFEM/ale/InriaCellElShcuts.h	deleted	 
mtFEM/ale/IsoParametricReZoner.h	deleted	 
mtFEM/ale/IterativeReZoner.h	deleted	 
mtFEM/ale/LagrangianReZoner.h	deleted	 
mtFEM/ale/Laplacian2DReZoner.h	deleted	 
mtFEM/ale/Laplacian3DReZoner.h	deleted	 
mtFEM/ale/LastStepReZoner.h	deleted	 
mtFEM/ale/LeastSquareStencil.h	deleted	 
mtFEM/ale/Limiter.h	deleted	 
mtFEM/ale/LimiterType.h	deleted	 
mtFEM/ale/LinearRecCell.h	deleted	 
mtFEM/ale/LinearRecCellElShcuts.h	deleted	 
mtFEM/ale/LinearRecEdgeFluxElement.h	deleted	 
mtFEM/ale/LinearRecFacetFluxElement.h	deleted	 
mtFEM/ale/LockUnknown.h	deleted	 
mtFEM/ale/LockUnknownAccessImplementor.h	deleted	 
mtFEM/ale/MeshBuilder.h	deleted	 
mtFEM/ale/MeshPointDetector.h	deleted	 
mtFEM/ale/NodalConvectionProblem.h	deleted	 
mtFEM/ale/NodalFieldApplicator.h	deleted	 
mtFEM/ale/OptiReZoner.h	deleted	 
mtFEM/ale/PostStep.h	deleted	 
mtFEM/ale/ReZoner.h	deleted	 
mtFEM/ale/ReZoner2D.h	deleted	 
mtFEM/ale/ReZoningStep.h	deleted	 
mtFEM/ale/ReZoningType.h	deleted	 
mtFEM/ale/SplineCurveReZoner.h	deleted	 
mtFEM/ale/Stencil.h	deleted	 
mtFEM/ale/StencilType.h	deleted	 
mtFEM/ale/Tm2DReZoner.h	deleted	 
mtFEM/ale/Tm3DReZoner.h	deleted	 
mtFEM/ale/Unknown.h	deleted	 
mtFEM/ale/UnknownAccessImplementor.h	deleted	 
mtFEM/ale/UpdEulerCurveReZoner.h	deleted	 
mtFEM/extractors/GapMaxValueExtractor.h	deleted	 
mtFEM/extractors/NcValueExtractor.h	deleted	 
mtFEMBase/ElementPropertyIDs.h	deleted	 
mtFEMBase/MaterialLawPropertyIDs.h	deleted	 
mtFEMBase/MaterialPropertyIDs.h	deleted	 
mtFEM/ale/AleMethod.inl	deleted	 
mtFEM/ale/BoundaryCellElShcuts.inl	deleted	 
mtFEM/ale/FluxElementShcuts.inl	deleted	 
mtFEM/ale/GodunovCellElShcuts.inl	deleted	 
mtFEM/ale/InriaCellElShcuts.inl	deleted	 
mtFEM/ale/LinearRecCellElShcuts.inl	deleted	 
mtFEM/ale/Stencil.inl	deleted	 
mtGlobal/IDListTemplate.inl	deleted	 
mtKernel/PropertyID.inl	deleted	 

intelSig/wrap	added	 
sabca/wrap	added	 
intelSig/src/mtIntelSig.cpp	added	 
sabca/src/mtSabca.cpp	added	 
intelSig/src/mtIntelSig.h	added	 
intelSig/wrap/mtIntelSig.i	added	 
sabca/wrap/mtSabca.i	added	 
intelSig/wrap/Makefile.in	added	 
sabca/wrap/Makefile.in	added	 

— Romain BOMAN 2007/08/28 11:36