Друк

[Гість]

Ласкаво просимо, Гість. Будь ласка, увійдіть або зареєструйтеся.
23 Березня 2026, 18:27:53

1 година 1 день 1 тиждень 1 місяць Назавжди

Увійти

[Новини]

•    Новини
•      Астрономія
•      Астрозаходи
•    Життя клуба
•      Новини
•      Проекти
•      Заходи
•      Звіти про спостереження
•      Документи
•    Статті
•      Обладнання та телескопи
•      Спостереження
•      Астрофотографія
•      Астрософт
•      Астрономія в Україні
•      Астрономи шуткують
•      Інше
•     
•      Файловий архів

Наш канал

Наші сайти

Астро-сайти

Програми

Наш канал

Наші сайти

Астро-сайти

Програми

[Oleg Astro]

Всім привіт!
Давно я тут не був...

Отже, на днях розпочав мій "пет проект" у програмуванні, котрий для душі і для загальної астрономічної користі.
Я про астрономічну бібліотеки, котрі програмісти підключають до свого софту.

Наразі у світі існують різні астрономічні бібліотеки під різними ліцензіями і різних рівнів точності обчислень, написані на FORTRAN, C, C++...

Я пишу бібліотеку на C++23 в IDE CLion. У ролі компілятора, використовую Ubuntu clang version 20.1.8

Кожен модуль/функція має свій бінарник для тесувань, бо треба не 3-5 тестів, а 30-50 мінімум.

Очевидно, що точність обчислень залежить від застосованих формул і т.п.
Код треба "крутити на всі боки", щоб знаходити його слабкі місця...

Що на це скажете?...

[Oleg Astro]

=== Базові стандарти / високоточна астрометрія
***  SOFA (IAU Standards of Fundamental Astronomy)

офіційна від IAU

золотий стандарт

час (UTC/TAI/TT/TDB), прецесія, нутація, трансформації систем координат

C + Fortran

- Якщо потрібна максимальна наукова коректність — це база.

*

Скрытый текст

**  ERFA (Essential Routines for Fundamental Astronomy)

форк SOFA з більш вільною ліцензією (BSD)

API майже 1:1 як SOFA

використовується в Astropy

- Фактично SOFA без ліцензійних обмежень.

=== Ефемериди / рух тіл Сонячної системи
***  SPICE Toolkit (NASA NAIF)

дуже потужний

орбіти, позиції, орієнтації КА, планет, місій

працює через SPK/CK/PCK kernels

C / Fortran / Python (SpiceyPy) / MATLAB / IDL

Можна:

де була Cassini у 2005?

куди дивився телескоп?

точні вектори стану тіл

- де-факто стандарт для космічних місій

***  JPL DE Ephemerides (через бібліотеки типу jplephem)

DE430/440/441

дуже точні координати планет/Місяця

Python: jplephem, skyfield

- коли треба максимальна точність положень планет

===  Python-екосистема (зручно для розробки)
***  Astropy

величезний комбайн

координати, час, ефемериди, FITS, фотометрія

всередині використовує ERFA + JPL

Має:

astropy.coordinates

astropy.time

astropy.units

- якщо хочеш швидко і красиво робити астрономію в коді

***  Skyfield

сучасні ефемериди на Python

простіший ніж SPICE

читає JPL kernels

дуже зручний API

- ідеальний для:

позицій планет

сходу/заходу

орбіт супутників (TLE)

***  poliastro

орбітальна механіка

маневри, трансфери Гомана, propagation

базується на Astropy

- для астродинаміки/орбітальних задач

=== C/C++ / низькорівневі
***  libnova

легка C-бібліотека

координати, час, ефемериди

проста і швидка

- для embedded/невеликих проєктів

***  NOVAS (US Naval Observatory)

ще один «офіційний» пакет

схожий за рівнем із SOFA

точні астрометричні розрахунки

C/Fortran

- альтернатива SOFA з боку USNO

Подякували

4 :AYN, Edward, ds40a, SIDEROCRATOR

[ds40a]

...
Що на це скажете?...

Круто!

Самі займаєтеся чи помічники є?

[Oleg Astro]

Копаю разом з ШІ чатами, щоб докладно виясняти різні тонкощі.

[ds40a]

А що спонукало почати цю роботу?

[Oleg Astro]

Однозначно, що моє бажання ще глибше у цьому розібратись і реалізувати у готовому продукті
.

[tlgleonid]

Моделі JPL (DE440) є фактично інтегруванням по траекторіям з розрахунком реперних точок і апроксимацією між ними. Тобто модель вже є розробленою і для кінцевого розробника там залишилась лише гола математика без жодної фізики. Я так розумію, що планується створити оболонку під модель?
І я чомусь думав, що людина, яка живе в ЄС обере трохи інший підхід моделі INPOP. Чому саме JPL?

[Oleg Astro]

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

Наприклад, є бібліотека ERFA (Essential Routines for Fundamental Astronomy) - компактна open source C бібліотека з еталонними алгоритмами фундаментальної астрономії.

Щось подібне і я пишу, але замість типу double використовую переваги real128, що дає точність розрахунків до 1e-34.

[ds40a]

AI каже, що real128 не має апаратної підтримки у процесорів, тому емулюється через це щвидкість обчислень знижується. По друге real128 має 33-36 зачущих ціфр. Чи достатньо це для астрономічних розрахунків? Ви писали, що радилися з AI при прийняті рішень. Які критерії до бібліотеки ви використовували?

p.s.  Це відповідь gemini на запитання
C++ бібліотека для астрономічних обчислень (ефемериди, інтегрування орбіт, сонячні системи) все таки що порадите використовувати?

Для професійних астрономічних обчислень у C++ вибір залежить від того, чи вам потрібні готові дані про положення планет (ефемериди), чи ви хочете самі інтегрувати рівняння руху (симуляція).
Ось найкращі варіанти:
1. NASA SPICE Toolkit (найпотужніша)
Це "золотий стандарт" в аерокосмічній галузі. Якщо вам потрібно знати, де буде Марс відносно Землі 12 квітня 2029 року з урахуванням усіх релятивістських ефектів — це ваш вибір.
Функції: Читання ефемеридних файлів (SPK), перетворення координат (J2000, галактичні тощо), розрахунок часу (TDB, UTC).
Посилання: NAIF SPICE Toolkit.
Версія: Для C++ використовуйте бібліотеку CSPICE.
2. REBOUND (найкраща для інтегрування)
Якщо ваша задача — кинути астероїд у Сонячну систему і подивитися, що з ним станеться через 1000 років.
Функції: Надшвидке та прецизійне інтегрування задачі N-тіл. Підтримує різні методи (IAS15 — адаптивний крок, дуже висока точність).
Перевага: Дуже стабільна при симуляції хаотичних орбіт.
Посилання: REBOUND на GitHub.
3. Boost.Numeric.Odeint + Boost.Multiprecision
Якщо ви пишете власну математичну модель з нуля і вам потрібна точність > 50 знаків.
Функції: Це конструктор. Ви берете Odeint для вирішення диференціальних рівнянь і підставляєте туди типи з Multiprecision.
Перевага: Дозволяє проводити інтегрування з будь-якою кількістю знаків після коми.
Посилання: Boost.Odeint Guide.
4. SOFA (Standards Of Fundamental Astronomy)
Бібліотека від Міжнародного астрономічного союзу (IAU).
Функції: Найточніші алгоритми для прецесії, нутації та перетворення часу.
Для кого: Для тих, кому потрібна фундаментальна точність в алгоритмах, затверджена міжнародною спільнотою.
Посилання: IAU SOFA Library.
Підсумок: що обрати?
Потрібні готові координати планет NASA? — SPICE.
Потрібна швидка симуляція багатьох тіл? — REBOUND.
Потрібна екстремальна точність (50+ знаків) для власної формули? — Boost.
Потрібні фундаментальні алгоритми (зірки, календар)? — SOFA.

Подякували

1 :Oleg Astro

[Oleg Astro]

То ж такий мій "пет-проект" 

Ну так. Я ж використовую комп'ютер із залізом  на 64-біти.

[Саша Наумов]

Хочу додати свої 5 шагів, як професійний С/С++ розробник.

Писати таку бібліотеку в якості pet project - непогана ідея.
Згадати сферичну тригонометрію, аналітичну геометрію в 3D, розібратись з системами часу і т.і.
Це все цікаво, я грався з такими штуками. Використовував VSOP і ELP від Паризького Бюро довгот, транслював з фортрану на С; хотів ще JPL DE405 додати і почав, але не закінчив.
Та банально розрахувати обставини прольоту заданого супутника в заданому місці і часі - то вже нетривіальна задача. Я коли спробував, швидко зрозумів що треба писати свій код.

Але. Існує маса факторів, чому така уявна бібліотека так і залишиться пет проектом.
Наприклад. От Ви кажете, real128 замість double. А чи знаєте Ви розподіл похибки обчислення синуса від аргумента real128 ? Як він співставляється з вказаними 1e-34? Я маю на увазі, що неточна або приблизна функція синуса зведе нанівець усі зусилля.
Також, не знаю, які фішки саме С++'23 використовуються і де там C++. Оператори перевантажувати?
Якщо треба 128-бітний floating point - то він підтриманий gcc і в С і в С++, тут 23 стандарта взагалі не потрібно!

Подякували

1 :Oleg Astro

[Oleg Astro]

Всім дякую за відповіді, бо вони мені допомагають формувати як загальну картину, так і тонкощі, котрі дуже різні.

Чому саме ця бібліотека, а не щось там інше?
Бо я вже доволі давно думав над "пет проектом", над котрим мені було б цікаво сидіти.
Звісно, що я читав різні приклади та пропозиції щодо подібних проектів, але вони " душу мені не гріли"

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

Щодо точності обчислень - то її мало, як такої.
Бо типи даних float, double, real128 - це межа представлення числа, але не про власне точність реалізації функцій.

Інакше кажучи, real128 дає гарантію зберігання числа π = 3.141592653589793238462643383279502884Q, проте нічого нам не каже, наскільки реально точним до 1e-34 будуть власне обчислені значення типу там sin(π/12), exp(x), atan(x) та інші функції, бо це вже про поліноми.

[Oleg Astro]

Моє дослідження ось які результати показало для sin(Pi/7):

0.4338837391175581204757683328483587 546099 907..020    // еталон
0.4338837391175581204757683328483587 546099 907...021   // BOOST
0.4338837391175581204757683328483587 546100                   // MPFR
0.4338837391175581204757683328483587 317387                   // 29 ступінь поліном
0.4338837391175581204757683328483587 317387                   // 27 ступінь поліном
0.4338837391175581204757683328483587 317387                   // 25 ступінь поліном
0.4338837391175581204757683328483587 317387                   // #include <quadmath.h>
0.4338837391175581204757683328483585 872939                   // 23 ступінь поліном

З оглядом на інші сторони, є смисл використовувати MPFR.

[tlgleonid]

Чесно кажучи, не бачу потреби в надвисокій точності тригонометричних розрахунків, бо вони використовуються переважно при поворотах систем координат і зазвичай достатньо точності 15 знаків. А так, фактично йде оперування координатами в певній визначеній системі координат (наприклад, еліптична система координат з центром в барицентрі сонячної системи) з алгебраїчними операціями.

[ds40a]

Чесно кажучи, не бачу потреби в надвисокій точності тригонометричних розрахунків...

Як на мене, не можна покладатися на інтуіцію, поки достаменно не з'ясовано, що буде достатньою точністью для задач які ставить перед собою Олег. Оскільки це поки не встановлено, то термін "надвисока точність" немає сенсу вживати. А якщо немає можливості достаменно визначити "достатню точність" то, як на мене, потрібно шукати компроміс між використанням маскимально можливої, швидкістью обчислень і зручностью викорнистання.

p.s. Це мої власні думки. Я не знайомий з галуз'ю для якої створює бібліотеку Олег. Але я знаю до чого можуть привести похибки, які пов'язані з використанням типів з плавючою комою при застосуванню у фінансових розрахунках. Тому з предосторогою ставлюся до вибору представлення чисел там де з ними виконуються математичні оперції.

[Oleg Astro]

По суті, кажу я взяв за основу документацію бібліотеки SOFA, що створити бібліотеку.
Власне коди SOFA мене не цікавлялять з відомої причини... щоб клон не вийшов.

Я досліджую цю тему більш глибоко, як в теорії обновити та поглибити - так і в реалізації на комп'ютері.

[tlgleonid]

Наскільки я розумію, якщо мова про інтегрування по траекторіям, то для того, щоб знати положення планет в кожен момент часу, необхідно створити аналог DE440, але всі підрахунки робити з підвищеною точністю. Проблеми виникають, оскільки чим вищу точність ми хочемо отримати, тим більшу кількість факторів треба враховувати, в тому числі і тих, які ми не можемо передбачити (спалахи на Сонці, невідомі комети, значну кількість астероїдів і невідомі планетоїди... ).

[Oleg Astro]

Зараз читаю документацію SOFA і релізую функції без підглядання в коди.

[Oleg Astro]

Що можу сказати про бенчмарки, коли мова йде про написання астрономічної бібліотеки типу SOFA?

MPFG - це абсолютно немає смислу, а ще дуже повільно.
Real128 - це дуже надлишково, обчислювально дорого і непотрібно для 99% функцій.
long double - це вже непогано, але десь в 2-3 рази повільніше, ніж double.
double - це достатньо для 99% "випадків астрономічного життя".

[Oleg Astro]

Отже, вже почалась реалізація коду астрономічної біібліотеки, котру я вирішив назвати AstroNix (Astronomy + Unix) .
Ліцензію вирішив взяти GNU General Public License v3 (GPLv3).

Назви файлів у стилі one_to_tree.*, бо оці oneToTree.* та one2tree.*, мені "ламають очі", не кажучи вже про шедевральні o2t.* , котрі "воопше моск видобують".

Щодо "базової" точності чисел із цілої та дробовою частинами  - то вона double.

Створений окремий файл, у якому задані псевдоніми типів для кодів всього проекта:

Код: [Select]

using real_t = double;
using int_time_t = long long;...

Формат юліанської дати в бібліотеці я взяв класичний, котрий розділений на цілу та дробову частину, для підчищення точності обчислень:

Код: [Select]

struct julian_date {
    real_t jd_int;   // Full days (integer part of Julian Date)
    real_t jd_frac;  // Fraction of the day [0.0 to 1.0)
};
Простір імен: namespace astronix { }

Ось такий стиль заголовків файлів.
Що виправити?
Що додати?...

Код: [Select]

/**
 * @file ast_constants.cppm
 * @path astronix/src/core/
 * @brief Standard precision constants for AstroNix (64-bit double).
 *
 * @project AstroNix: Astronomical Library
 * @created 2026-02-07 00:08:45 UT
 * @author [Developer Name]
 *
 * @modified 2026-02-08 12:55:00 UT
 * @modifier [Modifier Name]
 *
 * @sources
 * 1. IAU (International Astronomical Union) 2012 Resolutions.
 * 2. JPL Solar System Dynamics (SSD) - Planetary Constants.
 * 3. CODATA 2022 recommended values for fundamental physical constants.
 *
 * @license GNU General Public License v3 (GPLv3)
 * @note All angular data is stored and processed strictly in RADIANS.
 *
 * @checksum 0xB3C4D5E2
 */

export module ast_constants;

export namespace astronix::core {
    /**
     * @brief Pi constant.
     * Source: Mathematical standard.
     */
    export constexpr double PI = 3.14159265358979323846;

    /**
     * @brief Astronomical Unit in meters.
     * Source: IAU 2012 Resolution B2.
     */
    export constexpr double AU = 149597870700.0;
}