Trabalho bastante pesadamente em biologia / epidemiologia matemática, onde a maior parte do trabalho de modelagem / ciência computacional ainda é dominada por conjuntos de EDOs, reconhecidamente, às vezes, conjuntos bastante elaborados deles. Um dos pontos positivos desses modelos é que eles são fáceis de descrever e replicar. Uma tabela de valores de parâmetros, as próprias equações e você forneceu a alguém tudo o que eles precisam para replicar sua pesquisa da maneira que eles quiserem implementá-la.
Mas modelos um pouco mais complexos começaram a se tornar mais populares. Modelos baseados em agentes, em particular, parecem ser mais difíceis de descrever em uma publicação e mais difíceis de replicar, porque não são necessariamente descritos perfeitamente por um conjunto de ODEs. Existem diretrizes - ou apenas experiência prática - por trás da descrição desses modelos de forma que os leitores entendam o que aconteceu e os tornem relativamente simples de replicar?
fonte
Respostas:
Eu não trabalho nesse ramo, mas ingênuo acho que existem três partes para uma descrição completa
Uma descrição do cenário de dados em que vivem. Descreva isso em termos da estrutura de dados (gráfico (direcionado ou não direcionado, ponderado ou não ponderado); árvore; matriz; ...) e os dados associados a cada nó. Anote tratamento especial de caso, como condições periódicas de contorno ou estado assumido para vizinhos fora da região de teste. Presumivelmente, isso tem uma conexão bastante clara com o domínio do problema.
Uma descrição do estado interno do agente e como ele toma decisões. Novamente, espero que isso tenha uma interpretação razoavelmente clara.
Uma descrição do momento relativo e / ou sincronização das ações e atualizações entre os agentes e o cenário; e entre pares ou grupos de agentes.
Pseudo-código (ou mesmo código real, se não estiver muito poluído com detalhes de implementação) ajudará.
fonte
Existe algo chamado protocolo ODD (Overview, Design, and Details), proposto por Volker Grimm e outros para descrever um modelo baseado em agente. Consiste em uma lista de elementos necessários para a compreensão do funcionamento de um ABM e visa tornar as descrições desses modelos mais padronizadas.
A lista de verificação do que deve ser descrito consiste em:
Visão geral
Projeto
Detalhes
Mais detalhes podem ser encontrados em
Grimm, V., Berger, U., DeAngelis, DL, Polhill, JG, Giske, J., & Railsback, SR (2010). O protocolo ODD: uma revisão e primeira atualização. Ecological Modeling, 221, 2760-2768.
fonte
A melhor maneira, de longe, é incluir todo o seu código como material suplementar. Se possível, inclua também arquivos com as sementes aleatórias relevantes necessárias para recriar seus resultados. Isso não apenas permite que as pessoas recriem seus resultados (com os quais você talvez não se importe), mas também permite que elas continuem mais facilmente de onde você parou. Isso permite novas colaborações e citações para o seu trabalho. Infelizmente, isso ocorre com a dificuldade de forçá-lo a limpar seu código e garantir que não haja erros. Portanto, é mais um ideal do que o habitual na prática. Mas, no mínimo, você deve arquivar uma versão do seu código usada para produzir seus resultados, assim, se outro pesquisador solicitar código, você poderá produzi-lo.
Em termos de descrição em seu artigo, eu me concentraria em uma descrição independente de implementação de alto nível dos principais recursos novos do modelo (esta é a parte prática que o melhor artigo consegue). Concentre-se nos recursos que alterarão qualitativamente o resultado se eles forem aprimorados. Muitos modelos com os quais trabalho produzem resultados quantitativos, mas as quantidades específicas geralmente não são de interesse, apenas o comportamento qualitativo (uma vez que os parâmetros geralmente estão longe dos observáveis na natureza). Assim, concentro-me em descrever as partes do modelo que, se alteradas, mudarão o comportamento qualitativo do sistema. Se essa mentalidade me forçar a descrever todos os detalhes do meu modelo até a implementação, então eu sei que meu modelo não é muito robusto e, portanto, deve ser descartado.
Uma boa maneira de testar se sua descrição em papel é suficiente é pedir a um amigo (ou aluno) que não trabalhou nesse projeto com você para descrever como eles podem implementar seu modelo com pseudo-código. Se eles não ficarem presos ao tentar fazer isso (como eles chegam a um esboço de um modelo que deve produzir os mesmos resultados qualitativos), então você sabe que fez um bom trabalho de descrição.
fonte