Не вполне понятно, какой процесс вы намереваетесь моделировать: можно ли его считать дискретным, или есть непрерывные составляющие; какая требуется визуализация; почему вы упоминаете дифференциальные уравнения; насколько высока вычислительная сложность.
Я бы сказал, что существуют следующие методы решения задачи.
Настольное приложение на Python. Python для сколь-нибудь сложных систем более удобный язык, чем JavaScript, потому что вы можете легко разложить вашу симуляцию на классы, описать взаимоотношения между ними. Есть много структур данных: списки, очереди, словари, что угодно, - не надо делать свой класс prioritized queue, например. Есть всяческие оптимизированные инструменты вроде numpy, scipy.
Есть фреймворки для разработки приложений: pygame и более новый kivy. О kivy я ничего сказать не могу. О pygame могу сказать, что её API мог бы хорошо смотреться двадцать лет назад, но не сегодня. Python гибкий язык, на нём можно писать гораздо более человекопонятные библиотеки.
Кроме того, на pygame без дополнительных библиотек вам придётся руками, из прямоугольников и окружностей, рисовать графики, схемы, etc, - то есть вы много времени потратите на вспомогательные вещи вместо того чтоб разрабатывать вашу симуляцию. Возможно, библиотеки для этих вещей существуют, но я мало знаком с разработкой настольных приложений на Python, не могу сказать.
Наконец, чтобы распространять ваше приложение, потребуется сделать установщик, собрать его в .exe специальным инструментом, обновлять его как-то. Всё это довольно муторно и вселяет тоску.
Клиентское приложение на JS, как писали уважаемые участники обсуждения выше, лишено многих из этих недостатков. У пользователей будет доступ к вашей программе отовсюду, не нужно ничего устанавливать на компьютер. К вашим услугам Canvas, SVG и при необходимости WebGL. И море, нет, - океан разнообразных JS-библиотек, которые позволяют быстро и удобно делать графику, диаграммы, анимацию, визуализации любого сорта.
Недостатки, с которыми встречался я, когда занимался чем-то подобным:
- Отсутствие удобных структур данных. В JavaScript есть корявые списки, с которыми работать неудобно. Но я думаю, что сейчас этот недостаток нивелируется развитием самого языка и появлением библиотек типа underscore.js.
- Неудобство и лапшевидность получающегося кода в результате отсутствия нормального наследования. Ну тут снова: библиотек для того же наследования существует множество; есть requirejs и модули; ну и вообще, сейчас я бы сделал это всё иначе :)
- Медленность вычислений. Весьма относительная вещь, потому что программу можно при желании сильно оптимизировать; для большинства таких симуляций, о которых речь шла у меня, производительность проблемой не была.
Гибридный вариант. Веб-приложение, на бэк-енде работает процесс, выполняющий расчёты; на фронт-енде работает клиентский код, который общается с пользователем и визуализирует результаты. Для больших симуляций - очевидно лучший вариант, но и самый сложный. И клиент и сервер имеют каждый свою объектную модель, и в некотором смысле одно и то же, получается, нужно дважды реализовывать.
Поэтому, как итог - я бы предложил вам остановиться на варианте 2 (клиентский код на JS), а со временем, если симуляция окажется ну очень сложной - можно перейти к варианту 3, опираясь на накопленный опыт. Частично вынести из уже написанного приложения часть расчётов на сервер. Как пример: отдельный процесс по заданным параметрам с визуализацией вы считаете на клиенте, а если нужно посчитать сто процессов и найти какие-то усреднённые характеристики - это выносится на сервер. Просто и логично.
Если интересно - пишите на почту, можно пообщаться. Я ни в коем случае не являюсь специалистом, но пока учился в вузе - немного интересовался темой, читал книги/статьи и писал простенькие программы по дискретно-событийному моделированию экономических процессов в качестве курсового проекта.
