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

[crimchik]

А уж такую сложную задачу, как моделирование Солнечной системы  (пусть и с некоторыми допущениями), в ближайшие годы ИИ решить однозначно не сможет. Разве что "скоммуниздит" откуда-нибудь готовый код. Но все равно: в бесплатной версии сессия сильно ограничена в размере, так что, ему просто размера сессии не хватит, чтобы все исходники выложить.

в продолжение вот этой темы https://astronomy.ru/forum/index.php/topic,226601.msg6445322.html#msg6445322
модели дипсик уступают по качеству кода коммерческим моделям chatgpt/claude/grok. вот только вчера выкатили новую chatgpt5.2 с улучшенным кодингом и математикой - давайте на ней и попробуем.

хочу провести публичный эксперимент , чтобы нейросеть написала программу для моделирования солнечной системы. постараюсь, чтобы все решения сетка принимала максимально автономно :
1. планирование и разработка самого эксперимента
2. составление технического задания :
- планирование всех ключевых аспектов солнечной системы с точки зрения астрономии, физики и математики. реалистичность и допущение 
- планирования архитектуры, интерфейса, логики
3. самоконтроль и самоисправление .

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

[jaker]

Интересно, 5.2 уже доступна, ждем что получится

[crimchik]

Вот вся предложенная сеткой проектная документация, техническое задание, дорожная карта и правила для разработки

[crimchik]

поскольку в самом начале я указал, что это будет публичный эксперимент, то сетка предлагает .
## 2. Стек и ограничения (выбор по умолчанию)

**По умолчанию (рекомендуется для публичности):**

- **TypeScript + Vite** (сборка/дев-сервер)
- Визуализация: **Canvas 2D** (V0–V1), опционально **WebGL/Three.js** (после V2)
- Тесты: **Vitest**
- Линт/формат: **ESLint + Prettier**
- CI: GitHub Actions (или аналог)

**Ограничения:**

- Минимум зависимостей, особенно для физического ядра.
- Детализация/точность регулируется допущениями; ОТО и не-ньютоновские эффекты не обязательны.
- Никаких сетевых запросов в рантайме для критически важной физики (данные должны быть в репо).

[crimchik]

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

Сколько объектов в модели и нужен ли C++ или Python достаточно

📌 Сколько объектов в модели Солнечной системы?

Уровень детализации влияет на количество объектов:

• Минимальный реалистичный набор
  ☑ Солнце (1)
  ☑ 8 планет
  ☑ крупные спутники → всего ≈ до ~100 объектов
  Это легко моделировать на Python.
  
  
• Расширенный научный уровень
  ☑ сотни тысяч астероидов
  ☑ десятки тысяч околоземных объектов
  ☑ возможные миллионы мелких тел
  Это уже большое N для прямой симуляции.
  

📌 Проблема масштабируемости
Для прямого N-body расчёта каждая пара тел взаимодействует → это бутстрапно O(N²). Большое N быстро становится вычислительно тяжёлым даже на мощной машине.

Когда Python достаточно?

[]Если модель содержит до ~100 объектов (планеты + крупные луны)
[]Если основной интерес — визуализация, обучение, анализ поведения

• Когда исследование и прототип важнее, чем максимальная производительность

Python + NumPy/SciPy отлично справляются с таким объёмом без C++.

Когда Python может не хватить?

[]Если N становится большим (например >1000 тел)
[]Если нужно миллионы шагов интегрирования
[]Если вычисления должны быть быстрыми (реальное время, GPU)
[]Когда важна масштабируемость и параллелизм на уровне ядра

В таких сценариях C++ или ускоренные ядра дают реальный выигрыш.

📊 Оценка: сколько объектов и инструмент

[table width="100%"]

[th]Количество тел[/th][th]Инструмент / Стек[/th][th]Комментарий[/th]
~10	Python	Python достаточно, проста разработка
~100	Python + NumPy/SciPy	Python справится, удобный анализ
~1000	Python + NumPy/SciPy	Python ещё возможно, но нагрузка растёт
~10 000	Python + C++ / GPU	Нужна оптимизация, Python уже медленно
~100 000+	HPC / tree-code / GPU	Python без ускорения — неэффективно

Почему Python может быть недостаточен при большом N

[]O(N²) — число расчётов растёт квадратично с числом тел
[]Python интерпретируемый → медленнее чистого машинного кода
[]NumPy ускоряет операции с массивами, но сложные взаимодействия всё равно тяжёлые
[]Передача данных в Python-ядре сама по себе создаёт накладные расходы

📍 Когда нужен C++ (или ускоренное ядро)?

• Сценарий A — большое количество объектов
  ☑ ~10 000+ тел → нужна оптимизация ядра, C++ работает быстрее
  
  
• Сценарий B — длительное интегрирование
  ☑ миллионы шагов → C++ эффективнее
  
  
• Сценарий C — многопоточные/параллельные расчёты
  ☑ OpenMP / MPI / GPU: C++ хорошо масштабируется
  
  
• Сценарий D — высокие требования к ресурсам
  ☑ контроль памяти, оптимизация, низкоуровневые структуры
  

🧠 Комбинированный подход: Python + C++

Почему он работает хорошо:

[]Python остаётся «обвязкой» — удобен для:

[]визуализации[/li]
[]настройки параметров[/li]

[]анализа результатов[/li]
[/list]

• C++ берёт на себя тяжёлые вычисления — интеграторы, ускорения, оптимизации

[]Такой подход широко применяется в научных проектах:

[]Python облегчает разработку[/li]

• C++ даёт производительность

[/list]

📌 Пример архитектуры гибридной системы

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


Python (high level)

import integrator_core

bodies = load_initial_conditions()
results = integrator_core.simulate(bodies, dt=0.01, steps=1_000_000)
visualize(results)

C++ ядро (integrator_core) может быть написано с оптимизациями (OpenMP, SSE/AVX, GPU), и Python вызывает его как расширение через pybind11, Cython, или другие обёртки.

Вывод

[]Python — идеален для моделей с небольшим числом тел, анализа, визуализации, прототипирования.
[]Python сам по себе может справиться с реалистичной моделью Солнечной системы при умеренном N.
[]Если N большой — нужны оптимизации (C++/GPU), потому что Python будут тормозить.
[]Гибрид Python + C++ даёт лучшее сочетание: удобство Python + скорость C++.

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

Когда Python достаточно?

[]Если модель содержит до ~100 объектов (планеты + крупные луны)
[]Если основной интерес — визуализация, обучение, анализ поведения
Когда исследование и прототип важнее, чем максимальная производительность
Python + NumPy/SciPy отлично справляются с таким объёмом без C++.

Странные рекомендации, при правильной организации кода Питон и больше объектов в расчётах потянет, а напрямую для визуализации с OpenGL в 3D графике конечно нет, но в 2D он вполне жизнеспособен.
Главное в другом. Пока у вас не разрослось техзадание к ИИ до 1000 страниц. С чем сравнивать будете?
У меня среди исходников (не мой проект, форк с гитхаба) есть на Питоне атлас астероидов, где есть и планеты, и луны тоже - https://gitverse.ru/astrogeoscenter/atlas_of_asteroids. Вот пусть ваш дипсик или новый chatgpt 5.2 для сравнения и сделает лучше по точности с тем же самым набором небесных тел солнечной системы.   

[Ph_user]

нужны оптимизации

От робота надо требовать чтобы он
1. прочитал
2. понял
3. применял
все рулезы из мануала по оптимизации софтвари от производителя процесора. У интеля их там штук 100 примерно. Если какой рулез пропустит и то приведет к потери скорости софтвари - наказывать робота.

Старые версии даже на сайте наса выложены - https://www.nccs.nasa.gov/images/intel_optimization.pdf . С ними уже наверно душевно в космос летали.

[crimchik]

Когда Python достаточно?

[]Если модель содержит до ~100 объектов (планеты + крупные луны)
[]Если основной интерес — визуализация, обучение, анализ поведения
Когда исследование и прототип важнее, чем максимальная производительность
Python + NumPy/SciPy отлично справляются с таким объёмом без C++.

Странные рекомендации, при правильной организации кода Питон и больше объектов в расчётах потянет, а напрямую для визуализации с OpenGL в 3D графике конечно нет, но в 2D он вполне жизнеспособен.
Главное в другом. Пока у вас не разрослось техзадание к ИИ до 1000 страниц. С чем сравнивать будете?
У меня среди исходников (не мой проект, форк с гитхаба) есть на Питоне атлас астероидов, где есть и планеты, и луны тоже - https://gitverse.ru/astrogeoscenter/atlas_of_asteroids. Вот пусть ваш дипсик или новый chatgpt 5.2 для сравнения и сделает лучше по точности с тем же самым набором небесных тел солнечной системы.

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

[Eddy_Em]

Не, с питоном этого ИИ надо куда подальше слать!
Пусть на вменяемом ЯП пишет. Хотя бы - С++.
А с питоном пусть школота развлекается, ни для чего серьезного он не пригоден.

[crimchik]

Вот версия на питон. все принятые решения сетка записывала в лог :

# DECISIONS (ADR log)

Формат: Date / ADR-ID / Title / Context / Decision / Alternatives / Consequences

## 2025-12-12 / ADR-0001 / Выбор стека Python/NumPy
Context: цель — научная корректность при умеренном N и быстрые итерации.
Decision: Python 3.11+ + NumPy + Matplotlib + Pytest (+ SciPy опционально).
Alternatives: Web (TS), C++-ядро сразу.
Consequences: быстрее прототипирование/анализ; хватает для N<=100.

## 2025-12-12 / ADR-0002 / Инструменты качества кода
Context: нужны линтер, форматтер и тестовый фреймворк для поддержания качества.
Decision: Ruff (линтер) + Black (форматтер) + Pytest (тестирование). Конфигурация в pyproject.toml.
Alternatives: Flake8 + autopep8, pylint + yapf.
Consequences: Ruff быстрее и современнее, единая конфигурация в pyproject.toml упрощает поддержку.

## 2025-12-12 / ADR-0003 / Выбор единиц измерения
Context: необходимо выбрать систему единиц для внутренних вычислений и хранения данных. Варианты: SI (m, kg, s) или астрономические единицы (AU, day, solar mass).
Decision: Использовать астрономические единицы (AU для расстояния, day для времени, solar mass для массы). Это естественно для масштабов Солнечной системы и уменьшает риск ошибок округления при работе с очень большими/малыми числами в SI.
Alternatives:
- SI (m, kg, s): стандартные единицы, но требуют работы с очень большими числами (расстояния ~1e11 м, массы ~1e30 кг)
- Смешанная система: AU + day + kg (нормализует расстояния и время, но массы остаются большими)
Consequences:
- Расстояния: 1 AU = 1.496e11 m (удобно для орбит планет)
- Время: 1 day = 86400 s (удобно для орбитальных периодов)
- Масса: 1 M☉ = 1.989e30 kg (удобно для масс планет как долей солнечной)
- Константа гравитации G будет выражена в AU³/(M☉·day²)
- Все константы и преобразования хранятся в `src/physics/constants.py`
- При необходимости визуализации в других единицах — преобразование на границе модуля visualization

## 2025-12-12 / ADR-0004 / Корректная формула круговой скорости и барицентрическая система отсчёта
Context: Исходная реализация использовала упрощённую формулу круговой скорости v = sqrt(G·M_sun/r), которая не учитывает массу планеты. Также Солнце было помещено в начало координат, что приводило к ненулевому суммарному импульсу системы.

Decision:
1. **Формула круговой скорости:** Использовать полную двухтельную формулу v = sqrt(G·(M_sun + M_planet)/r). Это корректно для задачи двух тел.
2. **Барицентрическая система:** После расчёта начальных условий центрировать систему по барицентру (центру масс), обеспечивая нулевой суммарный импульс P=0.

Alternatives:
- Оставить упрощённую формулу: погрешность ~0.05% для Юпитера, пренебрежимо мала для остальных планет
- Гелиоцентрическая система: проще для визуализации, но нарушает сохранение импульса

Consequences:
- Солнце теперь смещено от начала координат на ~0.01 AU (влияние Юпитера)
- Суммарный импульс системы равен нулю (физически корректно)
- Тесты обновлены для проверки относительных позиций/скоростей (планета относительно Солнца)
- Погрешность формулы скорости снижена с ~0.05% до машинной точности

## 2025-12-12 / ADR-0005 / Softening Parameter для защиты от близких сближений

Context: При вычислении гравитационных ускорений используется формула a = G·m/r³·r, которая даёт деление на ноль при r→0. Хотя self-interaction обработана (distances=1), близкие сближения между разными телами могут привести к overflow/NaN.

Decision:
Добавить softening parameter ε в формулу ускорения:
```
a = G·m·r / (r² + ε²)^(3/2)
```
Значение по умолчанию: ε = 1e-8 AU (~1.5 км).

Alternatives:
- Проверка минимального расстояния и пропуск слишком близких тел
- Обнаружение коллизий и объединение тел
- Использование adaptive timestepping при сближениях

Consequences:
- Защита от численных ошибок при близких сближениях
- Для нормальной динамики Солнечной системы влияние пренебрежимо мало (ε << расстояний между планетами)
- При необходимости точных расчётов близких сближений можно уменьшить ε или отключить (ε=0)
- Параметр документирован в KNOWN_LIMITATIONS.md

## 2025-12-12 / ADR-0006 / Оптимизация алгоритма вычисления ускорений

Context: Исходный алгоритм вычислял ускорения в цикле по всем телам, при этом каждое взаимодействие (i,j) и (j,i) считалось отдельно, что давало O(N²) операций вместо возможного O(N²/2).

Decision:
Использовать симметрию третьего закона Ньютона: F_ij = -F_ji. Вычислять каждую пару взаимодействий только один раз (для i < j), применяя результат к обоим телам:
```python
for i in range(N):
    for j in range(i+1, N):
        # вычислить a_ij один раз
        accelerations += factor * masses[j] * dr
        accelerations[j] -= factor * masses * dr
```

Alternatives:
- Полностью векторизованная версия (NumPy broadcasting): O(N²) памяти, но может быть быстрее для малого N
- Barnes-Hut или FMM для больших N (O(N log N) или O(N))

Consequences:
- Количество вычислений расстояний уменьшено вдвое
- Сохранена точность до машинной погрешности (третий закон Ньютона выполняется точно)
- Добавлена альтернативная функция `compute_accelerations_vectorized` для сравнения производительности
- Память O(N) вместо O(N²) у векторизованной версии

## 2025-12-12 / ADR-0007 / Реалистичные орбитальные элементы планет

Context: Исходная модель использовала упрощённые круговые орбиты в плоскости XY. Реальные орбиты планет эллиптические с различными эксцентриситетами (0.007–0.206) и наклонениями к эклиптике (до 7° у Меркурия).

Decision:
1. Добавить полные орбитальные элементы на эпоху J2000:
   - a (большая полуось) — уже было
   - e (эксцентриситет)
   - i (наклонение)
   - Ω (долгота восходящего узла)
   - ω (аргумент перигелия)
   - M₀ (средняя аномалия на J2000)

2. Реализовать преобразование орбитальных элементов в декартовы координаты:
   - Решение уравнения Кеплера (Newton-Raphson)
   - Преобразование эксцентрической аномалии в истинную
   - Поворот из орбитальной плоскости в эклиптическую систему

3. Добавить параметр `realistic=True/False` для выбора модели

Alternatives:
- Загрузка эфемерид из SPICE/Horizons (точнее, но требует внешних данных)
- Только эксцентриситеты без наклонений (проще, но менее реалистично)

Consequences:
- По умолчанию используется реалистичная модель
- Упрощённая модель доступна через `realistic=False` для тестов и обратной совместимости
- Положения планет соответствуют эпохе J2000 (1 января 2000, 12:00 TT)
- Тесты обновлены: упрощённые тесты используют `realistic=False`, добавлены новые тесты для реалистичной модели
- Эксцентриситет Меркурия (0.206) приводит к изменению расстояния от Солнца на ~34% за один оборот — это физически корректно



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

Главное в другом. Пока у вас не разрослось техзадание к ИИ до 1000 страниц. С чем сравнивать будете?
У меня среди исходников (не мой проект, форк с гитхаба) есть на Питоне атлас астероидов, где есть и планеты, и луны тоже - https://gitverse.ru/astrogeoscenter/atlas_of_asteroids. Вот пусть ваш дипсик или новый chatgpt 5.2 для сравнения и сделает лучше по точности с тем же самым набором небесных тел солнечной системы.

мне нравится, потому что это как раз огромный массив данных . но я не очень пойму, что вы хотите с ним сделать ?

[crimchik]

забыл сами исходники приложить
https://disk.yandex.ru/d/4GrO56VDALtAKQ

сначала нужно запустить файл setup , он установит собственное окружение и необходимые зависимости . для запуска проекта запускаем файл run

[crimchik]

Не, с питоном этого ИИ надо куда подальше слать!
Пусть на вменяемом ЯП пишет. Хотя бы - С++.
А с питоном пусть школота развлекается, ни для чего серьезного он не пригоден.

Спросил, может ли он создать максимально реалистичную симуляцию на C++ ?

Идея: “максимально реалистичное” моделирование траекторий планет

• Ключевой нюанс: максимальная точность в астродинамике чаще достигается не “чистой” интеграцией N-тел с нуля, а использованием готовых высокоточных эфемерид, которые уже численно интегрированы и подогнаны по наблюдениям (радиолокация, VLBI, данные миссий и т.д.).
• Поэтому разумно делать проект двухрежимным: эталонный режим (эфемериды) + исследовательский режим (собственная интеграция).

1) Что значит “максимально реалистично”

Режим A — “Эталонный” (ephemeris-driven)

• Читаем высокоточную эфемериду (например, JPL DE440/DE441 через SPICE SPK) и получаем положение/скорость тел на любой момент времени в диапазоне покрытия.
• Плюсы: максимальная реалистичность и точность “как у профессионалов”, простая валидация (сравнение с Horizons), высокая скорость.
• Минусы: это не “свободное моделирование”, а воспроизведение готового решения.

Режим B — “Физический прогноз” (собственная интеграция)

• Берём начальные условия из эфемериды на эпоху

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

t0

и дальше интегрируем сами, выбирая модель сил.[/li]

• Плюсы: можно делать “what-if”: включать/выключать эффекты, добавлять тела, менять параметры, исследовать устойчивость.
• Минусы: без подгонки параметров к наблюдениям орбиты со временем начнут расходиться с DE/Horizons (даже при хорошей физике).

2) Научная модель: что учитывать “по-взрослому”

2.1. Базовая динамика

• Полная N-тел гравитация в барицентрической системе (SSB), а не “Солнце в центре”.
• Минимальный набор тел: Солнце + 8 планет. Практически полезно: добавить Луну (или систему Земля–Луна корректно), а также барицентры систем.

2.2. Релятивистика (обязательно для “максимально реалистично”)

• Поправки 1PN (постньютоновская динамика / PPN) — особенно важно для Меркурия.
• Опционально: эффекты типа Lense–Thirring от вращения Солнца (как расширение модели).

2.3. Пояс Койпера и дальние возмущения

• Для высокой точности полезно учитывать крупные KBO отдельно + аппроксимацию “остаточной массы” (кольцо/распределение).

2.4. Астероиды главного пояса

• Возмущения от астероидов заметны в точности внутренних планет (в т.ч. Марса).
• Рекомендуется сделать уровни детализации:
  
  • Быстро: несколько крупнейших астероидов (Церера/Паллада/Веста и т.п.).
  • Точно: расширенный список (десятки/сотни) или смесь “крупные отдельно + кольцевая аппроксимация”.

2.5. Время и шкалы

• Корректная временная шкала (обычно

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

TDB / ET), аккуратные преобразования

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

TT/TDB/TCB при необходимости.[/li]
[/list]

2.6. Системы координат и преобразования

• Базово: инерциальная (ICRF/J2000/ICRS).
• Для интерфейса: эклиптика, планетоцентрические/топоцентрические системы, преобразования во времени.

3) Какие данные использовать

3.1. Основной источник “истины”: JPL DE440/DE441

• Используем для получения точных положений/скоростей (режим A) и для начальных условий (режим B).
• Формат распространения: SPICE SPK (.bsp) — удобно и стандартно для космической навигации.

3.2. SPICE kernels (NAIF)

• Код: [Выделить]
  SPK — траектории (эфемериды)
• Код: [Выделить]
  PCK — константы/параметры ориентации
• Код: [Выделить]
  LSK — leap seconds
• Код: [Выделить]
  FK — фреймы/системы отсчёта

3.3. Константы

• Для динамики лучше брать значения, согласованные с выбранной эфемеридой (GM и т.п.).
• Для “вывода пользователю” можно хранить “номинальные” значения (IAU) отдельным слоем, чтобы не путать с динамическими GM.

3.4. Альтернативы для сравнения

• INPOP (IMCCE) — полезно для бенчмарка/сравнения.
• EPM (IAA RAS) — ещё один независимый источник для кросс-проверок.

4) Технический стек на C++

4.1. Основа проекта

• Код: [Выделить]
  C++20/23
• Код: [Выделить]
  CMake
• Менеджер зависимостей: vcpkg или Conan
• CI + тесты (GitHub Actions) + регрессионные наборы

4.2. Ядро вычислений

• NAIF CSPICE (официальный C-toolkit) как база для чтения SPK/PCK/LSK и преобразований времени/фреймов.
• Eigen для линейной алгебры (вектора/матрицы/состояния 6D).
• Интегратор для режима B:
  
  • вариант 1: Boost.Odeint как базовая инфраструктура
  • вариант 2: собственная реализация DOP853/адаптивных схем + (опционально) симплектическая схема для длинных прогонов
• Логи/форматирование: fmt + spdlog
• Конфиги: JSON (например, nlohmann/json)

4.3. Валидация

• Набор тестов “положения/скорости в даты X должны совпасть с DE в пределах допуска”.
• Для режима B: графики расхождения, контроль энергии/импульса, статистика шага интегратора.

5) Интерфейс (UX) и функции

5.1. Два фронтенда

• CLI: пакетные расчёты, экспорт CSV/JSON, сравнения моделей, быстро для науки и автоматизации.
• GUI: Qt или ImGui+OpenGL/Vulkan для 3D-сцены, таймлайна, параметров, графиков.

5.2. Основные сценарии

• Показать траектории планет за интервал времени, выбрать систему отсчёта и центр (SSB/Солнце/Земля).
• Сравнить: “DE440 (эталон)” vs “моя интеграция” с разными эффектами.
• Экспортировать эфемериды выбранного тела с шагом (например, каждые 6 часов).
• Показывать метрики точности/стабильности:

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

Δr(t), Δv(t), RMS, max

, дрейф энергии, статистику адаптивного шага.[/li]

5.3. Панель “уровень физики”

• Newton only
• + 1PN
• + Sun J2 (если добавим)
• + Lense–Thirring (опция)
• + KBO (кольцо/крупные отдельно)
• + астероиды (уровни детализации)

6) Реалистичные ожидания

• Если цель — максимально точные положения планет “как в астрономических эфемеридах”, главный путь — режим A (DE + SPICE).
• Если цель — исследовательский симулятор с гибкой физикой, нужен режим B, но без подгонки к наблюдениям он со временем будет расходиться с эталонными эфемеридами.

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

Если цель — максимально точные положения планет “как в астрономических эфемеридах”, главный путь — режим A (DE + SPICE).
Если цель — исследовательский симулятор с гибкой физикой, нужен режим B, но без подгонки к наблюдениям он со временем будет расходиться с эталонными эфемеридами

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

[crimchik]

Да, вчера закончили обсуждать проект более мощного и серьезного комплекса на языке C++. я получил целую кучу интересных и функциональных обещаний  отдельно обсудили возможность импорта данных по траекториям из этого каталога "...есть на Питоне атлас астероидов, где есть и планеты, и луны тоже - https://gitverse.ru/astrogeoscenter/atlas_of_asteroids..." для анализа и моделирования - посмотрим как все это будет реализовано, и будет ли вообще
из интересного: сетка составила подробное техническое задание с детальным указанием технологического стека для каждого из этапов , затем составила пошаговый план разработки для 3 отдельных этапов . я правда больше половины не понял, поскольку непосредственно с языком C++ не контактировал. но тем интереснее.

[Ph_user]

В паралельные вычисления кроме многопоточности времен первых двухкоровых процесоров надо уже добавлять все наличные симды до авх512 в новейших зионах и зенах. И оптимизацию многопоточности частями на коровые кеши л1/л2 вместо тяганий всей задачи тупым лупом из хострама через жалкую шинку в 2 канала малоимущим. Желательна промежуточная оптимизация на общий л3 кеш. В настройках програмы должно быть ручное указание размеров кешей под оптимизацию или без начальных рукопашных настроек програма должна сама смотреть размеры кешей и предлагать оптимизацию по решению програмы с возможностями рукопашных изменений.
В програме очень желательны режимы автоматической оптимизации производительности по результатам анализа тестовых прогонов задачи пользователя (в указаных размерах-конфигурациях задачи) разными вариантами исполнения и выбор наиболее быстрого варианта на наличной исполняющей машине. Уже типа конец первой четверти 21 века вместо начала первой четверти с первой 2процесорной платой в хозбыт и уходом от ммх к началу уже ссе - нада ставить роботам более взрослые задачи на програмы.

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

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

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

Вы правы, для больших задач необходимы параллельные вычисления, на что интерпретатор Питона в принципе не  способен, или ползает со страшными костылями. Тут только C++ или Object Pascal (в коробке Delphi есть модуль Threads.Parallel.Library на ядрах, не считая Cuda/OpenCL на GPU), Фортран идёт лесом. Вот ИИ пусть действует следующим образом - создаст точную астрометрическую модель СС на Питоне, раз он его знает и владеет как кодировать метод N-body. Сравнит с готовым атласом на Python, потом переведёт это дело на С++, распараллелит и оптимизирует код, чтобы бинарник работал точнее и быстрее. Вот тогда и можно посмотреть, что получится в итоге у этого искусственного умника.

[huch]

надо оптимизацию на внешние ускорители через мало зависимые от вендора апи

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

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

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

Ничего огриничивать нельзя, вы тем самым идеализируете систему, устраняя возможные возмущения массивных тел, и не очень, на орбиты. То-есть внося ошибки в систему. Или вы забыли как были открыты некоторые планеты? Всё должно быть по максимуму того, что есть в программе для сравнения, например, в указанном атласе на Питоне для Windows. А дальше уже можно добавлять функциональность по указаниям ИИ.

[crimchik]

надо оптимизацию на внешние ускорители через мало зависимые от вендора апи

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

Да, во время разработки оптимизаторов сетка спросила меня насчет видеокарт - у меня трехлетний rtx 3060. и говорит, что реальная выгода от перехода на видеокарту будет только при количестве объектов от 2000. если количество объектов меньше, то имеет смысл оставаться на процессоре.

[crimchik]

расскажу немного деталей . весь вечер сижу, жду пока установится qt6 через менеджер пакетов vcpkg . все файлы по этапу номер 1 (базовая версия mvp) уже написаны, но я не могу их запустить для проверки . сетка говорит, что обязательно нужно выполнить cmake --build . в питон в этом плане гораздо проще , поскольку можно запускать файлы напрямую через python filename.py

Апдейт спустя полтора часа и 4 попытки скомпилировать проект , mvp наконец - то запустился https://github.com/fortser/solar_cplus