Optimisation Multi-objectif Pire cas
Algorithme 7.1 Algorithme de réutilisation des appels
7.1.4.1 Efficacité de MOEGO NSGA-II couplé à EGO
Afin de valider notre approche, nous comparons ici le résultat de MOEGO NSGA-II couplé à EGO au résultat de l’algorithme NSGA-II classique pour la partie multi-objectif de l’équation (7.1) et l’algorithme à évolution différentielle pour estimer le pire cas en chaque point de contrôle multi-objectif x. Cette résolution est volontairement lourde et coûteuse en nombre d’appels aux deux fonctions objectif. Le résultat de cette optimisation constitue la référence à laquelle se comparer.
Comme précédemment, nous répétons l’optimisation cinquante fois et nous comparons la décroissance de la distance entre P F? discrétisé et le front retourné par chacune des ces deux méthodes. La figure 7.2 résume ce résultat. La distance cible choisie ici correspond à Mtarget= 0.005, où la distance est celle détaillée à l’équation (6.6). La figure 7.3 illustre un front obtenu lorsque cette distance cible est atteinte. On remarque que notre méthodologie nécessite un nombre restreint d’appels aux fonctions objectif afin d’atteindre une précision suffisante sur le front retourné. En particulier, la figure 7.4 met en évidence l’itération à partir de laquelle toutes les répétitions de l’algorithme ont atteint la distance cible. On remarque que MOEGO NSGA-II permet de converger en environ 39 appels distribués, alors que NSGA-II couplé à l’évolution différentielle (pour le pire cas) en nécessite 105.
Nous souhaitons ensuite mettre en évidence l’apport de la réutilisation des appels à f1
détaillée à l’algorithme 7.1. Pour cela, la figure 7.5 montre le nombre moyen d’appels à la fonction f1 à chaque calcul de pire cas et pour chaque itération de l’algorithme MOEGO NSGA-II. Cette figure montre que la réutilisation a un effet positif sur le nombre d’appels nécessaires à la fonction f1, puisque plus le nombre d’itérations est important, donc plus la base de données Ξ est remplie, moins il est nécessaire d’exécuter de simulations de f1. Par ailleurs, ce graphique illustre, comme la figure 6.47 au chapitre précédent, que MOEGO NSGA-II a une première phase à nombre d’appels réduit, une seconde phase où le nombre d’appels augmente beaucoup puis une phase finale qui nécessite moins d’appels. La zone où le nombre d’appels augmente traduit le fait que MOEGO NSGA-II explore de manière importante l’espace Dx. Ceci implique que les points à évaluer sont distants et donc que le cardinal de Ξx est nul. En d’autres termes, qu’il n’y aucun point de la base de données Ξ qui se trouve à proximité des points de contrôle où l’on évalue le pire cas à ces itérations. Ceci met également en évidence que lors des premières itérations de l’algorithme MOEGO NSGA-II, l’exploration ne se met pas tout de suite en place et la méthode stagne dans une zone, ce qui justifie l’efficacité de la réutilisation.
Enfin, la fonction f1 peut être coûteuse. Or, nous lui appliquons le calcul d’un pire cas à chaque appel distribué. Pour quantifier le coût de résolution de l’équation (7.1), il faut regarder le nombre moyen d’appels nécessaires à cette fonction à chaque itération de l’algorithme MOEGO NSGA-II. La figure 7.6 donne le nombre maximum d’appels à chaque itération de MOEGO NSGA-II. De cette dernière, on peut en déduire le temps d’exécution d’un tel algorithme. En effet, on remarque sur ce graphique qu’il faut une moyenne de 36 exécutions de f1au maximum afin de calculer le pire cas, en particulier grâce à l’algorithme 7.1 de réutilisation. De ce fait, en conjuguant les 39 itérations de MOEGO NSGA-II (donnée extraite de la figure 7.4) et les 36 exécutions de f1 à chaque itération, le temps d’exécution de l’algorithme est de l’ordre de 1400 exécutions de la fonction f1 pour
0 20 40 60 80 100 Number of distributed calls (with 10 CPU) 10-3 10-2 Me an Va lue of th e d ist an ce to th e t rue PF Target distance NSGA-II MOEGO-NSGA-II
Figure 7.2 – Graphique représentant la moyenne sur cinquante optimisations de la dis-tance entre P F? et P F en fonction du nombre d’appels distribués aux fonctions objectif pour le cas test MOP2 modifié
1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.0 2.1 maxξ f1 0.0 0.2 0.4 0.6 0.8 1.0 f 2 PF⋆ MOEGO NSGA-II
Figure 7.3 – Graphique représentant le front obtenu par MOEGO NSGA-II après 30 appels distribués et vérifiant le critère de l’équation (6.8) avec Mtarget = 0.005.
NSGA-II
(105 distributed calls) (39 distributed calls)MOEGO-NSGA-II 0.000 0.001 0.002 0.003 0.004 0.005 0.006
Comparison of the distance to the true PF
Figure 7.4 – Boîtes à moustaches du nombre d’appels aux fonctions objectif une fois le critère d’arrêt atteint pour le cas test MOP2 modifié
0 10 20 30 40 50 25 26 27 28 29 30 31 32 33 34
Mean number of calls to
for WC computation
MOEGO NSGA-II iteration (number of distributed calls completed)
Figure 7.5 – Nombre moyen d’appels à f1à chaque calcul de pire cas pour chaque itération de l’algorithme MOEGO NSGA-II
0 10 20 30 40 50
MOEGO NSGA-II iteration (number of distributed calls completed) 30 32 34 36 38 40 42
Maximum number of calls to
for WC computation
Figure 7.6 – Nombre maximum d’appels à f1 à chaque calcul de pire cas pour chaque itération de l’algorithme MOEGO NSGA-II
atteindre la convergence. Cette estimation se base sur la pire des cinquante répétitions réalisées. Ce qui nous donne donc une borne supérieure du nombre d’appels nécessaires. 7.1.4.2 Preuve de l’intérêt de l’optimisation pire cas
Un autre aspect qu’il est intéressant de mettre en évidence ici est l’apport de la prise en compte des incertitudes sur les entrées d’un problème d’optimisation.
Pour cela, nous comparons les solutions des deux formulations introduites jusqu’à maintenant. La première est celle ne prenant pas en compte les incertitudes sur les diffé-rents paramètres du problème d’optimisation, c’est-à-dire celle donnée à l’équation (6.1). La seconde est celle de l’équation (7.1) où les incertitudes sont prises en compte par un pire cas en chaque point de contrôle.
Nous effectuons cette comparaison sur le cas test introduit à l’équation (7.9). La figure 7.8 met sur un même graphique le front solution de l’équation (6.1), ici appelé détermi-niste, et le front solution de l’équation (7.1), ici appelé pire cas. On remarque que la prise en compte des incertitudes par le pire cas modifie la forme du front optimal. Plus précisé-ment, si l’on calcule à présent le pire cas sur l’objectif f1 des solutions Pareto-optimales déterministes (ce que représente la figure 7.8), on peut mettre en évidence deux points importants :
1. D’abord, les solutions du problème déterministe restent Pareto-optimales pour la formulation pire cas de l’équation (7.1).
2. Ensuite, un grand nombre de solutions qui n’étaient pas Pareto-optimales pour la formulation déterministe le deviennent dans la formulation prenant en compte les incertitudes par un pire cas.
Le deuxième point est important puisque les incertitudes peuvent traduire des effets non maîtrisables par l’utilisateur, telles que des contraintes d’usinage. De ce fait, ces solutions introduites par la résolution de la formulation pire cas présentent l’avantage d’être Pareto-optimales et robustes. La non-prise en compte des incertitudes présente le désavantage dans notre cas de ne pas saisir certaines solutions qui peuvent être d’intérêt pour l’utilisateur.
0.0 0.5 1.0 1.5 2.0 f1 0.0 0.2 0.4 0.6 0.8 1.0 f2 Deterministic Worst-Case
Figure 7.7 – Représentation dans l’espace des objectifs des points Pareto-optimaux pour la formulation déterministe et pour la formulation avec un pire cas pour quan-tifier les effets des incertitudes en entrée.
1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.0 2.1 f1 0.0 0.2 0.4 0.6 0.8 1.0 f2 Worst-Case Deterministic Figure 7.8 – Représentation du maxξ f1(ζ (x, ξx) , ξe) en fonction de
f2 des points Pareto-optimaux pour la formulation déterministe et pour la formu-lation avec un pire cas pour quantifier les effets des incertitudes en entrée.