Ce guide comprend trois parties :
BehaviorSpace est un outil logiciel intégré à NetLogo qui doit vous permettre d'expérimenter avec les modèles. Il fait tourner un modèle plusieurs fois de suite en faisant varier systématiquement les réglages du modèle et en enregistrant les résultats de chaque simulation. Ce procédé est parfois appelé « balayages des paramètres » («parameter sweeping»). Il vous permet d'explorer l'« espace » des comportements possibles du modèle et de déterminer quelles sont les combinaisons de réglages qui aboutissent à des comportements intéressants.
La nécessité de ce type d'expérimentations est mise en évidence par les observations suivantes. Les modèles ont souvent de nombreux paramètres réglables, chacun pouvant prendre toute une série de valeurs. Ensemble, ils forment ce qui, en mathématiques, est appelé un espace de paramètres pour le modèle, espace dont les dimensions correspondent au nombre de paramètres réglables et dans lequel chaque point est une combinaison de valeurs. Faire tourner un modèle avec différents réglages (et parfois même avec les mêmes réglages) peut conduire à des comportements radicalement différents du système qui a été modélisé. Ainsi, comment allez-vous savoir quelle configuration de valeurs particulière, ou quels types de configurations, produit le type de comportement qui vous intéresse? Cela revient à la question de savoir avec quel espace de paramètres multi-dimensionnel, parmi tous ceux possibles, votre modèle se comporte le mieux.
Par exemple, supposons que vous vouliez une synchronisation rapide des lucioles dans le modèle "Fireflies". Ce modèle possède quatre curseurs, "numbers", "cycle-length", "flash-length" et "flashes-to-reset" qui ont respectivement 2000, 100, 10 et 3 valeurs possibles. Ce qui signifie qu'il y a 2000 * 100 * 10 * 3 = 600'000 combinaisons de valeurs possibles pour ces curseurs! Essayer toutes ces combinaisons les unes après les autres n'est pas la manière la plus efficace de déterminer laquelle aboutit à la synchronisation la plus rapide.
BehaviorSpace offre un bien meilleur moyen de résoudre ce problème. Si vous spécifiez un sous-ensemble de valeurs possibles pour chaque curseur, il fera tourner le modèle avec toutes les combinaisons possibles de ces valeurs et, durant chaque simulation, enregistrera les résultats. De cette manière, il échantillonne l'espace des paramètres du modèle, non pas de manière exhaustive, mais suffisamment pour que vous puissiez voir les relations qu'il y a entre les différents curseurs et le comportement du système. Une fois toutes les simulations terminées, il génère et enregistre un ensemble de données que vous pouvez ouvrir dans un autre programme tel qu'un tableur, une base de données ou un programme de visualisation scientifique pour l'explorer à votre guise.
En permettant l'exploration de la totalité de l'espace des comportements qu'un modèle peut avoir, BehaviorSpace peut aussi être un puissant assistant au développeur de modèles.
Nous appellerons :
Les anciennes version de NetLogo (avant la 2.0) comprenaient une ancienne version de l'outil BehaviorSpace, version qui était passablement différente de l'actuelle. Elle n'était pas aussi souple dans les types d'expérimentations qu'elle permettait de mener. Mais elle offrait des possibilités d'afficher et d'analyser les résultats des expérimentations, possibilités qui font défaut dans la version actuelle. Avec la version actuelle, il est admis que vous utiliserez d'autres logiciels pour analyser les résultats. Nous espérons réimplanter les capacités d'affichage et d'analyses dans une future version de BehaviorSpace.
Avant d'utiliser BehaviorSpace, ouvrez votre modèle puis sélectionnez "BehaviorSpace" dans le menu "Tools" de NetLogo.
La boîte de dialogue que la commande précédente vient d'ouvrir permet de créer, d'éditer, de dupliquer, de supprimer et de lancer les descriptions d'expérimentations. Les expérimentations sont listées d'après leurs noms et leurs particularités.
Les descriptions des expérimentations sont considérées comme faisant partie du modèle et sont sauvegardées en tant que partie du modèle.
Pour créer une nouvelle expérimentation, pressez le bouton "New".
La boîte de dialogues "Experiment" qui s'affiche permet de spécifier les valeurs des paramètres décrits ci-dessous. Notez que vous ne devez pas toujours tout spécifier, certains champs pouvant être laissés vides ou avec leurs valeurs par défaut, en fonction de vos besoins.
Le champ Experiment name: permet de nommer l'expérimentation. Si le modèle fait l'objet de plusieurs expérimentations, leur donner des nom différents vous permet d'y voir plus clair.
Le champ à défilement Vary variables as follows: (faire varier les variables de la manière suivante) est l'endroit où vous spécifiez quels sont les paramètres à faire varier et quelles valeurs ces paramètres peuvent prendre. Ces variables peuvent être des curseurs (sliders), des commutateurs (switches), des sélecteurs (choosers), ainsi que toute variable globale définie dans le modèle.
Les variables de ce champ peuvent aussi comprendre les paramètres du modèle que sont max-pxcor, min-pxcor, max-pycor et min-pycor, world-width, world-height et random-seed. Ce ne sont, à proprement parler, pas des variables, mais BehaviorSpace vous permet de faire varier leurs valeurs comme si elles en étaient. Modifier les dimensions du monde permet d'explorer les effets de la taille du monde NetLogo sur votre modèle. Toutefois, la spécification de valeurs pour world-width et world-height ne définit pas nécessairement les limites du monde, car la manière dont ces limites sont déplacées dépend de l'emplacement de l'origine du monde. Si l'origine des coordonnées est au centre du monde, BehaviorSpace la laisse au centre du monde de manière à ce que les valeurs world-width ou world-height restent impaires. Si l'une des frontières a la coordonnée zéro, cette frontière restera à zéro et c'est la frontière opposée qui sera déplacée. Par exemple, si vous commencez avec un monde dont min-pxcor = 0 et max-pxcor = 10 et variez world-width de la manière suivante :
["world-width" [11 1 14]]
min-pxcor restera à zéro et max-pxcor prendra les valeurs 11, 12 et 13 pour chacune des simulations. Si aucune de ces conditions n'est vraie, autrement dit si l'origine n'est pas centrée ou si elle n'est pas sur un des bords du monde, vous ne pouvez pas faire varier world-height ou world-width directement, vous devez faire varier max-pxcor, max-pycor, min-pxcor et min-pycor à la place.
Faire varier la valeur transmise à random-seed permet de répéter les simulations en utilisant une amorce connue pour le générateur de nombres aléatoires de NetLogo. Notez que vous avez aussi la possibilité d'utiliser la commande random-seed dans les commandes que vous spécifiez pour l'expérimentation. Pour plus d'informations sur l'amorçage du générateur de nombres aléatoires, voyez la section Nombres aléatoires du Guide de la Programmation.
Pour une variable donnée, vous pouvez spécifier les valeurs à prendre soit en les listant, soit en spécifiant que vous voulez tester toutes les valeurs d'un intervalle donné correspondant à un certain incrément. Par exemple, pour donner à un curseur nommé number toutes les valeurs multiples de 50 entre 100 et 1000, vous devez écrire :
["number" [100 50 1000]]
Ou, pour lui donner seulement les valeurs 100, 200, 400, and 800, vous devez écrire :
["number" 100 200 400 800]
Ici, faites attention avec les crochets. Notez qu'il y a moins de crochets dans le second exemple. Ajouter ou non cette paire de crochets supplémentaires est votre manière de dire à BehaviorSpace si vous lui donnez une liste de valeurs individuelles ou si vous lui spécifiez un intervalle avec un incrément.
Notez également que les doubles guillemets anglais sont obligatoires autour des noms des variables.
Vous pouvez faire varier autant de paramètres que vous voulez, y compris un seul ou même aucun. Tout paramètre que vous ne faites pas varier garde sa valeur actuelle. Ne faire varier aucun paramètre est utile si vous voulez simplement faire plusieurs simulations de suite avec les réglages actuels.
L'ordre dans lequel les variables apparaissent dans le champ déroulant "Vary variables as follows :" détermine l'ordre dans lequel les différentes valeurs seront utilisées au cours de l'expérimentation. Toutes les valeurs d'une variable située plus bas dans la liste seront utilisées avant de passer à la valeur suivante d'une variable située au-dessus. Ainsi, par exemple, si vous faites varier x et y de 1 à 3, l'ordre dans lequel le modèle les utilisera dans les simulations successives sera : x=1 y=1, x=1 y=2, x=1 y=3, x=2 y=1, et ainsi de suite.
Le champ Repetitions: Parfois, le comportement du modèle peut passablement varier d'une simulation à l'autre même si les réglages des paramètres ne changent pas. Si vous voulez faire plusieurs simulations pour chaque combinaison de réglages de paramètres, entrez ici un nombre supérieur à 1 (le nombre de répétitions de la simulation).
Le champ Measure runs using these reporters: est l'endroit où vous spécifiez quelles données vous voulez récolter à chaque simulation. Par exemple, si vous voulez enregistrer comment la population de tortues augmente ou diminue au cours de chaque simulation, vous devez écrire :
count turtles
Vous pouvez spécifier un reporter, ou plusieurs, ou même aucun. Si vous en spécifiez plusieurs, chacun doit se trouver seul sur sa ligne, par exemple :
count frogs
count mice
count birds
Si vous ne spécifiez aucun reporter, la simulation se fait quand même. Cettte manière de faire est utile si vous voulez enregistrer vous-même les résultats, par exemple avec la commande export-world.
Le champ Measure runs at every step: (effectuer les mesures à chaque pas). Normalement, NetLogo mesure les paramètres des simulations à chaque pas en fonction des reporters que vous avez spécifiés dans le champ précédent. Si vous faites de très longues simulations, il est possibles que vous ne vouliez pas toutes les données récoltées. Désactiver cette casepour ne récolter que les données obtenues à la fin de chaque simulation.
Le champs Setup commands: contient les commandes qui seront exécutées au début de chaque simulation. Vous y entrerez typiquement le nom d'une procédure qui initialise le modèle, en général la procédure nommée setup. Mais il est aussi possible d'y mettre d'autres commandes.
Le champ Go commands: contient les commandes qui sont exécutées en boucle (encore et encore) pour faire avancer la simulation au pas suivant. Ce sera typiquement le nom d'une procédure telle que go, mais vous pouvez y mettre toutes les commandes que vous voulez.
Le champ Stop condition: (condition d'arrêt) permet de faire varier la durée des simulations, chaque simulation se terminant quand une condition devient vraie. Par exemple, supposons que vous voulez que chaque simulation tourne jusqu'à ce qu'il n'y ait plus de tortues. Vous devez alors écrire :
not any? turtles
Si vous voulez que la durée de chaque simulation soit toujours la même, laissez simplement ce champ vide.
La simulation peut aussi s'arrêter parce que les commandes du champ "Go commands:" utilisent la commande stop de la même manière qu'elle peut être utilisée pour arrêter l'action d'un bouton "forever" (« pour-toujours »). La commande stop peut être directement utilisée dans les commandes du champs "Go commands" ou placée dans une procédure appelée directement par l'une des commandes de ce champ. (L'idée est que la même procédure go puisse fonctionner aussi bien dans un bouton que dans une expérimentation BehaviorSpace.) Notez que le pas de simulation dans lequel la commande stop est appelée et utilisée est considéré comme n'ayant pas abouti. Il s'ensuit qu'aucun résultat issu de ce pas ne sera enregistré. C'est pourquoi le test d'arrêt devrait toujours être fait au début de la commande go ou de la procédure et non à sa fin.
Le champ Final commands: permet de donner des commandes qui ne devront être exécutées qu'une seule fois, à la fin de la simulation. En général, ce champ est laissé vide, mais vous pourriez l'utiliser pour appeler la commande export-world ou pour enregistrer les résultats de la simulation d'une autre manière.
Le champ Time limit: permet de fixer une durée maximale à ne pas dépasser pour chaque simulation. (L'unité de temps est le pas (tick) de simulation). Si vous ne voulez pas fixer ce temps limite, mais désirez que la durée des simulations soit plutôt contrôlée par une condition d'arrêt, entrez 0 dans ce champ.
Une fois les réglages de votre expérimentation terminés, pressez le bouton "OK" puis le bouton "Run".
Une boîte de dialogues vous demandera alors de sélectionner les formats dans lesquels les données de l'expérimentation seront sauvegardées. Les données sont récoltées pour chaque intervalle, c'est-à-dire pour chaque simulation ou pas de simulation en fonction des réglages de l'option "Measure runs at every step".
Le format "Table" place les données de chaque série de mesures dans une ligne, avec chaque mesure dans sa propre colonne. Les données de la table sont écrites dans le fichier de sortie à la fin de chaque simulation. Il en résulte que les données de chaque simulation sont disposées verticalement les unes à la suite des autres. Ce format est surtout destiné a un traitement automatique des données suite à l'importation du fichier obtenu dans une base de données ou un logiciel de statistique.
Le format "Spreadsheet" (feuille de calcul) calcule et enregistre les valeurs minimale, moyenne, maximale et finale de chaque paramètre mesuré (reporter), chacun d'eux occupant une ligne. En-dessous, les valeurs mesurées à chaque pas de la simulation sont disposées en ligne (un pas par ligne), chaque valeur occupant la colonne de son reporter. Les données de chaque simulation sont disposées les unes à côté des autres. Les données dans le format "Spreadsheet" sont plus facilement lisibles et interprétables par le cerveau humain que les données au format "Table", surtout si elles ont été importée dans un tableur.
Notez toutefois que les données au format "Spreadsheet" ne sont pas sauvegardées dans le fichier des résultats avant la fin de l'expérimentation (contrairement à celles au format "Table"). Du fait que ces données sont conservées en mémoire jusqu'à la fin du travail, de très longues expérimentations peuvent conduire à un débordement de mémoire. Et tout ce qui peut interrompre l'expérimentation en cours, comme une erreur d'exécution, un débordement de mémoire, un crash du système ou une coupure de l'alimentation conduira a une perte irrémédiable de toutes les données recueillies. Pour les longues expérimentations, vous aurez tout intérêt a utiliser conjointement les formats "Spreadsheet" et "Table" de manière à ce que si quelque chose de fâcheux survient, il vous restera au moins une table des résultats partiels.
Après sélection du format des données en sortie, BehaviorSpace vous demandera le nom du fichier dans lequel sauvegarder les résultats. Le nom par défaut se termine en .csv. Vous pouvez changer ce nom si vous le désirez, mais vous devez conserver l'extension .csv qui indique que le fichier est au format CSV pour Comma Separated Values (valeurs séparées par des virgules). C'est un format de données de type texte lisible aussi bien par n'importe quel éditeur de texte que par la majorité des tableurs et des gestionnaires de bases de données.
S'affiche alors la boîte de dialogues intitulée "Running Experiment". Cette fenêtre vous tient au courant du déroulement de l'expérimentation en indiquant combien de simulations ont déjà été faites et combien de temps s'est déjà écoulé depuis de début de l'expérimentation. Si vous aviez spécifié un ou des reporters pour mesurer des données fournies par les simulations et si vous aviez laissé la coche de sélection dans la case "Measure runs at every step", vous verrez un graphique affichant l'évolution de ces valeurs au cours de chaque simulation.
Vous pouvez également observer le déroulement de la simulation dans la fenêtre NetLogo principale. (Si la fenêtre "Running Experiment" cache une partie de la fenêtre principale, il suffit de la mettre ailleurs sur l'écran.) La Vue et les traceurs de courbes sont mis à jours tout au long de chaque simulation. Si vous n'avez pas besoin de voir ces mises à jours, utilisez alors les cases à cocher placées au bas de la fenêtre "Running Experiment" pour les désactiver. Cette inactivité d'affichage accélère fortement le calcul et donc le déroulement de la simulation.
Si vous voulez interrompre l'expérimentation en cours de route, pressez le bouton "Abort" (Abandonner) placé en bas à droite. Mais notez quand même que vous perdez alors tous les résultats qui ont été collectés dans le format "Spreadsheet" jusqu'à ce moment-là. Les résultats collectés dans le format "Table" étant enregistrés à la fin de chaque simulation, vous ne perdez que ceux de la simulation en cours.
Une fois toutes les simulations terminées, le programme sauvegarde tout ce qu'il doit, ferme les fichiers et se termine automatiquement : l'expérimentation est terminée. Il n'y a « plus qu'a » interpréter les résultats.
Il est possible de faire tourner des expérimentations BehaviorSpace « sans-tête » (headless), c'est-à-dire à partir de la ligne de commande et sans aucune interface utilisateur graphique (GUI). Ce qui est utile pour automatiser les simulations sur une seule machine ou sur un ensemble de machines.
Aucune connaissance en programmation Java n'est nécessaire. La description de l'expérimentation peut être créée dans l'interface graphique et exécutée plus tard à partir de la ligne de commandes, ou, si vous préférez, vous pouvez créer ou éditer directement cette description en utilisant le langage XML.
Il est plus facile de créer d'abord vos descriptions d'expérimentations dans l'interface graphique car elles seront sauvegardées en tant que partie du modèle. Voici un exemple d'utilisation de la ligne de commande pour lancer et exécuter une expérimentation qui a été sauvegardée dans un modèle :
java -server -Xmx1024M -cp NetLogo.jar \ org.nlogo.headless.HeadlessWorkspace \ --model Fire.nlogo \ --experiment experiment1
(Pour que cette méthode fonctionne, le fichier NetLogo.jar doit être présent avec le sous-répertoire lib contenant les bibliothèques nécessaires. Aussi bien le fichier NetLogo.jar que le sous-répertoire lib font parties de NetLogo.)
Une fois l'expérimentation nommée terminée, les résultats sont envoyés à la sortie standard dans un format de feuille de calculs, tel que CSV. (Pour modifier ce réglage par défaut, voir ci-dessous.)
Quand la classe HeadlessWorkspace fonctionne comme une application, la propriété système java.awt.headless est forcée à true. Ceci indique à Java de fonctionner en mode headless, ce qui permet à NetLogo de tourner sur des machines ne disposant pas d'un affichage graphique (donc de type terminal).
Notez l'utilisation du drapeau -server pour dire à Java d'optimiser les performances pour des applications de type « serveur ». Nous recommandons l'utilisation de ce drapeau pour de meilleures performances dans la plupart des situations.
Notez aussi l'utilisation de -Xmx pour spécifier une taille mémoire (heap) maximale de un gigabyte. Si vous ne spécifiez par une mémoire maximale, vous n'obtenez que la taille par défaut de la machine java virtuelle, qui peut être inhabituellement petite. (Un gigabyte est une taille arbitraire qui devrait être bien assez grande pour la plupart des modèles, mais vous pouvez spécifier une limite maximale différente si vous le voulez.)
L'argument --model est utilisé pour spécifier le fichier du modèle que vous voulez ouvrir.
L'argument --experiment est utilisé pour spécifier le nom de l'expérimentation que vous voulez mener. (Ce nom lui a été donné au moment où vous aviez créé la description de cette expérimentation dans l'interface utilisateur.)
Voici un autre exemple montrant l'utilisation d'autres arguments, cette fois en option :
java -server -Xmx1024M -cp NetLogo.jar \ org.nlogo.headless.HeadlessWorkspace \ --model Fire.nlogo \ --experiment experiment2 \ --max-pxcor 100 \ --min-pxcor -100 \ --max-pycor 100 \ --min-pycor -100 \ --no-results
Noter l'utilisation des arguments optionnels --max-pxcor, --max-pycor, etc., pour spécifier une taille de monde différente de celle qui avait été sauvegardée avec le modèle. (La description de l'expérimentation peut aussi spécifier des valeurs pour les dimensions du monde; si ces dimensions sont déjà spécifiées dans l'expérimentation, il n'est pas nécessaire de les re-spécifier dans la ligne de commande.)
Noter également l'utilisation de l'argument optionnel --no-results pour indiquer qu'il n'y a pas à générer de sortie de données. Cette précision est utile si les descriptions de l'expérimentation génèrent toutes les sorties de données dont vous avez besoin d'une autre manière, par exemple par exportation de fichiers world ou par écriture dans un fichier texte.
Voici encore un autre exemple :
java -server -Xmx1024M -cp NetLogo.jar \ org.nlogo.headless.HeadlessWorkspace \ --model Fire.nlogo \ --experiment experiment2 \ --table table-output.csv \ --spreadsheet spreadsheet-output.csv
L'argument optionnel --table <filename> spécifie que la sortie doit être générée dans le format "Table" et écrite dans le fichier donné au format CSV. Si - est mis à la place du nom du fichier, les données en sortie seront envoyées dans le flux de sortie standard du système. Les données de type "Table" sont écrites comme elles sont générées, à la fin de chaque simulation.
L'argument optionnel --spreadsheet <filename> spécifie que la sortie doit être générée dans le format "Spreadsheet" et écrite dans le fichier donné au format CSV. Si - est mis à la place du nom du fichier, les données en sortie seront envoyées dans le flux de sortie standard du système. Les données de type "Spreadsheet" ne sont écrites (donc sauvegardées) que lorsque toutes les simulations sont terminées, autrement dit à la fin de l'expérimentation.
Notez qu'il est parfaitement possible de spécifier à la fois --table et --spreadsheet, et si vous le faites, les deux types de sorties seront générées.
Le comportement de sortie par défaut, quand aucun format de sortie n'est spécifié, est d'envoyer les données sous forme de table dans le flux de sortie standard du système.
Voici enfin un dernier exemple qui montre comment faire exécuter une expérimentation qui a été enregistrée dans un fichier XML séparé plutôt que dans le fichier du modèle :
java -server -Xmx1024M -cp NetLogo.jar \ org.nlogo.headless.HeadlessWorkspace \ --model Fire.nlogo \ --setup-file fire-setups.xml \ --experiment experiment3
Si le fichier XML contient plus d'une description d'expérimentation, il est nécessaire d'utiliser l'argument --experiment pour spécifier le nom de la description à utiliser.
La section suivante montre comment créer des fichiers de descriptions d'expérimentations en utilisant le langage XML.
Nous n'avons pour le moment pas encore de documentation détaillée sur la programmation de descriptions d'expérimentations en XML, mais si vous êtes déjà quelque peu familiarisés avec ce langage, les quelques indications suivantes devraient être suffisantes pour vous permettre de commencer.
La structure des descriptions d'expérimentations de BehaviorSpace en XML est déterminée par un fichier "Document Type Definition" (DTD). Ce DTD est stocké dans le fichier NetLogo.jar en tant que fichier system/behaviorspace.dtd. (Les fichiers JAR étant aussi des fichiers compressés zip, vous pouvez extraire le fichier DTD du fichier JAR avec l'utilitaire Java jar ou avec tout programme capable de décompresser les fichiers zip.)
La méthode la plus facile pour voir à quoi ressemble une description d'expérimentation en XML est d'un créer quelques-unes dans l'interface graphique de BehaviorSpace, de sauvegarder le modèle puis d'examiner le fichier .nlogo résultant dans un éditeur de texte. Les descriptions d'expérimentations se trouvent vers la fin du fichier .nlogo, dans une section qui commence et se termine par une balise experiments. Par exemple :
<experiments>
<experiment name="experiment" repetitions="10" runMetricsEveryStep="true">
<setup>setup</setup>
<go>go</go>
<exitCondition>not any? fires</exitCondition>
<metric>burned-trees</metric>
<enumeratedValueSet variable="density">
<value value="40"/>
<value value="0.1"/>
<value value="70"/>
</enumeratedValueSet>
</experiment>
</experiments>
Cet exemple ne comporte qu'une seule description d'expérimentation, mais vos pouvez en mettre autant que vous le voulez entre les deux balises experiments.
En combinant l'observation du fichier DTD et celle des exemples que vous avez créés dans l'interface graphique, vous devriez pouvoir comprendre comment utiliser les différentes balises pour spécifier différents types d'expérimentations. Le ficher DTD spécifie quelles balises sont obligatoires et quelles balises sont optionnelles, lesquelles peuvent être répétées et lesquelles ne doivent apparaître qu'une seule fois, et ainsi de suite.
Quand les descriptions d'expérimentations en XML sont incluses dans le fichier du modèle, cette section ne doit pas commencer avec les en-têtes XML habituelles car le fichier .nlogo n'est pas un fichier XML dans sa totalité. Par contre, si vous gardez les descriptions d'expérimentations dans leur propre fichier, séparé du fichier du modèle, l'extension de nom de ce fichier devra être .xml et non pas .nlogo, et vous devrez le commencer par ses propres en-têtes XML, comme celles qui suivent :
<?xml version="1.0" encoding="us-ascii"?> <!DOCTYPE experiments SYSTEM "behaviorspace.dtd">
La deuxième ligne doit être écrite exactement comme montrée ci-dessus. Dans la première ligne, vous pouvez spécifier un autre encodage de caractères que us-ascii, tel que UTF-8 par exemple, mais souvenez-vous que NetLogo ne supporte pas les caractères non-ASCII (entres autres les caractères accentués) dans la plupart des situations. Il s'ensuit que la spécification d'un encodage différent peut se révéler peu judicieux.
Si BehaviorSpace ne peut satisfaire vos attentes, une alternative possible consiste à utiliser notre Controlling API qui vous permet d'écrire du code Java pour contrôler NetLogo. L'API vous permet de faire tourner des expérimentations BehaviorSpace à partir de code Java, et vous pouvez même écrire du code personnalisé qui contrôle encore plus directement NetLogo pour lui faire faire des choses qui ressemblent à ce que lui fait faire BehaviorSpace. Consultez la section Controlling du Manuel de l'utilisateur pour en savoir plus sur ces deux possibilités.
BehaviorSpace est encore en cours de développement. Nous aimerions avoir votre avis concernant des fonctionnalités supplémentaires qui pourraient être utiles pour vos recherches et travaux. Écrivez-nous à l'adresse feedback@ccl.northwestern.edu.