J'ai interfacé le solveur itératif des MKL. Il s'appelle ISSolver (Iterative Sparse Solver). C'est un GMRES tout à fait classique qui possède 2 préconditionneurs (ILU0 et ILUT). Le gros avantage, c'est qu'il remplace le solveur de Petsc. J'ai donc supprimé toutes les références à Petsc dans le code. L'utilisation du solveur petsc a été remplacée par le solveur ISSolveur dans les cas-tests.

J'ai même fait la doc: ISSolver

Une des tâches du projet FABULOUS est de déplacer la base de données monolithique (la “DB oofelie”) vers la géométrie et en particulier vers les noeuds et les points. C'est une opération assez complexe mais très utile car elle facilitera toutes les futures tâches dont on parle souvent: modification de maillages en cours de calcul, ajout/suppression de noeuds, parallélisme, etc.

Pour cette première étape, j'ai largement modifié l'ancien “mécanisme PhySet”. Pour rappel, le mécanisme PhySet permet:

• d'une part d'accéder à la DB de plus ou moins n'importe ou dans le code via un “findDBSet()”
• et d'autre part d'accéder à d'autres objets PhySet via un “findObject()”.

Le premier problème vient justement de ces deux fonctionnalités tout à fait différentes mais qui utilisent le même chemin dans le code. C'est pas clair du tout et quand on a mal configuré ses objets, on se retrouve avec des bugs très difficiles à corriger.

Pour isoler la partie “accès DB” et pour pouvoir la déplacer prochainement, je me suis attaqué à la routine “findObject()” que j'ai presque complètement désactivée. Ce qui reste aujourd'hui sont des accès DB par findObject (et oui, ca existe!).

Il n'est donc plus possible d'écrire par exemple: “findObject(DOMAIN_ID)”. Pour contrer ceux qui voudraient quand même l'utiliser, DOMAIN_ID n'existe plus! Les objets peuvent être atteint par d'autres mécanismes. Par exemple, pour un élément, on accède à son interaction par “getInteraction()” et de l'interaction au Domain par un “getDomain()” supplémentaire. Les accès sont donc beaucoup plus explicites qu'auparavant et ça ne peut pas faire de tort.

Au niveau de la géométrie, j'ai rendu les relations entre objets un peu plus claires. Il est par exemple possible d'accéder à la géométrie d'un objet par object.getGeometry(). L'objet “père” d'un objet géométrique est maintenant toujours le set associé (le père d'un Point doit être le PointSet). Ceci m'a posé un problème parce que la relation “objet géométrique” ⇒ “père” était également utilisée comme lien signifiant “objet maillage” ⇒ “entité CAO maillée”. J'ai donc du séparer ces deux relations en créant un nouveau pointeur dans GObject. Ce pointeur, nommé “meshParent” permet de faire le lien entre, par exemple, un point du maillage et l'entité sur laquelle il repose. Le pointeur est assigné lors du addMeshPoint.

Pour la suite, je vais tenter de supprimer complètement les “_ID” des objets et les quelques appels “findObject” qui restent. Il sera alors possible de déplacer la DB dans un endroit plus proche des points. PhySet devrait pouvoir être supprimé à ce moment.

J'utilise maintenant les MKL-10.2. Elles sont disponibles sur le FTP. N'oubliez pas de recompiler numpy si vous changez vos libs.

Il n'est pas obligatoire de faire cette mise à jour. Si vous avez un problème avec le FindMKL de CMake, introduisez en dur les libs MKL dans votre fichier .cmake.

L'install CMake a été amélioré (l'install de gen4 et geniso n'était pas faite). MetaforSetup a été adapté. Il est fonctionnel sous Windows.

• Suppression du leak (swig/python detected a memory leak of type 'DBIndex *', no destructor found.
• Suppression d'un assert dans UniformLoading (les tests Bacons utilisant des forces imposées ne passaient pas en debug).

— Romain BOMAN 2010/07/05 13:03