CHAPITRE 4. APPLICATION DE SCREENINGASSISTANT À DES PROJETS CONCRETS
B. Implémentations des méthodes d’optimisations
( ) ( 2 1 1 k local k global k k a V b X X b X X V+ = × + × − + × − (Équation 11)
• La valeur de chaque variable : Xk+1 =Xk +Vk+1 (Équation 12)
a est la constante d’inertie, b1 et b2 deux variables aléatoires positives.
4. Colonies de fourmis
Les algorithmes de colonies de fourmis ont été introduits par Marco Dorigo [22] lors de sa thèse. Ils imitent le comportement des fourmis pour trouver de la nourriture. Ils peuvent sembler similaires à l'optimisation par essaims particulaires, mais sont cependant bien différents, et utilise notamment les notions de chemins et de phéromones. En effet, les fourmis errent pour trouver de la nourriture. Quand elles en trouvent, elles marquent le chemin entre la colonie et la nourriture. D'autres fourmis vont être attirées par ces phéromones, et vont renforcer le marquage du chemin. Parmi plusieurs chemins menant à de la nourriture, les plus courts auront une concentration en phéromones plus forte et seront donc plus marqués. Etant donné qu'ils sont basés sur une notion de chemins, ces algorithmes trouvent leurs applications principales dans les graphes.
B. Implémentations des méthodes d’optimisations
Nous avons implémenté et testé les algorithmes génétiques et le recuit simulés. Les résultats obtenus par ces deux méthodes ont été satisfaisant, et nous n’avons pas eu besoin de tester les deux autres méthodes envisagées.
1. Algorithmes génétiques
Nous avons développé une bibliothèque d’optimisation. Cette bibliothèque devait dans un premier temps être utilisable pour la sélection de plaques. Cependant, elle devait également être suffisamment générale pour être utilisable dans d’éventuels projets futurs de chemoinformatique comme notamment le QSAR (sélection de descripteurs, optimisation de paramètres de réseaux de neurones ou de machine à support de vecteurs) et la conception
de-novo. Il a dans un premier temps été envisagé d’utiliser une bibliothèque d’algorithmes génétiques existante. Cette bibliothèque devait être en Java afin de pouvoir être intégrée facilement à d’autres logiciels du laboratoire, principalement ScreeningAssistant. Notre choix s’était porté sur la librairie JGAP [23]. Cependant les résultats de nos tests ont étés décevants sur des problèmes d’optimisation simples, sans que la cause de ces mauvais résultats puisse être trouvée. Nous avons donc décidé de développer notre propre algorithme génétique, afin de disposer d’une bibliothèque dont nous connaîtrions parfaitement le code. Les résultats avec cette nouvelle bibliothèque se sont montrés très satisfaisants, et ce code a été adopté pour la suite de nos travaux. Le diagramme UML de cette bibliothèque est présenté Figure 33.
Figure 33. Diagramme UML de la bibliothèque d’algorithmes génétiques.
Les noms de toutes les classes débutent par SA, pour ScreeningAssistant, et GA, pour Genetic Algorithms. La classe SAGAPopulation est la classe principale de la bibliothèque, et permet de contrôler l’évolution de l’algorithme. Elle stocke un tableau de SAGAChromosome, qui représente donc la population à un moment donné. SAGAChromosome stocke quand à elle un tableau de SAGAGene, qui correspond au génotype. Trois classes héritent de la classe abstraite SAGAGene. Ces classes permettent de manipuler des données de type booléen, entier, ou double (réel).
La classe abstraite SAGAFitnessFunction définit une structure générale pour calculer le score d’une solution. Il faudra donc, pour chaque problème, implémenter une classe enfant de SAGAFitnessFunction qui permet de calculer le score pour une solution (c.a.d. un chromosome) du problème donné. Cette classe sera passée au constructeur de
SAGAPopulation.
Les classes abstraites SAGASelection et SAGAMating permettent d’implémenter respectivement la sélection des parents, et la reproduction. Pour ces deux étapes, nous avons choisi d’implémenter des méthodes couramment utilisées. Ainsi la sélection des parents se fait par la méthode de la roue de la fortune avec une pondération basée sur les scores, et la reproduction par un crossover deux points.
Nous avons décrit les différents éléments constitutifs de notre algorithme génétique. Il y a cependant un facteur à prendre en compte, et que nous n’avons pas encore abordé : les contraintes sur les solutions. Nous avons pour l’instant comme unique contrainte dans notre système les intervalles qui sont définis pour les valeurs des gènes de types entiers et réels. Certains problèmes vont cependant nécessiter des solutions un peu plus sophistiquées. Supposons que notre algorithme génétique serve à sélectionner des descripteurs pour un modèle QSAR, ou bien des molécules pour la sélection d’un ensemble de composés divers. Le problème pourra être codé en attribuant un identificateur de type entier à chacun des éléments, les descripteurs dans un cas, et les molécules dans l’autre (on aura alors dans le premier cas un modèle QSAR avec un nombre de descripteurs prédéfini). Chacun des éléments ne devra être présent qu’une seule fois dans une même solution, car il est évidemment impensable d’avoir un modèle QSAR utilisant deux fois le même descripteur, ou bien un ensemble de molécules divers dans lequel on retrouve des doublons. Nous voyons donc que notre système doit permettre d’établir des contraintes sur les solutions. Dans nos exemples la contrainte est l’unicité des allèles. Il existe plusieurs manières de gérer ces contraintes. Ainsi JGAP [24] utilise la notion de supergène. Il s’agit d’un gène définissant une contrainte et regroupant tous les gènes concernés par la contrainte. Cette méthode a l’inconvénient de compliquer la structure des données. Nous avons pour notre part implémenté la gestion de la contrainte de manière un peu différente. Cette dernière s’effectue en étendant la classe Chromosome et en redéfinissant la méthode constraintIsRespected. Cette méthode sera appelée après chaque modification de chromosome c’est à dire pendant les étapes d’initialisation, de crossover et de mutation. Si le chromosome généré pendant une étape donnée ne respecte pas la contrainte, une autre tentative est effectuée.
On notera enfin que les performances des algorithmes génétiques peuvent être améliorées significativement par une implémentation parallèle. Dans ce cas ont utilise des sous-populations qui évoluent de manière indépendante, mais en échangeant des individus entre elles occasionnellement. Plusieurs études montrent même une augmentation superlinéaire de la vitesse d’exécution des algorithmes génétiques parallèles. Ces résultats nécessitent quelques précisions. En effet si l’on exécute sur un même processeur tous les processus d’un programme parallèle, le temps d’exécution ne peut pas être inférieur au temps d’exécution de la même tâche par un programme en série. En fait, la superlinéarité de la vitesse d’exécution peut généralement s’expliquer par le fait que les algorithmes génétiques
La parallélisation des algorithmes génétiques est donc très intéressante. Même si l’utilisation d’algorithmes génétiques parallèles sort du cadre de ce travail, certaines implémentations ont été réalisées afin de permettre une éventuelle parallélisation. Ainsi les classes SAGAChromosome, SAGAGene et SAGAFitnessFunction implémentent l’interface
Serializable, et elles sont donc transmissibles par communication réseau.
2. Recuit Simulé
En nous basant sur les classes définies pour les algorithmes génétiques, nous avons développé un algorithme de recuit simulé (Figure 34).
Figure 34. Diagramme UML de la bibliothèque de recuit simulé.
La classe principale est ici SASASimulatedAnnealing, qui prend en charge le déroulement de l’expérience de recuit simulé. Nous avons conservé la classe
SAGAChromosomes pour gérer les solutions. Bien que la notion de chromosomes n’entre pas en jeu dans les algorithmes de recuit simulé, notre classe est bien adaptée pour gérer la solution qui sera optimisée par le recuit simulé. Comme pour les algorithmes génétiques, les solutions pourront être de types entier, booléen ou double, et des contraintes pourront être
appliquées. La création d’une expérience de recuit simulé nécessite de définir le schéma de refroidissement (classe abstraite SASACoolingSchedule) et le critère d’acceptation (classe abstraite SASAAcceptanceCriterion). Nous avons implémenté le critère d’acceptation de Metropolis, et un schéma de refroidissement géométrique.