Best practice per la descrizione di modelli basati su agenti

Lavoro abbastanza pesantemente in biologia matematica / epidemiologia, dove la maggior parte del lavoro di modellistica / scienza computazionale è ancora dominata da insiemi di ODE, certo a volte insiemi abbastanza elaborati di essi. Uno dei punti di forza di questi modelli è che sono piuttosto facili da descrivere e replicare. Una tabella di valori dei parametri, le stesse equazioni e hai dato a qualcuno tutto ciò di cui hanno bisogno per replicare la tua ricerca nel modo in cui si sentono di implementarla.

Ma i modelli un po 'più complessi hanno iniziato a diventare più popolari. I modelli basati su agenti, in particolare, sembrano sia più difficili da descrivere in una pubblicazione, sia più difficili da replicare, poiché non sono necessariamente perfettamente descritti da una serie di ODE. Ci sono delle linee guida - o semplicemente un'esperienza pratica - dietro la descrizione di questi modelli in modo che i lettori capiscano cosa è successo e li rendano relativamente semplici da replicare?

Non lavoro in quel settore ma ingenuamente penso che ci siano tre parti per una descrizione completa

1. Una descrizione del panorama di dati in cui vivono. Descrivilo in termini di struttura dei dati (grafico (diretto o non indirizzato, ponderato o non ponderato); albero; array; ...) e dei dati associati a ciascun nodo. Prendere nota della gestione di casi speciali come condizioni al contorno periodiche o stato ipotizzato per i vicini al di fuori dell'area di test. Presumibilmente questo ha una connessione abbastanza chiara con il tuo dominio problematico.

2. Una descrizione dello stato interno dell'agente e come prende le decisioni. Ancora una volta, si spera che ciò abbia un'interpretazione ragionevolmente chiara.

3. Una descrizione dei tempi relativi e / o sincronizzazione dell'azione e degli aggiornamenti tra agenti e paesaggio; e tra coppia o gruppi di agenti.

Lo pseudo-codice (o anche il codice reale se non è troppo inquinato con i dettagli di implementazione) aiuterà.

Esiste qualcosa chiamato protocollo ODD (panoramica, progettazione e dettagli), proposto da Volker Grimm e altri per descrivere un modello basato su agenti. Consiste in un elenco di elementi necessari per comprendere il funzionamento di un ABM e mira a rendere più standardizzate le descrizioni di tali modelli.

L'elenco di controllo di ciò che deve essere descritto è costituito da:

Panoramica

1. Scopo
2. Entità, variabili di stato e scale
3. Panoramica e pianificazione del processo

Design

1. Principi di base
2. Emergenza
3. Adattamento
4. obiettivi
5. Apprendimento
6. Predizione
7. Sensing
8. Interazione
9. stocasticità
10. collettivi
11. Osservazione

Dettagli

1. Inizializzazione
2. Dati in ingresso
3. sottomodelli

Maggiori dettagli sono disponibili in

Grimm, V., Berger, U., DeAngelis, DL, Polhill, JG, Giske, J., & Railsback, SR (2010). Il protocollo ODD: una revisione e un primo aggiornamento. Modellistica ecologica, 221, 2760–2768.

Il modo migliore di gran lunga è includere tutto il codice come materiale supplementare. Se possibile, includi anche i file con i relativi semi casuali necessari per ricreare i risultati. Ciò non solo consente alle persone di ricreare i tuoi risultati (di cui potresti non preoccuparti), ma consente anche loro di continuare più facilmente da dove eri rimasto. Ciò consente nuove collaborazioni e citazioni per il tuo lavoro. Sfortunatamente, questo ha la difficoltà di costringerti a ripulire il tuo codice e assicurarti che sia privo di bug. Quindi, è più un ideale di quello che è solito nella pratica. Ma almeno, dovresti archiviare una versione del tuo codice utilizzata per produrre i tuoi risultati, in questo modo se un altro ricercatore richiede il codice, puoi produrlo.

In termini di descrizione nel tuo articolo, mi concentrerei su una descrizione indipendente di alto livello dell'implementazione delle principali novità del modello (questa è la parte pratica che la maggior parte del documento ottiene). Concentrati sulle caratteristiche che cambieranno il risultato qualitativamente se vengono modificate. La maggior parte dei modelli con cui lavoro produce risultati quantitativi, ma le quantità specifiche di solito non sono interessanti, ma solo il comportamento qualitativo (poiché i parametri sono generalmente lontani da quelli osservabili in natura). Pertanto, mi concentro sulla descrizione delle parti del modello, che se cambiate cambierà il comportamento qualitativo del sistema. Se questa mentalità mi costringe a descrivere ogni dettaglio del mio modello fino all'implementazione, allora so che il mio modello non è molto robusto e quindi dovrebbe essere demolito.

Un buon modo per verificare se la descrizione in-paper è sufficiente è chiedere a un amico (o studente) che non ha lavorato su questo progetto con te per descrivere come potrebbero implementare il tuo modello è lo pseudo-codice. Se non si bloccano mentre provano questo (poiché arrivano a uno schizzo di un modello che dovrebbe produrre gli stessi risultati qualitativi), allora sai che hai fatto un buon lavoro di descrizione.