Archi

Architecture de la plateforme LMGC90? . Fr´ed´eric Dubois [email protected] Laboratoire de M´ ecanique et G´ enie Civil Universit´ e de Montpellier 2 - CNRS

2007

? Logiciel

de M´ecanique G´erant le Contact en Fortran90.

F. Dubois (CNRS)

Architecture de LMGC90

2007

1 / 24

Plan

1

Motivations

2

Principes de programmation

3

Archictecture g´en´erale

4

Aujourd’hui

5

Perspectives

6

LMGC90v2

F. Dubois (CNRS)

Architecture de LMGC90

2007

2 / 24

LMGC90::Motivations

D´evelopper une plateforme de mod´elisation des milieux “divis´es”. Avec des contraintes fortes : P´erenniser un savoir faire existant important mais dispers´e, Disposer d’une plateforme d’accueil pour les d´eveloppements futurs qui r´eponde aux exigences de la mod´elisation: ´ Evolutive (en d´eveloppement perp´etuel de chose non pr´evues) Adaptative (r´eorganisation perp´etuelle) P´erenne (ce qui est fait est fait)

Diffuser la connaissance. Disposer d’un support de collaborations scientifiques. Valoriser.

F. Dubois (CNRS)

Architecture de LMGC90

2007

3 / 24

LMGC90::Principes de programmation

Mˆeme d´evelopp´e en FORTRAN90 LMGC90 repose sur des notions de programmation orient´ee objet : classe : attributs + m´ethodes On construit un module qui d´efinit un type utilisateur (globale) et impl´emente des proc´edures qui s’appliquent sur ce type encapsulation : gestion de la visibilit´e des attributs et m´ethodes Statut public/private.

F. Dubois (CNRS)

Architecture de LMGC90

2007

4 / 24

LMGC90::Principes de programmation module test implicit none private type T_test integer :: ID real(kind=8) :: value end type contains subroutine test_init(obj_test) implicit none type(T_test) :: obj_test .... end subroutine ... end module test F. Dubois (CNRS)

Architecture de LMGC90

2007

6 / 24

LMGC90::Principes de programmation type “public” Ü danger public type T_test integer :: ID real(kind=8) :: value end type

type(T_test) :: toto toto%ID=1 ...

type semi “public” Ü bien public type T_test type(T_test) :: toto private toto%ID = 1 ! NON integer :: ID real(kind=8) :: value end type type “private” Ü paranoiaque : les modules sont aussi les containers ! private type T_test integer :: ID real(kind=8) :: value end type F. Dubois (CNRS)

Architecture de LMGC90

type(T_test) :: toto ! NON

2007

8 / 24

LMGC90::Principes de programmation h´eritage use pere ... type T_fils type(T_pere) :: monpere ... end type aggr´egation, composition use pere ... type T_fils type(T_pere),pointer :: monpere ... end type F. Dubois (CNRS)

Architecture de LMGC90

2007

10 / 24

LMGC90::Principes de programmation

utilisation use pere integer :: ID_pere call xxx(ID_pere)

F. Dubois (CNRS)

Architecture de LMGC90

2007

12 / 24

LMGC90::Principes de programmation

polymorphisme statique (`a la compilation) Ü interface g´en´erique (i.e. le choix de la proc´edure est fait en fonction de ses arguments) polymorphisme dynamique (`a l’execution) Ü ´emulation avec des types+appels param´etr´es type T_matrix integer :: ID_type ! 1 full, 2 sparse type (T_full_matrix), pointer :: A_full type (T_sparse_matrix), pointer :: A_sparse end type ... bref on fait tout `a la main !

F. Dubois (CNRS)

Architecture de LMGC90

2007

14 / 24

LMGC90::Principes de programmation

On aimerait avoir : un vrai polymorphisme dynamique objets statiques pour mettre en place les plugs-points (introspection) exception template STL les librairies existantes (Boost) design pattern doxygen

F. Dubois (CNRS)

Architecture de LMGC90

2007

15 / 24

LMGC90::Principes de programmation Pour se consoler on a : modules Ü interface explicites (mieux que fortran77) variables globales dans un module Ü faut pas en abuser sinon ¸ca devient illisible allocation dynamique fonctions g´en´eriques gestion des IO OpenMP f2py robodoc

F. Dubois (CNRS)

Architecture de LMGC90

2007

16 / 24

LMGC90::Architecture g´en´erale Une architecture d´edi´ee `a la r´esolution des syst`emes multi-corps en interaction: tr`es naturellement (a posteriori) on est arriv´e `a une structure proche du probl`eme `a traiter.

F. Dubois (CNRS)

Architecture de LMGC90

2007

17 / 24

LMGC90::Architecture g´en´erale

Mod`eles Physiques: description du comportement volumique des corps.

Un corps peut porter plusieurs mod`eles physiques (m´ecanique, thermique, thermom´ecanique, etc.) avec des discr´etisation diff´erentes.

F. Dubois (CNRS)

Architecture de LMGC90

2007

17 / 24

LMGC90::Architecture g´en´erale

Possibilit´e de couplage entre mod`eles physiques. Mˆeme si l’allocation est dynamique (lecture), le nombre de corps reste inchang´e. On peut “´emuler” l’apparition/disparition de corps grˆace `a un flag (visible). Ainsi on peut mod´eliser la fracture de grains, transformer un corps rigide en d´eformable, etc. On peut coupler un code de calcul “volumique” externe. Exemple PELICANS (IRSN), Code Aster (EDF).

F. Dubois (CNRS)

Architecture de LMGC90

2007

17 / 24

LMGC90::Architecture g´en´erale Contacteurs: description des zones pouvant interagir entre elles.

Les contacteurs g`erent le passage entre les inconnues de la discr´etisation du comportement volumique et les inconnues impliqu´ees dans le comportement surfacique. F. Dubois (CNRS)

Architecture de LMGC90

2007

17 / 24

LMGC90::Architecture g´en´erale

On peut mettre plusieurs contacteurs par corps. On peut ainsi d´ecrire des enveloppes non convexes par des primitives convexes. Le nombre de contacteurs reste inchang´e au cours d’une simulation. Les contacteurs attach´es `a un corps qui n’est plus visible disparaissent.

F. Dubois (CNRS)

Architecture de LMGC90

2007

17 / 24

LMGC90::Architecture g´en´erale Interactions: description des ´el´ements de “contact”.

Les ´el´ements de contact servent `a d´eterminer l’information n´ecessaire au probl`eme d’interaction: interstice, vitesse relative, impulsion, etc. Le nombre d’´el´ements de contact change `a chaque pas, ce qui pose le probl`eme du transfert de l’information. F. Dubois (CNRS)

Architecture de LMGC90

2007

17 / 24

LMGC90::Architecture g´en´erale

Solveurs: m´ethodes num´eriques de r´esolution. LMGC90 dispose de diff´erents solveurs de contact. NLGS: Gauss Seidel non lin´eaire. 2D/3D, parall`elis´e (OpenMP), supporte toutes les lois d’interaction, GPCP: Gradient Conjugu´e. 2D/3D, parall´elis´e (OpenMP), supporte un nombre r´eduit de lois. Bi-potentiel. Tr`es proche de NLGS. Interfa¸cage avec SolverPack du projet Siconos (en cours).

F. Dubois (CNRS)

Architecture de LMGC90

2007

17 / 24

LMGC90::Architecture g´en´erale Mode de fonctionnement classique mots clefs CHIC + LMGC90.

CHIC assure l’ex´ecution du programme principal d´efinit par l’utilisateur dans un fichier de commandes. LMGC90 n’est qu’une librairie. F. Dubois (CNRS)

Architecture de LMGC90

2007

17 / 24

LMGC90::Architecture g´en´erale Il existe des dispositifs permettant d’ajouter des fonctionnalit´es sans toucher `a celles existantes. Fond de Panier Composants sur étagère

LMGC90 Utilisateur

Application Utilisateur

Principe d “INCLUDE” de proc´edures (more src) dans chaque module (src), qu’on peut activer par un mot clef CHIC : marche bien pour des fonctionnalit´es de “pilotage” du code marche mal pour inclure des fonctionnalit´es profondes qu’on ne peut d´eclencher par un mot clef Ü duplication du code !! F. Dubois (CNRS)

Architecture de LMGC90

2007

17 / 24

LMGC90::Aujourd’hui 100 000 lignes de Fortran90, un peu de C et de C++ une licence OpenSource: CECILL (avec d´epot APP par le CNRS), une version stable par an. La prochaine fin 2050. 1 architecte/mod´erateur du code source (IR CNRS) : Fr´ed´eric Dubois, 1 expert (DR CNRS ´em´erite (des claques)) : Michel Jean, 1 d´eveloppeur (CR CNRS) : Mathieu Renouf quelques utilisateurs avanc´es (programmeurs) qui enrichissent le code existant ou ajoutent des fonctionnalit´es pour leurs propres besoins : LMGC, LMA, EMA, INRA (?) des utilisateurs : LMGC, LMA, LABM, LTDS, CEMAGREF, EMA, LCPC, GRASP-ULG,INSA des industriels : SNCF, ALCAN-PECHINEY, IRSN, EDF, CEA, SAINT-GOBAIN (?), CERT (BE-Anger), etc. F. Dubois (CNRS)

Architecture de LMGC90

2007

18 / 24

LMGC90::Aujourd’hui un mod` ele de d´ eveloppement ouvert et coop´ eratif: serveur subversion utilisateur (docs, binaires, ...): https://subver.lmgc.univ-montp2.fr/LMGC90 serveur subversion d´eveloppeurs: https://subver.lmgc.univ-montp2.fr/LMGC90 dev serveur subversion exemples: https://subver.lmgc.univ-montp2.fr/LMGC90 examples listes de diffusion: [email protected], LMGC90 [email protected] page web: http://www.lmgc.univ-montp2.fr/∼dubois/LMGC90 des formations gratuites

F. Dubois (CNRS)

Architecture de LMGC90

2007

18 / 24

LMGC90::Perspectives Passage ` a la version 2 Gestion de mod`eles physiques coupl´es fortement: volumique (en cours de d´eveloppement) et surfacique. Abandonner CHIC pour python. Refonte d’une partie de l’architecture, pour diminuer le code redondant, avoir une structure de donn´ees plus dynamique et ˆetre en mesure de traiter de nouveaux probl`emes. Parall´elisme par passage de message. interface graphique. N´ecessit´e de renforcer l’´equipe de d´eveloppement : IE CNRS ? Consortium ? ANR ?

F. Dubois (CNRS)

Architecture de LMGC90

2007

19 / 24

LMGC90v2:Superviseur

Pilotage du code : Sortir la gestion chic du code Ü Core et Chic Apparition du superviseur python Les more src de pilotage du code utilisent des set/get sur les variables Ü on vire les includes la gestion des more src profonds remplac´ee par la notion de external (UMAT) on peut acc´eder aux donn´ees dans le superviseur python on peut faire la mise en donn´ees depuis le script python, on merge prelmgc

F. Dubois (CNRS)

Architecture de LMGC90

2007

20 / 24

LMGC90v2:Architecture La classe interaction apparaˆıt: elle stocke ce qui vient de la d´etection et elle a vue sur les solveurs (i.e. ca change de sens). On peut avoir autre chose que des interactions m´eca. Un seul stockage (this & verlet). la classe strat´egie apparaˆıt pour g´erer strat´egie, int´egrateurs, etc. La d´etection (grossi`ere+fine) ´eclat´ee dans les multiples modules ´el´ements de contact passe dans un d´etection handler (grossier) plus des modules particularis´es (fine) La notion de classe body (entit´e) apparaˆıt elle g`ere l’´evolution de la g´eom´etrie et elle chapeaute tous les mod`eles physiques. RBDY2/RBDY3 disparaissent pour devenir des P1xxx `a la MAILx. Un body peut avoir des noeuds actifs et entraˆın´es. Les contacteurs s’appuient sur des noeuds actifs (DISKx,SPHER,...) ou entraˆın´es (POLYR,...) F. Dubois (CNRS)

Architecture de LMGC90

2007

21 / 24

LMGC90v2:Architecture

Les syst`emes dynamiques utilisent une classe SOE. Vectorisation du traitement (vecteurs composites), Les interactions dialogues directement avec le SOE. couplage siconos on peut acc´eder aux donn´ees dans le superviseur python interface graphique et superviseur

F. Dubois (CNRS)

Architecture de LMGC90

2007

22 / 24

LMGC90v2:Architecture

F. Dubois (CNRS)

Architecture de LMGC90

2007

23 / 24

LMGC90v2:applications et m´ethodes

couplage multi-physiques (d´eformables et granulaires) prise en compte du fluide passage micro/macro (couplage FEM/DEM) d´ecomposition de domaine m´ethodes sur r´eseau m´ethodes meshless ´el´ements spectraux formulations hybrides FEM/DEM/etc ´evolutives parall´elisme par passage de message

F. Dubois (CNRS)

Architecture de LMGC90

2007

24 / 24