Комментарии 7
Помехи на экране вызваны тем, что интеграл считается по некоторой ограниченной области, что хорошо работает для щелей, но показывает себя плохо для ситуаций, когда некоторый объект перекрывает источник света.
А если заменить 
на 
и посчитать первый интеграл аналитически для 
(будет, очевидно, 
)?
Если я правильно вас понял, вы считаете, что 
- это индикатор (поправьте, если это не так), думаю, в такой постановке задачи предложенное решение довольно удачно и действительно решает проблему. Однако относительно общей задачи, где возможно наличие нескольких перегородок, входной слой не всегда представляет собой индикатор, из-за чего аналитическое решение кажется мне затруднительным. Наверное, можно было бы добавить особенное поведение, включающее ваше замечание, для случая, когда pipeline замечает лишь одну перегородку — это помогло бы повысить качество получаемых изображений.
Интересная задачка
Вы поставили перед собой цель смоделировать дифракцию через численное нахождение интеграла Френеля методом Монте-Карло.
И визуально сравнили полученный результат с наблюдаемым в результате эксперимента.
Полученный результат интегрирования ожидаемо дал значения заложенные в теоретическую модель.
В статье смущает вот что: длительность вычисления зависит от количества точек для которых проводится расчет. Очевидно -- взяв меньше точек вы сможете оптимизировать трудозатраты при сохранении визуализации. (Как вы выбирали дискретность вашего расчета?)
Очень похоже что в наличии ошибка наименования осей на графике, там где должна быть интенсивность поля указана координата Y.
В отношении пятна Пуассона, вы получаете интенсивность исходного поля, которая похоже задается как 1, просто исходя из того что exp(0) == 1;
Вы правы, я забыл поменять подпись к оси, и да, интенсивность исходного поля равна 1, впрочем, этот параметр настраиваемый.
Касательно выбора дискретизации, на данный момент она задаётся вручную для каждого слоя. Для представленных результатов она подбиралась из расчёта, что на каждую из интересующих зон Френеля попадает хотя бы 5–7 точек, если смотреть по диаметру.
Тогда не очень понятно как ваши вычисления могут занимать минуты, если исходить из того что в слое 200 на 200 точек то он будет обрабатываться за доли секунды.
Есть несколько возможных причин, например, float32, в целом Python или не самое производительное железо (R3600X). Думаю, основная проблема, помимо железа — это, конечно, Python, про что я написал в статье.
Возможно, вы не в полной мере осознаёте, насколько много вычислений требуется. Возьмём за пример ваши 200 на 200 точек — это один слой, но для каждой точки считается интеграл по предыдущему (в реализации учитывались все точки предыдущего слоя), нетрудными вычислениями получаем 1,6 * 10^9 в однопоток, пусть у меня 12 потоков, это ~ 10^8, и это не учитывая сложности вычислений. Проведя сравнение на i++ 10^8 раз, я получаю различие в ~78 раз (6с против 0.077c) по сравнению с C++. Сравнительные скорости работы именно torch-операций на разных языках я не сравнивал, но предполагаю, что в этом аспекте языки скорее покажут более схожие результаты в силу особенностей Python-библиотек.
Таким образом, даже в идеальной вселенной, где Python показывает себя в 75 раз хуже, время работы с 10 минут сократится до 8 секунд, но никак не до долей секунды. В реальном же мире, где Torch не наследуют проблем языка по части производительности и в силу того, что фактически сами Python операции занимают колоссально меньшую часть от времени работы программы, по сравнению с остальными вычислениями, сомневаюсь, что прирост будет больше, чем в 10–15 раз (даже такие числа я нахожу крайне преувеличенными), что даёт около минуты в C++ реализации. Это, конечно, куда лучше, но с вашим тезисом про «доли секунды» я не могу согласиться.
В прочем, я готов его принять, если вы приведёте примеры реализации, где подобная производительность достигается на сравнимом железе.
«Физика для программистов» — как физтехи применяют её в приложениях. Дифракция. Интеграл Френеля