Автор Тема: Помогите поправить методику определения LOD и понять удивительные графики  (Прочитано 15437 раз)

0 Пользователей и 2 Гостей просматривают эту тему.

Оффлайн vasnas

  • *
  • Сообщений: 1
    • Просмотр профиля

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

Я решил разобраться с Дельта-Т (delta-T),  накопившимся сдвигом во времени суток для древности, когда для эпохи, например, 1 г.н.э. необходима поправка в 3 часа во времени суток!

см. график

см. так же http://hpiers.obspm.fr/eop-pc/index.php?index=lod-1623&lang=en
и http://eclipse.gsfc.nasa.gov/SEhelp/deltaT2.html

А это существенно. За три часа полоса затмения, пройдет в сотнях и тысячах километров от наблюдателя, т.е. затмения не будет в предполагаемом месте. Это значит вопрос об идентификации древних наблюдений остается открытым без решения проблемы дельта-T

Так же при другом времени суток, планета может быть не наблюдаема на небе или наоборот, что важно при идентификации эпохи древних астрономических наблюдений.

Дельта-Т  можно представить, как разность между атомным временем, с 864000 секунд СИ в сутках и временем UT (универсальном), в котором время суток определяется по солнцу, т.е. секунды UT, то сжимаются, то растягиваются, в зависимости от ускорения или замедления вращения Земли. Во времени UT в календарных сутках тоже 864000 секунд, но их общая продолжительность укладывается от полудня до полудня (когда солнце в высшей точке), а в более современной трактовке рассматривается период тропического года, от равноденствия (предпочтительно весеннего) до равноденствия.

В работе http://bible-exodus.eu.pn/articles/astro_ephemeris/jpl_ephemeris/jpl_ephemeris.html#zet_vs_spice

я пытался сравнивать точность программного инструментария, но понял, что прежде сравнения программ,

(а, например, астропроцессор ZET имел поразительные ошибки, например, звезда 61 Cygin (61 Лебедя) пролетала в нем «полнеба» за 1000 лет, а в геоцентрическом виде выдавался горизонт Земли. Сейчас исправлено. Или интерфейс SPICE NASA выдавал время UTC на период выходящий за 72-2013 годы, когда его не существует …)

нужно разобраться с эфемеридами (предвычесленные опорные точки орбит) на основе которых эти интерфейсы работают.

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

Как раз были выпущены новые эфемериды DE431 от JPL NASA.

В них на периоде с 7.05.13201 B.C. (ET) по 1.03.17191 A.D. (ET) была реализована расчетная модель вращения Земли IAU_EARTH (по теории одобренной Международным Астрономическим Союзом – IAU)
Сегодня мы наблюдаем равномерное замедление вращения Земли, обусловленное многочисленными факторами, например, приливным и атмосферным трениями и т.д.
Точные значения фактического времени суток измеряются и их можно подключать в расчетах с помощью файла данных, например, earth_720101_070426.bpc на период 20.1.1962-26.4.2007 см. http://bible-exodus.eu.pn/articles/astro_ephemeris/jpl_ephemeris/jpl_ephemeris.html#what_to_download
Для древности доступна только расчетная модель вращения Земли вокруг своей оси IAU_EARTH.


Мой метод определения средней продолжительности суток (mean LOD – length of day).

Средней, здесь за год. Дело в том, что из-за эксцентриситета Земной орбиты Солнце то быстрее ходит по небу то медленнее, эти колебания описываются аналеммой, которая раньше применялась в поправках ко времени солнечных часов. День ото дня может быть короче до ~20 сек или длиннее до ~30 сек, а полдень наступает раньше на ~ 14 минут в ~'06.02.19?? 12:00 UTC' и через 16 мин после ~'03.11.19?? 12:00 UTC'. Т.е. ежедневные замеры полудня напрямую бесполезны.

Поэтому я беру от определенного момента (афелий, перигелий, равноденствие, солнцестояние) 365 солнечных суток и делю этот период на 365, получая, таким образом, среднюю продолжительность суток за ~год. Остаток в ~1/4 я отбрасываю, чтобы исключить лишнию погрешность при возне с этим «хвостом». Т.е. я делю именно период в 365 солнечных дней на 365, то отбрасывание этого остатка всего лишь дает повод назвать мой метод, метод 365 солнечных суток.

Период в 365 суток я определяю по тому же азимуту солнца, что и в начале периода. Т.е. измеряю азимут солнца на момент, например, равноденствия, а потом ищу такой же ближайший азимут солнца через 365 оборотов Земли вокруг своей оси, или через ~864000 сек. СИ * 365, т.к. мне заранее известно, что длина суток значительно не изменилась для древности.

И так следующие годы, на период в несколько тысяч лет.

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

См. http://vasnas.livejournal.com/228652.html

Последний обсуждаемый график новых DE431 эфемерид.


Получается вращение Земли вокруг своей оси в древности ускорялось,  потом почти ожидаемая прямая замедления в историческом интервале, потом опять ускорение до 6000 г.н.э. и потом вращение Земли опять замедляется.
За начальную точку годовых периодов я взял весеннее равноденствие, т.к. в предыдущих опытах это давало линейное изменение длительности суток, хотя в сторону их уменьшения. Инженер НАСА Вильям Фолкнер, автор эфемерид DE431 отметил мне, что график изменения времени суток в расчетной модели IAU должен быть линейным, а у меня нелинейный. Он не понимает моего метода расчета, хотя я ему и объяснял его. Прошу мне помочь и найти ошибку. Желающих неконструктивно убить мое время на подколки, другие темы и пустую болтовню, прошу пойти в другие темы.

См. http://vasnas.livejournal.com/232034.html
Мой скрипт для MatLab  доступен здесь (внизу 1-го поста)  http://www.chronologia.org/dcforum/DCForumID2/14372.html