ГАО2012

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

 

Посмотрите пример на С в вики.

 

Посмотрел. Убедился, что распределенные вычисления, даже на С пока не реализовали.)

 

Спасибо, сейчас попробую.
Зачем там многопроцессорность? Для геоида EGM96 там вообще все почти мгновенно считается, даже если в лоб делать (суммировать), а уж если использовать суммирование Кленшоу, так и еще быстрее. Для геоида 2008 года (который до 2190 степени) еще не пробовал - пока тренируюсь "на кошках". За ссылку на исходники на С++ спасибо, но мне пока проще работать с той программой на фортране - я для нее статью этого автора нашел и разобрал теорию. Будет время - обязательно посмотрю и этот материал. А по второй ссылке там только исполняемые программы и файлы с параметрами геоидов, но то же спасибо - сравню с тем, что уже успел накачать. Хотя, конечно, по этой программе высоту в БС не получить - для этого хорошо бы знать геопотенциальное число для футштока, но я его не нашел. Так что буду сам его считать.

 

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

 

Вся (полная) теория здесь. В программе дана ссылка на этот отчёт

Цитата со странички https://geographiclib.sourceforge.io/html/gravity.html#gravityinst

Reybermak, вам знакома страничка Software optimization resources?

--- Сообщения объединены, 27 дек 2017, Оригинальное время сообщения: 27 дек 2017 ---

Reybermak, не знаю, обратили ли вы внимание на последний рисуночек из поста ГАО2012?

 

На страничке кстати грамотно написано:
"Вычислите значения по нескольким широтам ПАРАЛЕЛЬНО. Один из самых простых способов сделать это с OpenMP на 8-процессорной системе Intel с тактовой частотой 2,66 ГГц, это МОЖЕТ ускорить вычисления в 8 раз."

Осталось только приобрести 8-процессорную систему Intel и попробовать.

А если запустить программу одновременно на 100 компьютерах, для вычислений сразу по 100 различным широтам, то вычисления гарантированно ускорятся в 100 раз.
И еще, сравните утверждения "Модель egm2008 использует более 2 миллионов сферических гармоник. По этой причине вычисления с использованием этой модели могут быть медленными" и "там вообще все почти мгновенно считается". Если мгновенно считается то, что должно считаться долго, то очевидно, считается что то не то. Два миллиона итераций, это явно не мгновенно.

 

Оффтоп

8 процессорные AMD Ryzen 7 не такие уж и дорогие.
цены на 8 процессорные Зеоны в Москве – от 13 тыр. (да, это Sandy Bridge, 2012 год, но 8-процессорный!)
А вот 18-ядерные Intel Core i9 для простых смертных, как по мне, уже кусаются.

 

Оффтоп

Сомневаюсь, что Reybermak-а есть реальная 8-ми процессорная система. А в случае с виртуальными процессорами, выигрыша в производительности не случится. Кстати, для математических вычислений более критична тактовая частота процессора, чем остальные его навороты. Поэтому с подобными задачами лучше справится система на Pentium IV 3.5 ГГц, чем система на Core i9 2.8 ГГц

--- Сообщения объединены, 27 дек 2017, Оригинальное время сообщения: 27 дек 2017 ---

Прямо обленённым себя почувствовал, т.к. застрял на i5 прошлого поколения. Правда "добрые языки" утверждают, что эта i5 помощнее иных последних i7, но льстят наверное.)

 

Оффтоп

Прошлого – это какого, Skylake?

--- Сообщения объединены, 27 дек 2017, Оригинальное время сообщения: 27 дек 2017 ---

 

Я нашел другую статью, не такую полную, так что спасибо за ссылку - я обязательно посмотрю, хотя с теорией я уже более или менее разобрался. Но насколько я понял высота в БС - это не совсем высота над геоидом (или точнее совсем не). Для этого надо определить полный потенциал для Кронштадского футштока и уже относительно него и считать высоту.

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

Про оптимизацию. Я сразу не написал - для моей задачи она не нужна, т.к. я перевожу только одну точку, а не строю карту для всей Земли.

Я видел рисунок в посте про ГАО2012, но не понимаю что он мне дает? Значение GM я итак знаю. Или Вы имели ввиду величину полного потенциала W в таблице?

 

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

 

Тогда я не понял, так как по этой ссылке нет формулы для нормального потенциала. А вообще нормальный потенциал я считаю по общей формуле - сумма произведения сферических функций Jn на полиномы Лежандра Pn.
Немного почитал сейчас отчет ICGEM и понял что я еще не совсем понимаю как все устроено (в программе считается высота геоида N приближенно, как я понял методом Ньютона), а потом еще есть какая-то добавка, вычисляемая исходя их средней плотности земной коры. Буду дальше разбираться. Для этого заказал на работе достать книгу Hofmann-Wellenhof, B. & Moritz, H., 2005, Physical geodesy, на которую активно все ссылаются. Буду читать. А пока я разбираюсь с программой на фортране - она у меня скомпилировалась, но значения в ней расходятся с моими где-то на 1 сантиметр и я пока не понимаю - это закралась ошибка в мою программу или это просто накопилась ошибка вычислений из-за немного разных подходов. Видимо, теперь уже после праздников продолжу - вряд ли удастся найти время на них.
В любом случае огромной спасибо за последние ссылки - они очень полезны.

P.S. Просто удивительно как много материалов по данной теме есть на английском языке - статьи, программы, сайты, книги, и как мало есть на русском. А то что есть - с ошибками. Например, в документе система ПЗ 90.11 от 2014 года в формуле для сферической функции Jn ошибка - они неправильно вынесли двойку. А ГОСТ 2017 года хоть уже и появился, но еще не вышел официально и в том что я видел тоже куча ошибок, но может это была предварительная версия.

 

Если брать те параметры GM и угловой скорости для эллипсоида Красовского из картинки, которая была в том посте (ну и всем известные значения сжатия и большой полуоси для элл. Красовского) и использовать их для расчета аномалий высоты на ICGEM (ну и использовать значения сжатия и большой полуоси для элл. Красовского), то результаты будут просто ультра чудовищные.

 

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

 

Вы когда это пишите, вспоминайте иногда про А. А. Изотова с арифмометром, который полигоны уравнивал.

 

Нечасто встретишь человека, которых по собственной инициативе будет читать Морица. В конце 70-х Гельмут Мориц, по приглашению Юрия Михайловича Неймана, читал обзорные лекции по физической геодезии в МИИГАиК. "Новое" здание ещё не было построено, лекции читались в самой большой на тот момент аудитории – 56. Студенты сидели на ступеньках и на полу, перед первым рядом. Э-э-х, были времена, а сейчас мгновения, раньше… а сейчас – давление.
Перевод книги на русский язык можно найти здесь. Рядом и оригинал. Помню, что Людмила Валентиновна Огородова была недовольна переводом, даже статью написала, но суть претензий сейчас не помню.

Да, это самое поганое, когда результаты не совпадают чуть-чуть. Для начала, если используется, то уберите опцию -ffast-math.

Я забываю, что вы не геодезист. Ключевой является фраза "… а гравиметрические наблюдения обрабатывают с использованием формулы Гсльмерта"

Что совсем не удивительно, зная кто отвечал за появление конкретно этого документа. Если вы имеете в виду эту формулу
то эта херня, если не забыл, тянется ещё со времён "красной книжки" (красная книжка, так мы называли методику по выводу ПЗ-90. Это был весьма увесистый талмуд в красном коленкоровом переплёте, где золотом было вытеснено по центру слово МУССОН, а в правом верхнем углу – секретно)

Если вы о ГОСТ 32453-2017, то я там тоже с ходу нашёл неверный знак в матрице вращения.
Для меня самым прикольным является пункт:
5.4.1 Для получения плоских прямоугольных координат в принятой на территории Российской
Федерации проекции Гаусса-Крюгера используют геодезические координаты на эллипсоиде Красовского.
Система координат у нас теперь 2011 года, со своим эллипсоидом, а прямоугольные координаты всё ещё связаны в этом ГОСТе с эллипсоидом Красовского. Дебилы, …
Но я вам больше скажу, ошибки в формулах в интерфейсном контрольном документе по ГЛОНАСС исправили совсем недавно. Сделали это втихаря, по-воровски, без изменения номера версии документа, оставив старую дату утверждения документа.

В этом вы правы.

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

"В одну телегу впрячь не можно коня и трепетную лань"

--- Сообщения объединены, 28 дек 2017, Оригинальное время сообщения: 28 дек 2017 ---

Оффтоп

Я иногда думаю, а как бы развивалась наука, появись компьютеры во времена Гаусса или маркиза де Лапласа. А ведь по историческим меркам они жили совсем недавно. В Америке ещё живы внуки (именно внуки, не правнуки или праправнуки) 10-го президента (Джон Тайлер), родившегося в 1790 году. А Гаусс родился 30 апреля 1777 г

 

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