Download Développement d`un pôle de calcul : CESAR-LCPC

Développement
d'un pôle de calcul :
CESAR-LCPC
Alain D U B O U C H E T
Technicien supérieur
Section Modèles numériques
Service Mécanique
Laboratoire Central des Ponts et Chaussées
Présentation
Pierre H U M B E R T
Chef de la Section Modèles numériques
Service Mécanique
Laboratoire Central des Ponts et Chaussées
RESUME
C E S A R - L C P C , progiciel de calcul par éléments finis, est né au début des années quatrevingt de l a critique des systèmes précédemment développés au L C P C , et de l'étude des
méthodes préconisées alors pour organiser de
tels outils. Il s'est développé dans les différents domaines du génie civil grâce à une
architecture modulaire et à une méthodologie
précise, décrites dans u n Manuel de programmation. Jusqu'à maintenant, les développeurs
avaient retenu pour leur production des critères de qualité inspirés essentiellement par
l'expérience acquise. Devenue une exigence
chez u n nombre croissant d'utilisateurs, la
qualité doit maintenant être prise en compte
dans le sens formalisé par les travaux de l ' A F C I Q et de l ' A F N O R . De façon à être présente à
tous les stades d'élaboration du progiciel, cette
formalisation se doit d'être introduite sous
forme de règles et de conseils dans le Manuel
de programmation de C E S A R - L C P C . S'appuyant sur des critères de qualité clairement
affichés, la sous-traitance pourrait alors être
envisagée pour les domaines ne constituant
pas strictement le « métier » de l'équipe de
développement.
M O T S C L É S : 20 - Programme de calcul •
Éléments
finis
(méthode)
Historique
Développement - Qualité • Génie civil.
Le progiciel CESAR-LCPC
représente une très grande
part de la compétence
acquise par le
Laboratoire
Central des Ponts et Chaussées depuis une vingtaine
d'années dans l'adaptation
et l'application
de la
méthode des éléments finis aux problèmes de génie
civil.
Historiquement,
cette méthode a d'abord été développée par les ingénieurs de la construction
mécanique
(aéronautique, construction navale, ouvrages métalliques). Au LCPC, c'est sous l'impulsion initiale des géotechniciens, confrontés à des problèmes insolubles par
les méthodes de calcul alors en vigueur, que la
méthode a été introduite. A leur demande, un grand
nombre de lois de comportement en mécanique des sols
et des roches, ainsi que des procédés permettant
la
prise en compte du phasage de construction, ont été
progressivement
introduits dans le code de calcul. Les
spécialistes des ouvrages d'art allaient rapidement se
sentir concernés par la généralité de la méthode et provoquer des développements adaptés à leurs problèmes
(éléments structuraux, modules de calcul en dynamique, etc.). Parallèlement, le développement de modules
de calcul en diffusion transitoire a permis
d'apporter
une aide appréciable aux hydrogéologues
et aux spécialistes
de l'environnement.
De même, dans le
domaine des chaussées, des modules existants ou en
cours de développement permettent d'aborder
certains
problèmes plus particuliers
à ce type de
structure
(contact, propagation de fissure).
77
Bull, liaison Labo. P. et Ch. - 178 - mars-avr. 1992 - Réf. 3632
Ainsi, au fil du développement
du progiciel, il
apparaît que tous les domaines
traditionnels
des Laboratoires
des Ponts et Chaussées
se
rejoignent sur une plate-forme de calcul commune.
Le développement,
la diffusion et la maintenance d'une telle plate-forme
nécessite
l'existence d'une équipe ayant une bonne compétence
dans les domaines
évoqués ci-dessus.
Cette
équipe doit également avoir la maîtrise d'un
certain nombre de techniques et de méthodes
empruntées à des disciplines scientifiques
(mathématiques,
analyse
numérique,
mécanique
des milieux continus, etc.), ou à des métiers (informaticien,
dessinateur, graphiste,
enseignant,
etc.) très divers.
Les
huitièmes
journées
d'informatique
de
Saint-Brieuc
ont été l'occasion pour l'équipe de
développement
d'aborder à travers la Qualité
un nouvel aspect méthodologique, et de mesurer
l'impact de ce concept sur notre production.
Cet
effort nous permet de suivre avec attention la
réflexion entreprise par le Service
informatique
pour doter le LCPC de véritables outils de génie
logiciel.
Introduction
C E S A R - L C P C est un progiciel* [1] de calcul
basé sur la méthode des éléments finis, particulièrement adapté à la résolution des problèmes de génie civil et de génie industriel : calcul
des structures, mécanique des sols et des
roches, thermique, hydrogéologie, etc. [2]. Il se
compose principalement du code de calcul
C E S A R et des pré- et post-processeurs interactifs graphiques M A X et P E G G Y . On l'utilise
dans de bonnes conditions sur les stations de
travail actuelles ou sur tout autre calculateur
scientifique ayant des caractéristiques analogues (mémoire centrale minimum de 8 Mo,
espace disque de 100 Mo ou plus, écran graphique couleur haute définition).
C E S A R - L C P C peut être considéré comme un
gros progiciel dans la mesure où il est actuellement constitué d'un système de programmes
dépassant les 150 000 instructions, de plus
d'une centaine de jeux de données de test et
d'une documentation répartie en une dizaine
de types de manuels. Tout ceci n'a pu se développer sans un minimum de règles intuitivement mises en place à l'origine. Aujourd'hui,
spécifications et méthodes sont clairement formalisées par le génie logiciel** [3].
A la méthodologie de développement établie
dès l'origine du progiciel, sont venues s'ajouter
au fil de sa croissance, des règles de gestion
introduisant entre autres des critères de
sûreté et de sécurité d'utilisation. C E S A R L C P C étant destiné à être diffusé, un ensemble de règles concernant la portabilité et la
satisfaction des utilisateurs (ergonomie) est
également présent, épousant parfois les
contours de la qualité. E n effet, « la qualité
78
d'un logiciel n'est pas l'absence d'erreur dans
son code (chose improuvable), mais plutôt son
aptitude à satisfaire les besoins de l'utilisateur, tant sur le plan fonctionnel que du point
de vue des caractéristiques d'utilisation » [4].
Rappel historique
L'actuel pôle de calcul est né à la fin des années
soixante de la volonté de voir renforcés au
L C P C les moyens d'études et de dimensionnement des ouvrages de génie civil et, en particulier, d'utiliser les éléments finis pour résoudre
certains problèmes de géomécanique insolubles
par les méthodes en vigueur à cette époque.
C'est ainsi que dès 1968 était constituée une
petite équipe pour développer un programme
qui allait prendre le nom de R O S A L I E . Les premières études réalisées avec cet outil allaient
vite montrer l'intérêt et les potentialités qu'offrait la méthode. L'équipe de développement
était alors renforcée pour lui permettre de
construire un système complet, permettant le
calcul des structures et de prendre en compte
les comportements non linéaires tels que ceux
rencontrés en mécanique et en hydrogéologie.
Outre le programme de calcul proprement dit,
ce système allait s'enrichir de programmes périphériques ayant pour objet la génération du
maillage, la vérification des données du calcul
et l'interprétation graphique des résultats [5].
L'architecture du système R O S A L I E et la
taille des problèmes traités nécessitaient l'emploi des gros calculateurs de
l'époque
(CDC 6600, I B M 370/168, etc.). Le réseau des
L P C ne pouvait pas utiliser cet outil, car i l
n'était pas envisageable de l'installer sur les
calculateurs alors disponibles dans les C E T E .
Aussi, à partir de 1975, la bibliothèque des
PPR (Petits Programmes Rapides, de dimension restreinte et d'application spécialisée)
était développée, avec comme principale spécification de pouvoir fonctionner sur des machines de la taille des IRIS 80, et de satisfaire
ainsi la demande du réseau [6].
Entre l'origine de R O S A L I E et le début des
années quatre-vingt, le paysage informatique
avait considérablement changé (disparition de
la carte perforée, apparition de la mémoire vir-
* « U n progiciel comprend le dossier-programme et
les supports d'information sur lesquels le programme est enregistré, les jeux d'essai et l a documentation associée. I l constitue un ensemble cohérent et adaptable de programmes ou de
sous-programmes permettant l a réalisation par l'ordinateur d'une tache importante et spécifique. »
** « Génie logiciel : ensemble des outils et de procédures relatifs aux différentes phases de l'élaboration d'un logiciel : spécification, programmation,
suivi de production, test et mise au point, qualification, recette, maintenance, etc. »
t u e l l e , d u temps partagé, télé-traitement,
b a n a l i s a t i o n d u g r a p h i q u e interactif), et a v a i t
fait naître de nouvelles exigences chez les u t i l i sateurs : convivialité, facilité d'emploi, etc. D e
son côté, R O S A L I E a v a i t a t t e i n t u n état c r i t i que à l a fois e n développement (taille et complexité d u code), e n m a i n t e n a n c e (nombreuses
redondances) et e n u t i l i s a t i o n (les p r o g r a m m e s
ne s'exécutaient qu'en t r a i t e m e n t p a r lots). I l
était donc d e v e n u nécessaire de revoir nos
méthodes de t r a v a i l et de f o r m u l e r de n o u v e l les spécifications p o u r le pôle « c a l c u l p a r élém e n t s finis ».
Genèse de CESAR-LCPC
Après
a n a l y s e et
critique
du
système
R O S A L I E et de l a bibliothèque P P R , et à p a r t i r d'une étude bibliographique de l a littérat u r e « éléments finis » devenue abondante et
désormais disponible e n l i b r a i r i e , u n c e r t a i n
nombre de spécifications étaient retenues, dont
p a r m i les p r i n c i p a l e s [7] :
— séparation des étapes « m i s e e n données »,
« c a l c u l », « e x p l o i t a t i o n des résultats » ;
— progiciel de recherche, donc des p r o g r a m mes f a c i l e m e n t développables : modularité ;
— progiciel i n d u s t r i e l , donc des p r o g r a m m e s
facilement utilisables : interactif graphique ;
— rédaction d'une d o c u m e n t a t i o n complète et
b i e n structurée ;
— diffusion s u r u n e l a r g e g a m m e de matériel
(micro-ordinateur exclu) : portabilité.
L e t r a v a i l de p r o g r a m m a t i o n p o u v a i t alors
commencer p o u r a b o u t i r a c t u e l l e m e n t à l'ensemble de p r o g r a m m e s c o m m u n i q u a n t entre
eux selon le schéma de l a figure 1.
-(CESAR - LCPCj-
MAX
CESAR
PEGGY
Outils
Basas de données
Unitaires
MAX
: pré-processeur interactif graphique pour la réalisation du
maltiage et la préparation des données du calcul.
CESAR
: code de calcul par éléments finis.
PEGGY
: post-processeur interactif graphique pour l'Interprétation
des résultats du calcul et la création de documents.
Utilitaires
: programmes d'aide à la mise en données
(ils agissent sur la base de données).
Outils
: programmes d'aide au développement (ils utilisent les
fichiers source des programmes comme données)
Fig. 1 - Architecture
du progiciel
CESAR-LCPC.
Organisation du
CESAR-LCPC
développement
de
L'équipe de développement
Dès l'origine, i l était établi que le développem e n t des p r o g r a m m e s a l l a i t être assuré p a r
u n e équipe spécialisée (actuellement répartie
entre les différentes i m p l a n t a t i o n s géographiques d u L C P C ) à laquelle v i e n d r a i e n t s'ajouter
thésards et stagiaires p o u r l a durée de l e u r
recherche. C e r t a i n s développements p o u r r a i e n t
également être réalisés dans d'autres l a b o r a t o i res (exemples : e n d o m m a g e m e n t p a r l'Ecole
N o r m a l e Supérieure C a c h a n , « l o i de C a m b o u »
p a r l'Ecole C e n t r a l e de L y o n , m e i l l e u r spécialiste e n bio-mécanique p a r l'Ecole N a t i o n a l e
Supérieure des A r t s et Métiers, etc.). C o m p t e
t e n u de l a complexité croissante des a l g o r i t h mes i n t r o d u i t s d a n s les p r o g r a m m e s , a u c u n
développeur ne p e u t être u n spécialiste de l ' e n semble des domaines abordés p a r C E S A R L C P C . C e l a a c o n d u i t à m e t t r e l'accent s u r
deux aspects :
— nécessité d'une d o c u m e n t a t i o n complète,
intégrant l a phase de p r o g r a m m a t i o n , a f i n que
p l u s i e u r s personnes puissent collaborer a u
développement sans r i s q u e de conflit ou de
redondance ;
— architecture des p r o g r a m m e s p e r m e t t a n t de
greffer les développements de manière s i m p l e ,
sans que c h a c u n a i t à connaître p a r f a i t e m e n t
l'ensemble d u p r o g r a m m e s u r l e q u e l i l t r a vaille.
La documentation
U n gros effort de d o c u m e n t a t i o n est demandé
à l'équipe de développement c a r les m a n u e l s
sont l ' u n des éléments visibles d u progiciel
(l'autre étant s a p r o d u c t i o n graphique). I l f a u t
donc souligner l'importance de celle-ci et y port e r u n e a t t e n t i o n a u m o i n s égale à celle de l a
p r o g r a m m a t i o n . C h a c u n doit considérer que l a
rédaction de l a d o c u m e n t a t i o n fait p a r t i e d u
t r a v a i l de développement : u n m i n i m u m de
rédaction s'impose de toute façon a u p r o g r a m m e u r , ne serait-ce que p o u r décrire l'ensemble
des équations t r a i t a n t le problème p h y s i q u e à
modéliser (partie théorique), p o u r t r a c e r l'organ i g r a m m e d u n o u v e a u m o d u l e à développer
(architecture des instructions), p o u r décrire les
données à f o u r n i r et les résultats obtenus
(mode d'emploi), etc. A i n s i , l o i n d'apparaître
comme u n e contrainte, l a d o c u m e n t a t i o n des
p r o g r a m m e s d e v i e n t u n e aide dans les phases
de développement et de m i s e a u point. E n dern i e r l i e u , et p o u r a s s u r e r le caractère i n d u s t r i e l de C E S A R - L C P C , les derniers développem e n t s ne p e u v e n t être intégrés dans l a v e r s i o n
officielle que s'ils sont correctement et complèt e m e n t documentés.
L a d o c u m e n t a t i o n est organisée en différents
m a n u e l s correspondant à u n usage b i e n précis.
79
É
P o u r conserver l a modularité propre a u progiciel et p o u r faciliter les mises à j o u r et les
développements, l a p l u p a r t des m a n u e l s sont
organisés e n fascicules indépendants les u n s
des autres. L ' o r d r e d a n s lequel les différents
m a n u e l s sont présentés ci-dessous correspond
sensiblement à l a chronologie que v a s u i v r e l a
rédaction de l a d o c u m e n t a t i o n d ' u n n o u v e l
a l g o r i t h m e i n t r o d u i t d a n s le progiciel :
— m a n u e l théorique ;
— m a n u e l de p r o g r a m m a t i o n ;
— mode d'emploi ;
— bibliothèque des j e u x de données (dont
recueil de s o l u t i o n s a n a l y t i q u e s ) ;
— bibliothèque d'exemples ;
— m a n u e l de f o r m a t i o n (dont fascicule de présentation, glossaire, etc.) ;
— fascicule d ' i m p l a n t a t i o n ;
— recueil d'incidents.
L a sortie des résultats ( i m p r e s s i o n s , a l i m e n t a t i o n de l a base de données) est réalisée d a n s des
unités de p r o g r a m m e s spécifiques, indépendantes de celles chargées d u t r a i t e m e n t proprem e n t d i t . E l l e s n ' a p p a r a i s s e n t pas s u r l a
figure 2 c a r étant très dépendantes de l a
f a m i l l e d'éléments ou d u m o d u l e d'exécution
utilisé, i l est plus commode de les r a t t a c h e r à
ceux-ci.
Modules
de gestion
des données
COOR,
CHAT,
etc.
Modules
d'exécution
LINE,
MCNL,
etc.
Librairie
des
(onctions
Le manuel de programmation
L e m a n u e l de p r o g r a m m a t i o n r e t i e n t i c i notre
a t t e n t i o n dans l a m e s u r e où c'est à p a r t i r de
l u i que l a n o t i o n de qualité v a pénétrer les différents c o n s t i t u a n t s d u progiciel. C e m a n u e l
contient e n effet les règles d'architecture, de
p r o g r a m m a t i o n et de d o c u m e n t a t i o n . I l présente les o r g a n i g r a m m e s et l e u r t r a d u c t i o n e n
langage de p r o g r a m m a t i o n (fichiers source), i l
décrit également les différents fichiers de l a
base de données a s s u r a n t l a c o m m u n i c a t i o n
entre les p r o g r a m m e s et i l expose les règles de
gestion des différentes v e r s i o n s . U n fascicule
p a r t i c u l i e r est chargé d'afficher les axes de
développement f u t u r s . L'objectif d u m a n u e l de
p r o g r a m m a t i o n est e n p r e m i e r l i e u d'assurer
l a m a i n t e n a n c e et de faciliter l a correction
d'éventuelles e r r e u r s . E n second l i e u , i l p e r m e t
a u x p r o g r a m m e u r s chargés des développem e n t s d'effectuer ceux-ci e n h a r m o n i e avec les
algorithmes déjà codés.
Règles d'architecture: exemple du code de
CESAR
C E S A R est constitué de modules de gestion des
données (exemple : C O O R pour l a définition des
coordonnées des nœuds, C H A R pour l a définition des chargements, etc.), de modules d'exécut i o n (exemple : L I N E pour l a résolution d'un
problème linéaire, M C N L pour u n problème de
mécanique à comportement n o n linéaire, etc.),
de familles d'éléments (exemple : f a m i l l e 1
regroupant les éléments bidimensionnels en
mécanique, f a m i l l e 5 pour les éléments de
coque, famille 22 pour les éléments t r i d i m e n sionnels e n diffusion, etc.) d'une interface réalisant l'aiguillage entre modules et les familles
d'éléments concernées, et d'une l i b r a i r i e de
fonctions générales.
L a figure 2 fait c l a i r e m e n t apparaître l a m o d u larité de C E S A R et l'indépendance q u i existe
d'une p a r t entre l'entrée des données et le t r a i tement, et d'autre p a r t entre l a p r o g r a m m a t i o n
des f a m i l l e s et celle des modules d'exécution.
80
générales
Familles d'éléments :
etc.
1,.. .5, ...22
Fig. 2 - Architecture
du code de calcul
CESAR.
L a gestion de l'espace réservé p o u r les
t a b l e a u x est u n autre p o i n t i m p o r t a n t de l ' a r chitecture d u code de c a l c u l . Schématiquem e n t , C E S A R u t i l i s e u n e table u n i q u e et des
p o i n t e u r s p e r m e t t a n t de découper celle-ci e n
différents t a b l e a u x créés p a r l ' e m p l o i des
modules activés p a r l ' u t i l i s a t e u r . C e u x - c i sont
alloués e n p r e m i e r , l a place n o n utilisée étant
ensuite attribuée à l a m a t r i c e de rigidité. S i
cette dernière sort de l a place disponible,
C E S A R déclenche alors u n mécanisme de p a g i n a t i o n s u r disque. L a gestion des p o i n t e u r s
a i n s i que l a réservation, l a r e s t i t u t i o n et l a
compression d'espace, sont assurées à l'intécalcul
r i e u r des modules p a r appel des fonctions de l a
l i b r a i r i e générale. Cette t e c h n i q u e d'allocation
pseudo-dynamique p e r m e t de régler f a c i l e m e n t
le p r o g r a m m e à l a t a i l l e des problèmes u s u e l l e m e n t traités et d'optimiser a i n s i l ' e m p l o i des
ressources i n f o r m a t i q u e s (adéquation mémoire
centrale / mémoire de m a s s e / t e m p s de calcul).
L e m a n u e l de p r o g r a m m a t i o n présente égalem e n t les règles p o u r insérer u n n o u v e a u
module ou u n e nouvelle f a m i l l e d'éléments et
les modifications que cela i m p l i q u e d a n s cert a i n e s unités de p r o g r a m m e de l'interface.
Règles de programmation
L'écriture des unités de p r o g r a m m e s doit évid e m m e n t se faire e n respectant u n c e r t a i n
nombre de règles a y a n t t r a i t à l a lisibilité (l), à
l a portabilité (p), etc. O n peut citer :
— les règles de r a n g e m e n t des unités de p r o g r a m m e s d a n s les fichiers source (l) ;
— l'ordre des i n s t r u c t i o n s de déclaration (l) ;
— les règles concernant les formats d'impression (p) ;
— l ' u t i l i s a t i o n de l a p r o g r a m m a t i o n s t r u c t u rée ;
— les règles d ' a t t r i b u t i o n des noms de v a r i a bles et d'unités de p r o g r a m m e s ;
— les règles d ' u t i l i s a t i o n des fonctions i n t r i n sèques d u langage de p r o g r a m m a t i o n (p).
Les programmes Interactifs graphiques: MAX
PEGGY
L e s fascicules consacrés à M A X et à P E G G Y
contiennent les i n f o r m a t i o n s indispensables
pour conserver l'homogénéité d'apparence des
divers modules graphiques. O n t r o u v e r a donc
l a d e s c r i p t i o n des différentes fenêtres écran et
t r a c e u r , les caractéristiques de couleur, t a i l l e ,
épaisseur, etc., retenues p o u r les p r i m i t i v e s
graphiques (ligne, texte, symbole, remplissage
de zone) a i n s i que l ' e n v i r o n n e m e n t des i n t e r actions utilisées (saisie clavier/réticule p u i s
décodage).
Règles de documentation
L e s règles et les conseils concernant l a rédact i o n des m a n u e l s , déjà évoqués précédemment,
figurent également dans le m a n u e l de prog r a m m a t i o n . U n complément i n d i s p e n s a b l e à
ce d e r n i e r consiste à documenter les fichiers
source à l'aide de commentaires. E n p a r t i c u l i e r , e n tête de chaque unité de p r o g r a m m e on
doit t r o u v e r :
— u n c o m m e n t a i r e décrivant l a fonction de
l'unité de p r o g r a m m e ;
— des commentaires r e l a t i f s à l a l i s t e des
a r g u m e n t s d'appel à l'unité de p r o g r a m m e
i d e n t i f i a n t les a r g u m e n t s s e r v a n t de données
et ceux contenant les résultats des calculs
effectués ;
— des commentaires i d e n t i f i a n t les a r g u m e n t s
contenus dans les zones communes et modifiés
dans l'unité de p r o g r a m m e ;
— l a liste des fonctions externes à l a l i b r a i r i e
des fonctions intrinsèques et q u i r i s q u e n t donc
de créer des problèmes de portabilité (par
exemple, tirage de nombres aléatoires, mesure
d u temps de c a l c u l , p r o d u i t scalaire, etc.) ;
— l a liste des fichiers manipulés ;
— des r e m a r q u e s éventuelles s u r les l i m i t a tions de l ' a l g o r i t h m i q u e actuelle, les difficultés
d'emploi ou de portabilité, et les améliorations
à envisager ;
— des commentaires i d e n t i f i a n t les corrections
o u modifications apportées à l a v e r s i o n o r i g i n a l e avec l e u r s dates.
Les versions de programmes
V a l o r i s e r les développements effectués p o u r
l a recherche e n les m e t t a n t dès que possible à l a d i s p o s i t i o n des clients d u L C P C
(réseau L P C , m i l i e u i n d u s t r i e l , m i l i e u de
recherche/enseignement)
est u n e de
nos
a m b i t i o n s . C E S A R - L C P C doit donc être à l a
fois u n progiciel i n d u s t r i e l et u n progiciel
de recherche.
U n progiciel i n d u s t r i e l est u n p r o d u i t fini
constitué de p r o g r a m m e s entièrement v a l i dés, accompagnés d'une d o c u m e n t a t i o n complète et des j e u x de données de test. L a
sécurité des a l g o r i t h m e s présents dans le
et
progiciel doit être telle que, après u n m i n i m u m de f o r m a t i o n , nos « clients » soient e n
mesure
d'utiliser C E S A R - L C P C
de
façon
autonome s u r l e u r propre c a l c u l a t e u r . Sous
réserve d'une modélisation correcte d u p r o blème traité, l a fiabilité des résultats doit
l e u r être g a r a n t i e .
U n progiciel de recherche offre u n cadre
m o i n s rigide que c e l u i décrit ci-dessus. I l
s'agit plutôt d'un p r o d u i t e n cours d'élaborat i o n fonctionnant comme une s t r u c t u r e d'accueil s u r laquelle de n o m b r e u x développeurs
peuvent i n t e r v e n i r . L e s objectifs sont alors
m u l t i p l e s et les i n t e r v e n t i o n s sont orientées
p r i n c i p a l e m e n t dans les directions s u i v a n tes :
— développements finalisés : i l s'agit d'introd u i r e les a l g o r i t h m e s issus d u fascicule « A x e s
de développement » q u i se retrouveront dans l a
version "industrielle" ;
— développements prospectifs : i l s'agit de test e r de nouveaux algorithmes. Après analyse et
critique, i l s peuvent ne pas être r e t e n u s p o u r
l a v e r s i o n « i n d u s t r i e l l e » (exemples : problème
de convergence ou de temps de c a l c u l , o u ,
encore, contrat de développement soumis à
confidentialité) o u laissés e n veille technologique (exemple : e m p l o i trop délicat) ;
— « taillage » d u code pour modéliser u n problème p a r t i c u l i e r ou pour l'adapter à une
machine
particulière
(exemples :
version
réduite pour essais de m a c h i n e s , i m p l a n t a t i o n
s u r m a c h i n e s « exotiques », etc.).
P o u r répondre à ces spécifications,
chaque
nouvelle fonctionnalité v a passer p a r une
étape de développement, p u i s p a r u n e étape
d'intégration dans le progiciel p o u r a t t e i n d r e
l'étape finale de l a diffusion a u x "clients". I l
est évident que C E S A R - L C P C est, et sera
toujours, e n constante évolution et que ce
processus est c o n t i n u dans le temps. T o u t
u t i l i s a t e u r doit pouvoir c l a i r e m e n t i d e n t i f i e r
l a v e r s i o n utilisée a i n s i que l a provenance
des résultats obtenus. C'est p o u r q u o i les étapes décrites ci-dessus sont respectivement
nommées « phase recherche », « phase b e t a test » et « phase s t a n d a r d » et que chaque
p r o g r a m m e édite ce n o m et le numéro de v e r sion à tous les endroits stratégiques :
— dans les
— dans les
— dans les
des risques
— dans les
dialogues à l'écran ;
fichiers d'édition ;
fichiers b i n a i r e s (surtout s ' i l y a
d'incompatibilité entre versions) ;
fichiers destinés a u x t r a c e u r s .
81
Les outils
Utilisation et diffusion
Pour pallier la carence de certains systèmes
d'exploitation utilisés au cours du développement de M A X , de C E S A R et de P E G G Y , des
programmes ont été écrits pour venir en aide
aux développeurs. Actuellement, des fonctions
telles que organigramme, édition de fichiers
source, index des unités de programmes, manipulation/comparaison de fichiers symboliques,
analyse des zones de variables communes, etc.,
peuvent être réalisées par ces petits programmes qui forment la « boîte à outils » de
C E S A R - L C P C . L a durée de vie de ces outils
est évidemment très dépendante de l'introduction de véritables outils de génie logiciel sur le
réseau Unix du L C P C .
Le progiciel C E S A R - L C P C est utilisé en
interne pour de nombreux travaux de recherche et dans des interventions d'experts. Il est
également diffusé dans le réseau des L P C ,
dans le réseau technique du Ministère, en
milieu industriel et dans le milieu rechercheenseignement. Une soixantaine d'implantations ont été réalisées sous divers systèmes
d'exploitation, le standard recommandé étant
Unix. L a diffusion sur des machines très diverses est rendue possible grâce à l'application de
règles exposées ci-dessous, et présentes bien
sûr dans le manuel de programmation.
Validation
D'une façon générale, il est établi que la validation d'un logiciel scientifique comporte deux
aspects [8] :
« — la vérification des modules élémentaires
qui réalisent une fonction mathématique ou un
algorithme numérique précis. Elle se fait par
autocontrôle au niveau du réalisateur ;
— la validation globale du logiciel qui intègre
ces modules vérifiés. Elle nécessite une comparaison avec des résultats théoriques, expérimentaux, ainsi qu'avec d'éventuels résultats
obtenus par des logiciels utilisant d'autres
algorithmes de résolution. Car ce n'est pas le
logiciel proprement dit qui a besoin d'être validé, c'est en fait l'ensemble des applications
qu'il permet de résoudre, avec pour chacune
d'elles une plage de validité précise. »
Pour C E S A R - L C P C , nous distinguons le cas
des pré- et post-processeurs pour lesquels une
vérification visuelle suffit pour valider les différents modules graphiques, du cas du code de
calcul, pour lequel nous appliquons des règles
voisines de celles qui viennent d'être énoncées :
a) Recherche de cas test ayant une solution
analytique et résolution par éléments finis. L a
comparaison entre ces résultats analytiques et
numériques fonde la validation de la programmation sur ces cas particuliers [9].
b) Calage des paramètres mécaniques des lois
de comportement en modélisant par éléments
finis les essais de laboratoire (validation du
progiciel, mais aussi validation de la loi de
comportement choisie).
c) Validation du progiciel par comparaison
avec les résultats expérimentaux provenant
d'essais in situ, effectués sur ouvrages réels.
Les jeux de données utilisés et les résultats
obtenus pour a) et b) sont en général répertoriés dans le manuel « Bibliothèque des jeux de
données ». L a méthodologie complète mise en
œuvre pour c) est plutôt décrite dans les fascicules de la « Bibliothèque d'exemples ».
82
Langage et bibliothèque graphique
L'écriture des programmes se fait avec le langage Fortran 77, en excluant toutes les extensions à la norme que pourraient offrir les compilateurs utilisés.
L a bibliothèque graphique utilisée par les préet post-processeurs est G K S . Cette bibliothèque autorise un niveau d'interactivité satisfaisant et permet surtout d'être indépendant des
unités graphiques (écrans, traceurs, imprimantes, etc.) sur lesquelles les programmes vont
dessiner.
Portabilité
L a portabilité ne se décrète pas a priori, mais se
constate lors d'une implantation sur une configuration (machine, système d'exploitation, compilateur, implémentation GKS) que l'on n'avait
pas encore rencontrée. Certains conseils peuvent néanmoins être précieux [10], associés au
strict respect des normes Fortran 77 et G K S .
Malgré ces précautions, certaines instructions
posent des problèmes de portabilité : on peut
citer les instructions relatives à la gestion des
fichiers, l'acquisition de la date, de l'heure, la
mesure du temps de calcul, l'emploi de dispositifs particuliers améliorant les performances
(typiquement, calcul du produit scalaire), les
initialisations de variables dépendant de l'implémentation G K S (exemple : numéros des polices de caractères, des symboles, des pilotes
d'unités graphiques, etc.). Pour pouvoir réaliser
facilement de nouvelles implantations, les instructions dépendant de la machine et du système d'exploitation, de l'implémentation G K S
et des terminaux graphiques ont été regroupés
dans des modules particuliers.
CESAR-LCPC et la qualité
Pour suivre les recommandations de l'Association Française pour le Contrôle Industriel et la
Qualité (AFCIQ), l'évaluation de la qualité
devrait être confiée à une « cellule qualité »,
intervenant, par exemple, sur toute la production informatique du L C P C (voire du réseau)
destinée à être diffusé. Anticipant sur la mise
en place d'un plan qualité logiciel au sein des
L P C , la section Modèles numériques se risque
donc à évaluer un progiciel dont elle est le
principal auteur. Toutefois, et compte tenu des
effectifs que le L C P C peut raisonnablement
mobiliser autour de C E S A R - L C P C , ne perdons
pas de vue que « la qualité est un compromis
entre ce qui est souhaitable et ce qui est possible... » [4].
Aspect qualité
A u cours des paragraphes précédents, le lecteur aura pu identifier certains critères qui
procèdent de la qualité :
— richesse des fonctionnalités (voir [2]) ;
— facilité d'emploi grâce aux pré- et postprocesseurs interactifs graphiques ;
— documentation bien structurée ;
— modularité facilitant le développement, la
portabilité et la maintenance ;
— fiabilité : aspect validation ;
— gestion de différentes versions ;
— portage sur de nombreuses machines en
particulier grâce au langage Fortran ;
— indépendance vis-à-vis des postes de travail
graphiques : G K S ;
— développements pouvant être répartis entre
plusieurs équipes.
L a production d'un logiciel de qualité consiste
également à passer par les phases classiques
de développement. On peut ainsi mettre en
face de chaque phase un document d'orientation ou un manuel du progiciel C E S A R - L C P C :
0 -Expression
des besoins
—» Recherche programmée, sujet de thèses ou fascicule
« Axes de développement »
1 -Spécifications —¥ Compte-rendu de réunion
avec le chef de projet
2 - Conception
—» « Manuel Théorique », et
fascicule « Description du
programme xxx »
3 -Réalisation/
codage
—> Fichiers source
gramme xxx
du
pro-
4 - Validation/
tests
« Bibliothèque des jeux de
données de test »
5 -Exploitation/
maintenance
« Recueil d'incidents »
Aspect non-qualité
L'équipe de développement identifie dans sa
production
actuelle
certains aspects
de
non-qualité :
• Fortran 77 n'est pas un langage garantissant
une programmation de qualité et mettant à
l'abri des effets de bord, des débordements de
tableaux ou des débranchements intempestifs.
Il exige donc une grande vigilance lors de la
phase d'intégration des développements.
• Bien que nous y portions une attention particulière, l'ergonomie des pré- et post-processeurs n'atteint pas celle qu'un utilisateur peut
trouver avec les logiciels industriels de la
micro-informatique ou de la C A O (Conception
Assistée par Ordinateur).
• Certaines redondances sont apparues entre
les programmes 2D et 3D des pré- et postprocesseurs de la version officielle à cause
notamment de leur développement à un
moment donné sur des machines non compatibles (Sintran et Unix) et surtout non
réseautées.
• L a procédure de correction d'erreurs, héritée
des habitudes passées, nécessite beaucoup trop
d'interventions humaines.
• Il n'y a pas de séparation entre équipe de
développement et équipe de diffusion/maintenance.
Amélioration de la qualité
Dans le but d'améliorer la qualité, certaines
modifications ont déjà été apportées à la version actuellement en fin de validation,
comme, par exemple, la création de modules
communs pour supprimer les redondances
apparues dans M A X et P E G G Y . Notre méthodologie des corrections doit également être
repensée, en utilisant par exemple sous Unix
l'outil standard S C C S (Source Code Control
System).
L a forte image de marque « génie civil » de
C E S A R - L C P C vient naturellement des possibilités de modélisation qu'offre le code de calcul
par éléments finis C E S A R (familles d'éléments, modules d'exécution, lois de comportement, etc.) et c'est plutôt ce domaine qui
constitue le « métier » de l'équipe de développement. Néanmoins, nous avons conscience que
C E S A R est de plus en plus utilisé comme une
boîte noire et que c'est sur les pré- et postprocesseurs interactifs graphiques M A X et
P E G G Y que l'ensemble du progiciel est jugé. Il
est ainsi assuré que les utilisateurs seront sensibles à la recherche d'une meilleure ergonomie, ainsi qu'à l'interfaçage avec les produits
standards de la C A O .
C E S A R - L C P C étant utilisé en France par des
non francophones et à l'étranger (Allemagne,
Grèce, Portugal, Brésil, Suède, Canada), nous
réfléchissons à une organisation des programmes permettant le multilinguisme. Pour la
documentation, il semble raisonnable de s'en
tenir à l'anglais.
On pourrait également discuter le choix du langage de programmation puisque celui-ci apparaît à la fois comme critère de qualité et de
non-qualité. Compte tenu du nombre d'instructions déjà rédigées et de l'aspect diffusion sur
un grand nombre de machines, C E S A R - L C P C
est, et restera, écrit en Fortran. Ce point pourra
être réexaminé lorsqu'il deviendra nécessaire
de donner un successeur à C E S A R - L C P C . . .
Mais peut-être y a-t-il beaucoup à attendre du
nouveau langage Fortran 90.
83
Conclusion
Après l'expérience d u système R O S A L I E et de
l a bibliothèque des P P R , nous avions créé
notre propre échelle de v a l e u r s p o u r r a n g e r les
spécifications et les critères de qualité de notre
actuel pôle de c a l c u l . C e t t e n o t i o n de qualité
est m a i n t e n a n t formalisée p a r les t r a v a u x de
l ' A F C I Q et de l ' A F N O R . S i elle d e v i e n t u n e
exigence chez u n n o m b r e croissant d ' u t i l i s a teurs et de d e s t i n a t a i r e s des résultats de
c a l c u l , elle doit s u r t o u t être prise e n compte à
chaque phase de développement. L a qualité
doit s'appliquer a u t a n t a u x logiciels destinés à
être diffusés qu'à ceux s o u m i s à u n e u t i l i s a t i o n
i n t e r n e i n t e n s i v e , et d e v e n i r u n e grille de lect u r e de l a p r o d u c t i o n i n f o r m a t i q u e de c h a c u n .
C E S A R - L C P C a y a n t été c o n s t r u i t s u r des
bases saines, u n e première évaluation de ses
aspects qualité a rassuré l'équipe de développ e m e n t q u i a u r a i t p u v o i r l a qualité comme
u n e nouvelle mode et comme u n e contrainte
r a l e n t i s s a n t et b r i d a n t les développements
f u t u r s . P o u v a n t m a i n t e n a n t nous a p p u y e r s u r
l a réflexion entreprise d a n s le réseau des L P C
depuis les journées d ' i n f o r m a t i q u e de S a i n t B r i e u c [ 1 1 ] , l'aspect qualité doit être c l a i r e m e n t affiché et, e n p a r t i c u l i e r , p r i s e n compte
dans le M a n u e l de p r o g r a m m a t i o n de C E S A R L C P C . N o u s veillerons toutefois à l i m i t e r le
nombre de critères et de spécifications p o u r
éviter t o u t phénomène de rejet de l a p a r t des
développeurs, ce q u i i r a i t à r e n c o n t r e de l a
n o t i o n même de qualité.
REFERENCES BIBLIOGRAPHIQUES
[1]
I B M C o r p o r a t i o n (1980), Terminologie du traitement de l'information,
Publication I B M ,
340 p.
[2]
H U M B E R T P . (1989), C E S A R - L C P C : U n code
de c a l c u l p a r éléments f i n i s , Bull, liaison
Labo.
P. et Ch., 160, m a r s - a v r i l , pp. 112-115.
[3]
01-Référence (1989), Les mots de
l'année,
Périodique 0 1 - I n f o r m a t i q u e , H o r s série n°3.
[4]
N E E L D . (1987), La notion de qualité dans le
cas des logiciels, N o t e C N R S , D i r e c t i o n de l a
Valorisation
et
des A p p l i c a t i o n s
de
la
Recherche.
[5]
[6]
84
[7]
F E Z A N S G . (1983), Présentation
du code
C E S A R : architecture et possibilités actuelles et
futures,
Séminaires R e c h e r c h e d u L C P C .
Exposés - Débats, (vidéo-cassette de l a séance
d u 12 j a n v i e r 1984), S e r v i c e a u d i o v i s u e l d u
LCPC.
[8]
N E E L D . (1987), Recommandations
pour l'assurance et le contrôle qualité des logiciels scientifiques
(Manuel
qualité),
Note
CNRS,
D i r e c t i o n de l a V a l o r i s a t i o n et des A p p l i c a t i o n s
de l a R e c h e r c h e .
[9]
M E S T A T P . (1987), Recueil de solutions
analytiques pour validation
des codes de calcul aux
éléments finis, P u b l i c a t i o n L C P C , S e c t i o n des
F o n d a t i o n s et soutènements ( F A E R 1.05.10.7).
G U E L L E C P . (1976), R O S A L I E : système de
c a l c u l des m a s s i f s et des s t r u c t u r e s . N o t i c e de
présentation et d ' u t i l i s a t i o n e n géomécanique
et e n mécanique des s t r u c t u r e s , P u b l i c a t i o n
L C P C , S e c t i o n Modèles numériques, (épuisé).
[10] F I C H E U X - V A P N E F . et al. (1985), F o r t r a n 77 :
Guide pour l'écriture de programmes
portables,
C o l l e c t i o n D E R - E D F , E d . E y r o l l e s , 150 p.
H U M B E R T P . (1981), Les systèmes de calcul
par éléments finis du LCPC, C o m p t e - r e n d u des
Journées de P h y s i q u e , L e s A r c s .
[11] C H E R V E T G . et al. (1991), Propositions
pour
un Manuel Qualité des applications
informatiques des LPC, doc. d u L R P C de S a i n t - B r i e u c .