====== Commit 2007-08-28 ====== {{commit:hot.gif|}} __Ceci est un gros commit: ne mettez pas à jour sans avoir un peu de temps à y consacrer__ {{commit:hot.gif|}} Pour ceux qui se fient aveuglément à Luc, lisez au minimum les paragraphes "Conséquences" de chaque section. ===== Modifs ===== ==== Redistribution des PropertyIDs ==== 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 [[http://www.unknownroad.com/rtfm/VisualStudio/warningC4251.html|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. {{commit:cube.gif|}} __Conséquence:__ {{commit:cube.gif|}} ''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 * ... ==== Accès python aux variables globales ==== 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... {{commit:cube.gif|}} __Conséquence:__ {{commit:cube.gif|}} 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''. ==== Suppression des dépendances cycliques entre DLL ==== 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! {{commit:cube.gif|}} __Conséquence:__ {{commit:cube.gif|}} 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... ==== Suppression des dépendances superflues ==== 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''. {{commit:cube.gif|}} __Conséquence:__ {{commit:cube.gif|}} 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" ? ;-) ==== Metafor sous "python pur" (Unix) ==== 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 [[http://mail.python.org/pipermail/c++-sig/2005-April/008829.html|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. ==== Création des wrappers manquants ==== 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'') === _mtPython === Contient les classes d'extension "python" telles que la ''PythonCurve'' et l'interpréteur python customisé pour Metafor. === _mtMaterialLaws === Contient les codes de propriétés des ''MaterialLaws''. === _mtMaterials === Contient les codes de propriétés des ''Materials''. === _mtElements === Contient les codes de propriétés élémentaires ainsi que certaines classes telles que ''FieldApplicator'' et les autres interactions spécifiques à Metafor. === _mtThixo === Contient les codes du matériau thixo et des lois associées. === _mtSabca === Contient les codes du matériau SABCA et des lois associées (répertoire ''oo_nda/sabca/wrap''). === _mtIntelSig === Contient l'élément XFEM et autres larateries (répertoire ''oo_nda/intelSig/wrap''). === _mtALE === Contient les crasses ALE et autres bomaneries. {{commit:cube.gif|}} __Conséquence:__ {{commit:cube.gif|}} Une solution Visual avec 42 projets! ==== Module mtALE ==== 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 {{commit:cube.gif|}} __Conséquence:__ {{commit:cube.gif|}} 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! ==== Nettoyages ==== 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'') ==== Nouveau script ==== 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. === Correction des end-of-line (EOL) === 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 ... === Correction des props === 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. ==== Amélioration des makefiles Unix ==== 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. ==== Suppression des warnings ==== * 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. {{commit:cube.gif|}} __Conséquence:__{{commit:cube.gif|}} Votre projet peut compiler "tout vert" en Warning level 3 sous VS 2005. ===== Projet ===== Créez les nouvelles DLL, vérifiez vos répertoires d'includes et vos dépendances... et c'est fini! :-P __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): {{ commit:2007:keepunref.png |Et hop, on garde les symboles non référencés!}} * 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 :-D. 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. {{ commit:2007:dynload.png |Chargement d'éléments au runtime (grâce à ce brave python)}} * Si vous doutez sur un dépendance entre lib, regardez les Makefiles Unix (nommés ''Makefile.in''). ===== Fichiers ajoutés/supprimés ====== _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 --- //[[r_boman@yahoo.fr|Romain BOMAN]] 2007/08/28 11:36//