Best Practices zur Beschreibung von agentenbasierten Modellen

Ich arbeite ziemlich stark in der mathematischen Biologie / Epidemiologie, wo der Großteil der Modellierungs- / Computerwissenschaftsarbeit immer noch von Sätzen von ODEs dominiert wird, zugegebenermaßen manchmal ziemlich ausgefeilten Sätzen von ihnen. Ein Pluspunkt dieser Modelle ist, dass sie sich recht einfach beschreiben und nachbilden lassen. Eine Tabelle mit Parameterwerten sowie die Gleichungen selbst und Sie haben jemandem alles gegeben, was er benötigt, um Ihre Forschung auf die Art und Weise zu replizieren, wie er sie implementieren möchte.

Etwas komplexere Modelle erfreuen sich jedoch zunehmender Beliebtheit. Insbesondere agentenbasierte Modelle scheinen sowohl schwieriger in einer Publikation zu beschreiben als auch schwieriger zu replizieren zu sein, da sie von einer Reihe von ODEs nicht unbedingt perfekt beschrieben werden. Gibt es Richtlinien - oder nur praktische Erfahrungen -, die es ermöglichen, diese Modelle so zu beschreiben, dass die Leser verstehen, was passiert ist, und sie relativ einfach zu replizieren?

Ich arbeite nicht in diesem Geschäft, aber naiv denke ich, dass es drei Teile zu einer vollständigen Beschreibung gibt

1. Eine Beschreibung der Datenlandschaft, in der sie leben. Beschreiben Sie diese anhand der Datenstruktur (Diagramm (gerichtet oder ungerichtet, gewichtet oder ungewichtet); Baum; Array; ...) und der Daten, die jedem Knoten zugeordnet sind. Beachten Sie die Sonderfälle, wie z. B. periodische Randbedingungen oder den angenommenen Zustand für Nachbarn außerhalb der Testregion. Vermutlich hat dies einen ziemlich klaren Zusammenhang mit Ihrer Problemdomäne.

2. Eine Beschreibung des internen Status des Agenten und der Art und Weise, wie Entscheidungen getroffen werden. Auch dies hat hoffentlich eine einigermaßen klare Interpretation.

3. Eine Beschreibung des relativen Zeitpunkts und / oder der Synchronisation von Aktionen und Aktualisierungen zwischen den Agenten und der Landschaft; und zwischen Paaren oder Gruppen von Agenten.

Pseudo-Code (oder sogar echter Code, wenn er nicht mit Implementierungsdetails verschmutzt ist) hilft.

Es gibt ein sogenanntes ODD-Protokoll (Overview, Design and Details), das von Volker Grimm und anderen zur Beschreibung eines agentenbasierten Modells vorgeschlagen wurde. Es besteht aus einer Liste von Elementen, die zum Verständnis der Funktionsweise eines ABM erforderlich sind, und zielt darauf ab, die Beschreibungen solcher Modelle standardisierter zu gestalten.

Die Checkliste von dem, was beschrieben werden muss, besteht aus:

Überblick

1. Zweck
2. Entitäten, Zustandsvariablen und Skalen
3. Prozessübersicht und -terminierung

Design

1. Grundprinzipien
2. Entstehung
3. Anpassung
4. Ziele
5. Lernen
6. Prognose
7. Wahrnehmung
8. Interaktion
9. Stochastizität
10. Kollektive
11. Überwachung

Einzelheiten

1. Initialisierung
2. Eingabedaten
3. Submodelle

Weitere Details finden Sie in

Grimm, V., Berger, U., DeAngelis, DL, Polhill, JG, Giske, J. & Railsback, SR (2010). Das ODD-Protokoll: eine Überprüfung und erste Aktualisierung. Ecological Modeling, 221, 2760–2768.

Der weitaus beste Weg ist, Ihren gesamten Code als ergänzendes Material aufzunehmen. Fügen Sie nach Möglichkeit auch Dateien mit den relevanten zufälligen Ausgangswerten hinzu, die für die Neuerstellung Ihrer Ergebnisse erforderlich sind. Auf diese Weise können die Benutzer nicht nur Ihre Ergebnisse neu erstellen (die Sie möglicherweise nicht interessieren), sondern auch einfacher dort weitermachen, wo Sie aufgehört haben. Dies ermöglicht neue Kollaborationen und Zitierungen für Ihre Arbeit. Leider ist dies mit der Schwierigkeit verbunden, Sie zu zwingen, Ihren Code zu bereinigen und sicherzustellen, dass er fehlerfrei ist. Es ist also eher ein Ideal als das, was in der Praxis üblich ist. Zumindest sollten Sie jedoch eine Version Ihres Codes archivieren, die zur Erstellung Ihrer Ergebnisse verwendet wird. Wenn Sie also von einem anderen Forscher nach Code gefragt werden, können Sie diesen erstellen.

In Bezug auf die Beschreibung in Ihrem Papier würde ich mich dann auf eine umfassende, implementierungsunabhängige Beschreibung der wichtigsten neuartigen Merkmale des Modells konzentrieren (dies ist der praktische Teil, den das meiste gute Papier erreicht). Konzentrieren Sie sich auf die Funktionen, die das Ergebnis qualitativ verändern, wenn sie optimiert werden. Die meisten Modelle, mit denen ich arbeite, liefern quantitative Ergebnisse, aber die spezifischen Größen sind normalerweise nicht von Interesse, nur das qualitative Verhalten (da die Parameter normalerweise weit von denen entfernt sind, die in der Natur beobachtet werden können). Daher konzentriere ich mich darauf, die Teile des Modells zu beschreiben, die, wenn sie geändert werden, das qualitative Verhalten des Systems verändern. Wenn diese Denkweise mich zwingt, jedes Detail meines Modells bis zur Implementierung zu beschreiben, weiß ich, dass mein Modell nicht sehr robust ist und daher verschrottet werden sollte.

Ein guter Weg, um zu testen, ob Ihre Beschreibung in Papierform ausreicht, besteht darin, einen Freund (oder Studenten), der nicht mit Ihnen an diesem Projekt gearbeitet hat, zu bitten, zu beschreiben, wie Ihr Modell möglicherweise im Pseudocode implementiert wird. Wenn sie dabei nicht hängen bleiben (wie in der Skizze eines Modells, das die gleichen qualitativen Ergebnisse liefern sollte), wissen Sie, dass Sie eine gute Beschreibung geleistet haben.