Programmation orient´ ee objet d’un code ´ el´ ements finisfinis

3.3.2.1 D´emarche de d´eveloppement

La mise en oeuvre de la strat´egie de calcul associ´ee au d´eveloppement en s´erie de Fourier a fait l’objet du d´eveloppement d’un code prototype, bien que de nombreuses librairies de calcul ´el´ements finis soient d´ej`a disponibles sur Internet. En effet, l’objectif ´etant de tester diff´erentes id´ees, il nous fallait maˆıtriser compl`etement l’architecture du code de calcul, or l’aide fournie avec les rares librairies libres aptes `a g´erer le niveau de complexit´e requis est tr`es souvent limit´ee et le code source herm´etique pour celui qui ne connait pas l’histoire de la librairie. Gilles Lubineau et Pierre-Alain Guidault ayant aussi eu besoin d’une telle plateforme, nous avons entrepris un d´eveloppement colla-boratif. Afin d’obtenir un code flexible et ´evolutif, la programmation orient´ee objet (POO) s’est av´er´ee tr`es int´eressante (Bersini, 2002; Barrett et al., 1994; Mackerle, 2004) ; l’accent alors mis sur le dialogue entre les diff´erents objets et non pas sur les donn´ees qu’ils contiennent (Besson et Foerch, 1997; Archer, 1996). Enfin, le langage associ´e au logiciel Matlab a ´et´e choisi. Celui-ci permet un d´ebogage simple car c’est un langage interpr´et´e, de plus le calcul matriciel est tr`es efficace car bas´e sur des librairies standard performante (LINPACK, EISPACK, FFTW) ou permet d’y acc´eder (MPI). Cependant les manipula-tions de donn´ees sont ralenties par un typage dynamique. Cet inconv´enient peut ˆetre en partie pali´e par l’inclusion de code compil´e (C, C++ ou Fortran) au sein des fonctions de Matlab. Cette technique est malgr´e tout assez res-treinte dans le cas de la POO et est donc r´eserv´e aux fonctions de bas niveau. Enfin, un argument majeur dans le choix de ce langage repose sur l’id´ee qu’une programmation propre dans un langage maˆıtris´e vaut mieux qu’une program-mation maladroite dans un langage plus puissant mais non maˆıtris´e.

Pour les ´el´ements finis, deux grandes architectures existent en POO . La premi`ere consiste `a consid´erer des op´erations sur des champs comme dans CAST3M par exemple, la seconde utilis´ee ici repose sur une description plus morcel´ee des ´el´ements finis (Zimmermann et al., 1992; Dubois-P`elerin et Zim-mermann, 1992, 1993). Plus le d´ecoupage est fin et plus le code est flexible, mais plus le temps pass´e `a l’ex´ecution `a manipuler les donn´ees est cons´equent, `a moins d’utiliser des techniques de m´eta-programmation qui sont syntaxi-quement lourdes (Veldhuizen, 2000). Une attention particuli`ere doit donc ˆetre port´ee sur l’organisation des diff´erentes classes et les concepts associ´es.

3.3.2.2 Architecture du code

Dans ce paragraphe les noms des diff´erentes classes sont not´ees en caract`eres majuscules italiques. Une pr´esentation de la programmation orient´ee objet est donn´ee dans (Bersini, 2002). Commen¸cons la description de l’architecture du code d´evelopp´e par la description du mat´eriau (MATERIAU ). Celui-ci donne acc`es `a la matrice de Hooke et `a la mani`ere d’int´egrer son comportement non-lin´eaire (si besoin). En pratique, deux types de comportement existent :

σ = K(ε − Θ∆T ) dans Ωpliset F = k([U ] − αr∆T ~er) dans Γint (3.30) Deux classes MAT GRAD (bas´ee sur ε = 1

2(gradu + gradTu)) et MAT SAUT (bas´ee sur [u] = u+ − u−) h´eritent donc de la classe MATERIAU, puis les diff´erents types de comportement sont d´eclin´es par famille (figure 3.16).

MATERIAU +coefficients MAT_GRAD +matrice Hooke (6x6) MAT_SAUT +matrice Hooke (3x3) ISOTROPE +hooke(MODE_CALC) ORTHOTROPE +axes orthotropie +hooke(MODE_CALC) ORTHOTROPE_TISSU_ENDO +hooke(MODE_CALC) +integration_rdc() ORTHOTROPE_UD_ENDO +hooke(MODE_CALC) +integration_rdc()

Figure 3.16 – Diagramme UML de la classe MATERIAU et des ses descendants La matrice de Hooke calcul´ee dans le cas 3D peut ˆetre modifi´ee par des hy-poth`eses de calcul sur le champ de contraintes ou de d´eformations (contraintes planes, d´eformations planes, Fourier mode N, Fourier coupl´e, Fourier recons-truit...). La m´ethode hooke prend donc en argument un objet de type MODE CALC

(figure 3.17). Celui-ci contient les diff´erentes hypoth`eses, l’ordre de rangement des contraintes et d´eformations sous forme de vecteur et les coefficients d´eter-minant la notation de Voigt (√

2 sur la d´eformation et sur la contrainte ou 2 sur l’un ou l’autre).

MODE_CALC

+notations de Voigt

CONTRAINTE_PLANE FOURIER_N DEFO_PLANE

+harmonique

Figure 3.17 – Diagramme UML de la classe MODE CALC et des ses descen-dants

La structure compl`ete (STRUCTURE, figure 3.18) est d´ecoup´ee en sous-structures (SOUSSTRUCTURE ). Celles-ci sont de deux types (hypoth`ese de la m´eso-mod´elisation (Ladev`eze et Le Dantec, 1992)) : plis (PLI ) ou inter-faces (INTERFACE ). Le mat´eriau est suppos´e ˆetre le mˆeme dans chaque sous-structure. Celles-ci sont form´ees d’un ensemble de noeuds (NOEUD) et d’´el´e-ments (ELEMENT ). De plus, des zones d’int´egration sont d´ecrites au niveau de ces sous-structures, cela permet d’implanter facilement une int´egration non-locale des lois de comportement de chaque entit´e (endommagement uniforme dans l’´epaisseur d’un pli). Afin de parall´eliser facilement le calcul, des classes sont d´eriv´ees des classes STRUCTURE et SOUSTRUCTURE, ces nouvelles classes contiennent les informations permettant aux processus de communiquer (orientation des flux de donn´ees). L’´elimination des noeuds ´etant automatique, il est n´ecessaire de s´eparer les noeuds de l’interface en deux groupes de part et d’autre de celle-ci. Les noeuds contiennent leurs coordonn´ees et des donn´ees (d´eplacements nodaux, contraintes, variables internes...).

Les ´el´ements (figure 3.19) sont de deux types, toujours pour prendre en compte les interfaces. De plus les ´el´ements d’interface ´etant bas´es sur des fonc-tions de formes classiques, ils sont en fait compos´es de deux ´el´ements clas-siques et permettent donc de recoller des ´el´ements incompatibles (fonctions de forme diff´erentes). Les ´el´ements sont li´es aux noeuds de la sous-structure et contiennent un objet de classe INTEGRATION. Ce dernier met en oeuvre la

STRUCTURE

+ensenble de SOUSSTRUCTURE +rigidite()

+conditions limites(): COND_LIMITES +resolution lineaire()

+resolution non lineaire()

SOUSSTRUCTURE +numerotation ddls +ensemble ELEMENT +ensemble NOEUDS +zones integration +rigidite() +conditions limites() STRUCTURE_MAITRE STRUCTURE_ESCLAVE SOUSSTRU_ESCLAVE SOUSTRU_MAITRE PLI INTERFACE

+ensemble NOEUD dessus +ensemble NOEUD dessous

Figure 3.18 – Diagramme UML de la classe STRUCTURE et des ses descen-dants

proc´edure d’int´egration intervenant dans le calcul de la matrice de rigidit´e par exemple. Il est d´efini au niveau des ´el´ements afin de pouvoir varier d’un ´el´e-ment `a un autre afin d’implanter facile´el´e-ment la XFEM et l’utilisation de level sets.

ELEMENT