8. Approfondissements
8.3. Optimisation du temps d’exécution par « retour arrière »
Dans cette section, je présente la fonctionnalité de « retour arrière » que j’ai ajoutée à l’algorithme initial de l’approche. Cette fonctionnalité a permis de fortement diminuer le temps d’exécution nécessaire pour calculer une trajectoire solution (trajectoire modélisant l’ensemble des périodes de la dynamique).
8.3.1. Algorithme initial
Afin d’identifier des trajectoires solutions qui permettent de modéliser l’en- semble d’une dynamique, l’approche développée construit chaque trajec- toire solution de manière itérative :
1. Calculer les contraintes sur les flux e/s de la période pi, définie sur
l’intervalle de temps ti → ti+1. Pour cela les concentrations prédites
au temps ti (issue de la période précédente) et les mesures expéri-
mentales à ti+1 sont utilisées.
2. Choisir au hasard une solution pour la période pi.
3. Prédire les concentrations en composés extracellulaires à ti+1, en pre-
nant en compte les valeurs de flux correspondant à la solution obtenue à l’étape no2, et les concentrations initiales au temps t
i. Revenir en-
suite à l’étape no1 pour traiter la période suivante p
i+1, définie sur
ti+1→ ti+2.
Initialement, lorsque cet algorithme rencontrait une période pipour laquelle
aucune solution n’existait (compte tenu des concentrations initiales prédites à tiet des concentrations cibles à ti+1), alors la construction de la trajectoire
en cours était « abandonnée », et la construction d’une nouvelle trajectoire était recommencée depuis la période initiale p0.
Dans la section9.2(p.201), je montrerai que certaines périodes de la culture de C. glutamicum sont difficiles à modéliser, notamment la période 3h → 6h où des solutions n’existent que pour certaines combinaisons de concentra- tions en composés à t = 3h. Conséquence de ces périodes difficilement modélisables, le temps d’exécution pour trouver une bonne trajectoire est particulièrement long : sans la fonctionnalité de « retour en arrière », le
8.3. Optimisation du temps d’exécution par « retour arrière »
temps d’exécution est d’environ 70 minutes pour trouver une unique tra- jectoire solution.
8.3.2. Optimisation de l’algorithme
En plus de l’identification des raisons pour lesquelles des périodes étaient difficilement modélisables, je me suis intéressé à l’amélioration de l’efficacité de l’algorithme.
L’approche construit une trajectoire en traitant les périodes les unes après les autres, et cette construction reprend depuis le début si une période s’avère être sans solution. Afin de diminuer le temps moyen nécessaire pour générer une trajectoire, une manière de procéder est de ne pas recommencer entièrement la construction lorsqu’une période sans solution est rencontrée. Pour cela, j’ai ajouté à l’algorithme une fonctionnalité de « retour en ar- rière » que je vais discuter ici.
Les figures 8.10 (entrées et sorties de la fonction) et 8.11 (algorithme de la fonction, p.183) donnent une description synthétique de l’algorithme de la fonction principale « CalculerSegmentTraj » finalement utilisée pour construire les trajectoires.
Fonction : CalculerSegmentTraj(traj , ti, ti+1, datExp)
Entrées :
traj : objet qui représente la trajectoire jusqu’au temps ti, contient notamment :
- desc, description du réseau - const , contraintes constantes
- conc, concentrations prédites jusqu’au temps ti (conct0, . . ., concti) - sol , solutions retenues aux périodes précédentes (solp0, . . ., solpi−1) ti : temps de début de la période
ti+1 : temps de fin de la période
datExp : mesures expérimentales à tous les temps Sortie :
traj : objet qui représente la trajectoire jusqu’au temps ti+1
Figure 8.10. – Fonction principale utilisée pour générer une trajectoire, entrées et sortie de la fonction.
8. Approfondissements
Notons que cette fonction est récursive : une instance de la fonction (ins- tance mère) peut exécuter une autre instance de la fonction (instance fille).
Chaque instance de la fonction recherche une solution pour une période pi,
définie sur l’intervalle de temps allant de ti à ti+1. Lorsqu’une solution est
trouvée pour pi, la fonction en cours d’exécution appelle une instance fille
qui recherchera une solution pour la période suivante pi+1. La construction
d’une trajectoire se termine lorsque le temps de fin d’une période ti+1 cor-
respond au temps de fin de la dynamique modélisée. Dans cette situation, si des solutions ont pu être échantillonnées, l’une de ces solutions est choisie au hasard et la fonction fille qui correspond à la dernière période renvoie la description de la trajectoire complètement construite (sortie « a »). Le retour de cette fonction fille est alors évalué par la fonction mère, et la description de la trajectoire complète est retournée jusqu’à la première ins- tance de la fonction (sortie « c »).
La fonctionnalité de « retour en arrière » se situe au niveau des sorties « b » et « d » de la fonction CalculerSegmentTraj. Au cours de la construction d’une trajectoire, si la solution choisie à la période pi−1(au niveau de l’ins-
tance mère de la fonction) conduit à l’absence de solution pour la période pi (instance fille), l’instance fille renvoie la valeur 0 (sortie « d »). Le pro-
cessus de construction revient alors à la période pi−1(instance mère) et une
autre solution est choisie pour prolonger la trajectoire vers la période pi.
Par ailleurs, si après avoir testé 10 solutions pour la période pi−1, aucune ne
s’avère être une « bonne » solution pour la période pi, un autre « retour en
arrière » est effectué vers la période pi−2(sortie « b » de l’instance mère).
Pour chaque période (autrement dit, pour chaque instance de la fonction), les 10 solutions testées avant d’effectuer un « retour en arrière » corres- pondent aux solutions échantillonnées aux itérations 11 à 20 des chaînes de Markov (solutions indépendantes du point de départ). Ce faisant, il n’est pas nécessaire de réaliser un nouvel échantillonnage à chaque « retour en arrière », ce qui contribue aussi à réduire le temps de calcul.
8.3.3. Impact sur le temps d’exécution
Sans la fonctionnalité de « retour en arrière », le temps d’exécution moyen nécessaire pour obtenir une unique trajectoire solution est d’environ 70 minutes. Lorsque la fonctionnalité de « retour en arrière » est utilisée, ce
8.3. Optimisation du temps d’exécution par « retour arrière »
Début
Obtenir concentrations prédites à ti (depuis traj )
Obtenir concentrations expérimentales à ti+1 (depuis datExp)
Calculer contraintes variables sur flux e/s
sys ← Appliquer contraintes constantes et variables pour définir le système Siil existe au moins une solution pour sys alors :
| Échantillonner espace des solutions de sys
| candidates ← Retenir solutions aux itérations 11 à 20 | test ← 0
|
| Tant que
| (1) il reste au moins une solution dans candidates et | (2) test == 0
| faire :
| | sol ← Choisir une solution parmi candidates | | candidates ← Retirer sol de candidates
| | concti +1 ← Prédire conc. à ti+1 selon la solution choisie
| | Retenir concti +1 et sol dans traj
| |
| | Si ti+1 est le dernier temps de la dynamique alors :
| | | Retourner traj Sortie A
| | Sinon:
| | | test ← CalculerSegmentTraj(traj , ti+1, ti+2, datExp)
| | Fin si | |
| Fin tant que |
| Si test == 0 alors :
| | Retourner 0 Sortie B
| Sinon :
| | traj ← test
| | Retourner traj Sortie C
| Fin si | Sinon: | Retourner 0 Sortie D Fin si Fin
8. Approfondissements
temps d’exécution moyen passe à environ 7 minutes et 45 secondes (plus ou moins 2 minutes à un écart-type). Les temps moyens ont été estimés à partir de la génération de 1 000 trajectoires pour l’algorithme sans « retour arrière », et de 9 000 trajectoires pour l’algorithme avec « retour arrière ». Chaque trajectoire modélise la dynamique de la culture de C. glutamicum allant de t = 0 à t = 16, 5h, sans prendre en compte les mesures à t = 4, 5h. Les trajectoires ont été générées en utilisant des processeurs Intel Xeon E5-4607, où chaque cœur est cadencé à 2,2 gigahertz.
Lors de l’utilisation de la fonctionnalité de « retour en arrière », l’essentiel du temps de calcul correspond à la recherche d’une « bonne » solution pour la période de temps allant de t = 3 à t = 6h. La figure 8.12 montre le nombre moyen de chaque type de sortie de la fonction CalculSegmentTraj lors de la construction d’une trajectoire, selon la période de la dynamique traitée. Comme on peut le voir, les « retours en arrière » sont effectués en très grande majorité lors du traitement de la période p3 (période allant de
t = 3 à t = 6h), où chaque sortie de type d correspond à une situation où les concentrations prédites à t = 3h impliquent une absence totale de solution pour cette période. Le fait que des sorties de type b soient utilisées pour la période p1,5 indique par ailleurs que l’obtention d’une bonne solution
pour la période p3 peut aussi nécessiter l’essai de plusieurs solutions pour
la période p1,5.
Figure 8.12. – Nombre moyen de chaque type de sortie de la fonction CalculSegmentTraj selon la période de la dynamique traitée. Chaque graphique cor- respond à une période, dont le temps de début est donné au-dessus. Le nombre de sorties est donné en ordonnée. Chaque graphique correspond à l’une des périodes traitées. Le code couleur indique le type de sortie.
8.3. Optimisation du temps d’exécution par « retour arrière »
8.3.4. Optimisation du temps d’exécution par « retour
en arrière » : bilan
Dans cette section, il s’agit de présenter l’optimisation réalisée sur l’algo- rithme de génération des trajectoires solutions. L’ajout de la fonctionnalité de « retour en arrière » m’a permis de passer d’un temps moyen de 70 mi- nutes à environ 7 minutes et 45 secondes pour générer une trajectoire. Cela représente une accélération de la vitesse de génération par un facteur voisin de 9.
Remarquons que, comme (i ) le calcul de chaque trajectoire est indépendant et (ii ) l’ensemble de l’approche est implémenté dans le langage R, la géné- ration des trajectoires peut facilement être parallélisée sur plusieurs cœurs, processeurs, ou machines différentes.
Ainsi, en utilisant 12 processus simultanés, le temps nécessaire pour générer un jeu de 1 000 trajectoires était à l’origine d’environ 4 jours. Dans le même laps de temps, 9 000 trajectoires peuvent maintenant être construites. Cela permet potentiellement d’obtenir une meilleure résolution des distributions de flux, et de tester plus facilement différentes hypothèses sur le fonction- nement du métabolisme étudié.
Le nombre de 10 essais avant d’effectuer un « retour en arrière » d’une pé- riode pi−1 vers une période pi−2 (sortie « b ») peut être discuté : il s’agit
avant tout de trouver un compromis entre (i ) rejeter suffisamment vite la solution choisie pour pi−2, car les concentrations prédites à partir de cette
solution peuvent conduire indirectement à une « impasse » (les concentra- tions prédites à ti−1permettent encore de trouver des solutions, mais quelles
que soient ces solutions, les concentrations qui seront prédites à ti ne pour-
ront plus déboucher sur des solutions pour la période ti → ti+1), et (ii ) ne
pas rejeter trop vite la solution choisie pour pi−2, car elle n’est pas nécessai-
rement en cause dans le fait qu’aucune des solutions échantillonnées à pi−1
ne permet de poursuivre la trajectoire à pi (la solution pi−1est peut être la
cause). Remarquons que le fait que les 10 solutions testées correspondent à des itérations successives d’une même chaîne de Markov ne diminue pas la qualité de l’échantillonnage des « méta » espaces des solutions, puisque, au mieux, seule une des solutions sera retenue pour poursuivre la construction de la trajectoire.