February 12, 2004

Ce commit est une étape supplémentaire vers la généralisation de l'ALE dans Oofelie et plus principalement des schémas de convection par volumes finis.

Depuis quelques versions, il est possible de générer un maillage et de générer des éléments finis sur les mailles créées (via la magnifique classe FieldApplicator). Comme je viens de le dire c'est possible mais malheureusement pas obligatoire; si bien que les deux manières de faire cohabitent et ça rend ma tâche de généralisation de l'ALE très ardue. J'ai donc retroussé mes manches et j'ai supprimé définitivement la manière "Oofelie". Le gros du boulot était, bien sûr, de convertir tous les cas-tests qui datent de l'époque lointaine où on commitait des fichiers .e résultants de la moulinette Z-Mesh (ne plus le faire, svp!).

Voici les étapes suivies:

1. Modification de MeshedObject: les objets maillés possèdent maintenant une liste de points (de la géométrie maillage) qui remplace la liste des noeuds. On y accède via MeshedObject::getMeshPoint(int). Pour l'instant, la liste de noeuds est toujours là mais elle n'est (presque) plus utilisée. Elle est remplie pendant le prépro lors de l'exécution des FieldApplicator. Pourquoi remplacer des noeuds par des points? C'est vrai que ça change rien pour la majorité des cas-tests. Par contre, dans le cas des éléments de Laurent où le champ thermique est de degré 2 et la géométrie de degré 1, on a un avantage très intéressant: chaque point d'une maille possède un noeud et chaque arête aussi. On peut donc très facilement distinguer les types de noeuds. Imaginons qu'on veuille boucler sur les noeuds d'une face. Avant, on faisait un Side::getNode() et on s'arrangeait avec des flags pour savoir si un noeud était un noeud d'interface ou pas. Maintenant, on boucle sur les points du maillage de la face et, ensuite, sur les arêtes. Chaque point peut avoir un noeud EF et chaque arête aussi (idem pour les facettes mais on n'a pas d'éléments avec des noeuds internes).

Par exmeple,Au niveau élémentaire (cas 2D), si je veux boucler sur les noeuds d'un elem :

• elem.getTopology()->getSide(0)->getPoints(i)->getNode(0); (noeud associé au sommet i), puis
• elem.getTopology()->getCurve(i)->getNode(j); (noeud j associé à l'arête i) et enfin,
• elem.getTopology()->getSide(0)->getNode(i); (noeud i associé à la facette)

On voit donc que, en pratique, une courbe de la géométrie utilisateur aura un nombre de points de maillage non nul et un nombre de noeuds nul. Par contre, une courbe définissant une arête du maillage aura un nombre de points nul (pas de maillage associé) et, éventuellement un ou plusieurs noeuds (au maximum 1 pour Metafor actuel). Ci-dessous, un petit schéma qui résume tout ça:

(Cliquez dessus pour agrandir)

Dans le cas de l'ALE, je vais plus loin: une arête peut avoir un nombre de points de maillage non nul parce que je crée un maillage en "remaillant les mailles" (si,si, ça marche!)

Au niveau de MeshedObject, il reste donc à :

• virer le remplissage du tableau de noeuds pour les entités géométriques de l'utilisateur.
• virer les points de maillage extrêmes dans le cas d'une courbe (en effet, une ligne maillée possède une référence vers les noeuds de ses extrémités. Cette référence devrait être unique et attribuée au points extrême.

2. Modification de NumberedObject: mise au point d'un système de recherche des points de maillage comparable à celui qui existe pour les noeuds (initNodeSearch devient initMeshPointSearch). J'ai eu qq problèmes pour gérer les recherches imbriquées (dans la génération des éléments de contact) et je généraliserai le système aux recherches imbriquées lors d'un prochain commit.

3. Modification des cas-tests .e: C'est assez automatique si bien que je peux vous donner les regular expressions à introduire dans EditPad ou PowerGrep. Pour vous donner une idée du boulot, j'ai passé 3 jours rien qu'à faire ça.

4. ALE: création d'un FieldApplicator relatif aux volumes finis : c'est la nouvelle classe GPointFieldApplicator.

5. ALE: génération "propre" de la géométrie du maillage auxiliaire et gestion des conditions aux limites associées (en cours de développement).

6. Matériaux: Creation d'un constructeur virtuel pour les points de Gauss (voir GpStateBase.h). Chaque point de Gauss peut donc se cloner. C'est utile pour séparer les trucs ALE de l'élément Metafor. La configuration ALE du point de Gauss sera ainsi gérée par le volume fini ALE (InriaCell) et non plus par l'élément! J'espère pouvoir supprimer toute trace d'ALE dans l'élément fini grande défo très prochainement. C'est la clef de la généralisation de l'ALE pour tout type d'éléments.

7. Création d'un PointBuilder: je sais pas si c'est utile mais c'est sensé permettre de créer des mailles ponctuelles (pour les éléments de masse par exemple). Peut-être que ça disparaitra plus tard.

8. Modification des classes Loading et Fixaset: ces classes nécessitent de boucler sur l'entièreté des noeuds d'une entité. Cette opération est plus compliquée qu'avant puisque les noeuds ne sont pas directement accessibles (il faut boucler sur les points, les edges, les facettes et les volumes élémentaires). C'est ce qu'on fait maintenant. Il faut cependant s'attendre à des pertes de performences vu la complexité accrue de la procedure (j'y jetterai un oeil plus tard - de nombreuses optimisations sont possibles).

EN RESUME: Au niveau "utilisateur", la philosophie est la suivante:

• Oublier PositionSet::define() : l'utilisateur ne doit jamais toucher àce truc (c'est pas nouveau). Je vais d'ailleurs le désactiver dans une prochaine version.
• Oublier NodeSet::define() : on ne crée plus des noeuds mais plutôt des points (l'utilisateur "dessine" des mailles). Metafor se chargera de créer la physique sur le maillage. Bref, on utilise domain[TOPOLOGY_PO][POINTSET_PO].define() à la place.
• Oublier ElementSet::define() : je vais le virer ou, au moins, il ne fonctionnera plus avec des éléments dérivant de MetaElement (éléments Metafor). On ne crée plus des éléments à la main mais des mailles ! Pour ce faire, on utilise domain[TOPOLOGY_PO].define() en spécifiant le type de maille (par exemple CELL_QUAD pour un quad).
• Remarque pour les développeurs: l'ancien Topology::build() n'est donc plus jamais appelé (je vais virer aussi). La géométrie du maillage est créée lors de chaque ajout de maille de manière incrémentale.
• Les groupes de noeuds ( grp.addNode() ) deviennent des groupes de points de maillage ( grp.addMeshPoint() ).
• Partout où on addressait des noeuds via un NODE_PO (loadingset, fixations, etc), on continue à écrire NODE_PO mais Metafor va rechercher un Point lors de l'exécution de la commande. En effet, les numéros des noeuds sont générés par Metafor et ne sont plus prédictibles.
• Lorsque le maillage est dessiné, on applique des Interactions sur le maillage. Pour générer des volumes, des ressorts et des masses, on utilise le FieldApplicator. Pour les autres types (contact, pressions, etc), rien n'a changé au niveau de l'interface. Pour les propriétés (PropElem), elles doivent être appliquées au niveau de l'interaction pour les éléments de condition aux limites et au niveau de l'entité géométrique "père" des mailles pour le FieldApplicator (j'unifierai ça plus tard).
• Certaines commandes archaïques (par exemple Metafor::setInitialVelocity()) doivent être appelées APRES la génération des éléments parce qu'elles fonctionnent sur les noeuds.

Autre truc que j'ai remarqué:

Les éléments de traction sont utilisés "à l'envers" en 3D (parce que les normales d'une volume hexa pointent vers l'intérieur - héritage de Denis Graillet) et à l'endroit en 2D (les normales pointent à l'extérieur dans ce cas). Si bien que pour appliquer une pression, on donne un nombre positif en 3D et négatif en 2D.

Dernière remarque:

Si vous comprenez pas la nouvelle philosophie ou si vous lui trouvez des défauts, venez m'en parler. D'après moi, voilà ce qu'on peut donner comme avantages actuellement:

• découplage des "mailles" (géométrie) et des éléments finis (physique). Ca entraine la suppression de beaucoup de couper/coller à terme et conceptuellement, c'est propre et beau.
• suppression de l'étape artificielle de reconstruction de la géométrie (Topology::build) avec tout ce que ça entraîne (voir les crasses dans MetaElement::buildTopology()).
• possibilité de gérer des noeuds d'interface de manière souple (sans flag bidon au niveau de chaque noeud - faut d'ailleurs que je pense à le virer, il est inutile).
• possibilité de générer des éléments thermiques du second degré sur un maillage Bacon ou Z-Mesh.
• possibilité de généraliser l'ALE à tous les éléments (actuels et futurs).
• suppression (future) du MetaElement::fillAndConvertNodeVector(). Ouf!

et les inconvénients:

• consomation de mémoire accrue. J'ai des idées pour y remédier (en délégant la gestion de mémoire relative à MeshedObject dans les classes dérivées par exemple)
• pas possible de gérer plusieurs éléments par maille actuellement (pas possible de mettre facilement des ressorts en parallèle par exemple). Pour lever cette limitation, il "suffirait" d'améliorer la classe ElementContainer qui fait l'interface entre les mailles et les éléments.
• application des fixations plus lente. Là aussi, la généralité à un coût. On pourrait facilement accélérer le truc en stockant plus d'infos au niveau de MeshedObject (compromis "rapidité-consomation mémoire réduite" à discuter).

Fichiers ajoutés:

./oo_ale/GPointFielApplicator.*
./oo_geo/PointBuilder.*

	created : February 10, 2004		modified : February 12, 2004
	contact : r_boman_AT_yahoo.fr