Meilleures pratiques pour décrire les modèles basés sur des agents

Je travaille assez fortement en biologie mathématique / épidémiologie, où la plupart des travaux de modélisation / science informatique sont encore dominés par des ensembles d'OD, certes parfois assez élaborés. L'un des avantages de ces modèles est qu'ils sont assez faciles à décrire et à reproduire. Un tableau des valeurs des paramètres, et les équations elles-mêmes et vous avez donné à quelqu'un tout ce dont il a besoin pour reproduire votre recherche de la manière dont il a envie de la mettre en œuvre.

Mais les modèles un peu plus complexes ont commencé à devenir plus populaires. Les modèles basés sur les agents, en particulier, semblent à la fois plus difficiles à décrire dans une publication et plus difficiles à reproduire, car ils ne sont pas nécessairement parfaitement décrits par un ensemble d'ODE. Existe-t-il des lignes directrices - ou simplement une expérience pratique - pour décrire ces modèles de manière à ce que les lecteurs comprennent ce qui s'est passé et les rendent relativement simples à reproduire?

Je ne travaille pas dans cette entreprise mais naïvement, je pense qu'il y a trois parties dans une description complète

1. Une description du paysage de données dans lequel ils vivent. Décrivez-le en termes de structure de données (graphique (dirigé ou non, pondéré ou non pondéré); arbre; tableau; ...) et les données associées à chaque nœud. Prenez note de la gestion des cas spéciaux tels que les conditions aux limites périodiques ou l'état supposé pour les voisins en dehors de la région de test. Vraisemblablement, cela a une connexion assez claire avec votre domaine problématique.

2. Une description de l'état interne de l'agent et comment il prend des décisions. Encore une fois, j'espère que cela a une interprétation assez claire.

3. Une description du calendrier relatif et / ou de la synchronisation de l'action et des mises à jour entre les agents et le paysage; et entre une paire ou des groupes d'agents.

Un pseudo-code (ou même du vrai code s'il n'est pas trop pollué par les détails d'implémentation) vous aidera.

Il existe quelque chose appelé le protocole ODD (Overview, Design, and Details), proposé par Volker Grimm et d'autres pour décrire un modèle basé sur un agent. Il consiste en une liste d'éléments nécessaires à la compréhension du fonctionnement d'un GAB et vise à uniformiser les descriptions de ces modèles.

La liste de contrôle de ce qui doit être décrit comprend:

Aperçu

1. Objectif
2. Entités, variables d'état et échelles
3. Aperçu du processus et planification

Conception

1. Principes de base
2. Émergence
3. Adaptation
4. Objectifs
5. Apprentissage
6. Prédiction
7. Détection
8. Interaction
9. Stochasticité
10. Collectifs
11. Observation

Détails

1. Initialisation
2. Des données d'entrée
3. Sous-modèles

Plus de détails peuvent être trouvés dans

Grimm, V., Berger, U., DeAngelis, DL, Polhill, JG, Giske, J., & Railsback, SR (2010). Le protocole ODD: un examen et une première mise à jour. Modélisation écologique, 221, 2760–2768.

La meilleure façon est de loin d'inclure tout votre code comme matériel supplémentaire. Si possible, incluez également des fichiers avec les graines aléatoires pertinentes nécessaires pour recréer vos résultats. Non seulement cela permet aux gens de recréer vos résultats (ce qui peut ne pas vous intéresser), mais cela leur permet également de continuer plus facilement là où vous vous étiez arrêté. Cela permet de nouvelles collaborations et citations à votre travail. Malheureusement, cela vient avec la difficulté de vous forcer à nettoyer votre code et à vous assurer qu'il est exempt de bogues. C'est donc plus un idéal que ce qui est habituel dans la pratique. Mais à tout le moins, vous devez archiver une version de votre code utilisée pour produire vos résultats, de cette façon, si un autre chercheur demande du code, vous pouvez le produire.

En termes de description dans votre article, je me concentrerais alors sur une description de haut niveau, indépendante de la mise en œuvre, des principales caractéristiques nouvelles du modèle (c'est la partie pratique que le meilleur article réalise). Concentrez-vous sur les fonctionnalités qui changeront le résultat qualitativement si elles sont modifiées. La plupart des modèles avec lesquels je travaille produisent des résultats quantitatifs, mais les quantités spécifiques ne sont généralement pas intéressantes, seulement le comportement qualitatif (car les paramètres sont généralement loin de ceux observables dans la nature). Ainsi, je me concentre sur la description des parties du modèle qui, si elles sont modifiées, changeront le comportement qualitatif du système. Si cet état d'esprit m'oblige à décrire les moindres détails de mon modèle jusqu'à l'implémentation, alors je sais que mon modèle n'est pas très robuste et doit donc être abandonné.

Un bon moyen de tester si votre description sur papier est suffisante, est de demander à un ami (ou étudiant) qui n'a pas travaillé sur ce projet avec vous de décrire comment ils pourraient implémenter votre modèle est un pseudo-code. S'ils ne se coincent pas en essayant cela (car ils arrivent à un croquis d'un modèle qui devrait produire les mêmes résultats qualitatifs), alors vous savez que vous avez fait un bon travail de description.