астрономия и нейросети

[Ph_user]

(то есть сложность расчетов n^2). при таком подходе у меня процессор тянет до 30000 объектов.

Можно запросить у робота примерную скорость математики по функции computeAccFromState с учетом положения на симд порядка авх256 и с фактором суперскалярности 2 при точности флоат32.

Под симд256 и фсс 2 надо будет внутрений луп
        for (int i = 0; i < n; ++i) {
 анролить в 4раза до         for (int i = 0; i < n; i+=4) { (количество проходов 2 лупов будет н*(н/4))
Внутрености лупа по скорости (если на флоат32 4байтовых делать) -
                Eigen::Vector3d r_vec = states[j].pos - states.pos; - одна загрузка (типа с кеша л1 - 5 тактов). Одно вычитание https://www.laruence.com/sse/#techs=AVX&text=mm256_sub_ps&expand=5730 имеет латенси 4 при производительности 1 и суперскалярности 2 на приличных чипах - 2 вычитания по 2 вектора будет порядка 4+1 = ну около 5 тактов

Дубль межрегистровый +произведение                 double dist2 = r_vec.squaredNorm();
 https://www.laruence.com/sse/#techs=AVX&text=mm256_mul_ps&expand=5730,3931 - еще порядка 5 тактов

Примерный корень квадратный -                 double dist = std::sqrt(dist2); https://www.laruence.com/sse/#techs=AVX&text=mm256_rsqrt_ps&expand=5730,3931,5368,4804 4+2 = 6 тактов
Точный корень квадратный - https://www.laruence.com/sse/#techs=AVX&text=mm256_sqrt_ps&expand=5730,3931,5368,4804,5368 12+6 = 18 тактов

Дубль межрегистровый +произведение                 double dist3 = dist2 * dist; - около 5 тактов

                Eigen::Vector3d a_newton = r_vec * (G * bodies[j].mass / dist3); - ну примерно 2 бродкаста масы + примерное обратное для dist3 + 2 умножения - ну около ну около 20 тактов.

Где-то около 5+5+5+6(18)+5+20=46 тактов с примерным корнем и примерным делением на 4 пары вещей (ну на 2 точнее - сколько там будет итоговой суперскалярности на всех инструкциях надо смотреть по наличному чипу). На частоте 3гигагерца - 1 такт то 3е-10 секунд. Где-то 1.5е-8 секунд на 4 пары на 1 поток при авх256. Около 4е-9 секунд на пару вещей на 1 поток. На 20потоковом процесоре - 2е-10 секунд на пару (?). Итого производительность порядка 5гигапар в секунду. Квадратный корень будет 72000 - ну так средненько. На авх512 должно быть еще раза в 2 лучше. Но это таки заметно меньше даже 1 милиарда. Надо бы посмотреть щас дизасемблер исполняемого файла в дебагере (или профилере) - чем оно таки вычисляет внутрености того лупа - на фпу или уже на симд хотя бы частично.

[crimchik]

Для реализации моделирования столкновения галактик с миллионами звезд на одной видеокарте (RTX 3060), нам нужно уйти от простых алгоритмов.

Я провел исследование современных методов (используемых в астрофизических кодах вроде Gadget-4, Bonsai и ChaNGa) и адаптировал их под архитектуру OpenGL Compute Shaders.

Вот единственный жизнеспособный путь для достижения вашей цели (1M+ звезд, честная гравитация, 60 FPS).


Главный Алгоритм: GPU Barnes-Hut (Linear Octree)

Классический алгоритм Барнса-Хата (который мы делали на CPU) использует рекурсию и указатели. Видеокарты ненавидят рекурсию и не имеют прямой работы с указателями в памяти так, как CPU.

Поэтому для GPU используется модификация: Линейное Октодерево (Linear Octree) на основе Z-кривой (Morton Codes).

Суть метода:

• Вместо того чтобы хранить дерево как «объект с ссылками на детей», мы линеаризуем пространство.

Сортировка (Morton Codes / Z-Order Curve):

• Каждой звезде присваивается уникальный целочисленный код (Morton Code), основанный на её координатах X, Y, Z.
  
• Если отсортировать звезды по этому коду, то звезды, находящиеся рядом в массиве, будут находиться рядом и в 3D-пространстве.

Реализация: Compute Shader считает код, затем мы используем GPU Radix Sort (быстрая сортировка на видеокарте) для упорядочивания массива частиц.


Построение дерева (Bottom-Up):

• Вместо того чтобы делить пространство сверху вниз, мы смотрим на отсортированный массив.
• Группы подряд идущих звезд с одинаковым префиксом кода Мортона образуют "листья" дерева.
• Затем мы объединяем листья в узлы (Nodes), узлы в супер-узлы, пока не дойдем до корня.
• Все узлы хранятся в одном плоском массиве (SSBO) на видеокарте.
  

Расчет Центра Масс (Up-Sweep):

• Запускается шейдер, который идет от листьев к корню.
• Каждый узел суммирует массу и взвешенную позицию своих детей.

Расчет Сил (Force Calculation - Stackless Traversal):

Самая сложная часть. Поскольку на GPU нет стека для рекурсии, мы используем алгоритм "Stackless Traversal" (обход без стека) с использованием ссылок skip (куда прыгать, если мы решили не открывать узел).

Для каждой звезды шейдер "путешествует" по массиву узлов:

• Узел далеко? -> Примени силу от узла, прыгни по ссылке skip к следующему брату.
  
• Узел близко? -> Зайди внутрь (перейди к следующему индексу в массиве).

Научные улучшения (Для максимальной достоверности)

Чтобы это было не просто "красиво", а "научно", нужно добавить следующие компоненты:


1. Активная Темная Материя (Live Dark Matter Halo)

В нашей CPU-версии гало было статической формулой. При столкновении галактик гало деформируются, сливаются и создают "гравитационное трение", которое заставляет галактики сливаться быстрее.

Решение: Добавить в симуляцию невидимые массивные частицы.

Например, 1 млн видимых звезд (легких) + 100 тыс. частиц темной материи (тяжелых).

Они участвуют в гравитационном расчете, но не рендерятся.


2. Симплектическая Интеграция (Leapfrog / Velocity Verlet)

Метод Эйлера (

Код: [Выделить]

V=V+A⋅dt) накапливает ошибку, и энергия системы растет ("взрыв" орбит).

Решение: Использовать схему Leapfrog ("Чехарда").

Координаты и скорости обновляются со сдвигом в полшага по времени. Это гарантирует сохранение энергии системы на миллионы лет симуляции.


3. Сглаживание (Softening Kernel)

При тесном сближении двух звезд сила

Код: [Выделить]

F→∞. Это выкидывает звезду из системы с неестественной скоростью.

Решение: Использовать Пламмеровское сглаживание не просто как константу, а как часть потенциала.

Код: [Выделить]

1 / (r^2 + ϵ^2)

Итоговая архитектура проекта (Версия 4.0)

Если мы решим это делать, структура проекта изменится кардинально:

• Rendering: QOpenGLWindow (вместо Qt3DWindow). Нам нужен полный доступ к OpenGL 4.5+.
  
• Data: Все данные (pos, vel, mass, morton_code) живут в SSBO (Shader Storage Buffer Objects).
  

Pipeline (один кадр):

• CS_Morton: Вычисление кодов Мортона.
  
• CS_Sort: Bitonic Sort или Radix Sort на GPU.
  
• CS_BuildTree: Построение линейного дерева (запись в NodeBuffer).
  
• CS_Summarize: Расчет центров масс (снизу вверх).
  
• CS_Force: Расчет гравитации (обход дерева).
  
• CS_Integrate: Обновление позиций (Leapfrog).
  
• VS_Render: Отрисовка точек напрямую из буфера позиций.
  

Сложность реализации

Это High-End задача.

Написание GPU-сортировки и построения дерева с нуля — это уровень курсовой работы по CUDA/OpenCL в топовом техвузе.

Но это единственный способ получить 1-2 миллиона частиц с честной физикой

Код: [Выделить]

O(NlogN) на одной карте.


Мой совет:
Если вы хотите научную точность столкновений (где важны именно тесные взаимодействия ядер), Barnes-Hut (Linear Octree) — это безальтернативный король.

Мы можем попробовать реализовать его версию. Это займет время, но результат будет ошеломляющим.

[Ph_user]

Это High-End задача.

Написание GPU-сортировки и построения дерева с нуля — это уровень курсовой работы по CUDA/OpenCL в топовом техвузе.

Слабые отмазки - тут от роботов ожидают свернаучных машиных прорывов за уровни топовых белковых мозгов. Выходы за границы доступных програмильных решений лучшим белковым мозгам на планете. А робот намекает на сложность задачи только обязательную для жалких серийно обученых дитенышей вырожденцев времен конца техноцивилизации и тормозит с выдачей решения. Фуу. Может намекает на потребность доплатить.

[Павел Васильев]

Для реализации моделирования столкновения галактик с миллионами звезд на одной видеокарте (RTX 3060), нам нужно уйти от простых алгоритмов

Вот вы с сеткой ИИ солнечную систему моделируете, а небосвод чёрный, звёзд нет. Пусть покажет для начала на сфере линии и границы созвездий.  Или проще, наоборот, преобразует файл границ созвездий constells.csv из сферической системы координат с ra dec  в цилиндрическую систему координат с x, y и сохранит в файл constells_c.csv? Не справится ведь. А вы о высоких материях, о N-body и столкновении галактик хотите ещё сетку заставить считать параллельно на CUDA/OpenCL.

[crimchik]

Ответы, которые мы заслужили 

[Ph_user]

В дебаг то оно может чтобы понять что там с нулями и откуда ? Для дебага если иде без возможности дебага шейдеров сразу с удобствами пошаговых просмотров можно выгружать текстуры из ускорителя и там уже смотреть в обычной памяти машины че ускоритель записывал. Но надо делать дебажные версии шейдеров с сохранением нужных под контроль чисел в выходные текстуры выгружаемые из ускорителя.

Ну и одна из проблематик работы с внешними ускорителями то сильная зависимость и до дров и от фирмвари ускорителя. Центральный процесор машины обычно работает намного стабильнее и баги под фикс в центральных процесорах обычно весьма редки.

Потому при выборе апи работы с ускорителем может быть полезны апи с улучшеным тестированием. Директ икс как часть виндуса может иметь более тестированые мелкософтом дрова. Бо мелкософт может лучше заставлять дровописателей делать качественые дрова под свой товар.

[Astro_Coder]

А что там с точностью? сравнивали с данными Горизонса после некоторого интервала моделирования Солнечной системы?

Я когда то давно тоже "страдал" этой темой  и у меня вышло что РК4 слишком быстро накапливает вычислительную ошибку, нужен интегратор более высокого порядка.

[Павел Васильев]

А что там с точностью? сравнивали с данными Горизонса после некоторого интервала моделирования Солнечной системы?

О какой вообще точности идёт речь? Crimchik заказывает у ИИ нейронки упрощённую СС c малым числом тел,  даже если влияние соседних планет и будет учтено, возмущающих орбиты, это не будет соответствовать полному составу системы. В общем затея не стоит и выеденного яйца.

[Ph_user]

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

Раньше это сильные головой дяди ваще на бумажке карандашом могли. Без терафлопсов дабл точности под столом.

[crimchik]

В общем затея не стоит и выеденного яйца.

о нет, я бы так не сказал. тема затевается не ради того, чтобы сделать еще один симулятор солнечной системы. а ради того, чтобы показать что такая задача возможна при помощи нейросетей и пользователя, который не очень разбирается в программировании https://astronomy.ru/forum/index.php/topic,226601.msg6434978.html#msg6434978
если брать конкретно программу для солнечной системы, то туда можно добавить любое разумное количество предикторов. версия того алгоритма на центральном процессоре гарантировано поддерживает до 30.000 объектов, а теоретически до 100.000 с полным анализом взаимодействий "каждый к каждому". дальше уже зависит от мощности процессора

[Ph_user]

Но кроме количества вещей ещё вторая проблема в точности относительно алайзинга в простанствено-временых частотах. Если шаг времени относительно скоростей и смещений большой - будут ошибки большие. Если шаг времени мал - будут овертормоза. Потому надо чтобы робот думал как оценить требуемый шаг времени для исполнения требований котельникова-найквиста по нарезке изменяемых во времени вещей на куски без алайзинга или с алайзингом заданной максимальной величины. Пока там нету вааше оценок потери точности от алайзинга и выбора шага симуляции для баланса между точностью и скоросттю счета. А нужна ваше адаптивная программа чтобы шаг был динамически подбираемый между разными вещами - может зависеть от скорости и удалений и ускорений и др. Робот должен разработать методику и реализацию программы.

Пример алайзинга во времени из двух вещей -
1. камень стоит в центре
2. запускаем второй камень на скорости с пролетом рядом (на два радиуса).

При излишне малой частоте семплировки во времени програма посчитает первую точку далеко до и вторую далеко после пролета (как интегральную координату по времени от скорости +ускорения через время до второй точки           

Код: [Выделить]

bodies[i].position += bodies[i].velocity * dt + 0.5 * bodies[i].acceleration * dt * dt; ). Куча важных реальных физических точек на малом удалении и с большой гравитацией пропущена.

Шаг времени дт взят мало понятно откуда     float fixedDt = 0.005f;  .Может быть и маловат в части мест.

Вот робот должен разработать алгоритм для подбора шага времени (между всеми парами ? вещей) чтобы ошибка интегрировки была меньше заданой (пользователем в процентах или других попугаях).

Замер ошибки в контрольных полетах по космосу -
1. посчитать конечный набор 1 координат вещей при автовыборе дт.
2. убавить дт в разы (в 10 раз ?) и посчитать второй набор 2 конечных координат после времени симуляции т.

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

Если ошибка сильно (в 10 раз ?) меньше заданой - значит алгоритм плохой и задает слишком много шагов интегрировки и все тормозит - и надо допиливать в сторону прибавки дт.

Вариант алгоритма автовыбора дт - фурьить кусок симуляции во времени для ускорения (или всех параметров вещи - координаты + скорости + ускорения) по каждому измерению 3д космоса при разных дт и смотреть на спектральную плотность мощности у верхних частот. Если там многовато - делать еще раз просчет куска на убавленом дт и пробовать довести спм где-нить в верхней половине фурьевых частот до заданого минимума (в более хорошем случае до обнуления). Это может намекать на уже достаточную частоту семплировки во времени чтобы уйти от алайзинга вмеру далеко.

Попытка в рк4 делить дт только на пополам может быть тоже слишком большой по дт. Дт должно быть изменяемым роботом внутри симуляции чтобы выходить на нужную точность за минимальное время без излишних тормозов. Начинать отладку програмы с изменяемым дт можно с двух камней в одном космосе.

Реальный физический космос с камнями работает на безконечно большой частоте семплировки с условно нулевым дт между всеми оценками межкамневой гравитации. Ну и еще в програму надо положить конечную скорость изменений потенциала гравиполя вокруг летящих камней равную тоже с.

[crimchik]

да, в плане повышения реалистичности расчетов сетка много чего интересного предлагает, просто я сюда не копирую все . вот, например, комментарий по наиболее реалистичной версии для моделирования столкновений галактик, которая сейчас работает только на центральном процессоре , зато учитывают абсолютно все взаимодействия между всеми звездами , центрами галактик , и так называемой темной материи

3. Оценка научной реалистичности (7/10)

Я бы оценил текущую модель на 7 из 10 по шкале симуляторов звездной динамики.

Что у нас ЕСТЬ (Научно):

[list=1]

• ✅ Бесстолкновительная динамика: Звезды взаимодействуют гравитационно, но не сталкиваются физически (как бильярдные шары). Это абсолютно верно для реальных галактик (расстояния между звездами огромны).
• ✅ Самогравитация: Звезды чувствуют друг друга через дерево. Это позволяет формировать спиральные волны плотности.
• ✅ Темная материя: Мы учитываем её через аналитический потенциал гало и ядер.

Чего у нас НЕТ (Почему не 10/10):

[list=1]

• ❌ Газ (Гидродинамика): Это главное упущение. В реальных галактиках есть межзвездный газ. Он, в отличие от звезд, сталкивается, нагревается, теряет энергию и падает в центр. Именно газ создает самые четкие тонкие спиральные рукава и рождает новые звезды.
• ❌ Эволюция звезд: Звезды не взрываются сверхновыми, не меняют массу.

4. Как повысить реалистичность? (Новые факторы)

Если вы хотите двигаться к 8/10 или 9/10, нам нужно добавить новые физические явления.

А. Динамическое Трение (Dynamic Friction) — Легко реализовать

Когда массивная галактика летит сквозь облако мелких звезд, она должна тормозиться ("вязнуть" в гравитационном поле).

• Реализация: Добавить в шейдер небольшую силу, направленную против скорости (F = -k * v), но только в плотных областях. Это заставит ядра галактик сливаться быстрее, а не вечно кружить друг вокруг друга.

Б. Гидродинамика сглаженных частиц (SPH - Smoothed Particle Hydrodynamics) — Сложно

Это симуляция газа.

• Мы можем объявить, что 10% наших частиц — это не звезды, а облака газа.
• Для них нужно добавить силы давления и вязкости.
• Визуально: Газовые облака будут сплющиваться в тончайшие диски и сталкиваться "всмятку", образуя красивые ударные волны при столкновении галактик.

В. Активное Гало Темной Материи — Средне

Сейчас гало задано формулой (оно не деформируется).

• Идея: Добавить 100 000 невидимых, очень тяжелых частиц, которые будут летать вокруг галактики широким облаком.
• Эффект: При столкновении эти невидимые облака будут проходить сквозь друг друга, искажаться и менять судьбу видимых звезд.

[Ph_user]

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

Гораздо больше нужна точность для самоходок с посадкой на планеты - там точность уже хороша порядка 1процента от толщины атмосферы. Это может быть в разы меньше 1 процента от радиуса планеты.

[Павел Васильев]

Гораздо больше нужна точность для самоходок с посадкой на планеты - там точность уже хороша порядка 1процента от толщины атмосферы. Это может быть в разы меньше 1 процента от радиуса планеты.

Вы зря такой огород разводите, лишнее это всё. Небесные тела итак летают по орбитам по определённым эфемеридам, эти вещи сталкиваться и проникать друг в друга не будут, тут обработка коллизий не нужна. А корабль вполне можно посадить на меш планеты, чтобы он не проваливался ниже высотной отметки террейна в месте посадки. Рельеф известен в виде сетки триангуляции или регулярного грида топоповерхности. Так что в простом случае вполне можно обойтись без всякой физики тяготения масс и сложных расчётов траекторий. Симуляция приземления или прилунения звездолёта на тело и дальше навигация по рельефу.

[Ph_user]

тут обработка коллизий не нужна

Тут надо сначала получить требуемую точность интеграла случайной (и еще и зависящей от координат в ощутимой степени) функции. В относительно взрослом и платном маткаде прайме под то даже крутилки точности в наличии - штук 7 вариантов. На около 1е-3 ответ достаточно быстрый но может быть достаточно кривой. На 1е-4 может уже переставать выдавать ответ и за часы. А можно и 1е-7 выставить вроде.

Начать можно с посылки робота искать алгоритмы вычислений интегралов на нужной точности. Вместо долблений через одинаковый дт. И потом досыпать эти алгоритмы в програму.

Симуляция приземления или прилунения звездолёта на тело и дальше навигация по рельефу.

Может быть симуляция идей великих древних типа *из пушки на луну* - один раз толкнуть чтобы потом по законам физики само долетело куда надо без рукопашных поправок по дороге.

[Павел Васильев]

Может быть симуляция идей великих древних типа *из пушки на луну* - один раз толкнуть чтобы потом по законам физики само долетело куда надо без рукопашных поправок по дороге.

Тут разные цели посещения объектов симуляции, в данном случае тел СС. Если вы хотите точно смоделировать полёт ракеты до планеты, то много чего ещё надо учесть, помимо всего прочего, а если надо просто исследовать полученную с помощью ИИ модель солнечной системы, то достаточно вьюера с навигацией от первого или третьего лица с камерой наблюдения. И чтобы наблюдатель не проваливался под сеточную поверхность планеты. Вполне реалистично для общего представления о точности моделирования.

[Ph_user]

Исходно тута робот обещал вот ваще чесную научную физику точную. А реально даже еще плохо умеет в математику задано точных интегралов и прикладку математики к физике.

Про попытки математики в интегралы даже в вики насыпали идеи умных - https://ru.wikipedia.org/wiki/%D0%A7%D0%B8%D1%81%D0%BB%D0%B5%D0%BD%D0%BD%D0%BE%D0%B5_%D0%B8%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

1   Одномерный случай
1.1   Метод прямоугольников
1.2   Метод трапеций
1.3   Метод парабол (метод Симпсона)
1.4   Увеличение точности
1.5   Метод Гаусса
1.6   Метод Гаусса — Кронрода
1.7   Метод Чебышёва
1.8   Метод Гаусса-Лагера
1.9   Метод Гаусса-Эрмита
1.10   Интегрирование при бесконечных пределах
1.11   Методы Монте-Карло
1.12   Методы Рунге — Кутты
1.13   Метод сплайнов

Куча старых методов - значит годно рабочего идеала так и нету.

Увеличение точности
Приближение функции одним полиномом на всем отрезке интегрирования, как правило, приводит к большой ошибке в оценке значения интеграла. Для уменьшения погрешности отрезок интегрирования разбивают на части и применяют численный метод для оценки интеграла на каждой из них. При стремлении количества разбиений к бесконечности оценка интеграла стремится к его истинному значению для аналитических функций для любого численного метода.

Но при обнулении шага дт время исполнения математики пойдет к безконечности даже для двух камней в космосе.

Скорость то интеграл от ускорения и положение то интеграл от скорости. Чтобы знать точно положение надо дважды взять интегралы годно точно.

[Павел Васильев]

Скорость то интеграл от ускорения и положение то интеграл от скорости. Чтобы знать точно положение надо дважды взять интегралы годно точно

  Вот вы перечислили весь справочник по математике, а зачем? Коллега для симуляции решил использовать ИИ, который в последнее время стал гораздо более продвинутым, чем прежде. По его идее он сам должен выбрать наилучший, надёжный и оптимальный комплекс математических методов решения задачи. И он вам скажет, что  вполне достаточно точности в два знака после запятой или плавающей точки, или скажем, грубо говоря, до 1метра. Без всяких ваших лишних интегралов. Не сегодня, а завтра конечно такие задачи будут под силу нейронкам и прочим искусственным интеллектам и даже роботам с киборгами. Но не в Новом году, а возможно после Старого нового года, лет через десять.

[Ph_user]

Робот мог обмануть заказчика если заказчик забыл потребовать точности в нужных размерах. Тут уже постили обещания робота типа симулятор готов и всегда годен. А там еще вручную дт задают очень примерно под получение результата отрисовки *вроде похоже* и адаптации дт для баланса скорости и точности мало видно. И даже задания и выдачи полученой точности и сравнения заданой и полученой нету. Робот скорее слишком хорошее слишком рано обещает.

Нии - летать через галактики по таким симуляторам еще опасно для жизни и имущества.

[Павел Васильев]

Нии - летать через галактики по таким симуляторам еще опасно для жизни и имущества.

Даа, в те края летать надо в настоящем и будущем, а не в прошлом, что мы в телескопы наблюдаем. Симуляция будет другая, поэтому надо нейросетке выдать задание на расчёт 5д картины видимой вселенной на текущий  момент с максимально возможной точностью. Пусть думает.