Лучшие практики для описания агентных моделей

Я довольно много работаю в области математической биологии / эпидемиологии, где в большинстве работ по моделированию / вычислительной науке все еще преобладают наборы ODE, правда, иногда довольно сложные их наборы. Одним из плюсов этих моделей является то, что их довольно легко описать и воспроизвести. Таблица значений параметров, а также сами уравнения, и вы дали кому-то все, что им нужно для того, чтобы воспроизвести ваше исследование так, как он хочет реализовать.

Но несколько более сложные модели начали становиться более популярными. В частности, модели на основе агентов, как представляется, сложнее описать в публикации и труднее воспроизвести, потому что они не обязательно идеально описываются набором ODE. Есть ли какие-либо руководящие принципы - или просто практический опыт - за описанием этих моделей таким образом, чтобы читатели понимали, что произошло, и делали их относительно простыми для воспроизведения?

Я не работаю в этом бизнесе, но наивно думаю, что есть три части для полного описания

1. Описание ландшафта данных, в котором они живут. Опишите его в терминах структуры данных (график (направленный или ненаправленный, взвешенный или невзвешенный); дерево; массив; ...) и данные, связанные с каждым узлом. Запишите особый случай обработки, такой как периодические граничные условия или предполагаемое состояние для соседей за пределами тестовой области. Предположительно это имеет довольно четкую связь с вашей проблемной областью.

2. Описание внутреннего состояния агента и того, как он принимает решения. Опять же, надеюсь, это имеет достаточно четкую интерпретацию.

3. Описание относительного времени и / или синхронизации действий и обновлений между агентами и ландшафтом; и между парой или группами агентов.

Псевдокод (или даже реальный код, если он не слишком загрязнен деталями реализации) поможет.

Существует нечто, называемое протоколом ODD (Overview, Design и Details), предложенное Volker Grimm и другими для описания модели на основе агентов. Он состоит из списка элементов, необходимых для понимания функционирования ПРО, и призван сделать описания таких моделей более стандартизированными.

Контрольный список того, что должно быть описано, состоит из:

обзор

1. Цель
2. Объекты, переменные состояния и масштабы
3. Обзор процесса и планирование

дизайн

1. Основные принципы
2. появление
3. Приспособление
4. Цели
5. Учусь
6. прогнозирование
7. считывание
8. взаимодействие
9. Стохастичность
10. Коллективы
11. наблюдение

Детали

1. Инициализация
2. Входные данные
3. Подмодели

Более подробную информацию можно найти в

Гримм В., Бергер У., ДеАнджелис Д.Л., Полхилл Дж.Г., Гиске Дж. И Рейлсбек С.Р. (2010). Протокол ODD: обзор и первое обновление. Экологическое моделирование, 221, 2760–2768.

На сегодняшний день лучший способ - включить весь ваш код в качестве дополнительного материала. Если возможно, также включите файлы с соответствующими случайными семенами, необходимыми для воссоздания ваших результатов. Это не только позволяет людям воссоздавать ваши результаты (о которых вы можете не беспокоиться), но и позволяет им легче продолжать работу с того места, где вы остановились. Это позволяет новым сотрудникам и ссылкам на вашу работу. К сожалению, это связано с трудностью принуждения вас очистить код и убедиться, что в нем нет ошибок. Следовательно, это больше идеал, чем обычно на практике. Но, по крайней мере, вы должны заархивировать версию своего кода, использованного для получения результатов, таким образом, если другой исследователь запрашивает код, вы можете его создать.

Что касается описания в вашей статье, то я бы сконцентрировался на высокоуровневом, независимом от реализации описании ключевых новых особенностей модели (это практическая часть, которую достигла большинство хороших статей). Сконцентрируйтесь на функциях, которые качественно изменят результат, если их настроить. Большинство моделей, с которыми я работаю, дают количественные результаты, но конкретные величины обычно не представляют интереса, только качественное поведение (поскольку параметры обычно далеки от наблюдаемых в природе). Таким образом, я сосредотачиваюсь на описании частей модели, которые в случае изменения изменят качественное поведение системы. Если это мышление вынуждает меня описывать каждую деталь моей модели вплоть до реализации, то я знаю, что моя модель не очень надежна и, следовательно, должна быть пересмотрена.

Хороший способ проверить, достаточно ли вашего внутреннего описания, - попросить друга (или студента), который не работал с вами над этим проектом, описать, как они могут реализовать вашу модель, - псевдокод. Если они не застревают при попытке сделать это (например, они приходят к эскизу модели, которая должна давать такие же качественные результаты), то вы знаете, что проделали хорошую работу по описанию.