Commit 2013-06-21

Commit sur le couplage XFEM et ALE. Pour l'instant je n'ai pas commité les cas-test, je ferais ca plus tard une fois les derniers problèmes résolu (concentration de contraintes et pertes de symétrie du problème lors du sous découpage).

J'ai implanté la ALE en utilisant une partition de l'opérateur éulérien-lagrangien.

La phase de relocalisation des noeuds consiste à repositionner le maillage dans sa position initiale. Vu que l'on utilise des XFEM, le domaine maillé peut être un “carré” maillé de manière régulière. La level-set informe de la position de la frontière de la structure.

La phase de transfert des données est par contre plus complexe : une fois que l'on a relocalisé les noeuds et reconstruit la nouvelle level set sur le maillage (traduisant la position de la frontière dans la configuration courante), il faut redéfinir les cellules d'intégration sur les éléments découpés par la frontière. Le transfert des données aux points de Gauss est réalisé en utilisant les éléments non-découpés et les cellules d'intégration.

Après avoir passé pas mal de temps à essayer d'implémenter la méthode X-ALE-FEM dans le code C++ (de manière transparente pour l'utilisateur, à l'image de la ALE actuelle), j'ai fini par introduire la ALE dans le jeu de données python.

Le problème venait du fait que mes objets “ElementSet” sont constitués des éléments XFEM non-découpés et des cellules d'intégration. Aussi, même si la topologie du maillage (élements XFEM) reste inchangée, la dimension de mon ElementSet changeait.

J'ai essayé de créer une “XALEMethod” pour réaliser le transfert et échanger les objets “Domain” et “ElementSet” après transfert, mais il y avait toujours des problèmes de liaison (entre autre au niveau des pointeurs).

Etant donné le temps que j'ai passé sur le sujet, j'ai malgré tout commité les fichiers “XALEMethod”, “XFEMGPTransferProblem” et “XFEMNodalTransferProblem” (dossier _Unactive files) au cas où quelqu'un retravaillerait sur les XFEM et voudrait se pencher sur l'implémentation “en dur” de la XALEMethod . Ces fichiers regroupent une partie des développements inachevés sur le sujet.

Le X-ALE-FEM s'appuie sur les opérateurs de transfert déjà développés et sur une opération de remaillage global. De plus, étant donné que la phase de transfert (et donc de sous-découpage) est couteuse, j'ai décidé de n'activer la ALE que si le maillage devient trop mauvais (indicateurs implantés par Cédric).

Pour faire bref, le fonctionnement est le suivant :

• On fait un pas de calcul
• On vérifie la qualité du maillage
• Si le maillage a une qualité insuffisante, on enregistre les frontières actuelles de la structure (frontières matière et frontières de chargement)
• On reconstruit un nouvel objet metafor et un nouveau domain en utilisant ces frontières
• On transfert les données entre les deux maillages
• On reprend le calcul sur ce nouveau maillage

Pour le moment, la stratégie X-ALE-FEM ne fonctionne que si on utilise un unique point de Gauss par sous-cellule d'intégration (j'ai définit un mtGeoTriangleSplitter a l'image du mtGeoQuadSplitter (algo pour split des cellules d'intégration triangulaires en 3 quad)).

Il reste des problèmes à régler… Entre autre au niveau des sur-contraintes pour les éléments possédant une faible quantité de matière. Je n'ai pas commité de cas test X-ALE-FEM le temps de régler le problème (et je vais surement essayer de construire une toolbox pour simplifier le jeu de données).

Afin d'utiliser les fonctions de transfert “classiques” '(qui travaillent entre ElementSet et non entre XFEMElementSet), j'ai défini une classe “SubInteraction”, dont la seule fonction est de copier dans son propre ElementSet le XFEMElementSet du XFEMFieldApplicator avant de réaliser le transfert.

Pour “copier” les transferts actuellement utilisés dans Metafor, j'ai également défini une classe de transfert, une transferCell et une transferRegion spécifiques aux XFEM.

A venir une fois que j'aurais fait le nettoyage. Pour information et si quelqu'un veux me donner une vision critique sur la syntaxe, j'ai commité un fichier “X-ALE-FEM_frictionless.txt” qui fonctionne.

Les quelques modifications effectuées en dehors des sous-dossiers XFEM et XFEMDrawables (pour contrôle).

Il y avait quelques output pendant les phases de transfert que je trouvais “inutiles” et qui pour moi empêchaient une bonne lecture de la sortie Metafor. Etant donné que je ne suis pas le seul à utiliser les opérateurs de transfert, je les ai commentées et j'ai rajouté un commentaire “displayTransferALE” afin de les retrouver. Si vous jugez qu'ils étaient utiles, je peux les remettres. Sinon on peut supprimer les lignes.

J'avais besoin d'interfacer 3 fonctions en python et de pouvoir les récupérer sur mes interactions spécifiques. J'ai défini 3 fonctions virtuelles supplémentaires dans interaction (NOT_IMPLEMENTED)

virtual std::vector<mtGeo::Curve *> exportBoundaryPos(mtGeo::Geometry &newGeo);
virtual bool restartNeeded(double siRef, double arRef) ;
virtual mtGeo::Geometry &getXFEMSides() ;

Ajout d'un variable bool à ElemDataSet,ElementCloud pour forcer un update de la visu. Dans le cas XFEM, l' “ElementSet” utilisé pour l'affichage regroupe les éléments non découpés et les cellules d'intégration des éléments découpés. Le nombre d'éléments de l'ElementSet varie donc d'un pas à un autre et la vizu ne réagissait pas correctement.

- Correction de DummyCouplingMeshes (la fonction “execute” n'était jamais appelé et l'execute réalisé était celui du FECouplingMeshes).

- Changement de l'IPMeshBuilder : la verification du nombre de point de Gauss (nbIp==1 || nbIp==2) a été transférée depuis la fonction MeshSide, vers le constructeur.

- Monomesher2D construit désormais aussi bien des quad que des tri

J'ai fait un petit chkrep.py avant de commiter. J'ai été étonné du nombre d'alertes qu'il y avait. Ce serait bien si tout le monde le faisait avant de faire un commit je pense .

Les derniers trucs que je n'ai pas réglé car incertain de la marche a suivre :

'#include "gisoSimplifyMesh.h"' not the first file included in [D:\Ewen\Commit\oo_meta\geniso\src\gisoSimplifyMesh.cpp]
'#include "gisoVtkTools.h"' not the first file included in [D:\Ewen\Commit\oo_meta\geniso\src\gisoVtkTools.cpp]
'using namespace' found in [D:\Ewen\Commit\oo_meta\geniso\src\gisoVtkTools.h]
VTKHAUSDORFFDISTANCEPOINTSETFILTER_H not found 3x in [D:\Ewen\Commit\oo_meta\geniso\src\vtkHausdorffDistancePointSetFilter.h]
RESOURCE_H not found 3x in [D:\Ewen\Commit\oo_meta\mtMain\resource.h]
'#include "mtMain.h"' not found in [D:\Ewen\Commit\oo_meta\mtMain\resource.h]
RESOURCE_H not found 3x in [D:\Ewen\Commit\oo_meta\stp2py\resource.h]
UNISTD_H not found 3x in [D:\Ewen\Commit\oo_meta\stp2py\win32\unistd.h] 

[r]:
[a]:mtGeo/mtGeoTriangleSplitter.cpp
[a]:mtXFEM/SubInteraction.cpp
[a]:mtXFEM/XFEMIPMeshBuilder.cpp
[a]:mtXFEM/XFEMToXFEMTransfer.cpp
[a]:mtXFEM/XFEMTransferCell.cpp
[a]:mtXFEM/XFEMTransferRegion.cpp
[a]:mtGeo/mtGeoTriangleSplitter.h
[a]:mtXFEM/SubInteraction.h
[a]:mtXFEM/XFEMIPMeshBuilder.h
[a]:mtXFEM/XFEMToXFEMTransfer.h
[a]:mtXFEM/XFEMTransferCell.h
[a]:mtXFEM/XFEMTransferRegion.h
[a]:mtXFEM/_Unactive files
[a]:mtXFEM/_Unactive files/README.txt
[a]:mtXFEM/_Unactive files/XALEMethod.cpp.txt
[a]:mtXFEM/_Unactive files/XALEMethod.h.txt
[a]:mtXFEM/_Unactive files/XFEMGPTransferProblem.cpp.txt
[a]:mtXFEM/_Unactive files/XFEMGPTransferProblem.h.txt
[a]:mtXFEM/_Unactive files/XFEMNodalTransferProblem.cpp.txt
[a]:mtXFEM/_Unactive files/XFEMNodalTransferProblem.h.txt

[r]:apps/XFEM/a_debug_cl.py
[a]:apps/XFEM/A_Reunion_ALE_cont_frictionless.txt