La validation num´erique : principes et m´ethodes
Definition 2.2. ulp(x) est la distance entre deux nombres flottants proches de x, même si x est l’un d’eux
2.3 La validation numérique en industrie
par exemple les méthodes issues du domaine de l’interprétation abstraite comme celles utili-sées dans l’outil Fluctuat [Goubault et al., 2008] du CEA qui permettent de calculer des sur-approximations des erreurs générées.
L’interprétation abstraite permet grâce à une analyse statique (i.e. sans l’exécuter) de prou-ver des propriétés d’un programme qui sont valables pour toutes les exécutions possibles de celui-ci. Il est nécessaire pour cela de définir une sémantique collectrice qui regroupe toutes les sémantiques pour tous les environnements. Prouver qu’un programme est correct revient à vérifier que la sémantique collectrice de ce programme est incluse dans la spécification (l’en-semble des états valides) du programme [Ioualalen, 2013, chapitre 3].
Les travaux de Martel ont été consacrés à l’interprétation abstraite et à son application à l’amélioration de la qualité numérique des programmes. Il a présenté dans [Martel, 2006] une sémantique qui permet de définir un domaine abstrait qui calcule une approximation des erreurs d’arrondi introduites par l’arithmétique à virgule flottante durant l’évaluation d’une expression. Une autre sémantique présentée toujours par Martel permet de formaliser une abstraction qui a pour but d’optimiser automatiquement la précision numérique d’un pro-gramme [Martel, 2007]. Cette dernière sémantique montre qu’il est possible de se servir de la sémantique de propagation d’erreurs d’arrondi afin de synthétiser un nouveau programme dont l’erreur d’arrondi est plus faible [Martel, 2009].
Outre l’interprétation abstraite, des méthodes stochastiques et des techniques issues du do-maine de la différentiation automatique (A.D.38) [Bischof et al., 2008,Griewank et Walther, 2008] de code peuvent aussi être utilisées pour estimer les erreurs d’arrondi et les réduire [ Bracon-nier et Langlois, 2002]. Le logiciel CADNA, que nous présentons dans lechapitre 3, implémente l’approche stochastique que nous avons introduit ensection 2.2.1.
L’idée de la différentiation automatique est de considérer un programme comme une fonc-tion mathématique définie par composifonc-tion de foncfonc-tions élémentaires (+, −, ×, ÷) et d’en cal-culer sa dérivée. Cette méthode s’appuie sur la règle de la dérivation en chaîne : si f et g sont deux fonctions dérivables alors f ◦ g est différentiable telle que (f ◦ g)0= g0(f0◦ g) [Chapoutot et al., 2009, section 2.5]. La méthode permet, par le biais des valeurs différentielles, une ana-lyse de dépendance entre les variables présentes dans le programme et ainsi d’en déduire une approximation des erreurs. Deux implémentations sont possibles pour la méthode de diffé-rentiation automatique : par surcharge d’opérateurs (basée sur le concept d’objet des langages de programmation) et par transformation de code source. On retrouve la première implémen-tation dans la bibliothèque ADOL-C [Walther et Griewank, 2012] dédiée au langage C++. Ce type d’implémentation a pour avantage d’être facilement utilisable grâce aux objets mais dé-grade les performances. La transformation de code source est utilisée dans les bibliothèques ADIC39[Bischof et al., 1997], TAPENADE40[Hascoëet et Araya-Polo, 2006] pour les langages C/C++ et le Fortran. La transformation de code s’appuie sur des concepts issus de la compi-lation. L’idée est de modifier le programme initial en y ajoutant des instructions permettant le calcul des dérivées.
2.3 La validation numérique en industrie
La validation numérique en industrie est une partie importante de la conception des outils de simulation numérique. Elle rentre dans de cadre du processus V&V (vérification et
valida-38. Automatic Differentiation, voirhttp://www.autodiff.org/ 39. http://www.mcs.anl.gov/research/projects/adic/ 40. http://www-sop.inria.fr/tropics/tapenade.html
Chapitre 2. La validation numérique : principes et méthodes
tion). La vérification analyse les comportements du logiciel par rapport aux spécifications pré-établies. La validation a pour objectif de confronter les résultats des simulations à des modèles ou à des mesures. En fait, par abus de langage, les termes vérification et validation sont souvent utilisés comme synonymes. Toutefois, il existe une petite nuance. La vérification numérique consiste à vérifier la qualité numérique. La vérification permet la validation de la qualité nu-mérique.
Les outils et méthodes que nous avons cités dans les sections précédentes peuvent tous ser-vir dans ce processus mais à des étapes différentes. En ce qui concerne les erreurs d’arrondi, nous résumons le processus de vérification numérique en cinq étapes indépendantes. On consi-dère ici que la modélisation mathématique a déjà été faite.
1. Analyse des algorithmes : la première étape dans la conception d’un code de calcul est le choix des algorithmes à implémenter. Les algorithmes doivent être choisis en fonction des problèmes physiques traités. Il est nécessaire de faire une analyse d’erreur (directe, inverse) de chaque algorithme afin d’étudier sa stabilité. Les principaux algorithmes d’al-gèbre linéaire ont déjà été l’objet de nombreuses études [Higham, 2002]. Il suffira alors de consulter la littérature à sujet. Il est aussi possible pour les problèmes d’algèbre linéaire d’implanter directement dans le code des routines qui permettent d’estimer l’erreur di-recte ou inverse [Baboulin et al., 2012].
2. Implémentation des algorithmes : au cours de cette phase, il est nécessaire de faire atten-tion aux spécificités du langage de programmaatten-tion choisi et de l’architecture matérielle cible.
3. Vérification : l’objectif ici est de vérifier la reproductibilité et l’exactitude des résultats sui-vant les plateformes de test. On peut faire appel à l’arithmétique des intervalles, l’arith-métique multiprécision ou l’arithl’arith-métique stochastique.
4. Détection des erreurs : dans le cas où l’étape vérification n’a pas été jugée concluante, il faut identifier les sources d’erreurs. On peut utiliser dans ce cadre les outils cités dans la section 2.2.3.
5. Améliorer la précision des résultats : après l’identification des problèmes, il faut chercher à les éliminer (ou réduire leurs effets). La première solution serait alors d’améliorer la pré-cision en utilisant tout outil susceptible d’augmenter la prépré-cision de calcul (arithmétique multiprécision, algorithmes compensés). Une autre solution possible est de ré-écrire les parties des codes entachées de problèmes en respectant autant que possible les spécifici-tés du langage de programmation.
D’un point de vue industriel, le coût du processus de vérification est un paramètre très im-portant. Par coût, nous sous-entendons temps de développement ou de mise en œuvre de la méthode de validation, coût de la licence logiciel et temps d’exécution des versions de code in-tégrant les outils de validation. C’est la raison pour laquelle, l’industriel privilégiera, du moins dans un premier temps, les outils les moins intrusifs (sans modification de codes sources), les moins onéreux (open source) et ceux qui demande un minimum d’effort pour la prise en main. Cette notion de coût justifie également l’utilisation de bibliothèques externes pendant la conception des logiciels de simulation. En fait, il s’agit d’une mutualisation des coûts. Toute-fois, nous faisons remarquer que même si l’aspect financier est important, l’industriel est prêt à payer quand il a une garantie de la qualité du service fourni et si le service répond entièrement à ses besoins.
Pour être plus complet sur la validation numérique dans l’industrie, elle ne se fait bien sou-vent qu’après la détection de problèmes de reproductibilité. L’idée est de détecter puis de
pro-2.4. Conclusion
poser des solutions. Certains outils comme Fluctuat peuvent aussi être utilisés dans un cadre industriel [Delmas et al., 2009]. Fluctuat présente pour principal inconvénient d’être propriété du CEA et ne fonctionne que sur les codes développés en C ou ADA, ceci limite son utilisa-tion pour les codes industriels écrits en Fortran. On peut également cité l’outil Astree41 qui a été utilisé pour valider le logiciel de commande de vol électrique primaire de l’A340 et de l’A380 [Bouissou et al., 2009]. Astree a été principalement conçu pour les systèmes embarqués et ne traite que des problèmes qui surviennent à l’exécution. Enfin, il y a aussi l’outil CADNA qui est utilisé à EDF R&D. Cet outil a pour principal avantage d’être disponible en C/C++ et en Fortran, qui sont deux langages souvent utilisés pour le calcul scientifique. En outre, l’ou-til peut être facilement implémenté dans un code surtout si ce dernier est développé en C++. CADNA permet de localiser les problèmes numériques et propose un diagnostic à la fin des exécutions. Nous présentons cet outil dans le prochain chapitre.
Des outils ou méthodes sont ensuite nécessaires pour corriger les erreurs détectées lors de la vérification numérique. Dans ce cas, l’industriel a le plus souvent recourt aux outils d’arith-métique multiprécision et notamment MPFR. A titre d’exemple, c’est cette bibliothèque qui a été utilisée dans les deux cas présentés ensection 1.4.1.
2.4 Conclusion
Nous avons exposé dans ce chapitre les principales notions de la validation numérique. En effet, les résultats des calculs sur ordinateurs peuvent être erronés du fait de l’arithmé-tique flottante. La norme IEEE 754-1985 et sa révision de 2008 ont permis de créer un cadre pour les calculs sur les nombres à virgule flottante. La norme exige un arrondi correct pour les quatre opérations élémentaires (+, −, ×, /) et la racine carrée. Cependant, pour des raisons de performance, la norme n’est pas toujours strictement respectée (section 2.1). En fait, les résul-tats de l’exécution d’un code dépendent principalement de l’environnement de travail (OS), de l’architecture matérielle sur laquelle est exécuté le code (le processeur), du langage de pro-grammation (C, C++, Fortran) et du compilateur utilisé (Intel, GNU GCC, etc). Nous montrons ensection 2.1.4que très peu de responsabilités reposent sur les développeurs. Néanmoins, ils gagneraient beaucoup à porter attention à la documentation des langages de programmation ainsi que des options de compilation auxquelles ils font appel.
En résumé, il est impossible d’éviter la propagation des erreurs d’arrondi dans les calculs flottants. Le mieux que l’on puisse faire est mettre en place des méthodes qui permettent d’esti-mer la qualité numérique des résultats finaux. Un état de l’art des principaux outils et méthodes de validation numérique a été proposé ensection 2.2. Ces méthodes sont résumées ici en trois classes :
i. Analyse des erreurs pour ensuite estimer l’erreur totale commise ; ii. Détection des erreurs pour proposer des solutions d’amélioration ;
iii. Diminution des erreurs en augmentant ou en simulant des précisions de travail élevées. Dans l’industrie, la validation numérique des codes de calculs ne se fait bien souvent qu’après la détection de problèmes de reproductibilité. Nous montrons dans lasection 2.3que cette validation peut se faire en plusieurs étapes indépendantes. Cependant, dans les faits, elle ne se fait principalement qu’en deux étapes : détection des erreurs et mise en place de solutions pour améliorer la qualité numérique. Notons également que la validation numérique des codes
Chapitre 2. La validation numérique : principes et méthodes
industriels répond à des critères de coût et de performance. En ce sens, il a été montré que l’ou-til CADNA basé sur l’approche stochastique d’analyse d’erreurs est adapté pour la détection des instabilités numériques dans un code industriel. Outre le fait d’être disponible en C/C++ et Fortran, cet outil a pour principal avantage de localiser les problèmes numériques et de proposer un diagnostic à la fin des exécutions. La bibliothèque CADNA ainsi que la méthode CESTAC qu’elle implémente sont présentées en détail dans le prochain chapitre.
Chapitre