Archi

Architecture de la plateforme LMGC90?.

Frederic [email protected]

Laboratoire de Mecanique et Genie CivilUniversite de Montpellier 2 - CNRS

2007

?Logiciel de Mecanique Gerant le Contact en Fortran90.

F. Dubois (CNRS) Architecture de LMGC90 2007 1 / 24

Plan

1 Motivations

2 Principes de programmation

3 Archictecture generale

4 Aujourd’hui

5 Perspectives

6 LMGC90v2


LMGC90::Motivations

Developper une plateforme de modelisation des milieux “divises”.

Avec des contraintes fortes :

Perenniser un savoir faire existant important mais disperse,

Disposer d’une plateforme d’accueil pour les developpements futursqui reponde aux exigences de la modelisation:

Evolutive (en developpement perpetuel de chose non prevues)Adaptative (reorganisation perpetuelle)Perenne (ce qui est fait est fait)

Diffuser la connaissance.

Disposer d’un support de collaborations scientifiques.

Valoriser.


LMGC90::Principes de programmation

Meme developpe en FORTRAN90 LMGC90 repose sur des notions deprogrammation orientee objet :

classe : attributs + methodesOn construit un module qui definit un type utilisateur (globale) etimplemente des procedures qui s’appliquent sur ce type

encapsulation : gestion de la visibilite des attributs et methodesStatut public/private.



module testimplicit noneprivate

type T_testinteger :: IDreal(kind=8) :: value

end type

contains

subroutine test_init(obj_test)implicit nonetype(T_test) :: obj_test....

end subroutine...

end module test



type “public” Ü danger

public type T_test type(T_test) :: totointeger :: ID toto%ID=1real(kind=8) :: value ...

end type

type semi “public” Ü bien

public type T_test type(T_test) :: totoprivate toto%ID = 1 ! NONinteger :: IDreal(kind=8) :: value

end type

type “private” Ü paranoiaque : les modules sont aussi les containers !

private type T_test type(T_test) :: toto ! NONinteger :: IDreal(kind=8) :: value

end type



heritage

use pere...type T_filstype(T_pere) :: monpere...

end type

aggregation, composition

use pere...type T_filstype(T_pere),pointer :: monpere...

end type



utilisation

use pereinteger :: ID_perecall xxx(ID_pere)



polymorphisme statique (a la compilation) Ü interface generique (i.e.le choix de la procedure est fait en fonction de ses arguments)

polymorphisme dynamique (a l’execution) Ü emulation avec destypes+appels parametres

type T_matrixinteger :: ID_type ! 1 full, 2 sparsetype (T_full_matrix), pointer :: A_fulltype (T_sparse_matrix), pointer :: A_sparse

end type...

bref on fait tout a la main !



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



Pour se consoler on a :

modules Ü interface explicites (mieux que fortran77)

variables globales dans un module Ü faut pas en abuser sinon cadevient illisible

allocation dynamique

fonctions generiques

gestion des IO

OpenMP

f2py

robodoc


LMGC90::Architecture generale

Une architecture dediee a la resolution des systemes multi-corps eninteraction:

tres naturellement (a posteriori) on est arrive a une structure proche duprobleme a traiter.



Modeles Physiques: description du comportement volumique des corps.

Un corps peut porter plusieurs modeles physiques (mecanique, thermique,thermomecanique, etc.) avec des discretisation differentes.



Possibilite de couplage entre modeles physiques.

Meme si l’allocation est dynamique (lecture), le nombre de corps resteinchange.

On peut “emuler” l’apparition/disparition de corps grace a un flag(visible). Ainsi on peut modeliser la fracture de grains, transformer uncorps rigide en deformable, etc.

On peut coupler un code de calcul “volumique” externe.Exemple PELICANS (IRSN), Code Aster (EDF).



Contacteurs: description des zones pouvant interagir entre elles.

Les contacteurs gerent le passage entre les inconnues de la discretisationdu comportement volumique et les inconnues impliquees dans lecomportement surfacique.



On peut mettre plusieurs contacteurs par corps. On peut ainsi decrire desenveloppes non convexes par des primitives convexes.

Le nombre de contacteurs reste inchange au cours d’une simulation.

Les contacteurs attaches a un corps qui n’est plus visible disparaissent.



Interactions: description des elements de “contact”.

Les elements de contact servent a determiner l’information necessaire auprobleme d’interaction: interstice, vitesse relative, impulsion, etc.

Le nombre d’elements de contact change a chaque pas, ce qui pose leprobleme du transfert de l’information.



Solveurs: methodes numeriques de resolution.

LMGC90 dispose de differents solveurs de contact.

NLGS: Gauss Seidel non lineaire. 2D/3D, parallelise (OpenMP),supporte toutes les lois d’interaction,

GPCP: Gradient Conjugue. 2D/3D, parallelise (OpenMP), supporteun nombre reduit de lois.

Bi-potentiel. Tres proche de NLGS.

Interfacage avec SolverPack du projet Siconos (en cours).



Mode de fonctionnement classique mots clefs CHIC + LMGC90.

CHIC assure l’execution du programme principal definit par l’utilisateurdans un fichier de commandes.LMGC90 n’est qu’une librairie.



Il existe des dispositifs permettant d’ajouter des fonctionnalites sanstoucher a celles existantes.

Fond de Panier

Application Utilisateur

Composants sur étagère LMGC90

Utilisateur

Principe d “INCLUDE” de procedures (more src) dans chaque module(src), qu’on peut activer par un mot clef CHIC :

marche bien pour des fonctionnalites de “pilotage” du code

marche mal pour inclure des fonctionnalites profondes qu’on ne peutdeclencher 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 depot APP par le CNRS),

une version stable par an. La prochaine fin 2050.

1 architecte/moderateur du code source (IR CNRS) : Frederic Dubois,

1 expert (DR CNRS emerite (des claques)) : Michel Jean,

1 developpeur (CR CNRS) : Mathieu Renouf

quelques utilisateurs avances (programmeurs) qui enrichissent le codeexistant ou ajoutent des fonctionnalites 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.


LMGC90::Aujourd’hui

un modele de developpement ouvert et cooperatif:

serveur subversion utilisateur (docs, binaires, ...):https://subver.lmgc.univ-montp2.fr/LMGC90

serveur subversion developpeurs: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


LMGC90::Perspectives

Passage a la version 2

Gestion de modeles physiques couples fortement: volumique (en coursde developpement) et surfacique.

Abandonner CHIC pour python.

Refonte d’une partie de l’architecture, pour diminuer le coderedondant, avoir une structure de donnees plus dynamique et etre enmesure de traiter de nouveaux problemes.

Parallelisme par passage de message.

interface graphique.

Necessite de renforcer l’equipe de developpement : IE CNRS ? Consortium? ANR ?


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 remplacee par la notion de external(UMAT)

on peut acceder aux donnees dans le superviseur python

on peut faire la mise en donnees depuis le script python, on mergeprelmgc


LMGC90v2:Architecture

La classe interaction apparaıt: elle stocke ce qui vient de la detectionet elle a vue sur les solveurs (i.e. ca change de sens). On peut avoirautre chose que des interactions meca. Un seul stockage (this &verlet).

la classe strategie apparaıt pour gerer strategie, integrateurs, etc.

La detection (grossiere+fine) eclatee dans les multiples moduleselements de contact passe dans un detection handler (grossier) plusdes modules particularises (fine)

La notion de classe body (entite) apparaıt elle gere l’evolution de lageometrie et elle chapeaute tous les modeles physiques.RBDY2/RBDY3 disparaissent pour devenir des P1xxx a la MAILx.Un body peut avoir des noeuds actifs et entraınes.

Les contacteurs s’appuient sur des noeuds actifs (DISKx,SPHER,...)ou entraınes (POLYR,...)



Les systemes dynamiques utilisent une classe SOE. Vectorisation dutraitement (vecteurs composites),

Les interactions dialogues directement avec le SOE.

couplage siconos

on peut acceder aux donnees dans le superviseur python

interface graphique et superviseur


LMGC90v2:applications et methodes

couplage multi-physiques (deformables et granulaires)

prise en compte du fluide

passage micro/macro (couplage FEM/DEM)

decomposition de domaine

methodes sur reseau

methodes meshless

elements spectraux

formulations hybrides FEM/DEM/etc evolutives

parallelisme par passage de message


Archi

Documents

Transcript of Archi