You are on page 1of 38

See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/241708880

Architecture des logiciels et langages de


modlisation
ARTICLE MAY 2012
DOI: 10.1080/12506559.1992.10511024

CITATIONS

READS

16

2 AUTHORS:
Piotr Breitkopf

Gilbert Touzot

French National Centre for Scientific Resea

Universit Numrique Ingnirie Et Techno

130 PUBLICATIONS 655 CITATIONS

62 PUBLICATIONS 1,878 CITATIONS

SEE PROFILE

All in-text references underlined in blue are linked to publications on ResearchGate,


letting you access and read them immediately.

SEE PROFILE

Available from: Piotr Breitkopf


Retrieved on: 25 January 2016

Architecture des Logiciels


et
Langages de Modlisation
Piotr Breitkopf, Gilbert Touzot
Universit de Technologie de Compigne
Ple Modlisation Picardie
RESUME:
Le prsent document souligne les difficults qui apparaissent lors du
dveloppement de logiciels de modlisation, puis propose quelques remdes, certes
non dfinitifs. Aprs un bref rappel du sens donn ici au mot "modlisation" et des
particularits de ce domaine de recherche, nous dcrirons les caractristiques
communes aux logiciels de modlisation; nous dtaillerons ensuite les diffrents
problmes qu'ils posent. Enfin, nous dcrirons quelques solutions mises en place
dans le cadre de l'architecture gnrale du logiciel SIC, dont les prototypes ont t
mis au point l'UTC depuis 1985, en collaboration avec quelques industriels et des
laboratoires de Marseille, Grenoble, Montpellier, Poitiers.

The article points out major difficulties emerging in the software


developement for computational engineering purposes. Solutions are suggested,
some of them not definitive. The common characteritics of existing programs are
described; the problems encountered are detailed. Finally the solutions adopted for
the SIC program general architecture are presented. SIC is developed at UTC, since
1985 in cooperation with industry partners and scientific laboratories from
Marseille, Grenoble, Montpellier, Poitiers.

ABSTRACT:

MOTS-CLES : architecture des logiciels, modlisation, lments finis


KEY WORDS: software architecture, finite elements, computational engineering

1. Prliminaires
Le prsent document souligne les difficults qui apparaissent lors du
dveloppement de logiciels de modlisation, puis propose quelques remdes, certes
non dfinitifs. Aprs un bref rappel du sens donn ici au mot "modlisation" et des
particularits de ce domaine de recherche, nous dcrirons les caractristiques

communes aux logiciels de modlisation; nous dtaillerons ensuite les diffrents


problmes qu'ils posent. Enfin, nous dcrirons quelques solutions mises en place
dans le cadre de l'architecture gnrale du logiciel SIC, dont les prototypes ont t
mis au point l'UTC depuis 1985, en collaboration avec quelques industriels et des
laboratoires de Marseille, Grenoble, Montpellier, Poitiers.
2. La Modlisation
2.1 La Modlisation, mais encore ?
Nous savons tous que le mot "modlisation" revt des significations trs
diffrentes selon les interlocuteurs; par exemple :
pour certains il s'agit de l'laboration de relations entre les variables
caractristiques d'un systme ou processus physique donn, capables de bien
simuler le comportement de celui-ci dans un contexte donn; en ce sens de
trs nombreux scientifiques font de la modlisation;
pour d'autres, la modlisation se confond avec la simulation numrique, c'est-dire avec la rsolution d'quations d'volution de la physique;
pour d'autres enfin la modlisation correspond l'ensemble des activits qui
permettent la cration et la mise en uvre sur un ordinateur de maquettes
virtuelles de systmes physiques.
Nous retiendrons ici cette dernire dfinition, en nous restreigant la
modlisation utile pour l'ingnieur dans sa dmarche de conception et d'optimisation
de produits; c'est ce que l'on nomme en anglais "computational engineering". En ce
sens, la modlisation peut faire rfrence toutes sortes de tches interdisciplinaires
bien diffrentes de la simple simulation numrique, telles que :
la description informatique des divers aspects de systmes physiques
complexes;
la gnration de familles de modles d'un mme systme, de complexit
varie, et rpondant des besoins diffrents;
la cration de nouvelles mthodes et formulations adaptes la
modlisation;
l'amlioration de l'insertion de la modlisation dans le processus de
conception
l'utilisation optimale, dans la conception de modles, de l'exprience
accumule lors d'essais, d'exprimentations ou de modlisations;
l'automatisation des tches de prparation, d'excution et d'exploitation des
rsultats de la modlisation par des techniques issues de la recherche en
Intelligence Artificielle ou en calcul formel;
...

Ce sont autant de thmes de recherche qui posent de difficiles problmes de


mthodologie, et qui n'ont avec le calcul numrique que des relations de bon
voisinage, ou encore de client fournisseur.
2.2 La Modlisation en Sciences de l'Ingnieur
La Modlisation en consiste simuler des systmes physiques varis l'aide d'un
ordinateur, de manire en tudier le comportement ou en modifier certaines
caractristiques. Bien qu'utilise dans de trs nombreux secteurs de la recherche et
de l'industrie, la Modlisation prsente des spcificits et une importance particulire
en Sciences de l'Ingnieur. En effet, au cours de la conception et de l'optimisation de
produits industriels, l'Ingnieur fait de plus en plus appel la simulation sur
ordinateur pour viter la construction de maquettes et de prototypes, ce qui permet
des conomies substantielles, fournit des informations auxquelles on ne peut accder
directement par l'exprience, rduit parfois les risques lis certaines
exprimentations, et diminue la dure du cycle de conception des produits.
Les Ingnieurs ont besoin de simuler des systmes physiques de nature trs
diverse: pices mcaniques, sous-ensembles de vhicules ou de machines, ouvrages
de gnie civil, circuits intgrs, systmes de production, procds de fabrication,
fours induction, racteurs biologiques, moteurs lectriques, ... Les phnomnes
physiques modliss sont galement trs varis : comportement mcanique,
thermique, acoustique, lectro-magntique, effets de chocs, coulements, transport de
matire en suspension, propagation de fronts, apparition de discontinuits, ... Trs
souvent plusieurs de ces phnomnes interagissent , et la prise en compte de leurs
diffrents modes de couplage constitue l'un des dfis actuels de la Recherche en
Modlisation. Malgr cette grande diversit, la Modlisation en Sciences de
l'Ingnieur prsente une forte unit; elle suit une dmarche gnrale unique qui
s'adapte chaque application particulire :
Analyse de la physique du systme tudi, slection d'un sous-systme
modlisable et des grandeurs significatives, compte tenu de l'objectif vis;
choix d'hypothses simplificatrices partir de la connaissance a priori dont on
dispose;
Dfinition de ce qui est considr comme connu et inconnu; laboration d'un
modle mathmatique bien pos et capable de simuler le comportement du
systme tudi;
laboration d'un modle informatique correspondant au modle mathmatique;
choix d'un mode de description du systme tudi (aspects gomtriques et
physiques);
Implantation puis excution du modle informatique sur un ordinateur;
Validation du modle par comparaison avec d'autres modles et avec
l'exprience;
Exploitation des rsultats, par exemple sous forme graphique;
Corrections ou amliorations successives du modle;

Etudes paramtriques, analyse de sensibilit, optimisation.


La Modlisation en Sciences de l'Ingnieur est une activit fdratrice par nature
: elle fait appel aux diverses Sciences de base de l'Ingnieur (Rsistance de
matriaux, Mcanique des Structures, des Solides et des Fluides, Thermique,
Electricit, ...), ainsi qu'aux Mathmatiques Appliques et l'Informatique. La
Recherche en Modlisation doit intgrer rapidement les nouveaux concepts et
rsultats issus de tous ces domaines, les adapter ses propres besoins, puis les insrer
dans des logiciels de plus en plus complexes. Ces logiciels de Modlisation
concentrent aujourd'hui le savoir et le savoir faire des Organismes de Recherche
Publique, ainsi que celui des Entreprises, pour les rendre facilement utilisables par
les concepteurs de produits nouveaux. Ces logiciels sont le plus souvent issus d'une
collaboration troite entre l'Industrie et la Recherche Publique; par exemple le
logiciel NASTRAN [MAC] est n la NASA, puis a t dvelopp par Mc Neal
Swendler; SAMCEF [SAM] est n l'Universit de Lige et s'est ensuite rpandu
dans l'Industrie Aronautique Europenne par l'intermdiaire de la socit
SAMTECH.
La Modlisation revt aujourd'hui une importance stratgique pour de
nombreuses Entreprises petites et grandes, car elle a une influence directe sur la
comptitivit de leurs produits. La Recherche Publique doit donc s'efforcer
d'amliorer, par diffrents moyens, la qualit et l'efficacit des outils de
Modlisation dont dispose le pays, de manire viter une dpendance trop
importante de l'Industrie nationale, vis vis des logiciels de Modlisation trangers,
cette dpendance risquant d'induire rapidement une dpendance technologique et
culturelle. La Recherche doit s'intresser la fois aux nouvelles mthodes utilisables
en Modlisation, la mthodologie d'utilisation de la Modlisation, ses
applications, ainsi qu'aux problmes poss par la ralisation des logiciels de
Modlisation, pour en amliorer la fiabilit, la gnralit et la facilit d'emploi.
La mise en commun des efforts de recherche, des mthodes et des outils
informatiques entre les diffrents secteurs de la recherche en Modlisation en
Sciences de l'Ingnieur est trs fructueuse : d'une part chaque secteur bnficie des
perces et rsultats obtenus dans les autres secteurs; d'autre part, on vite ainsi de
dupliquer le coteux dveloppement de nombreux modules informatiques
(interaction homme-machine, post-traitement graphique, resolution de grands
systmes d'quations, organisation des donnes, ...); enfin, on favorise ainsi la
construction de modles coupls.
2.3 La dmarche de modlisation traditionnelle
Un problme de modlisation est en gnral caractris par :

a) La dfinition d'un systme physique rel dans lequel certaines grandeurs sont
inconnues a priori, et d'autres sont supposes connues (exemple: une chambre
air de bicyclette soumise une pression interne);
b) Une ou des questions (par exemple : quelle pression maximale peut-t-on
appliquer cette chambre air ?).
La premire tape de la dmarche de modlisation consiste faire une srie
d'hypothses simplificatrices qui rendent le problme "modlisable": idalisation de
la gomtrie, des conditions aux limites, des sollicitations, hypothses sur le
comportement des matriaux, sur l'amplitude des dplacements et des dformations,
isolement d'un sous-systme. Dans notre exemple, une premire approximation
grossire consiste essayer de ne modliser que la chambre air en supposant qu'elle
n'interagit pas avec la roue et le pneu :

u=0

La seconde tape consiste slectionner les relations qui rgissent le modle (loi
de comportement lastique, relations dplacements-dformations, quations
d'quilibre), liminer certaines variables entre ces relations, faire des hypothses
simplificatrices (dformations "petites" ... sans doute fausses), puis choisir des
mthodes de discrtisation des quations ainsi obtenues (lments finis, ...).
La cration d'un tel modle discrtis utilise de nombreuses connaissances explicites
et implicites de l'utilisateur : influence des conditions de symtrie du problme,
position d'ventuelles concentrations de contraintes, tailles d'lments requises,
erreurs induites par une finesse de discrtisation donne, erreurs acceptables sur les
diffrentes variables, etc ... On peut ainsi construire un systme d'quations
algbriques (ventuellement linaires) qui reprsente approximativement le
comportement du systme physique tudi. La rsolution de ce systme fournit les
inconnues, ici les dplacements des noeuds de discrtisation de la chambre air :

?
0
=

sym.
v=0

[K]

{U}

{F}

On effectue ensuite des calculs auxiliaires (contraintes, dformations,...), puis on


procde une analyse critique des rsultats (validit des hypothses, vraisemblance
des solutions obtenues, comparaison avec d'autres rsultats analogues, ...), et une
interprtation de ceux-ci : comparaison des contraintes maximales calcules avec les

contraintes de rupture du matriau, exploitation du caractre linaire du problme


pour en dduire le niveau de sollicitation admissible, ....
2.4 Evolution de la Modlisation en Sciences de l'Ingnieur
La modlisation a en fait dbut par de simples rsolutions d'quations aux
drives partielles destines par exemple au calcul de champs de tempratures
(quations de Laplace), de champs de dplacements, de dformations et de
contraintes (quations de l'lasticit), de champs de vitesses (quations de Stokes).
Les schmas de discrtisation spatiale initiaux taient le plus souvent bass sur des
diffrences finies.
Les premires volutions de la modlisation ont port :
sur les techniques de discrtisation spatiales (formulations variationnelles et
lments finis varis, volumes finis, quations intgrales);
sur l'augmentation du nombre de dimensions d'espace des modles (1, 2 puis 3
dimensions), les applications tri-dimensionnelles tant trs svrement
limites par la capacit des ordinateurs;
sur les mthodes de rsolution : mthodes itratives varies, mthodes directes,
mthodes multi-chelles, mthodes de dcoupage en sous-domaines, ...
En parallle, on a augment graduellement la complexit des modles physiques :
en mcanique des solides, on est pass de l'lasticit la plasticit, la viscoplasticit puis l'endommagement; on a galement pris en compte les grands
dplacements, les grandes dformations, les instabilits;
en thermique aprs la simple loi de Fourier on a modlis la convection, le
rayonnement puis les problmes de transport;
en mcanique des fluides aprs les quations de Stokes sont venues les
quations de Navier Stokes puis des modles de turbulence de degr de
raffinement croissant, puis la prise en compte de phnomnes ractifs.
Le caractre non-linaire, non stationnaire, et parfois non-diffrentiable de
certains de ces modles a impos la mise au point :
de mthodes varies de rsolution de grands systmes d'quations non-linaires
(variantes de la mthode de Newton-Raphson, BFGS, ...),
de mthodes de traitement des instabilits, bifurcations, catastrophes;
de mthodes de traitement des relations non diffrentiables (par exemple pour le
contact et le frottement)
de mthodes d'intgration de grands systmes d'quations diffrentielles du
premier et du second ordre (mthodes explicites puis implicites).

Dans la modlisation traditionnelle, on cherche calculer des champs de


variables qui vrifient des quations aux drives partielles ou des quations
variationnelles quivalentes sur un domaine connu, ainsi que des conditions aux
limites donnes. On a ensuite tent de modifier ce qui est considr comme connu et
inconnu en ajoutant, lorsque c'est ncessaire, des relations additionnelles : par
exemple dans certains problmes d'optimisation, la forme du domaine est une
inconnue que l'on peut dterminer en exprimant que la masse d'une pice est
minimale, cest dire que le gradient de la masse par rapport aux paramtres qui
dfinissent la forme, est nul. Dans un problme de contact, certaines des conditions
aux limites sont inconnues, mais peuvent tre dtermines grce aux relations
(inquations) de contact (raction normale de contact et distance en corps positives).
Enfin un domaine de recherche trs actif est celui qui s'intresse aux couplages de
modles : fluide - thermique, fluide - structures, acoustique - structures, lectromagntisme - solides, etc ... Il peut s'agir de couplages forts qui manipulent deux
types d'quations et de variables dans un mme modle, ou de couplages faibles dans
lesquels on se contente de traiter alternativement modles diffrents qui changent de
l'information par l'intermdiaire de champs de variables.
Un exemple de modle coupl est fourni par l'optimisation du procd de
fabrication de tubes couds. L'objectif est la dtermination de la forme optimale d'un
outil (mandrin), de manire obtenir la forme de tube coud souhaite, moindre
cot. Un tel problme couple mcanique des solides visco-plastiques en grandes
dformations, thermique non linaire , lectro-magntisme (chauffage par induction),
contact et frottement, optimisation.
u impos

u impos

chauffage
par induction
contact
frottement
outil
rigide ou
lastique
matriau
visco-plastique

De nombreuses mthodes numriques utilisent des paramtres dont la valeur


optimale dpend de la solution cherche. C'est en particulier le cas de la mthode des
lments finis (maillages), et des mthodes d'intgration d'quations diffrentielles
par rapport au temps (taille des pas de temps). Pour fournir les valeurs de ces
paramtres, l'utilisateur doit disposer d'une certaine connaissance priori de ce qu'il
cherche, ce qui n'est pas toujours le cas. Sinon il doit procder par essais successifs.
On commence disposer aujourd'hui de mthodes auto-adaptatives qui utilisent les
rsultats de premiers modles grossiers pour ajuster les valeurs des paramtres
requis, au prix de r-analyses successives.

3. Les logiciels de Modlisation


3.1 Modlisation et logiciels
Ds qu'un modle devient compliqu et dpend de plus de quelques paramtres,
on doit faire appel un ordinateur. Celui-ci se charge alors de l'acquisition des
informations supposes connues, de la construction et de la rsolution des quations,
et de l'affichage des informations dtermines par le modle. Il est vident que la
programmation est d'autant plus longue et coteuse que le modle ou les mthodes de
construction et de rsolution des quations sont complexes. L'volution de la
modlisation, l'ouverture du spectre des problmes que l'on dsire simuler avec le
mme logiciel pour faciliter les couplages et amortir le cot de dveloppement de
celui-ci, ainsi que des considrations commerciales ont provoqu une augmentation
trs rapide de la complexit des logiciels. Ces derniers, n'ayant souvent pas t
conus pour faire face une telle volution, deviennent de plus en plus difficiles
dvelopper, entretenir, et utiliser.
Il est donc ncessaire aujourd'hui de repenser profondment les processus de
construction, d'amlioration et d'utilisation des logiciels de modlisation.
3.2 Connaissance sous forme active
Hier encore la connaissance logeait dans les esprits et dans les livres. Que les
bibliothques contiennent de vrais livres ou leurs enregistrements informatiques, la
connaissance n'y est disponible que sous une forme passive : on ne peut en effet
l'utiliser qu'aprs l'avoir tudie puis assimile.
Avec le dveloppement de la modlisation et de quelques autres techniques
informatiques, la connaissance s'installe aujourd'hui dans les ordinateurs sous une
forme active qu'il est possible d'utiliser sans avoir l'assimiler, ... ce qui peut
conduire de graves difficults ... .
Lorsqu'ils sont excuts, les logiciels gnrent de la connaissance additionnelle,
qui apparat :
sous forme passive dans des listes de rsultats ou dans des courbes,
sous forme active dans le cerveau de l'utilisateur qui interprte les rsultats du
logiciel, et ventuellement dans les modifications et amliorations que l'on
peut ensuite apporter aux logiciels.
Ces derniers peuvent ainsi tre considrs la fois comme des outils de
concentration et d'activation automatique de connaissances passives et comme des
gnrateurs de connaissances additionnelles.

Utilisateur (Connaissance active)

Connaissance
passive

Action

Logiciels (Connaissance active)

Personne ne peut prdire aujourd'hui les limites du champ d'action et de


l'autonomie des futures gnrations de logiciels. En revanche, et sans tre
exagrment pessimiste, on peut prvoir que la consultation (trop ?) rapide des
machines remplacera, progressivement certes, mais presque totalement, l'tude et la
rflexion pralables la rsolution des problmes [d'aprs B. Nayroles, Les verrous
de la Modlisation, Grenoble, Septembre 1990].
3.3 Varit des logiciels de modlisation
Il existe de nombreux types de logiciels de modlisation :
les logiciels de recherche spcialiss sont conus et utiliss dans les
laboratoires de recherche pour simuler et comprendre un phnomne
exprimental particulier, ou pour tester, amliorer, comparer des mthodes,
formulations et modles nouveaux;
les logiciels de recherche gnraux servent de base de travail, de moyen
d'archivage, et d'outil d'change dans un laboratoire, dans un ensemble de
laboratoires, ou dans des rseaux de recherche regroupant laboratoires et
industriels;
les logiciels industriels spcialiss sont destins satisfaire un besoin particulier
(outils mtiers). Ils concentrent de plus en plus la connaissance de l'entreprise;
les logiciels industriels gnraux s'efforcent de rpondre un nombre maximal
de besoins, et de s'adapter des environnement varis; ils sont de plus en plus
dvelopps et diffuss par des socits spcialises.
Ces diffrents types de logiciels ne sont en fait pas isols les uns des autres. En
technologie plus qu'ailleurs, on s'efforce en effet de transfrer le plus rapidement
possible les rsultats de la recherche vers l'industrie. Le vecteur de transfert le plus
efficace est aujourd'hui le logiciel. D'autre part pour diminuer le nombre de logiciels,
simplifier leur entretien et garantir leur prennit, on s'efforce d'insrer les logiciels
spcialiss ou les mthodes qu'ils utilisent, ds qu'elles sont stabilises, dans des
logiciels plus gnraux.
Les caractristiques des divers types de logiciels peuvent tre trs diffrentes,
qu'il s'agisse de la taille du logiciel, de sa fiabilit, de sa facilit de dveloppement ou
de la varit des mthodes qu'il met en uvre. Il y a en particulier une grande
diffrence, souvent sous-estime, entre logiciel industriel et logiciel de recherche :

les logiciels industriels sont (ou devraient tre) bass sur des mthodes
prouves, largement testes sur de nombreuses applications. D'autre part leur
programmation est (ou devrait tre) conue pour garantir la fiabilit, faciliter la
recherche d'erreurs et les dveloppements ultrieurs, au prix ventuel d'une certaine
complexit. De plus il est clair que la qualit de l'interface logiciel-utilisateur et de la
documentation sont ici prpondrants. Un logiciel industriel peut inclure des modles
complexes, mais son utilisation doit rester simple; il doit tre efficace dans un
environnement de production. Le logiciel doit contenir des protections contre les
utilisations qui conduisent des rsultats faux; la complexit des actions que peut
entreprendre l'utilisateur est donc limite, le logiciel se prsentant alors plus ou
moins comme une bote noire ferme.
les logiciels de recherche doivent au contraire offrir un maximum de flexibilit,
encourager leurs utilisateurs faire des modifications, faciliter au maximum l'ajout
de fonctions supplmentaires tout en favorisant la rutilisation des modules existants.
Les logiciels de recherche sont, selon les cas, des botes outils de chercheurs isols
ou d'ensembles de chercheurs, ou des plateformes fdratrices au niveau de
laboratoires ou d'ensembles de laboratoires. Ces logiciels utilisent normalement des
mthodes novatrices qui ne sont pas, par nature, valides sur un large spectre
d'applications. Ils n'ont souvent t tests que sur des cas assez particuliers. Enfin la
qualit de leur programmation et de leur organisation informatique laisse souvent
dsirer, ce qui pose des problmes lors de la recherche d'erreurs ou lors de
dveloppements ultrieurs. Une autre difficult provient souvent de la faiblesse de la
documentation. Dans le meilleur des cas, ces logiciels peuvent seulement tre
considrs comme des prototypes de logiciels industriels. Vus comme tels, ils sont
prcieux comme aide l'criture des logiciels industriels, mais ne les remplacent pas.
Il faut souligner que dans certaines quipes de recherche de grandes socits, la
situation est souvent plus proche de celle d'un laboratoire de recherche que de celle
d'un bureau d'tudes. Les problmes de transferts internes de telles socits sont
aussi dlicats, si ce n'est plus, qu'entre le monde de la Recherche et l'Industrie.
Les logiciels utilisables pour l'enseignement se situent entre les logiciels de
recherche et les logiciels industriels, bien que plus proches de la recherche. Ils
rclament surtout de la simplicit, car le temps dont disposent les tudiants pour
assimiler les particularits dun logiciel est trs limit.
mise en ouvre des algorithmes
interface
metier

prototype

macro-commandes
langage
interactif

industrie

donnes manipuls

laboratoire
industriel

enseignement

objets
de conception
FORTRAN
C

recherche

industrie

laboratoire
industriel

Programmes = Algorithmes + Structures de Donnes

objets
structurs

enseignement

matrices
vecteurs

recherche

Tout en respectant leurs spcificits, une certaine continuit (cohrence,


compatibilit) est souhaitable entre les diffrents types de logiciels pour simplifier
les transferts de mthodes et de modules informatiques, depuis les logiciels
spcialiss vers les logiciels plus gnraux, et depuis les logiciels de recherche vers
les logiciels industriels. Cette continuit est en pratique difficile assurer.
3.4 Description d'un logiciel de modlisation
On peut dcrire un logiciel de modlisation de diffrentes manires. L'une d'elles
consiste faire abstraction des caractristiques internes du logiciel et le dfinir
uniquement en termes des donnes qu'il utilise en entre et des rsultats qu'il produit
en sortie, c'est dire le considrer comme une bote noire. Cette description
s'adapte bien un logiciel conu pour traiter un type de problme particulier; elle
s'adapte moins bien aux logiciels gnraux pour lesquels il faut lister les trs
nombreuses configurations d'entre et de sortie disponibles. Ce mode de description
ne permet pas d'valuer la validit des modles thoriques sur lesquels sont bass les
calculs.
On peut d'autre part tenter de caractriser la "complexit" d'un logiciel par des
critres purement informatiques, tels que le nombre de lignes de programme (souvent
de l'ordre de centaines de milliers), le nombre de sous-programmes (souvent de
l'ordre de centaines ou de milliers), les possibilits d'excution sur divers ordinateurs
(prestigieux: CRAY, rapides mais abordables: stations de travail RISC, trs
rpandus: PC), la richesse des structures de donnes, etc ....
La description du logiciel peut aussi porter sur des aspects purement scientifiques
: on citera alors les caractristiques des mthodes numriques utilises, en soulignant
l'originalit de l'implantation; pour un logiciel bas sur la mthode des lments finis
on pourra numrer les types d'lments disponibles ainsi que les mthodes de
rsolution ou d'intgration offertes.
On peut galement s'intresser au confort de l'utilisateur en dcrivant l'interface
entre le logiciel et son utilisateur, le langage d'introduction de donnes, le systme de
menus, la documentation.
En fait le logiciel de modlisation est une construction logique complexe et
multiforme difficile dcrire. Il n'est que la partie merge et visible de l'ensemble
beaucoup plus vaste que constitue le processus de modlisation entier. La partie
invisible contient les connaissances et l'exprience de l'ensemble des personnes qui
ont cr le logiciel, ainsi que toutes ses particularits informatiques. Ces informations
touchent des domaines aussi varis que l'informatique, les mathmatiques appliques,
l'analyse numrique, les Sciences pour l'ingnieur; elles incluent galement
l'exprience accumule par les auteurs du logiciel, concernant les systmes physiques
tudis. Il est clair qu'une description complte du logiciel devrait inclure l'ensemble

de ces informations, ce qui est en gnral impraticable. Le logiciel reste donc


largement inconnu de ses utilisateurs, et ceci d'autant plus qu'il est complexe. Les
difficults lies l'utilisation d'un logiciel de modlisation sont de mme nature que
celles qui apparaissent dans la communication entre deux tres logiques complexes :
mauvaise apprhension des connaissances de l'autre, mauvaise interprtation de son
mode de pense, extrapolations indues, ... Seule une organisation interne simple du
logiciel et une logique d'ensemble facile dcrire permettent de rduire la distance
entre le logiciel et l'image que s'en construit son utilisateur.

logiciel
Processus
de
modlisation
de systmes
physiques

Informatique
- Langages
- Manip. donnes
- Gnie logiciel
- Graphique
- I.A.

Math. appliques
Analyse numrique

S.P.I
R.D.M
Mcanique
Thermique
...
Exprience
du systme physique

Il est clair qu'une description complte du logiciel devrait inclure l'ensemble de ces
informations, ce qui est en gnral impraticable. Le logiciel reste donc largement
inconnu de ses utilisateurs, et ceci d'autant plus qu'il est complexe. Les difficults
lies l'utilisation d'un logiciel de modlisation sont de mme nature que celles qui
apparaissent dans la communication entre deux tres logiques complexes : mauvaise
apprhension des connaissances de l'autre, mauvaise interprtation de son mode de
pense, extrapolations indues, ... Seule une organisation interne simple du logiciel et
une logique d'ensemble facile dcrire permettent de rduire la distance entre le
logiciel et l'image que s'en construit son utilisateur.
3.5 L'volution des logiciels de modlisation [DHA 84, MAC, SAM]
Les logiciels de modlisation tels que nous les connaissons aujourd'hui ont subi une
longue volution depuis les premiers programmes du dbut des annes 60 .
La structure interne d'un logiciel capable de mettre en uvre la dmarche de
modlisation traditionnelle dcrite au paragraphe 2.3 est relativement simple. De trs
nombreux logiciels organiss de cette manire ont t crits au cours des 30 dernires
annes. Il s'en crit encore dans le cadre des thses. La majorit d'entre eux
fonctionnaient (et fonctionnent encore parfois) dans un environnement de traitement

par lots. L'utilisateur prpare un fichier de donnes d'entres (autrefois une bote de
cartes perfores), puis soumet celui-ci un ordinateur. Il obtient, aprs une priode
de temps souvent difficile prvoir, un fichier de rsultats (autrefois un simple
listing).
Fichier d'entre:

Excution:

Fichier de sortie:

1 1.0 2.0
2 2.0 3.0
11 2
21 3 5
SUBMIT XX.INP XX.OUT

NOEUDS
...
ELEMENTS
...
Assemblage
!!? erreur: pivot nul
Dplacements
...
erreur

OK

Une telle organisation laisse peu de degrs de libert l'utilisateur,


l'enchanement des oprations tant prdtermin; en cas de difficults, celui-ci ne
peut que modifier le contenu du fichier de donnes et excuter de nouveau
compltement le programme. L'information fournie par le logiciel en sortie est elle
aussi prdtermine, et souvent mal adapte aux besoins instantans de l'utilisateur.
A partir de cette structure de base, les logiciels de modlisation ont volu sur
quatre plans :
d'une part les logiciels ont du suivre l'volution de la modlisation mentionne
au paragraphe 2.4. Ceci a multipli le nombre de boucles et de branchements,
rendant de plus en plus difficile la description de l'organisation du programme
par des schmas simples; seuls restent facilement descriptibles des sousensembles de plus en plus petit du logiciel;
d'autre part des logiciels gnraux se sont efforcs de regrouper un maximum
de mthodes et de traiter un maximum de classes de problmes, ce qui conduit
une croissance difficile matriser de leur complexit interne;
certains logiciels se sont efforcs de simplifier la tche de leurs utilisateurs,
grce des amliorations de l'interface logiciel-utilisateur.
Conus
initialement comme de simples outils d'analyse de systmes physiques bien
dfinis, ces logiciels ont ainsi volu graduellement vers de vritables outils
d'aide la conception..En mme temps, le dveloppement des logiciels de

CAO (manipulation de formes gomtriques complexes) a amen les logiciels


de modlisation venir chercher les descriptions gomtriques dont ils ont
besoin dans les logiciels de CAO. Ceci conduit lentement vers une intgration
CAO-Modlisation, qui se trouve freine par des considrations
commerciales.
les logiciels ont d s'adapter aux volutions rapides de l'informatique: passage
du traitement par lots au traitement interactif, interfaces graphiques multifentres, stations de travail, rseaux, nouvelles techniques d'organisation des
donnes, traitement distribu et parallle. En particulier, en ce qui concerne la
"convivialit", les logiciels de modlisation sont contraints de s'aligner
progressivement sur les traitements de textes, tableurs, etc ..., utiliss
quotidiennement par chaque utilisateur sur sa station de travail ou son microordinateur: entre assiste des donnes, visualisation graphique de toute
information tout moment, intervention en cours de calcul, menus droulants,
...
Ces volutions ont augment considrablement le champs d'action de la
modlisation, le nombre d'enchanements d'oprations, de mthodes et de services
disponibles dans chaque logiciel. Cette tendance est amplifie par le cycle infernal
suivant :

Malheureusement les possibilits ainsi offertes par les logiciels augmentant, les
connaissance requises pour les utiliser augmentent galement. On peut affirmer
qu'aujourd'hui la limitation la plus critique au dveloppement de la modlisation
rside dans le volume des informations que doivent assimiler les utilisateurs pour
tirer parti des logiciels existants.
4. Des difficults, des souhaits, des solutions ?
4.1 Un logiciel, ... , des logiciels

Si un seul logiciel se propose de regrouper l'ensemble des modules ncessaires


pour effectuer tous les types de modlisation envisageables, son volume et sa
complexit deviennent inacceptables. Ceci est dj vrai dans une discipline donne
telle que la thermique ou la mcanique des solides.

D'autre part si chaque nouvelle modlisation donne naissance un nouveau


logiciel, avec ses caractristiques, son organisation et son interface utilisateur propre,
le nombre de logiciels crot de manire totalement incontrle. Dvelopper,
entretenir et assurer la prennit de cet ensemble croissant de logiciels trs diffrents
les uns des autres devient une tche sur-humaine, mme au sein d'une grande
entreprise. En pratique seuls quelques rares logiciels survivront leur phase de test,
ou au dpart de leur concepteur. D'o un norme gchis d'efforts. De plus les
couplages entre logiciels seront difficiles ou impossibles, sauf au prix de l'criture
d'un grand nombre d'interfaces ("n" logiciels ... "n2" interfaces).

Une solution possible consiste crer des ensembles de logiciels (ou modules) de
taille limite, qui partagent entre eux un certains nombre de sous-programmes, de
structures de donnes, et qui respectent un nombre limit de normes communes.
Deux modules peuvent ainsi communiquer ou mme tre immergs par la suite dans
un module unique pour traiter des problmes coupls. Selon l'ampleur des
similitudes, un utilisateur ou un dveloppeur peut travailler sur l'un ou l'autre des
modules avec une priode d'adaptation plus ou moins longue. Un tel ensemble de
modules "coordonns" peut tre considr, par analogie avec les ensembles
lectroniques, comme un fond de panier logique, constitu par tout ce que partagent
les modules, dans lequel viennent "s'enficher" les diffrents cartes logiques que sont
les modules. Il faut bien sr :
choisir correctement la dfinition du fond de panier. S'il est trop contreignant,
l'ensemble des logiciels capables de s'y adapter sera limit, et, ce qui est pire,
les dveloppeurs ne respecteront pas ses normes. S'il ne l'est pas assez, les
interactions possibles entre les logiciels seront limites;
s'assurer que les logiciels (ou modules) sont bien compatibles avec le fond de
panier;
dfinir correctement la taille et les fonctions des nouveaux modules. Ceux-ci
peuvent tre trs petits et correspondre une opration lmentaire (simple
modification d'une variable, construction d'un systme d'quations, excution
des oprations correspondant un pas de temps ou une itration d'quilibre,
affichage slectif d'informations, ...). Au contraire un module peut tre un
logiciel de modlisation complet correspondant une application ou un
domaine donn.
4.2 Architecture des logiciels de modlisation [FEL 80, FEL81, AUN90, BRE 91]]
L'architecture d'un logiciel est constitue par l'ensemble des rgles, normes et
techniques d'organisation que doivent respecter tous les constituants prsents et
futurs du logiciel. Ces rgles ont pour but :
de simplifier les communications entre les divers sous-ensembles du logiciel;
de donner une certaine homognit l'ensemble des modules constitutifs du
logiciel, pour en faciliter la comprhension;
d'viter une explosion de la complexit du logiciel, mesure que celui-ci se
dveloppe;
d'aider les utilisateurs et dveloppeurs du logiciel se construire rapidement une
reprsentation mentale correcte du logiciel;
L'architecture d'un logiciel devant tre connue en dtails par tous les
dveloppeurs, et dans ses grandes lignes par les utilisateurs, il importe qu'elle soit
simple, limpide, et facile dcrire.
Celle-ci est souvent dfinie par un dcoupage logique du logiciel en blocs
fonctionnels, et par des normes de passage d'informations entre ces blocs. Ce
dcoupage permet de faire ressortir les grandes fonctions du logiciel, et de modifier

ou mme remplacer globalement un bloc fonctionnel sans se soucier des autres, pour
autant que l'on respecte les normes des interfaces.
Bloc-A

Bloc-B
Bloc-1
interfaces

Bloc-C

Bloc-2

Bloc-N

Un second mode de dfinition d'une architecture, complmentaire du premier,


consiste crire une premire version (de bonne qualit ...) de chacun des sousprogrammes caractristiques, puis dvelopper le logiciel par duplications et
modifications mineures de ces derniers. On peut ainsi diffuser un style de
programmation dans l'ensemble du logiciel par simple mimtisme.
Il est certain que les rgles qui dfinissent l'architecture d'un logiciel limitent ou
contreignent les volutions futures de celui-ci. Comme la dure de vie des logiciels
de modlisation est souvent de l'ordre de 10 20 ans, il importe que les options
architecturales ne dpendent pas de techniques informatiques ou de mthodes
numriques particulires qui risquent de disparatre bien avant le logiciel lui-mme,
ou au moins son architecture. Par exemple, s'il est probable que l'on devra, pendant
longtemps encore, entrer des donnes dans un logiciel, puis construire et rsoudre
des systmes d'quations, il est possible que la mthode des lments finis soit un
jour remplace par une mthode plus efficace sur de futurs ordinateurs. De la mme
manire, il est dangereux de parier sur la prennit d'un modle de structure de
donnes particulier (tel qu'une base de donnes relationnelle). Mais on ne prend pas
trop de risques en affirmant que toutes les oprations qu'excute un logiciel peuvent
tre organiss logiquement sous la forme d'un ensemble extensible d'oprateurs de
base et de macro-oprateurs reprsents par le graphe suivant :
Macro (1-2)
Macro
((1-2)-(2-3-4))

opration-3
Macro (2-3-4)

soit, titre d'exemple :

opration-1
opration-2

opration-4
. . .

4.3 Normalisation
Depuis quelques annes, dans de nombreux domaines de la technologie, les
oprations et objets qui ont atteint une certaine maturit ont fait l'objet de
normalisations systmatiques. C'est en particulier le cas en informatique (langages,
systmes d'exploitation, bases de donnes, rseaux, ...). Dans le domaine de la
modlisation cette tendance ne s'est pas manifeste. Ce manque de normalisation
conduit la r-criture inlassable de sous-programmes presque identiques, et
d'importantes difficults pour rutiliser les rsultats informatiques d'une recherche
dans le cadre d'une recherche ultrieure.
Alors que des langages scientifiques de haut niveau tels que "Mathmatica" ou
"Mathlab" s'imposent graduellement, rien d'quivalent ne voit le jour en
modlisation. Il est intressant de se demander pourquoi les chercheurs en
modlisation acceptent, volontiers semble-t-il, la norme constitue par un langage
assez simple (tel que FORTRAN), mais ne dsirent pas ou n'acceptent pas de normes
de plus haut niveau; ils jugent mme utile pour la formation que les tudiants
crivent eux-mme, de manire souvent maladroite, tous les modules informatiques
dont ils ont besoin. Ceci limite fortement la complexit des modles envisageables.
Deux types de normalisation sont souhaitables :
celle des oprateurs de base de la modlisation, certains tant trs gnraux,
d'autres tant lis des domaines ou applications spcifiques. Ce type de
normalisation permet, certes, la rutilisation de sous-programmes, mais il met
galement en lumire les similitudes, les diffrences et les complmentarits
des divers domaines d'application de la modlisation; ceci conduit souvent
de fructueuses fertilisations croises entre domaines de recherche.
celle des structures de donnes manipules par les divers oprateurs de
modlisation. Ce type de normalisation permet le couplage des programmes,
ainsi que l'criture de sous-programmes de service gnraux qui se chargent
d'une part importante de la manipulation des donnes.

La normalisation favorise la cration d'outils gnraux, utilisables dans de


nombreuses circonstances, ce qui diminuent d'autant la taille et le nombre des
programmes spcifiques d'une application donne. La normalisation contribue ainsi
diminuer la fois la complexit et la taille des logiciels, amliorer leur lisibilit, et
raccourcir la dure de formation des utilisateurs.
4.4 Langage de modlisation
Le processus de modlisation fait appel de nombreux concepts de haut niveau
smantique concernant la physique, le processus de modlisation par essais et
erreurs, des notions d'algorithmique, des connaissances a priori sur le systme
modlis, .... Pourtant l'criture des logiciels de modlisation se fait trs bas niveau,
par l'intermdiaire de langages tels que FORTRAN ou C. Ceci est certes justifi par
des raisons historiques, et par un besoin impratif d'efficacit des logiciels de
modlisation. Les langages plus flexibles ou plus puissants tels que LISP, ADA,
C++, APL, MATHEMATICA sont en gnral beaucoup plus gourmands en
ressources informatiques que C ou FORTRAN. De plus, ils ne rpondent pas non
plus l'envie des spcialistes de la modlisation de parler leur propre langage, et de
manier directement des concepts caractristiques de la modlisation tels que des
contraintes, des matrices, des points, des champs de variables, des fissures, des
formes, des hypothses, ...
Tout en conservant l'efficacit des langages compils simples pour crire les
divers modules d'un logiciel, il est possible de crer un ensemble d'oprateurs de base
qui constituent collectivement un vritable langage de modlisation. L'utilisateur
peut alors activer ces oprateurs dans un ordre quelconque, par l'intermdiaire d'une
syntaxe adapte la modlisation, si ce n'est une application particulire. La seule
condition requise pour activer un oprateur est l'existence et la validit des
informations qu'il utilise en entre; cette condition peut tre teste par chaque module
pour viter des catastrophes informatiques irrmdiables. On associe ainsi l'efficacit
des langages compils et le confort d'utilisation des langages interprts. Les
possibilits ainsi offertes l'utilisateur averti sont nombreuses : il peut par exemple
crer de nouveaux algorithmes, crer des couplages et des enchanements non
prvisibles, afficher et modifier slectivement toute information en cours de calcul.
Ceci exige toutefois de la part de l'utilisateur une bonne comprhension du rle de
chaque oprateur et de la logique globale du logiciel qui doit donc tre conu en
consquence.
L'utilisateur moins averti ou intress seulement par des oprations plus
rptitives pourra faire appel des enchanements standards ou macro-oprateurs de
plus ou moins haut niveau.

Utilisation plus dlicate


Flexibilit importante

Oprateur
de base
(lment du
langage de
Modlisation)
Sous-programme
Fortran
ou C

Utilisation simple
Flexibilit faible

Macro-oprateur complexe
(lment de haut niveau
du langage de Modlisation)

Macro-oprateur simple
(lment intermdiaire
du langage de
Modlisation)

De tels langages de modlisation permettent d'lever le niveau smantique de


la programmation des applications, favorisent la rutilisation d'oprateurs de base, et
simplifient la tche des utilisateurs occasionnels. D'autre part il est facile de crer des
versions du logiciel adaptes un besoin particulier en slectionnant les seuls
oprateurs utiles (outil-mtier).
4.5 Diffrents modes d'interaction avec le logiciel
L'informatique d'aujourd'hui nous a habitus l'utilisation de nombreux modes
d'interaction avec un ordinateur : langages varis, souris, menus droulants, ...
Chacun peut, bon droit, avoir ses prfrences. Pour s'adapter aux divers types
d'utilisation ou d'utilisateur, un logiciel de modlisation idal doit offrir en particulier
:
une entre clavier traditionnelle, donnant accs un (ou des) langage(s) de
modlisation adaptable(s) au contexte d'utilisation,
une entre guide par une hirarchie de menus compatibles, si possible, avec le
langage de modlisation,
un systme de navigation dans les structures de donnes du logiciel, permettant
l'accs, tant en lecture qu'en criture, toutes les informations,
un systme de reprsentation graphique des entits physiques et gomtriques
manipules, incluant la possibilit de slectionner des entits au moyen d'une
souris,
un systme de cration/modification de macro-oprateurs partir d'oprateurs et
macro-oprateurs existants.
Une voie attrayante est la commande du logiciel par simple spcification d'objectifs
atteindre : construire telle information, modifier telle donne et recalculer ce qui n'est
plus valide, afficher tel rsultat lorsqu'il aura t modifi de manire significative, ...
Une possibilit consiste inclure dans le logiciel une description de lui-mme, et
exploiter cette description pour synthtiser un macro-oprateur capable d'atteindre le
but spcifi. Ceci peut tre interprt comme de la programmation automatique dans
le langage de modlisation, programmation plus aise que dans un langage standard,

compte tenu de la granulomtrie plus importante du langage de modlisation. Cette


approche peut rduire considrablement les connaissances que doit possder
l'utilisateur concernant le logiciel lui-mme.
5. Exemple de l'architecture SIC
5.1 Gnralits
Depuis 1985, l'Universit de Technologie de Compigne a conu puis test dans
le cadre de plusieurs prototypes successifs une architecture de logiciel gnral de
modlisation, base sur les concepts prsents ci-dessus. Cette architecture porte le
nom interne "SIC" (Systme Interactif de Conception). Le travail correspondant a t
ralis en troite collaboration avec :
plusieurs quipes de recherche, en particulier celles de O. Debordes (IMT,
Marseille), de M. Jean (USTL, Montpellier), de B. Nayroles (INPG,
Grenoble);
des industriels, en particulier Renault, Pechiney, Valourec;
le CNRS, dans le cadre de l'Action de Recherche Coordonne du PIRSEM
"Thermique et Modlisation".
5.2 Organisation gnrale
L'architecture SIC dfinit trois blocs fonctionnels principaux :
une librairie extensible d'oprateurs (Librairie de Commandes : L.C.) qui
regroupe tous les traitements lmentaires que peut excuter l'utilisateur;
une systme de manipulations des informations, ces dernires tant organises
sous la forme d'un rseau d'objets (Gestionnaire d'objets : G.O.);
un systme de gestion des entres, qui interprte les ordres que fournit
l'utilisateur par l'intermdiaire d'un langage de modlisation, de macrocommandes, de menus, etc ... (Gestionnaire des Entres : G.E.).

Une autre reprsentation de l'architecture SIC, base sur un modle en couches,


est la suivante :

5.3 Gestionnaire d'objets (G.O.)


La spcification du systme de manipulation des informations est l'tape la plus
dlicate dans la conception d'une architecture de logiciel de modlisation. En effet
elle se heurte des objectifs contradictoires : tout en manipulant de gros volumes de
donnes, on cherche la rapidit pour les oprations de calcul intensif, mais aussi la
flexibilit et la richesse des structures de donnes pour :
les interactions homme-machine,
la reprsentation paramtre de systmes physiques et de formes gomtriques
complexes,
la manipulation des diffrents modles correspondant diffrentes hypothses,
l'accueil de structures de donnes complexes issues des programmes de CAO,
les oprations bases sur des techniques de manipulation explicite de la
connaissance (Intelligence Artificielle),
les traitements distribus.
Le modle gnral de structure de donnes retenu est le rseau d'objets; toutes les
informations manipules par le logiciel sont regroupes en paquets "typs", nomms
ici "Objets". Par exemple il existe des objets de type "points", "lignes", "matrices",
"vecteurs", "descripteurs de type d'objets", "fentres graphiques", "macrooprateurs", etc ... Chaque objet contient un certain nombre d'attributs de longueur

fixe ou variable, dont le nombre et le contenu dpend du type d'objet considr.


Chaque objet est identifi de manire unique par un identifieur, qui lui est attribu
par le G.O., lors de sa cration, ainsi qu'ventuellement par un nom. Chaque attribut
d'un objet peut contenir un ou des nombres rels ou entiers, des caractres (noms
d'objets), ou des identifieurs d'autres objets. De cette manire, chaque objet peut
pointer vers d'autres objets pour former des structures varies : rseaux, listes, arbres,
piles, ... :

A titre d'exemple, les attributs d'un objet de type "Noeud" sont les suivants :

Les services offerts par le Gestionnaires d'Objets sont organiss en couches :


couche 1 : Gestion de l'espace de stockage
Cette couche gre un espace virtuel en mmoire; elle permet de crer, dplacer,
rallonger, supprimer des objet de type indiffrenci; elle permet galement de
rcuprer l'espace laiss libre par des objets dtruits ou raccourcis, grce un
mcanisme de compactage, dont l'activation, coteuse, doit tre limite au maximum
:

couche 2 : Gestion interne des objets


Cette couche permet d'accder aux attributs des objets, d'en modifier le contenu,
ventuellement d'en modifier la longueur. On peut accder chaque attribut de
chaque type d'objet :
a) dans un programme, par un paramtre qui dfinit la position de l'attribut dans
l'objet;
b) en interactif, par le nom de l'attribut.
couche 3 : Gestion d'un rseau d'objets
Cette couche permet de naviguer dans un rseau d'objets qui pointent les uns sur
les autres; elle gre en particulier les noms des objets, leurs identifieurs, leurs
adresses, ainsi que divers mcanismes d'accs aux objets. Un objet ne peut pointer
sur un autre directement par son adresse puisque le mcanisme de rcupration
d'espace de la couche 1 peut tre amen dplacer des objets, c'est dire changer
leurs adresses. On utilise pour ce faire l'identifieur de l'objet qui est reli son
adresse grce un objet spcial : la "Table des Identifieurs" (TID) :

Chaque grande classe d'application (modles bass sur les lments finis,
optimisation, reprsentation de formes gomtriques) utilise un rseau d'objets
particulier adapt ses bsoins. Par exemple, le rseau destin au calcul par lments
finis est le suivant:

racine
variables relles
variables entires
liste de noeuds
noeud noeud ... noeud

sollicitation

table d'volution

cond. limite

table d'volution

matriau

table d'volution

lment lment ... lment


liste d'lments
matrice tangente
second membre
vecteur ddl
autres objets

couche 4 : Navigation dans un rseau d'objets


Cette couche utilise le mcanisme de dsignation d'objets par leurs
identifieurs ainsi qu'un systme de menus dynamiques. On fait appel deux modes
de reprsentation graphique d'un mme objet: son modle gomtrique et un menu
dont les cases correspondent aux attributs de l'objet :
Elment

slection
souris

ID

Numro
Matriau
Prop. gomtriques
Prop. lmentaires
Noeuds

lment

menu

L'identifieur d'un objet peut tre obtenu par slection sur la reprsentation
graphique de l'objet au moyen de la souris. L'objet ainsi slectionn devient alors
l'objet courant du navigateur et son contenu (attributs) apparat dans un menu sur
l'cran. Le comportement d'un tel menu est le suivant: la slection la souris d'un
attribut qui contient une valeur (numrique, caractres) permet d'diter cette valeur;
celle d'un attribut de type "identifieur" selectionne l'objet correspondant et affiche le
contenu de cet objet. Ainsi, en partant d'un lment fini on peut accder ses noeuds
(1, 2), ensuite aux sollicitations ou conditions aux limites affectes l'un de ces
noeuds (3) puis ventuellement modifier le niveau de chargement (4):

Elment
Numro
Matriau
Prop. gomtriques

Prop. lmentaires

Noeuds: Zone d'ID


1

Noeuds

2
3

"CLIM_XY"

Numros ddl imposs


Noeud

Valeurs ddl
Niveau de charge

1.0e2

lecture
ou
modification

Tables d'volution

Z
Condition Limite
Sollicitation
Numros equations

Valeurs des ddl

couche 5: Encapsulation
Les diffrents types d'objets peuvent tre manipuls par toutes les
oprations standards du GO: cration, destruction, modification, ... . On peut
galement dfinir d'autres oprations (mthodes) spcialises qui ne s'appliquent
qu' un type d'objet particulier. Une description de type d'objet associe aux
oprations spcifiques qui s'y appliquent dfinit un service. Un des services de
SIC les plus utiliss est la "table d'volution". Ce mcanisme est particulirement
puissant car il est utilisable dans de nombreux contextes parfois trs loigns
conceptuellement les uns des autres. Une table d'volution, au sens de SIC, est un
mcanisme d'interpolation qui, partir d'un ensemble de points de contrle et
d'un algorithme d'interpolation donn, est capable de rendre une valeur interpole
en chaque point d'un domaine 1 dimension. La description de l'objet "table
d'volution" est la suivante:
Table
d'volution
X1
X2
...
Xn
Y1
Y2

Y
Y4

(interpolation
linaire)

Y2,Y3
Y1
X

...
Yn

X1 X2

X3

X4

Mthode

Les zones Xi et Yi contiennent les points de contrle de la table; l'attribut


"mthode", de type nombre entier, selectionne l'algorithme d'interpolation (1 =
paliers, 2 = linaire, 3 = quadratique, etc ...). Le calcul est effectu par une fonction
spcifique:

y = ytevcv(identifieur_table_evolution, x)
Diffrents effets peuvent tre obtenus, en fonction du type d'objet auquel on
affecte une table d'volution, . L'affectation d'une table d'volution une "condition
la limite" ou une "sollicitation concentre" permet le pilotage du niveau des charges.
Affecter une table d'volution une proprit de matriau permet par exemple de
dfinir sa dpendance vis vis de la temprature. Dans l'exemple prcdent de
coudage de tubes, le module d'Young du matriau dpend de la temprature, ellemme variable selon la position axiale "s" vis vis de l'outil. La dtermination de la
valeur du module d'Young en un point d'integration numrique passe alors par deux
"tables d'volution" qui relient l'une la temprature la position axiale, et l'autre le
module d'Young la temprature:
T

point
d'integration

C
600

chauffage
par induction
600C

PGi

Table 1
T(s)

20

Elment
E

E(PGi)

T(s)

Table 2
E(T)

s
T

Une "table d'volution" constitue de paliers peut tre affecte un objet de posttraitement graphique du champ des ractions de contact sur la face interne du tube.
Ceci permet le filtrage des iso-couleurs: les zones en contact (raction positive)
seront traces en rouge, les zones o la raction est nulle (non contact) en bleu. Une
seconde table, linaire par morceaux, permettra de dfinir la cote z des iso-surfaces
reprsentant par exemple le niveau de la contrainte de Mises :

No couleur

Table 1
bleu: 3

bleu:
pas de contact

rouge: 1

rouge:
contact

Rn

Table 2
maillage
droul

!
!pl

2"!pl

5.4 Librairie de Commandes (L.C.)


Chaque classe d'application de SIC comporte deux parties: un rseau d'objets GO
qui structure les donnes, et une collection d'oprateurs (ou commandes) associs qui
excutent des actions.
La structure interne du sous-programme qui correspond une commande est la
suivante:
LC

...

...
...
...

GO
...

Commande No i
lecture des
valeurs de paramtres

Objet d'appel

recherche d'informations
dans le GO,
calcul des pointeurs

Objets d'entre
Objets modifis

traitement
remise des rsultats
dans le GO
...

...

Objets de sortie

...

Les applications de la mthode des lments finis en mcanique des solides sont
caractrises par :
1) les lois constitutives utilises :
- loi lastique linaire de HOOK
- lasto-plasticit avec des diffrents schma dcrouissage

- lasto-viscoplasticit
- ...
2) les schmas cinmatiques retenus :
- grandes/petites dformations
- hypothse cinmatique sur un pas de charge
- repre dans lequel on crit la loi de comportement
- ...
3) les types d'approximation spatiale par lments finis retenus; actuellement, le
systme. SIC reconnait les types suivants:
L2

L3

H8

TH4

T3

P6

Q4

H20

T6

TH10

Q8

P15

Dans SIC, une famille lmentaire est caractrise par le triplet (loi de
comportement, schma cinmatique, type d'lment).
Dans la version actuelle de SIC, les familles lmentaires suivantes sont
disponibles :
type de modlisation

type dlment

ElAsticit Plane
T3,Q4,T6,Q8
ElAsticit Tridimensionnelle
H8,H20,TH4,TH10,P6,P15
Diffusion Thermique Plane
T3,Q4,T6,Q8
Diffusion Thermique aXi
T3,Q4,T6,Q8
Diffusion Thermique Tridimensionnelle H8,H20,TH4,TH10,P6,P15
Echange Thermique Plane
L2,L3
Echange Thermique Axisymetrique
L2,L3
Echange Thermique Tridimensionnelle
T3,Q4,T6,Q8
Coque Mince
T3
Coque Axisymetrique
L2
Coque non-lineaire
Contact Bidimensionnel
lments de liaison
PlAsticite Plane
T3,Q4,T6,Q8
PlAsticite Axisymetrique
T3,Q4,T6,Q8
PlAsticite Tridimensionnelle
H8,H20,TH4,TH10,P6,P15
Visco-plasticit Plane
T3,Q4,T6,Q8
Visco-plasticit Axisymetrique
T
3,Q4,T6,Q8
Visco-plasticit Tridimensionnelle
H8,H20,TH4,TH10,P6,P15
Visco-plasticit g-des dformations Plane
T3,Q4,T6,Q8
Visco-plasticit g-des dformations Axi.
T3,Q4,T6,Q8
Visco-plasticit g-des dformations Tridim.
H8,H20,TH4,TH10,P6,P15

Une commande, associe la description des structures de donnes qu'elle


manipule, constitue un service gnral, capable de s'appliquer dans des contextes
varis. Un exemple de service gnral de la librairie de commandes est l'assemblage
de la matrice tangente d'un systme d'quations non-linaires par perturbation des
degrs de libert. La commande correspondante est base sur les objets "liste
d'lments finis" et "forces internes lmentaires" et construit une "matrice globale
tangente". Le traitement consiste parcourir les lments de la liste, valuer par
perturbations la matrice tangente de chaque lment, puis l'assembler.
liste des lments

...

...

F2
!u

F1

1
3

NELT

matrice lmentaire
!F1
!u1

!F1
!u2

!F1
!u3

!F2
!u1

!F2
!u2

!F2
!u3

!F3
!u1

!F3
!u2

!F3
!u3

F3

matrice globale

Pour chaque lment, on saisit ses caractristiques et les valeurs courantes de ses
degrs de libert. Ensuite, la commande standard de SIC "calcul des forces internes"
d'un lment fini est utilise pour le calcul des forces internes dans la configuration
courante et dans des configurations perturbes. Les colonnes de la matrice
lmentaire sont alors obtenues par une formule de differences finies. Une fois la
matrice tangente lmentaire value, celle-ci est assemble dans la matrice globale,
par un appel l'oprateur d'assemblage standard de SIC. Ainsi le mode stockage de
la matrice globale et les particularits des calculs lmentaires n'interviennent que
dans les oprateurs standards de SIC. On peut donc utiliser le service "calcul d'un
matrice tangente par perturbation" pour n'importe quel mode de stockage global et
n'importe quel type d'lment. Les applications de ce service sont nombreuses, tant
en mcanique non linaire qu'en optimisation.
Voici les groupes de commandes de la version standard de SIC :

Cration d'informations dans la base d'objets


Affichages et modifications d'informations varies
Oprations lies aux macro-commandes
Oprations de base de la mthode des lments finis
0prations lies aux rsolutions non linaires
Commandes pour la cration d'entits gomtriques
Calculs divers sur la gomtrie
Commandes pour la cration des entits constitutives d'un domaine
Oprateurs divers concernant la gestion des entits topologiques
Commandes relatives au maillage
Commandes relatives au raffinement d'un maillage
Commandes pour le repositionnement barycentrique ou lastique des noeuds par

rsolution directe
Commandes pour la dfinition du problme physique
Rsolution des ingalits dues au contact-frottement
Commandes d'homognisation
Gestionnaire graphique
Parametrage - Optimisation
Oprations de manipulation de la base d'objets
Gestion de l'historique des commandes excutes
Interface avec d'autres logiciels
Commandes diverses

5.5 Gestionnaire des entres (G.E.)


Le gestionnaire d'entres (GE) recoit les ordres transmis par l'utilisateur au
logiciel sous la forme de lignes de commande classiques. Le GE est l'interprteur de
ces lignes de commandes. Chaque fois qu'une ligne de commande est mise par
l'utilisateur, le GE vrifie sa syntaxe puis gnre un objet de type "objet d'appel de
commande" dans la base de donnes. Cet objet contient, sous une forme compacte
(ou "compile"), l'information ncessaire l'activation d'une commande :

L'objet d'appel obit aux mmes principes que tous les autres objets du GO. Il
contient un attribut qui identifie la commande excuter et ainsi que des attributs de
diffrents types pour le stockage de valeurs des paramtres de la commande. Ds
que le systme dtecte la prsence d'un nouvel "objet d'appel", la commande requise

est excute en mode synchrone ou asynchrone. Les valeurs des paramtres peuvent
tre restitues l'aide des fonctions d'accs aux attributs standards offertes par le GO.
Un "objet d'appel" correspond ainsi une commande "compile".
Une liste d'"objets d'appel" forme naturellement une macro-commande. Une telle
liste peut tre place dans un "objet macro-commande". Le systme de macrocommandes est hirarchique en ce sens que les macros peuvent tre appeles par
d'autres macros. Les services de base de ce systme offrent la possibilit de crer, de
modifier et de mettre au point pas pas des macro-commandes.
Le systme de macro-commandes hirarchiques permet de construire
progressivement un algorithme de rsolution compliqu. Par exemple la macro
"Rsolution" suivante peut tre utilise pour la rsolution du problmes linaris
interne une itration de la mthode de Newton Raphson :

Le dialogue GE suivant permet de dfinir une telle macro:


Sic3> CREER MACRO 'RESOLUTION'
RESOLUTION> INITIALISER MATRICE TANGENTE
RESOLUTION> ASSEMBLER MATRICE TANGENTE
RESOLUTION> APPLIQUER CONDITIONS_LIMITES
RESOLUTION> TRIANGULARISER
RESOLUTION> RESOUDRE
RESOLUTION> TERMINE
Sic3>

L'excution de cette macro ncessite l'excution de quelques commandes


pralables de cration des objets qu'elle utilise en entre :
Sic3>
Sic3>
Sic3>
Sic3>
Sic3>
Sic3>
Sic3>

CALCULER NUMEROTATION
CALCULER LARGEUR_BANDE
CALCULER FONCTIONS_INTERPOLATION
INITIALISER VECTEUR DEPLACEMENTS 'DU'
INITIALISER VECTEUR UPAS
EXECUTER MACRO 'RESOLUTION'

On peut ensuite visualiser l'tat des contraintes sur l'cran l'aide des commandes:
Sic3> ACTUALISE DEPLACEMENTS /VECTEUR='DU'
Sic3> POSTRAITE RESULTATS-ELEMENTAIRES SIGMA-MISES
Sic3>

Nous pouvons alors rutiliser la macro 'Rsolution' dans une nouvelle macro
"Itration" qui correspond une itration de rsolution d'un problme non-linaire:
Sic3> CREER MACRO/NOM=ITERATION
ITERATION> CALCULER SOMME/OBJET_1=FC/OBJET_2=R/OBJET_3=R
ITERATION> EXECUTE MACRO 'RESOLUTION'
ITERATION> CALCULER SOMME 'DU' 'UPAS' 'UPAS'/COEFFICIENT-1=BETA
ITERATION> INITIALISER VECTEUR RESIDU /NOM='R'
ITERATION> ASSEMBLER VECTEUR FORCES_INTERNES /VECTEUR='R'
ITERATION> CALCULER NORME/VECTEUR=DU VARIABLE/NOM='NMDU'
ITERATION> CALCULER NORME/VECTEUR=UPAS VARIABLE/NOM='NMU'
ITERATION> DIVISER VARIABLE 'NMDU' 'NMU' 'NMDL'
ITERATION> TERMINER
Sic3>

Les schmas suivants illustrent le fonctionnement des macros 'Pas' correspondant


un pas de charge et 'Newton' permettant d'enchaner un enesmble de pas :

Sic3> CREER MACRO 'PAS'


PAS> INITIALISER VECTEUR UPAS
PAS> AUGMENTER VARIABLE 'TMPS' 'DTMP'
PAS> ACTUALISER NIVEAUX
PAS> INITIALISER VECTEUR FORCES_CONCENTREES
PAS> ASSEMBLER VECTEUR FORCES_CONCENTREES/VECTEUR=FC
PAS> INITIALISER VARIABLE 'ITER'
PAS> 200:
PAS> AUGMENTER VARIABLE 'ITER'
PAS> EXECUTER MACRO'ITERATION'
PAS> TESTER/VALEUR=ITER SUPERIEURE/VALEUR=ITMAX ALLER 300
PAS> TESTER/VALEUR=NMDL SUPERIEURE/VALEUR=EPDL ALLER 200
PAS> 300:
PAS> ACTUALISER DEPLACEMENTS/VECTEUR=UPAS
PAS> ACTUALISER VARIABLES_INTERNES
PAS> TERMINER
Sic3>
Sic3> CREER MACRO 'NEWTON'
NEWTON> INITIALISER VARIABLE'MPAS' %1
NEWTON> INITIALISER VARIABLE'EPDL' %2
NEWTON> INITIALISER VARIABLE'DTMP' %3
NEWTON> INITIALISER VARIABLE'ITMAX'%4
NEWTON> IMPRIMER MESSAGE/TEXTE=' >>> Dtmp =
'/VALEUR='DTMP' '<<<'
NEWTON> INITIALISER VECTEUR RESIDU /NOM=R
NEWTON> 100:
NEWTON> AUGMENTER VARIABLE'IPAS'
NEWTON> EXECUTER MACRO 'PAS'
NEWTON> TESTER/VALEUR=IPAS INFERIEURE/VALEUR=MPAS ALLER 100
NEWTON> TERMINER
Sic3>

Dans cette dernire macro-commande le symbole "%i" signifie "paramtre No i de


la macro".
Supposons, que l'utilisateur, aprs avoir excut un pas de calcul:
Sic3> EXECUTER MACRO 'NEWTON'/PARAMETRE-1=1 /P-2=0.0001 /P-3=0.001 /P-4=10

dsire modifier ses macros pour suivre l'volution du champ de contraintes au fil des
pas (les parties inchanges sont en pointill). Il pourra alors apporter des
modifications la macro "Pas" (en gras dans le texte) laide de lditeur de
macros, la version finale de la macro tant la suivante:
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>
PAS>

INITIALISER VECTEUR UPAS


AUGMENTER VARIABLE 'TMPS' 'DTMP'
ACTUALISER NIVEAUX
INITIALISER VECTEUR FORCES_CONCENTREES
ASSEMBLER VECTEUR FORCES_CONCENTREES/VECTEUR=FC
INITIALISER VARIABLE 'ITER'
200:
AUGMENTER VARIABLE 'ITER'
EXECUTER MACRO'ITERATION'
TESTER/VALEUR=ITER SUPERIEURE/VALEUR=ITMAX ALLER 300
TESTER/VALEUR=NMDL SUPERIEURE/VALEUR=EPDL ALLER 200
300:
ACTUALISER DEPLACEMENTS/VECTEUR=UPAS
ACTUALISER VARIABLES_INTERNES
EFFACE ISOVALEURS
POSTRAITE RESULTATS-ELEMENTAIRES /DEFORMEE SIGMA-MISES
ACTUALISE ECRAN REDESSINE
TESTER/VALEUR=IPAS INFERIEURE/VALEUR=MPAS ALLER 100

Sic3> EXECUTER MACRO 'NEWTON'/P-1=350 0.0001 0.001 10


Sic3>

Le GE gre galement des variables globales du logiciel, ainsi que des variables
locales aux macro-commandes.
Le GE offre diffrents autres services tels que :
- la sauvegarde de l'historique (la liste de commandes d'une session).
- la cration d'un fichier espion qui permet la reprise d'une session,
- l'excution de fichiers de commandes permettent d'utiliser le logiciel en mode
"traitement par lots".
Une autre particularit du GE est la possibilit offerte l'utilisateur de spcifier, de
manire dclarative, la syntaxe et la smantique du langage de commande. Celles-ci
sont en effet dfinies dans des fichiers de texte modifiables dynamiquement
(xxxx.DSC). Elles peuvent tre adaptes une application particulire pour adhrer
la terminologie propre un mtier; par exemple en mcanique on appelle
"dplacements" les degrs de libert d'un noeud alors qu'en thermique on parlera de
"tempratures"; la diffrence est purement syntaxique alors que les oprateurs
mettre en oeuvre sont identiques. La possibilit d'dition du fichier de dfinition de la
syntaxe du langage de commande facilite galement l'internationalisation du logiciel.
On peut s'en servir galement pour limiter l'accs certains oprateurs jugs

superflus ou dangereux dans un environnement donn, en supprimant la syntaxe


correspondante du fichier, le logiciel restant inchang.
5.6 Interface Utilisateur (IU)
L'Interface Utilisateur constitue la couche de gestion de l'interactivit entre
l'utilisateur et le logiciel. L'criture de cette portion du logiciel, variable d'une
application l'autre, constitue la phase ultime du processus d'industrialisation du
logiciel. Cette couche permet d'isoler l'utilisateur de la complexit du logiciel
gnral, lorsque cela s'avre utile, et de crer des outils mtiers simples adapts des
classes d'applications limites. Il y aura donc autant d'IU qu'il y aura d'outils mtiers.
Pour raliser des IU efficaces, on prendra en compte les habitudes et les modes de
travail de chaque groupe d'utilisateurs industriels.
Du ct "utilisateur" de l'IU, on pourra utiliser toutes les techniques disponibles :
des menus bien sr mais aussi des images vido, la reconnaissance de la parole,
divers modes de prsentation graphique. De nombreux outils, bass sur la norme
OSF/MOTIF facilitent la crations d'IU trs raffins.
L'IU est coupl avec le reste du logiciel par l'intermdiaire de lignes de
commande qui sont ensuite interprtes par le GE, ou plus directement par
l'intermdiaire d'un objet d'appel de commande. Les commandes gnres par l'IU
activeront plus souvent des macro-commandes que des oprateurs de base. Le
passage par le langage de commande isole mieux l'IU du reste du logiciel, et
simplifie son criture : on peut en particulier simuler aisment le fonctionnement de
l'interface indpendemment du reste du logiciel.

L'individualisation de l'IU proprement dit facilite les dveloppements, car, adapt


un problme particulier, il prsente des spcifications assez simples, et ne doit
connatre qu'un nombre rduit de lignes de commande. Il est facile de modifier un IU
sans tenir compte de la complexit du logiciel gnral, et en se concentrant sur la
convivialit et l'ergonomie de l'IU. Toute commande issue de l'IU doit s'excuter
sans problme dans le logiciel, la vrification de la cohrence des donnes tant
assure par l'IU. Contrairement au GE, l'IU n'admet pas de donnes invalides (en
dehors du domaine admissible par le logiciel) et ne permet pas l'excution d'une
commande avant que toutes les donnes ncessaires ne soient collectes et valides.
Ceci simplifie la tche de l'utilisateur inexpriment en vitant que le logiciel ne
s'arrte sur une erreur, et conduit :
- une amlioration de la"connivence" entre l'utilisateur et le logiciel,

- une meilleure "tolrance du programme aux erreurs humaines".


1. Bibliographie
[FEL 81] C. A. Felippa Architecture of a distributed analysis network for
computational mechanics Computers & Structures vol. 13(1981) pp 405-414
[FEL 80] C. A. Felippa Database in Scientific Computing Part I Computers &
Structures vol. 12(1980) pp131-146
[AUN 90] S. Aunay Architecture de Logiciel de modlisation et Traitements
Distribus thse de doctorat, UTC, France 1990
[DHA 84] G. Dhatt, G. Touzot, Une prsentation de la mthode des lments
finis, 2e ed., Maloine S.A., Paris 1984
[BRE 91] P. Breitkopf, C. Knopf-Lenoir, L. Moranay, G. Touzot, R. Younsi An
Integrated Software Architecture for Generalized Sensitivity Analysis and
Optimization of Physical Systems European Conference, Giens April 1991
[SAM] S.A.M.C.E.F., Systme dAnalyse des Milieux Continus par Elments
Finis, SAMTECH, Lige, Belgique
[MAC] MSC/NASTRAN, The MacNeal-Schwendler Corporation, Los Angeles,
California

You might also like