Selon Blaise, dès lors que l’on a formalisé et discrétisé les éléments en interaction, il faut recourir à une technique de modélisation adaptée et éprouvée par ailleurs. Il s’agit de la simulation à événements discrets. Il la décrit comme une « technique de modélisation permettant de construire une abstraction de la réalité et de faire évoluer cette abstraction en fonction du temps » 1898 .
Nous allons décrire les particularités de ce type de modélisation afin de comprendre le choix qui a été fait. L’idée qui préside à cette technique et qui justifie sa dénomination est que les variables numériques décrivant le système sont discrètes et en nombre fini. Il en résulte trois conséquences essentielles pour la conduite de la programmation : tout d’abord, l’ensemble des combinaisons de valeurs qu’elles peuvent prendre, et qui constitue l’espace d’état de la simulation, est a priori fini ou encore dénombrable. La deuxième conséquence concerne la façon de traiter l’évolution du système modélisé. Cette évolution y est expliquée en termes de changements d’état. Or, étant donné le caractère discret des variables, ces changements d’états doivent eux aussi être représentés de façon discrète, puisqu’on ne peut passer continûment d’une valeur discrète à une autre. Il y a donc des instants de changement appelés « temps d’occurrence d’événement » ou dates d’événement où l’on admet que le système fait un saut. Le temps se trouve donc aussi discrétisé 1899 . La troisième conséquence de ce traitement discret des variables peut s’exprimer par la notion d’ordre de traitement des événements simultanés. Cet ordre renvoie simplement à la décision désormais possible pour le programmeur de faire traiter dans un ordre séquentiel des événements qui ont lieu en fait simultanément. Il peut donc être parfaitement ignoré de l’utilisateur du logiciel. Cette discrétisation informatique du temps a pour essentielle qualité de permettre au programme d’« arrêter » le temps afin de traiter toutes les tâches simultanées, les unes après les autres. Le temps de la simulation est donc un temps virtuel qui se sépare du temps réel non seulement parce qu’il possède un rapport de rythme différent mais parce qu’on se permet de l’« arrêter » pour réaliser des tâches parallèles. Ainsi, en toute rigueur, une machine séquentielle peut, moyennant cette technique, procéder de façon quasi-parallèle 1900 .
La première difficulté qu’il faut ensuite résoudre lorsque l’on opte pour ce type de simulation concerne la gestion du temps. Elle peut être de deux types : par horloge ou par événements. Il pourrait sembler naturel, étant données les idées avancées en ce sens par de Reffye, que Blaise utilise la simulation dirigée par une horloge. Dans ce type de simulation, à chaque top d’horloge incrémenté, « la liste des événements est explorée et tous les événements apparaissant à cette date sont activés ». Mais Blaise rejette cette solution « parce qu’on ne peut précisément définir les différents états de la plante au cours de sa croissance » 1901 . Ce n’est pas une impossibilité technique qui est ici visée. Le problème n’est pas de type informatique. Il concerne le choix du pas de temps. Pour pouvoir réellement définir un battement minimal dans l’élaboration d’une forme naturelle, il faut que l’élaboration de toutes ses parties possibles nécessite un nombre entier positif de battements. Il faut pouvoir ainsi définir l’échelle de « temps virtuel » réaliste. Dans les faits, les rapports de rythme temporels et intrinsèques à une plante donnée sont des nombres réels. Or, bien que cela soit discutable, l’ensemble mathématique des nombres réels peut à première vue être considéré comme un concept modelé sur notre appréhension du continuum physique. C’est là qu’intervient la nature du phénomène à simuler. Le phénomène biologique se distingue par là nettement du phénomène mécanique ou industriel tel qu’il peut être conçu à l’avance ou reconstitué par CAO. Si ce phénomène n’est pas artificiel, si donc il est biologique (au contraire de ce qui a lieu dans le dessin technique de l’ingénieur mécanicien ou architecte où l’on peut faire apparaître un module), il n’y pas d’étalon simple de mesure temporelle de l’évolution puisqu’on n’a pas eu le loisir d’en choisir un. Il n’est donc pas facile d’assigner un événement minimal, c’est-à-dire de durée minimale, qui constituerait une mesure de base pour tous les autres événements 1902 . Cela est dû au fait qu’on ne maîtrise justement pas la connaissance d’une hypothétique échelle minimale des phénomènes naturels jusqu’à ce point où l’on pourrait les quantifier et les ramener aux règles simples de l’arithmétique et de la logique.
Pourtant la notion d’horloge interne ne perd pas du tout de sa pertinence même si elle n’est pas réellement implémentée en tant que telle dans le programme. En fait, c’est la notion d’échéancier qui va identifier le fonctionnement du programme au battement d’une horloge interne. Dans un échéancier, on peut faire paraître des tops d’horloge réels. C’est la simulation dirigée par événements qui permet cela. Le temps de la simulation est alors géré par une « liste linéaire d’événements », selon l’expression de Blaise 1903 . Mais comment simule-t-on le traitement simultané de plusieurs événements ? Lorsque plusieurs événements peuvent avoir lieu en même temps, ils s’appellent et se succèdent dans l’échéancier, sans modification de leur champ « date » dans la liste des définitions de leurs attributs. Leur ordre d’apparition, invisible à l’utilisateur, dépend donc de la manière dont on balaie l’échéancier 1904 .
Le choix de la gestion du temps étant fait, il convient de mettre en œuvre soit une approche événement, soit une approche processus pour le « noyau de synchronisation » 1905 . Dans le premier cas, le noyau de synchronisation a pour tâche essentielle d’ordonnancer les événements suivant leurs dates absolues dans le temps virtuel. Dans le second cas, la simulation est centrée sur la notion de processus. Elle figure un ensemble de processus progressant parallèlement dans le temps 1906 . Blaise fait le choix d’une « voie intermédiaire entre un noyau basé sur la notion d’événement et un noyau basé sur la notion de processus » 1907 . Il ne dispose pas en effet d’un langage de programmation de processus du type ModSim II, QNAP2 ou Simula67 1908 qui tous émanent de la programmation orientée objet, encore balbutiante. La programmation d’une telle solution resterait de toute façon difficile. Le choix de Blaise est donc justifié par la limitation des ressources informatiques disponibles au CIRAD mais aussi par la simplicité de l’implémentation.
[Blaise, F., 1991], p. 75.
[Blaise, F., 1991], p. 75.
Pour plus de précision, voir [Coquillard, P. et Hill, D., 1997], pp. 133-145.
[Blaise, F., 1991], p. 77.
Ces réflexions d’ordre épistémologique sur l’existence d’un « module », c’est-à-dire sur la capacité d’une séquence élémentaire d’un processus naturel à rythmer toutes les autres qui y participent fait l’objet d’une remarque importante de [Coquillard, P. et Hill, D., 1997], p. 136 : « Lorsque le rapport entre l’échelle de temps des occurrences d’événements et le pas de temps sélectionné est très variable, il est intéressant d’opter pour une gestion du temps dirigée par les événements. » Autrement dit, il faut renoncer à la simulation dirigée par horloge. Cela semble être une limitation conceptuelle pour la production de modèles globaux à changements d’échelles. Voici comment ces auteurs définissent l’approche par événements : « Avec une gestion du temps dirigée par les événements, le temps virtuel va progresser d’une date d’occurrence d’événements à une autre. Il n’y a plus de recherche des événements à traiter entre l’instant t et t + (pas de temps), mais au contraire, il faut gérer un échéancier qui stocke les événements ordonnés chronologiquement. Avec cette approche, lorsque le modèle connaît une longue période d’inactivité, la simulation passe directement au prochain événement significatif », ibid., p. 136. Pour résumer, nous dirions que, dans une simulation guidée par les événements, c’est l’ordre qui crée le temps et non le temps qui crée l’ordre.
[Blaise, F., 1991], p. 76.
En 1978, dans un même contexte de simulation de formes biologiques, Pauline Hogeweg avait déjà fait face à un problème similaire : le faible réalisme du synchronisme parfait des règles des automates cellulaires. Sur une idée qui lui avait été suggérée par l’informaticien et modélisateur américain Bernard P. Zeigler, elle avait proposé de désynchroniser les L-systèmes ou les automates cellulaires (de type Ulam) en ne conservant, dans les meilleurs des cas, que des synchronismes locaux. L’approche par événements proposée par Zeigler dès 1976 lui semblait donc aussi d’emblée préférable. Voir [Hogeweg, P., 1978]. Voir également [Coquillard, P. et Hill, D., 1997], p. 160 : « La complexité liée au codage de la concurrence d’acteurs ou d’agents en compétition spatiale au même temps de simulation est souvent passée sous silence. En effet, que le modèle soit réalisé avec un langage de simulation implémentant des co-routines, un langage d’acteurs ou un langage de programmation général, seuls les modèles stochastiques de résolution de cette compétition sont jugés comme sérieux par les experts en simulation et les militaires que les situations de guerre confrontent au même problème. » Ce sont les auteurs qui soulignent. La question est donc ici de savoir dans quel ordre faire traiter les événements dont on considère qu’ils ont lieu en même temps. Car ces différents ordres ne donnent pas toujours des résultats équivalents : ils sont donc eux-mêmes en compétition les uns avec les autres. Dans le cas qui nous occupe, pour le traitement de la gêne entre deux unités de croissance qui pourraient paraître simultanément, se toucher, et donc créer des conflits, Blaise utilise des règles de priorités crédibles (observées) d’un point de vue botanique qui sont fonction de la situation relative et hiérarchique des bourgeons concernés dans la topologie générale de l’arbre. Mais comme il y a tout de même des cas où il n’y a pas de priorité claire, Blaise introduit finalement aussi un aléa dans le parcours de l’échéancier. Voir [Blaise, F., 1991], pp. 123-125 et 175.
Ensemble de procédures qui permettent d’entretenir et de manipuler l’échéancier. Voir [Blaise, F., 1991], p. 76.
Voir [Blaise, F., 1991], p. 77 et [Coquillard, P. et Hill, D., 1997], pp. 136-142.
[Blaise, F., 1991], p. 79.
Ces langages sont cités, avec les références, par [Coquillard, P. et Hill, D., 1997], p. 140. Plus loin, les auteurs commentent : « en conclusion sur la simulation à événements discrets, il faut rappeler que le développement d’un modèle de simulation dans un langage évolué (Fortran, C, C++, Ada, Pascal…) reste parmi les tâches de programmation les plus difficiles. », ibid., p. 144.