Architecture de la plateforme LMGC90? .

Frédéric Dubois
dubois@lmgc.univ-montp2.fr
Laboratoire de Mécanique et Génie Civil
Université de Montpellier 2 - CNRS

2007

? Logiciel de Mécanique Gérant le Contact en Fortran90.

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

Plan

1 Motivations

2 Principes de programmation

3 Archictecture générale

4 Aujourd’hui

5 Perspectives

6 LMGC90v2

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

LMGC90::Motivations

Développer une plateforme de modélisation des milieux “divisés”.

Avec des contraintes fortes :

Pérenniser un savoir faire existant important mais dispersé,
Disposer d’une plateforme d’accueil pour les développements futurs
qui réponde aux exigences de la modélisation:
Évolutive (en développement perpétuel de chose non prévues)
Adaptative (réorganisation perpétuelle)
Pérenne (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ême développé en FORTRAN90 LMGC90 repose sur des notions de

programmation orientée objet :
classe : attributs + méthodes
On construit un module qui définit un type utilisateur (globale) et
implémente des procédures qui s’appliquent sur ce type
encapsulation : gestion de la visibilité des attributs et méthodes
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 type(T_test) :: toto
integer :: ID toto%ID=1
real(kind=8) :: value ...
end type
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 type(T_test) :: toto ! NON
integer :: ID
real(kind=8) :: value
end type

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

LMGC90::Principes de programmation

héritage

use pere
...
type T_fils
type(T_pere) :: monpere
...
end type

aggrégation, 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 (à la compilation) Ü interface générique (i.e.

le choix de la procédure est fait en fonction de ses arguments)
polymorphisme dynamique (à l’execution) Ü émulation avec des
types+appels paramétrés
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 à 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 ça
devient illisible
allocation dynamique
fonctions génériques
gestion des IO
OpenMP
f2py
robodoc

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

LMGC90::Architecture générale

Une architecture dédiée à la résolution des systèmes multi-corps en

interaction:

très naturellement (a posteriori) on est arrivé à une structure proche du

problème à traiter.

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

LMGC90::Architecture générale

Modèles Physiques: description du comportement volumique des corps.

Un corps peut porter plusieurs modèles physiques (mécanique, thermique,

thermomécanique, etc.) avec des discrétisation différentes.

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

LMGC90::Architecture générale

Possibilité de couplage entre modèles physiques.

Même si l’allocation est dynamique (lecture), le nombre de corps reste

inchangé.

On peut “émuler” l’apparition/disparition de corps grâce à un flag

(visible). Ainsi on peut modéliser la fracture de grains, transformer un
corps rigide en déformable, 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énérale

Contacteurs: description des zones pouvant interagir entre elles.

Les contacteurs gèrent le passage entre les inconnues de la discrétisation

du comportement volumique et les inconnues impliquées dans le
comportement surfacique.
F. Dubois (CNRS) Architecture de LMGC90 2007 17 / 24
LMGC90::Architecture générale

On peut mettre plusieurs contacteurs par corps. On peut ainsi décrire des
enveloppes non convexes par des primitives convexes.

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

Les contacteurs attachés à un corps qui n’est plus visible disparaissent.

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

LMGC90::Architecture générale

Interactions: description des éléments de “contact”.

Les éléments de contact servent à déterminer l’information nécessaire au

problème d’interaction: interstice, vitesse relative, impulsion, etc.

Le nombre d’éléments de contact change à chaque pas, ce qui pose le

problème du transfert de l’information.
F. Dubois (CNRS) Architecture de LMGC90 2007 17 / 24
LMGC90::Architecture générale

Solveurs: méthodes numériques de résolution.

LMGC90 dispose de différents solveurs de contact.

NLGS: Gauss Seidel non linéaire. 2D/3D, parallèlisé (OpenMP),

supporte toutes les lois d’interaction,
GPCP: Gradient Conjugué. 2D/3D, parallélisé (OpenMP), supporte
un nombre réduit de lois.
Bi-potentiel. Très proche de NLGS.
Interfaçage avec SolverPack du projet Siconos (en cours).

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

LMGC90::Architecture générale

Mode de fonctionnement classique mots clefs CHIC + LMGC90.

CHIC assure l’exécution du programme principal définit 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énérale
Il existe des dispositifs permettant d’ajouter des fonctionnalités sans
toucher à celles existantes.

Fond de Panier

Composants sur étagère LMGC90

Utilisateur

Application Utilisateur

Principe d “INCLUDE” de procédures (more src) dans chaque module

(src), qu’on peut activer par un mot clef CHIC :
marche bien pour des fonctionnalités de “pilotage” du code
marche mal pour inclure des fonctionnalités profondes qu’on ne peut
déclencher 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épot APP par le CNRS),
une version stable par an. La prochaine fin 2050.

1 architecte/modérateur du code source (IR CNRS) : Frédéric Dubois,

1 expert (DR CNRS émérite (des claques)) : Michel Jean,
1 développeur (CR CNRS) : Mathieu Renouf
quelques utilisateurs avancés (programmeurs) qui enrichissent le code
existant ou ajoutent des fonctionnalités 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èle de développement ouvert et coopératif:

serveur subversion utilisateur (docs, binaires, ...):

https://subver.lmgc.univ-montp2.fr/LMGC90
serveur subversion développeurs:
https://subver.lmgc.univ-montp2.fr/LMGC90 dev
serveur subversion exemples:
https://subver.lmgc.univ-montp2.fr/LMGC90 examples
listes de diffusion: LMGC90@lmgc.univ-montp2.fr,
LMGC90 dev@lmgc.univ-montp2.fr
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 à la version 2

Gestion de modèles physiques couplés fortement: volumique (en cours

de développement) et surfacique.
Abandonner CHIC pour python.
Refonte d’une partie de l’architecture, pour diminuer le code
redondant, avoir une structure de données plus dynamique et être en
mesure de traiter de nouveaux problèmes.
Parallélisme par passage de message.
interface graphique.
Nécessité de renforcer l’équipe de développement : 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ée par la notion de external
(UMAT)
on peut accéder aux données dans le superviseur python
on peut faire la mise en données 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étection

et elle a vue sur les solveurs (i.e. ca change de sens). On peut avoir
autre chose que des interactions méca. Un seul stockage (this &
verlet).
la classe stratégie apparaı̂t pour gérer stratégie, intégrateurs, etc.
La détection (grossière+fine) éclatée dans les multiples modules
éléments de contact passe dans un détection handler (grossier) plus
des modules particularisés (fine)
La notion de classe body (entité) apparaı̂t elle gère l’évolution de la
géométrie et elle chapeaute tous les modèles physiques.
RBDY2/RBDY3 disparaissent pour devenir des P1xxx à la MAILx.
Un body peut avoir des noeuds actifs et entraı̂nés.
Les contacteurs s’appuient sur des noeuds actifs (DISKx,SPHER,...)
ou entraı̂nés (POLYR,...)

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

LMGC90v2:Architecture

Les systèmes dynamiques utilisent une classe SOE. Vectorisation du

traitement (vecteurs composites),
Les interactions dialogues directement avec le SOE.
couplage siconos
on peut accéder aux données 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éthodes

couplage multi-physiques (déformables et granulaires)

prise en compte du fluide
passage micro/macro (couplage FEM/DEM)
décomposition de domaine
méthodes sur réseau
méthodes meshless
éléments spectraux
formulations hybrides FEM/DEM/etc évolutives
parallélisme par passage de message

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