ADT MUMPS Campagne ADT 2009
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
ADT MUMPS
Campagne ADT 2009
Récapitulatif de l’ADT
Titre & Acronyme : ADT MUMPS (ADTM)
Porteur de l’ADT : Jean-Yves L’Excellent Email : Jean-Yves.L.Excellent@ens-lyon.fr
CRI : Grenoble Rhône-Alpes EPI : GRAAL
Durée prévisionnelle (4 ans max) : 3 années
S’agit-il d’une ADT déjà en cours ? Non
Les partenaires internes (EPI / CRI) et externes (autres labos, industriels) de l’ADT :
L’ADT est portée par l’EPI Graal (contact :Jean-Yves.L.Excellent@ens-lyon.fr), en collaboration
étroite avec l’équipe APO (Algorithmes Parallèles et Optimisation) de l’INPT-IRIT à Toulouse
(contact : Patrick.Amestoy@enseeiht.fr). Elle se fera aussi en collaboration avec Abdou
Guermouche, maître de conférences à l’Université de Bordeaux, et actuellement membre de l’EPI
ScAlAppliX.
Total des ressources demandées pour l’ADT : 30 kEuros (fonctionnement) + 24 h.m (jeune
diplômé) + 12 h.m (ingénieur qualifié du SED)
Total des ressources demandées pour la 1ère année : 12 kEuros (fonctionnement) + 12 h.m
(jeune diplômé) + 4 h.m (ingénieur qualifié du SED)
Le résumé de la soumission ADT (10 lignes max) : MUMPS est à la fois un outil recherche
et un logiciel reconnu mondialement, original et compétitif, utilisé par de nombreux groupes
académiques et industriels versés dans le domaine de la simulation numérique. Sa robustesse
numérique, sa richesse de fonctionalités et sa souplesse d’interface en font un outil unique.
Avec plus de 1000 téléchargements par an (et une demande toujours croissante), le travail autour
de cette plate-forme logicelle demande une structuration plus professionnelle que celle qui nous
a permis de fonctionner depuis 10 ans. Cette ADT doit ainsi nous permettre de mieux faire face
aux besoins (résultant du succès de sa distribution) de ce logiciel, avec pour principaux objectifs
d’en faciliter : (i) la maintenance ; (ii) l’évolution en lien avec les utilisateurs et les besoins
applicatifs ; (iii) transfert des travaux résultant de nos recherches et (iv) la structuration/gestion
de la documentation.
11 Introduction ADT MUMPS
MUMPS est à la fois un outil recherche et un logiciel reconnu mondialement, original et compétitif,
utilisé par de nombreux groupes académiques et industriels versés dans le domaine de la simulation
numérique. Sa robustesse numérique, sa richesse de fonctionalités et sa souplesse d’interface en
font un outil unique.
Avec plus de 1000 téléchargements par an (et une demande toujours croissante), le travail autour
de cette plate-forme logicelle demande une structuration plus professionnelle que celle qui nous
a permis de fonctionner depuis 10 ans. Cette ADT doit ainsi nous permettre de mieux faire face
aux besoins (résultant du succès de sa distribution) de ce logiciel, avec pour principaux objectifs
d’en faciliter : (i) la maintenance ; (ii) l’évolution en lien avec les utilisateurs et les besoins
applicatifs ; (iii) transfert des travaux résultant de nos recherches et (iv) la structuration/gestion
de la documentation.
2 Contexte : état des lieux et positionnement avant l’ADT
2.1 Aspects scientifiques
Le contexte scientifique est la résolution parallèle de systèmes linéaires creux de grande taille
par des solveurs dits directs. Ces méthodes sont centrales dans les applications de simulation
numérique pour de nombreux domaines. De par leur robustesse et leur efficacité, les méthodes
directes sont souvent préférées, et ce surtout dans le monde industriel, à une autre classe
d’approche, les méthodes itératives. En fait, les approches itératives les plus robustes utilisent en
général des approches directes pour traiter partiellement le problème global. Aujourd’hui, un des
problèmes critiques issu des besoins applicatifs consiste à résoudre des systèmes linéaires de taille
de plus en plus grande, tout en gardant performance et stabilité numérique. Cela nous amène entre
autres à effectuer des recherches sur des approches dites out-of-core (ou hors-mémoire), sur des
prétraitements numériques efficaces en parallèle (les données ne pouvant typiquement pas toujours
être stockées sur un seul processeur), et sur la scalabilité (passage à l’échelle) aussi bien du point
de vue mémoire que du point de vue des performances.
Parmi les nombreuses publications liées à nos travaux sur le sujet, on peut citer par exemple
[2], [5], [1] (voir page 18). Depuis le départ de cette activité en 1996, et au travers de chaque
projet, notre objectif a toujours été de valoriser nos recherches au travers d’un logiciel (MUMPS,
pour MUltifrontal Massively Parallel Solver), qui sert à la fois d’environnement d’expérimentation
pour nos recherches et de valorisation de nos travaux auprès des utilisateurs et notamment des
industriels. MUMPS a débuté avec le projet européen PARASOL (Esprit IV, projet LTR 20160,
1996-1999), dont les résultats et développements logiciels ont été versés dans le domaine public
en fin de projet. Depuis, de nombreux travaux et développements ont été effectués par l’INPT-IRIT,
le CNRS et l’INRIA, tandis que le CERFACS a contribué par le financement de bourses de thèses
de de recherche.
Les principaux projets en lien avec l’objet de l’ADT sont :
– projet européen PARASOL (1996-1999) : la naissance du prototype logicel MUMPS, repartant
2ADT MUMPS
au départ des travaux de thèse de Patrick Amestoy. Ce prototype logiciel du domaine publique
issu du projet PARASOL sert de base à P. Amestoy et J.-Y. L’Excellent pour bâtir et diffuser la
première version publique de MUMPS en Septembre 1999.
– projets France-Berkeley (1999-2000 et 2008-2009) : ces projets avec Xiaoye S. Li,
développeur du logiciel concurrent/complémentaire SuperLU, nous ont permis de comparer nos
approches respectives et de les améliorer, publications communes dans ACM Transactions on
Mathematical Software [3] et dans Parallel Computing [4].
– contrat avec la société belge Samtech (2005-2006) : développement de la première version
de la fonctionnalité "out-of-core" permettant d’accroître la taille des problèmes traités par une
utilisation explicite du disque comme extension de la mémoire.
– contrat avec le CERFACS/CNES (2006) : développement d’une fonctionnalité permettant de
mieux traiter les problèmes couplés, en renvoyant un complément de Schur sous forme 2D
cyclique par blocs.
– collaboration avec le consortium SEISCOPE (2006-2008) : Ce consortium, mis en place par le
laboratoire Geosciences Azur pour des problèmes de géophysique et notamment de sismique,
a fait une utilisation poussée de nos méthodes de résolution et de nombreuses interactions ont
permis d’améliorer les résultats obtenus et les tailles limites des problèmes pouvant être résolus
(voir par exemple []).
– nouveau contrat qui démarre avec la société SAMTECH (2008-2010) : l’objectif est d’étudier
comment de nouvelles fonctionnalités, qui seront versées dans le domaine publique en fin de
contrat, pourront permettre à SAMTECH de : (i) traiter des problèmes plus gros (ii) plus
efficacement en out-of-core (iii) avec une interface permettant de mieux gérer la mémoire
fournie par l’utilisateur
– projet qui démarre avec l’Université de Tel Aviv (2009-2010) : l’objectif est d’utiliser MUMPS
pour paralléliser la résolution de problèmes de dynamique des fluides de grande taille, et
d’orienter les travaux dans MUMPS pour la résolution efficace de ces problèmes, notamment
sur des architectures modernes du type multicoeurs.
– projet GridTLSE (2002-) est un projet connexe, cf http ://gridtlse.org qui sert actuellement à nos
utilisateurs pour le partage et l’échange de problèmes de tests. L’objectif du projet est également
de pouvoir tester divers solveurs et algorithmes à distance et de fournir un site d’expertise à
base de scénarios d’expertise où un utilisateur pourra par exemple expérimenter l’union de
tous les prétraitements disponibles sur un ensemble de solveurs et comprendre comment ces
prétraitements se comportent dans d’autres solveurs sur ses classes de problèmes.
– ODL INRIA sur MUMPS (2005-2007) : une jeune ingénieur (Aurélia Fèvre) a travaillé deux
ans avec nous. Elle a organisé le premier MUMPS Users’ Day (24 novembre 2006, succès aussi
bien pour les développeurs que les utilisateurs). Elle a également participé au développement
d’une interface Scilab à MUMPS [6] et a entre autres complété les tests de non régression, en
association avec l’utilisation d’outils de couverture de code. Elle avait mis au point des scripts
Scilab pour tester la performance séquentielle des versions successives de MUMPS, mais nous
n’avons pas réussi à maintenir ces scripts après son départ.
– projet ANR Solstice (ANR-06-CIS6-010, 2007-2010), Solstice pour SOLveurs et SimulaTIon
en Calcul Extrême. L’objectif de ce projet et de concevoir et développer des solveurs
3ADT MUMPS
linéaires parallèles efficaces sur des problèmes de très grandes dimensions. Ce projet concerne
le LaBRI/INRIA Bordeaux Sud-Ouest (coordinateur), le CERFACS, l’INPT-IRIT, le CEA-
CESTA, EADS-Innovative Works, EDF R&D et le CNRM (Météo). Les participants à cette
ADT sont particulièrement impliqués dans les tâches qui concernent la factorisation et la
résolution out-of-core, la parallélisation de la phase d’analyse, et la détection du rang, les
travaux réalisés étant injectés en ce qui nous concerne dans le logiciel MUMPS pour être ensuite
expérimentés par les partenaires industriels.
Par rapport à la concurrence, l’originalité de l’approche est de ne pas avoir du tout sacrifié
les aspects numériques pour des raisons de performances ou de parallélisation sur calculateurs
à mémoire distribuée. De plus nous sommes les seuls à avoir un ensemble de fonctionnalités
aussi étendu, qui résulte de l’intégration aussi systématique et cohérente que possible de nos
travaux dans une seule et même plate-forme logicielle. Même en séquentiel, il n’y a pas à notre
connaissance d’autres code disponible publiquement comme MUMPS qui ait la même gamme
d’options permettant de traiter des problèmes symétriques indéfinis.
Les travaux de recherche envisagés pour le futur (qui ne sont pas purement l’objet de cette ADT
mais seront effectués en parallèle) concernent : (i) la scalabilité mémoire sur architectures à grands
nombres de processeurs (Blue Gene par exemple), (ii) l’étude et la parallélisation pour architectures
mixtes distribué/multicoeurs, (iii) la parallélisation de certains prétraitements numériques, comme
par exemple les algorithmes dits de maximum weighted matching, (iv) le traitement efficace
(temps, qualité numérique, mémoire) de problèmes les plus gros possibles.
2.2 Aspects technologiques
L’objet de l’ADT est le logiciel MUMPS (cf http ://graal.ens-lyon.fr/MUMPS ou
http ://mumps.enseeiht.fr). MUMPS est un solveur parallèle pour la résolution de systèmes
linéaires creux de grande taille. MUMPS (pour MUltifrontal Massively Parallel Solver) implante
une méthode directe, la méthode multifrontale. C’est un code parallèle unique par les performances
obtenues et le spectre de fonctionnalités disponibles, parmi lesquelles on peut citer :
– différents types de systèmes : symétriques définis positifs, symétriques généraux (indéfinis) ou
non symétriques,
– différents formats d’entrées : matrices assemblées ou exprimés comme une somme de matrices
élémentaires provenant typiquement de problèmes d’éléments finis, matrices centralisées sur un
processeur ou distribuées sur les processeurs,
– différentes précisions arithmétiques pour les données et le calcul (simple ou double précision,
réel ou complexe),
– détection des pivots nuls et estimation d’une base du noyau,
– prétraitements et mises à l’échelle (parallélisation récente de certains prétraitements),
– factorisation partielle et calcul d’un complément de Schur,
– seconds membres denses ou creux, solution centralisée ou distribuée,
– pivotage partiel avec seuil,
– approche asynchrone avec recouvrement des calculs et des communications,
– ordonnancement dynamique et distribué des tâches de calcul pour permettre un bon équilibrage
de charge en présence de pivotage numérique imprédictible ou pour les environnements multi-
4ADT MUMPS
utilisateurs,
– stockage sur disque des facteurs quand la mémoire disponible n’est pas suffisante.
Sur les aspects purement technologiques, MUMPS est un code d’assez grande taille (plus de 200
000 lignes) écrit en Fortran 95 (avec un style à la Fortran 77 pour les noyaux de calcul bas niveaux)
et en C. Le parallélisme est effectué grâce à la librairie de transfert de messages MPI (Message
Passing Interface), même si certains utilisateurs ont commencé à tester l’insertion de directives
OpenMP dans leur version du code. Un seul code est maintenu et nous générons automatiquement
les diverses précisions (single, double, single complex, double complex). MUMPS s’appuie sur les
bibliothèques publiques BLAS et Scalapack.
Un module de communications permet d’effectuer les communications asynchrones et de gérer
un buffer de communications cyclique dans l’espace utilisateur. Lorsque le buffer est plein, il faut
être capable de passer en mode réception et gérer l’arrivée de messages et de nouvelles tâches afin
d’éviter tout risque de deadlock.
Les couches bas-niveaux pour les entrées-sorties sont écrites en C, et nous utilisons les threads
POSIX (sur les architectures où ceux-ci sont disponibles) pour gérer l’asynchonisme entre les
calculs et les requêtes d’entrées-sorties. Les portages pour machines de type Microsoft Windows R
et le maintien de fichiers Visual Studio R sont actuellement effectués par des utilisateurs.
Le fonctionnement correct du logiciel est contrôlé par des tests de non-régression qui tournent
toutes les nuits, actuellement sur deux machines différentes (avec deux compilateurs différents),
l’une à Lyon, l’autre à Toulouse. Une étude de couverture de code est effectuée de temps en temps
(manuellement).
Les développements sont effectués de manière collaborative grâce au gestionnaire de version SVN.
L’intégration des développements recherche est normalement gérée à l’aide de directives du pre-
compilateur (e.g., #ifdef) ou, pour les développements les plus en amont, au moyen de la création
de branches dans le système SVN.
2.3 Public visé, diffusion, transfert, innovation
MUMPS est utilisé par quelques milliers utilisateurs (rythme actuel mille téléchargements par an)
académiques ou industriels (environ moitié/moitié), dans des domaines d’applications très variés.
MUMPS est par ailleurs utilisé et directement distribué dans des codes de calcul (FEMTown de
FFT, SAMCEF de SAMTECH, Code ASTER d’EDF, PETSC, IPOPT). Parmi les utilisateurs
industriels on peut citer par exemple BOEING, le CEA, EADS, EDF, ESI-Group, Free Field
Technologies, RTE ou SAMTECH. Les utilisateurs qui demandent à apparaître sur la page
applications de MUMPS sont visibles sur http ://graal.ens-lyon.fr/MUMPS/index.php ?page=apps
Compte tenu de l’historique compliqué de MUMPS (nombreux partenaires, code qui a commencé
en 1996 sans l’INRIA et à partir de travaux existants), nous nous sommes appuyés sur la librairie
domaine publique disponible en fin de projet PARASOL pour pouvoir continuer à travailler sur ce
logiciel, et la solution qui a été retenue jusqu’à maintenant a continué dans le même esprit, dans le
sens où chaque nouvelle version de MUMPS diffusée aux utilisateurs est domaine publique. Ainsi
pour chaque contrat (contrats industriels, contrat ANR), les clauses liées à la propriété intellectuelle
indiquent que les développements résultant du contrat sont reversées dans une version domaine
publique du logiciel MUMPS à la fin du contrat. Cette solution a pour l’instant donné satisfaction,
5ADT MUMPS
sachant que c’est plus la capacité à faire évoluer le logiciel qui est une richesse que le logiciel
lui-même.
Une des originalités par rapport à la concurrence est le support et les discussions
avec les utilisateurs, notamment via la liste mumps-users, (cf https ://listes.ens-
lyon.fr/sympa/subscribe/mumps-users pour les archives) et l’alias des développeurs mumps-dev.
Le contact étroit que nous avons avec beaucoup d’utilisateurs nous satisfait car il nous permet de
rester proches des applications et d’orienter nos travaux de recherche en fonction de ces besoins.
Les utilisateurs sont satisfaits aussi qu’on prenne le temps de comprendre leurs problèmes et de
répondre à leurs questions. En revanche nous commençons à être victimes du succès de MUMPS
et à ne plus pouvoir effectuer ce travail de manière satisfaisante.
3 Objectifs de l’ADT
Le succès de nos travaux et du logiciel MUMPS est incontesté ; le dernier rapport d’évaluation
de GRAAL en 2008 mentionne notamment que "The work on sparse solvers is one of the most
recognized and successful efforts in that area. MUMPS is used by a large number of researchers
in academia and industry." Aujourd’hui, nous sommes en quelque sorte victimes de ce succès et
assurer la maintenance et le support aux utilisateurs du logiciel est de plus en plus difficile. Insérer
de nouvelles fonctionnalités également. De plus, la dimension du groupe a changé (arrivée de deux
chargés de recherche CNRS, Bora Uçar à Lyon et Alfredo Buttari à Toulouse).
La difficulté est donc de passer à l’échelle, cela nécessite de passer d’une phase qu’on pourrait
qualifier de structurée mais artisanale à une phase plus professionnelle d’industrialisation d’un
outil recherche. Cela concerne non seulement la qualité du code et de sa documentation, mais
aussi la qualité de la documentation utilisateurs avec plusieurs niveaux de documentation selon
les utilisateurs. Le suivi des performances et des outils simples pour ajouter des cas d’utilisation
provenant des utilisateurs dans nos séries de tests (non régression, performances) est aussi critique.
Un bilan de performance par rapport aux outils concurrents doit être refait et partiellement
automatisé.
Tout cela doit rester suffisamment simple et documenté pour être utilisé sans formation préalable
par des personnels qui rejoignent le projet pour des durées souvent courtes (stagiaires, postdocs,...)
et évolutif car le logiciel est nourri par une recherche active.
4 La sortie de l’ADT : positionnement après l’ADT
L’objectif principal, en plus des développements ponctuels en cours, est d’avoir un objet en fin
d’ADT qui soit plus robuste, plus structuré et qui soit évolutif de manière simple :
– aussi bien au niveau du code et de ses fonctionnalités,
– que pour l’ajout de cas tests (performance, non régression), provenant éventuellement
d’utilisateurs : rapports de bugs ou de mauvaises performances
– que pour avoir une documentation orientée support, où ajouter des informations ou des
illustrations algorithmiques liées à des discussions avec les utilisateurs soit simple et
6ADT MUMPS
soit structuré sémantiquement pour que d’autres utilisateurs puissent retrouver facilement
l’information qu’ils cherchent.
Le travail d’analyse et de comparaison de performance avec les logiciels concurrents et la capacité
à automatiser même partiellement cette analyse constituera un outil de base fondamental pour la
validation et la valorisation de notre logiciel.
4.1 Aspects scientifiques
Deux thèses viennent de se terminer. Nous sommes en phase de recrutement d’un postdoc à Lyon,
et une thèse devrait commencer à la rentrée prochaine à Toulouse. A la fin de l’ADT, les travaux
de recherche récemment intégrés ou en cours et les travaux liés aux contrats industriels seront
validés. Cela permettra de traiter des problèmes de très grande taille efficacement et de garder
notre position vis à vis de la concurrence. Cela permettra aussi de poursuivre des objectifs de
recherche sur de vrais problèmes industriels de plus en plus difficiles et de grande taille, avec une
plate-forme logicielle robuste et stable permettant plus facilement d’expérimenter de nouvelles
idées recherche.
Le bilan de l’étude et la comparaison avec les autres logiciels du domaine doit nous permettre
de bâtir une jeu de problèmes critiques et représentatifs (utile pour la validation), d’identifier des
verrous logiciels ou algorithmiques critiques à lever, d’orienter nos recherches futurs. Par ailleurs
nous espérons que cette étude pourra être la base d’un travail de documentation expliquant et
analysant les comportements des outils en fonction de problèmes. Ce travail pourra être l’objet,
comme cela avait été le cas avec Sherry Li (auteur de SuperLU du projet Sclalapack, concurrent
USA) du Lawrence Berkeley Nat. Lab. en 2000, d’une collaboration étroite avec les auteurs
d’autres outils.
En fin d’ADT nous serons également plus réactifs aux besoins scientifiques des utilisateurs
(support, reproduction de comportements type des utilisateurs), grâce à une meilleure structuration
de notre travail et de meilleurs outils d’analyse et de diagnostic de notre logiciel.
4.2 Aspects technologiques
Nous espérons grâce au résultat de l’ADT être capable de réduire les délais entre la production
d’un produit de la recherche et sa mise à disposition des utilisateurs. Une plus grande efficacité
globale dans la gestion de la vie de la plate-forme logicielle doit nous permettre de mieux nous
consacrer à l’enrichissement du logiciel et au support algorithmique vis à vis des utilisateurs.
L’automatisation d’un bilan de comparaison de performance avec les autres outils doit aussi
permettre outre la valorisation et la validation de suivre les évolutions (recherche et technologique)
des autres outils. Pour un logiciel comme MUMPS ayant un spectre d’application aussi large il
est important aussi de suivre pour chaque classe d’application les évolutions des logiciels plus
spécifiques.
7ADT MUMPS
4.3 Aspects diffusion, transfert, innovation
Nous souhaitons garder notre base d’utilisateurs et satisfaire les nouveaux besoins applicatifs
associés au mieux. Accroître la base d’utilisateurs devrait se faire naturellement. Le nombre moyen
de téléchargement par jour a doublé l’an dernier. Nous avons engagé des discussions pour la
signature d’autres projets de recherche et d’autres contrats de recherche directement avec des
industriels et pensons les concrétiser d’ici la fin de l’ADT.
Les éléments sur la propriété intellectuelle, le mode de diffusion et la licence sont discutés dans
la section 2.3. Nous pourrions étudier en collaboration avec les services des relations industrielles
et les services juridiques de l’INRIA, de l’INPT-IRIT/CNRS, et du CERFACS l’opportunité/les
difficultés/les implications de passer à une licence de type LGPL ou Cecill-C.
4.4 Mode de gestion envisagé pour l’objet de l’ADT après le terme
L’INRIA, le CNRS et l’INPT-IRIT continueront à se charger du support et de la maintenance
logicielle de l’objet de l’ADT. Les chercheurs et enseignants-chercheurs impliquées sont Patrick
Amestoy, Alfredo Buttari, Abdou Guermouche, Jean-Yves L’Excellent et Bora Uçar. Le fait
d’avoir un ingénieur permanent du SED qui participerait à cette ADT peut permettre d’aider
ponctuellement aux travaux de support/maintenance sur les aspects qui font spécifiquement l’objet
de cette ADT.
5 Mise en oeuvre prévisionnelle de l’ADT
5.1 Identification des rôles et organisation de l’ADT
Responsable de l’ADT : Jean-Yves L’Excellent
Responsables techniques : Patrick Amestoy et Abdou Guermouche
Responsables du contact utilisateurs et de la valorisation : Alfredo Buttari et Bora Uçar
Nous prévoyons au minimum une réunion mensuelle impliquant au moins une personne par
institution à chaque fois. Des réunions techniques plus fréquentes pourront avoir lieu. Les
déplacements pour réunions administratives régulières à Grenoble ou à Lyon peuvent être
l’occasion de discussions plus informelles avec le SED.
De manière générale, les chercheurs en enseignants-chercheurs permanents encadreront le travail
et exprimerons leurs besoins pour permettre d’effectuer les spécifications de chacune des tâches.
En plus des tâches qui lui sont affectées (voir Section 5.2), l’ingénieur qualifié du SED suivra le
travail du jeune diplomé et apportera son point de vue sur les aspects génie logiciel et méthodes de
travail.
Les risques de nature organisationnelle sont liés à la distance (Equipe Graal à Lyon, INPT-IRIT à
Toulouse, ingénieur qualifié du SeD à Grenoble, Abdou Guermouche à Bordeaux). C’est pourquoi
nous souhaitons avoir un planning de réunion régulière. L’ADT constituant un projet important
pour le groupe MUMPS il aura aussi un effet structurant et de ce point de vue il sera motivant
pour ajouter de la cohésion malgré la distance (avec laquelle nous avons vécu depuis la fin du
8ADT MUMPS
projet européen PARASOL en 1999). Un autre risque est la promotion, auquel cas chercheurs et
enseignants-chercheurs concernés pourraient avoir moins de temps à consacrer à l’activité. De ce
point de vue, le résultat de l’ADT devrait nous permettre de mieux faire face à ce risque par la
suite.
5.2 Planification prévisionnelle
Les différentes tâches du projet sont décrites ci-dessous et le calendrier prévisionnel est
résumé Figure 1. Pour certaines tâches où les choix de conception sont importants, les
spécifications et une première maquette seront effectués par l’ingénieur qualifié, tandis que les
développements plus simples seront effectués en priorité par l’ingénieur jeune diplômé. Dans tous
les cas, l’ingénieur qualifié participera au suivi et à la supervision du travail de l’ingénieur débutant.
Les phases de conception dépendront des besoins / du cahier des charges sont à définir en
collaboration avec les chercheurs et enseignants-chercheurs impliqués. Ceux-ci sont directement
impliqués dans l’objet de l’ADT qui est directement liée à leur activité de recherche principale et
aux contrats en cours. Les volumes mentionnés ci-dessous sont des hommes x mois d’ingénieur.
Nous fournissons également les dates de début, dates de fin et jalons prévisionnels.
Tâche 1 — Outils d’expérimentation et de validation :
Ingénieur qualifié pour superviser la conception et les premiers développements (notamment pour
la sous-tâche 1.2), la suite du travail pouvant être effectué par l’ingénieur jeune diplômé.
Date début : T0
Date Fin : T0+12
Volume : 4 hommes x mois
Jalon T0 + 6 : fin de la tâche 1.1, spécification de la tâche 1.2
Jalon T0 + 12 : tâche 1 terminée
Cette tâche consistera à :
1.1 Rendre le driver d’utilisation avancé de MUMPS (actuellement nommé testhb) plus simple,
modulaire et évolutif. Intégrer le driver pour matrices distribuées en entrée (actuellement
nommé test_distMM) dans le même driver global.
1.2 Rendre le code permettant d’effectuer les tests de non régression (test_mumps) plus simple,
modulaire et évolutif.
1.3 Fournir la capacité à tous les contributeurs d’ajouter de nouveaux problèmes de test provenant
de nos utilisateurs avec un fichier de paramètre simple (documentation de la tâche 1.1) pour
reproduire les cas d’exécution des utilisateurs. En fonction de la difficulté à l’implanter de
manière suffisamment générale en fonction des différentes phases de calcul de MUMPS,
ajout éventuel d’une fonctionnalité à MUMPS pour "dumper" les paramètres utilisateur dans
un fichier lors de l’exécution par un utilisateur. Ce fichier pourrait avoir le même format que
le fichier d’entrée de nos drivers de tests pour être inclus tels quels dans les bases de tests.
9!"##$% ADT MUMPS
!""#$%& !""#$&' & !""#$&(
)* )*+, )*+%' )*+%- )*+'. )*+(*
)/01$&% *"+
)/01$&' *"+ ,"+
)/01$&( ,"+
)/01$&. ,"+
)/01$&2 -"+
)/01$&, *"+ ,"+
)/01$&3 %"+
)4% %"+ %"+ %"+
)4' %"+ ."+ ,"+
)5)!6 %-"+ %-"+ *"+
F IG . 1 – Planing prévisionnel.
Tâche 2 — Software engineering :
Ingénieur jeune diplômé. L’ingénieur qualifié pourra compléter la définition du travail à effectuer.
Date début : T0
Date fin : T0+16
Volume : 6 hommes x mois
Jalon T0 + 16 : tâche 2 terminée,
les CODING_RULES sont adoptées par tous les développeurs et appliquées
La plupart des sous-tâches ci-dessous pourront commencer dès le début de l’ADT. La tâche 2.7
dépend de la tâche 1.2 et elle est à la limite d’une tâche de fond. Elle nécessite une familiarisation
avec le code et un rôle actif dans les discussions à mener avec les développeurs. La tâche 2.8
également.
Les sous-tâches proposées sont :
2.1 L’utilisation (et la définition préalable) d’un ensemble d’options de compilation pour un
ensemble de compilateurs et de machines correspondant aux tests journaliers. Associé au
nettoyage de tous les warnings correspondants aux options de compilation choisies, l’objectif
est toujours d’améliorer la qualité du code. Cet ensemble d’options servira aussi pour la tâche
3 (tests systématiques de compilation)
2.2 un codage et un traitement systématique et uniformisé des erreurs, avec en plus des
informations actuelle la remontée du nom de la routine où l’erreur s’est produite
2.3 l’amélioration de la portabilité sur différentes plates-formes, le cas échéant
2.4 la suppression/simplification des directives pre-compilateur inutiles ou trop obscures, en
collaboration avec les développeurs,
2.5 un nettoyage systématique des variables déclarées mais non utilisées,
10ADT MUMPS
2.6 la prise en compte et l’évolution éventuelle des conventions et règles de codage (fichier
CODING_RULES du SVN), puis le suivi du bon respect des règles de codage par tous
les développeurs,
2.7 l’amélioration de la couverture de code et l’identification du code mort, en relation avec
l’extension des tests de non régression (tâche 1) : tests externes (ou “boite noire”) + tests de
fonctionnalités plus internes, non contrôlables directement par l’utilisateur (“boite blanche”)
2.8 l’amélioration des méthodes de documentation interne du code.
Tâche 3 — Tests automatisés de machines et chaînes logicielles :
Ingénieur qualifié
Date début : T0+6
Date fin : T0+12 mois
Volume : 2 hommes x mois
Jalon T0 +12 : tâche 3 terminée,
des tests nocturnes tournent régulièrement sur un ensemble de machines,
l’ajout d’une machine de test quelconque est simple à réaliser.
Cette tâche consistera d’abord à enrichir les scripts existants (test_script.sh) pour pouvoir
tester de nouveaux compilateurs/configurations/machines. Cela pourra inclure en plus des
machines actuelles (un serveur à Lyon, un autre à Toulouse) les machines de la plate-forme de
portage pipol de l’INRIA, en particulier pour ce qui est des architectures MAC OS et Microsoft
Windows. Il faut prévoir de pouvoir utiliser facilement aussi des machines de production voire un
peu plus exotiques : machines parallèles (IBM, NEC, SGI, . . .) de l’IDRIS, du CCRT, du CINES.
Les tests sur ces machines pourraient être systématiques avant une release, occasionnels sinon.
Pour une machine donnée, on peut aussi prévoir d’utiliser différents compilateurs et différentes
version de MPI (MPICH, LAM, OpenMPI).
On souhaiterait ne pas être dépendants d’outils trop spécifiques (idéal=ssh, shell scripts) pour
pouvoir inclure une nouvelle machine (éventuellement parallèle) aussi simplement que possible.
Tâche 4 — Mécanisme de suivi de performances :
Ingénieur jeune diplômé, supervision par l’ingénieur du SED
Date début : T0+12
Date fin : T0 + 18 mois
Volume : 2 hommes x mois
Jalon T0+18 : tâche 4 terminée,
le mécanisme existe et toute l’équipe est capable de l’utiliser et de l’enrichir.
L’objectif de cette tâche est la mise en place et documentation d’un mécanisme (aussi léger que
possible) de suivi des performances. La capacité à ajouter facilement de nouveaux cas tests à nos
11ADT MUMPS
drivers (tâche 1) sera pour cela utilisée. Les matrices liées aux cas tests pourraient être déposées
sur le site GRID-TLSE, projet connexe à MUMPS, avec accès aux matrices depuis différentes
machines par "wget" et cache local éventuel.
Pour chaque cas, un fichier doit décrire le scénario d’utilisation (valeurs des paramètres de
contrôle, matrice de test, machine, nombre de procs, etc + une section de taille illimitéé avec
des commentaires décrivant l’origine du cas test et son historique).
Le driver de la tâche 1.1 doit être pensé pour permettre de tourner le cas test avec en entrée un
fichier et de garder les sorties, les temps des phases principales (analyse, factorisation, résolution)
et quelques statistiques critiques comme l’utilisation mémoire à chacune des phases du calcul.
Exemple type : un utilisateur nous fournit un nouveau cas test sur lequel la performance est
mauvaise ou surprenante. On crée un nouveau fichier qui correspond à ce scénario. On identifie le
problème de performance et on apporte des modifications au code pour améliorer les performances.
On vérifie ensuite de release en release que les performances restent satisfaisantes sur cette classe
de problèmes.
Tâche 5 — Comparaison avec d’autres solveurs directs :
Ingénieur jeune diplômé
Date début : T0+12
Date fin : T0+24 mois
Volume : 6 hommes x mois
Jalon T0+24 : tâche 5 terminée,
rapport technique avec génération automatisée des tableaux de résultats
L’objectif de cette tâche est d’effectuer un bilan de performances et une comparaison avec
d’autres logiciels publiques, notamment sur des machines parallèles d’architecture récente. Il
s’agit d’un besoin identifié par des partenaires industriels qui n’ont accès qu’à de vieux articles
de comparaison.
5.1 Définir l’environnement de test :
– Déterminer un jeu significatif de problèmes de test permettant d’illustrer les propriétés
algorithmiques des différents outils.
– Déterminer un jeu de machines de test.
– Déterminer un jeu de métriques et organiser la récupération de ces statistiques communes
(parfois certaines métriques comme la mémoire utilisée ne sont pas fournies par un solveur
et il faudra les recalculer).
5.2 Production et analyse de résultats :
Il faudra définir des modes d’utilisation des outils, par exemple :
– Défaut : on lance chaque outil avec ses paramètres par défaut.
– Intermédiaire : on lisse les comportements avec des réglages par classe d’application
– Best effort : on règle par problème chaque outil logiciel.
5.3 Automatisation partielle L’objectif est de :
12ADT MUMPS
– contrôler la génération automatique de résultats avec contrôle du choix des outils, des
problèmes et des métriques,
– de garantir la capacité à intégrer de nouvelles releases.
Cette tâche est liée à d’autres tâches, en particulier la tâche 1. A noter qu’elle permettra aussi,
en collaboration avec les développeurs historiques, le réglage des tailles de blocage des calculs
locaux et de différents paramètres par défaut qui agissent directement sur la performance de nos
algorithmes. (Certains n’ont pas été modifiés depuis des années alors que les machines, tailles de
caches, etc... ont évolué. Cas du NEC pour lequel la performance a pu être augmentée de façon
significative en modifiant le paramètre dit d’amalgamation du graphe des tâches).
Tâche 6 — Documentation utilisateur et aide au support
Ingénieur qualifié
Date début :
T0+6
Date fin :
T0 + 24
Volume :
4 hommes x mois
Jalon T0 + 12 :
fin des spécifications et première maquette,
à cette date toute l’équipe doit être capable de compléter et faire évoluer la documentation,
Jalon T0 + 18 : fourniture de la nouvelle documentation en beta test à quelques utilisateurs,
Jalon T0 + 20 : mise en production.
L’objectif de cette tâche est de moderniser la documentation existante avec un objectif “support”. Il
existe une FAQ et une documentation utilisateurs mais cela ne répond actuellement pas totalement
à nos besoins.
On envisage une documentation plus dynamique avec des hyperliens et des niveaux de description
qui dépendraient du niveau de l’utilisateur et du contexte d’utilisation du logiciel. En particulier,
la compatibilité des paramètres pour les utilisateurs est difficile à comprendre, certains paramètres
répondent à des besoins particuliers, certains réglages font appel à la connaissance algorithmiques
qui sont internes aux solveurs, on a parfois des discussions qui se ressemblent dans le travail
de support aux utilisateurs et on aimerait un endroit où on dépose et retrouve facilement ces
informations.
Améliorer la documentation demande avant tout un travail de conception significatif, qui devra
aboutir à une première maquette à T0 + 12 mois. La documentation sera alors nourrie par l’équipe
MUMPS pour aboutir à une version diffusable aux utilisateurs (distribution de MUMPS, site web)
en fin de tâche (version beta à T0 + 18, en production à T0 + 20). Jusqu’à T0 + 24 il s’agira surtout
d’améliorer et de maintenir l’existant.
Il faut que le schéma soit suffisament simple et évolutif pour pouvoir y injecter de nouvelles
informations et les retrouver facilement.
Tâche 7 — Stabilisation et maintenance du travail du jeune ingénieur
Ingénieur expérimenté
13ADT MUMPS
Date début : T0+24
Date fin : T0+36
Volume : 1 homme x mois
Il s’agit de stabiliser si nécessaire et d’effectuer la maintenance du travail du jeune diplômé après
son départ à T0 + 24, afin de pérenniser le travail effectué dans les tâches 1 à 6 et assurer la
réutilisation de tous ses travaux par l’équipe.
On peut penser que cette tâche n’a idéalement pas lieu d’être, il est pour autant important de borner
les développements et de stabiliser un produit finalisé.
Tâche de fond 1 — Participation et suivi du support aux utilisateurs
Ingénieur jeune diplômé et/puis ingénieur qualifié
Date début : T0+6
Volume : 3 hommes x mois
Cette tâche commencera à T0 + 6, une fois les ingénieurs suffisamment “dans le bain”. Il s’agit de
participer au contact avec les utilisateurs, et d’en assurer le suivi.
– Lorsque le problème est intéressant d’un point de vue performances, insertion dans la base des
problèmes à tester pour le suivi des performances (Tâche 4).
– Lorsque le problème est intéressant parce qu’il révèle un bug ou un problème algorithmique
dans un morceau du code passe peu d’habitude, insertion dans la base des problèmes à tester
pour la non régression.
– Lorsque la réponse à une question utilisateur est intéressante, insertion de la réponse et/ou
explication algorithmique et/ou illustration des effets d’un paramètre de contrôle dans le schéma
de documentation mis en place au niveau de la tâche 6.
Tâche de Fond 2 — Aide à la validation des nouvelles fonctionnalités
Ingénieur jeune diplômé et/puis ingénieur qualifié
Date début : T0+6
Volume : 6 hommes x mois
L’objectif de cette tâche est de participer aux travaux en cours :
– Aide à la validation et à la stabilisation des fonctionnalités récentes (gestion d’entiers 64 bits,
out-of-core, analyse parallèle). Aide à la validation et à la stabilisation des fonctionnalités
nouvelles développées dans le cadre des projets et contrats existants (SAMTECH, Solstice, ESI
Group si qqchose démarre, etc.). Participation à l’enrichissement des tests de non régression
pour chaque nouvelle fonctionnalité développée.
– Le cas échéant, conception et développement d’une fonctionnalité simple d’ampleur limitée
faisant réponse à un besoin identifié par un utilisateur.
14ADT MUMPS
Risques techniques et plan de levée des risques :
Un des risques est de vouloir être trop ambitieux dans nos attentes. L’élément important à avoir à
l’esprit pendant toute la durée de l’ADT (plan de levée de risques) est de garantir que dans chaque
tâche, on aura amélioré l’existant et surtout qu’on aura amélioré la capacité qu’aura chacun de
nous à l’utiliser et l’enrichir, garantissant ainsi son évolutivité.
Il faut pour cela que chacun puisse intégrer les nouveaux travaux et développements (et tests
associés le cas échéant) de manière simple et efficace, si possible sans dépendre d’outils ou de
procédures trop spécifiques, trop nouveaux ou demandant trop d’apprentissage.
6 Ressources
6.1 Bilan des ressources demandées
6.1.1 Ressources mises à disposition par la (les) EPI(s) dans l’ADT
Chercheurs et enseignants-chercheurs (à temps partiel) :
– Patrick Amestoy (professeur, INPT-IRIT, Toulouse),
– Alfredo Buttari (chercheur CNRS, INPT-IRIT, Toulouse),
– Abdou Guermouche (mcf, LaBRI, EPI ScAlAppliX, Bordeaux),
– Jean-Yves L’Excellent (chercheur INRIA, LIP, EPI Graal, Lyon),
– Bora Uçar (chercheur CNRS, LIP, EPI Graal, Lyon)
En CDD :
– Nouveau postdoctorant XXX à recruter à Lyon, dans le cadre du projet SOLSTICE.
– Stagiaire en master François-Henry Rouet à l’INPT-IRIT, Toulouse, poursuite probable en thèse.
Même si tout est lié, le personnel de type postdoctorant ou doctorant est destiné à travailler sur
des aspects recherche plus "amont" plutôt que sur les aspects purement logiciels et technologiques
décrits dans cette ADT.
6.1.2 Ressources demandées
Sur poste :
Un ingénieur avec des compétences en calcul numérique du SED (Service Expérimentation et
Développement), du Centre de Rercherche Grenoble Rhône-Alpes, à 30 % sur le projet pendant la
durée de l’ADT (3 ans).
En CDD :
Un ingénieur jeune diplômé sur 2 ans.
15ADT MUMPS
Aspect formateur et analyse des débouchés pour l’ingénieur jeune diplômé :
L’ingénieur jeune diplômé s’intégrera dans une équipe dynamique et se formera sur les techniques
de développement et de validation de logiciel scientifique de grande taille, sur des calculateurs
variés. Il sera amené à travailler en collaboration avec des parternaires aussi bien industriels
qu’universitaires. Compte tenu du nombre important d’utilisateurs industriels (dont des sociétés
comme Boeing, EADS, Samtech, ...) du logiciel MUMPS, cette expérience peut constituer un
tremplin idéal pour que l’ingénieur rejoigne une équipe R&D industrielle ou une PME impliquée
dans le calcul scientifique, grâce à la compétence acquise sur des logiciels numériques conséquents
et sur le calcul parallèle sur réseaux de machines. L’ingénieur pourrait aussi faire valoir son
expérience pour s’intégrer dans une équipe de maintenance et/ou support de logiciel dans un centre
de calcul.
6.2 Aspects budgétaires autres que ressources humaines
6.2.1 Budget ADT dans les EPIs
Les équipes financent des travaux de recherche et des travaux amont au travers de projets de
recherche ou de contrats. Par exemple un nouveau postdoc doit arriver dans le cadre de l’ANR
Solstice, les contrats industriels nous fournissent également du fonctionnement qui est utilisé en
lien avec ces projets ou avec notre activité en général et la valorisation de nos recherches.
Les financements additionnels demandés sont spécifiques aux tâches identifiés dans l’ADT.
6.2.2 Budget additionnel demandé
Le budget additionnel demandé consiste à financer les travaux additionnels liés à l’ADT :
– 2 kEuros = une machine de travail pour l’ingénieur débutant qui sera recruté,
– 30 kEuros = 10 kEuros par an de fonctionnement pour couvrir :
– les réunions entre participants de l’ADT (pour tous les sites) et déplacements ponctuels en
lien direct avec l’objet de l’ADT,
– éventuellement une licence pour un ou deux logiciels utiles pour l’ADT (compilateur Intel...),
si les licences déjà disponibles via le service expérimentation et développement de l’INRIA
ne suffisaient pas.
7 Suivi et évaluation
Nous rappelons les jalons prévisionnels ci-dessous, tâche par tâche :
Tâche 1 — Outils d’expérimentation et de validation :
Jalon T0 + 6 : fin de la tâche 1.1, spécification de la tâche 1.2
Jalon T0 + 12 : tâche 1 terminée
Tâche 2 — Software engineering :
Jalon T0 + 16 : tâche 2 terminée,
16ADT MUMPS
les CODING_RULES sont adoptées par tous les développeurs et appliquées
Tâche 3 — Tests automatisés de machines et chaînes logicielles :
Jalon T0 +12 : tâche 3 terminée,
des tests nocturnes tournent régulièrement sur un ensemble de machines,
l’ajout d’une machine de test quelconque est simple à réaliser.
Tâche 4 — Mécanisme de suivi de performances :
Jalon T0+18 : tâche 4 terminée,
le mécanisme existe et toute l’équipe est capable de l’utiliser et de l’enrichir.
Tâche 5 — Comparaison avec d’autres solveurs directs :
Jalon T0+24 : tâche 5 terminée,
rapport technique avec génération automatisée des tableaux de résultats
Tâche 6 — Documentation utilisateur et aide au support
Jalon T0 + 12 : fin des spécifications et première maquette,
à cette date toute l’équipe doit être capable de compléter et faire évoluer la documentation,
Jalon T0 + 18 : fourniture de la nouvelle documentation en beta test à quelques utilisateurs,
Jalon T0 + 20 : mise en production.
Tâche 7 — Stabilisation et maintenance du travail du jeune ingénieur
Outre les jalons dont les dates de réalisation restent prévisionnelles, une mesure du succès sera
la capacité qu’aura chacun des membres de l’équipe de développement (y compris membres non
permanents) à enrichir et à faire évoluer le résultat de chacune des tâches. La capacité des nouveaux
ingénieurs à travailler sur les projets et contrats liés au développement de nouvelles fonctionnalités
dans MUMPS sera aussi un bon indicateur de succès.
Enfin, l’impact de l’objet de l’ADT pourra d’autre part être mesuré au nombre de requêtes
quotidiennes de téléchargement, à l’activité sur la liste de diffusion, et aux nouveaux logiciels
de simulation qui décident de s’appuyer sur le solveur MUMPS.
A Description des partenaires
Pour chaque partenaire sont indiqués les membres permanents impliqués dans l’ADT :
INRIA :
– EPI Graal : Jean-Yves L’Excellent (CR INRIA) et Bora Uçar (CR CNRS), LIP, ENS Lyon
– Ingénieur du SED, Grenoble
– Abdou Guermouche (Université de Bordeaux et membre de l’EPI ScAlAppliX), LaBRI,
Bordeaux
INPT-IRIT, équipe APO, Toulouse :
– Patrick Amestoy (professeur)
17ADT MUMPS
– Alfredo Buttari (CR CNRS)
L’IRIT, créé en 1990, est une Unité Mixte de Recherche (UMR-5505) du Centre National de
la Recherche Scientifique (CNRS), de l’Institut National Polytechnique de Toulouse (INPT),
de l’Université Paul Sabatier (UPS), de l’Université Toulouse1 Sciences Sociales (UT1) et de
l’Université de Toulouse2-le Mirail (UTM). L’équipe Algorithmes Parallèles et Optimisation
(APO) regroupe actuellement 13 chercheurs et enseignants chercheurs permanents, 8 doctorants
et 2 ingénieurs et s’est développée autour des thèmes de l’algèbre linéaire et de l’optimisation.
Son activité concerne quatre grands axes : algèbre linéaire et calcul sur la Grille, contrôle
optimal, optimisation globale et fouille de données. Dans ce contexte, notre activité nous porte
plus particulièrement vers la résolution de problèmes de taille toujours plus grande en nombre
d’opérations (de l’ordre du petaflops soit 101 5 opérations), et nécessitant toujours plus de mémoire
(des dizaines de teraoctets soit 101 3 octets) sur des super-calculateurs (ordinateurs les plus
puissants à un temps donné).
Apports et attentes des différents partenaires :
Chaque partenaire de l’ADT est critique à un bon déroulement de l’ADT soit de par ses
contributions passées à l’objet de l’ADT, soit compte tenu de ses capacités à le faire évoluer.
Un des objectifs en plus du résultat naturel de l’ADT est d’officialiser une collaboration étroite
existant depuis de nombreuses années avec pour objectif à terme une équipe commune.
Références
[1] E. Agullo, A. Guermouche, and J.-Y. L’Excellent. A parallel out-of-core multifrontal method :
Storage of factors on disk and analysis of models for an out-of-core active memory. Parallel
Computing, Special Issue on Parallel Matrix Algorithms, 34(6-8) :296–317, 2008.
[2] P. R. Amestoy, I. S. Duff, J. Koster, and J.-Y. L’Excellent. A fully asynchronous multifrontal
solver using distributed dynamic scheduling. SIAM Journal on Matrix Analysis and
Applications, 23(1) :15–41, 2001.
[3] P. R. Amestoy, I. S. Duff, J.-Y. L’Excellent, and X. S. Li. Analysis and comparison of two
general sparse solvers for distributed memory computers. ACM Transactions on Mathematical
Software, 27(4) :388–421, 2001.
[4] P. R. Amestoy, I. S. Duff, J.-Y. L’Excellent, and X. S. Li. Impact of the implementation of MPI
point-to-point communications on the performance of two general sparse solvers. Parallel
Computing, 29(7) :833–847, 2003.
[5] P. R. Amestoy, A. Guermouche, J.-Y. L’Excellent, and S. Pralet. Hybrid scheduling for the
parallel solution of linear systems. Parallel Computing, 32(2) :136–156, 2006.
[6] A. Fèvre, J.-Y. L’Excellent, and S. Pralet. Scilab and MATLAB interfaces to MUMPS.
Technical Report RR-5816, INRIA, Jan. 2006. Also appeared as ENSEEIHT-IRIT report
TR/TLSE/06/01 and LIP report RR2006-06.
18Vous pouvez aussi lire
