Задачка математическая. Теорию распределенных вычислений пока не изобрели. Зачем при решении математической задачки поддержка многопроцессорности? На данном этапе, многопроцессорность дает только мультизадачность.
Спасибо, сейчас попробую. Зачем там многопроцессорность? Для геоида 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 миллионов сферических гармоник. По этой причине вычисления с использованием этой модели могут быть медленными" и "там вообще все почти мгновенно считается". Если мгновенно считается то, что должно считаться долго, то очевидно, считается что то не то. Два миллиона итераций, это явно не мгновенно.
Оффтоп (Move your mouse to the spoiler area to reveal the content) 8 процессорные AMD Ryzen 7 не такие уж и дорогие. цены на 8 процессорные Зеоны в Москве – от 13 тыр. (да, это Sandy Bridge, 2012 год, но 8-процессорный!) А вот 18-ядерные Intel Core i9 для простых смертных, как по мне, уже кусаются.
Оффтоп (Move your mouse to the spoiler area to reveal the content) Сомневаюсь, что Reybermak-а есть реальная 8-ми процессорная система. А в случае с виртуальными процессорами, выигрыша в производительности не случится. Кстати, для математических вычислений более критична тактовая частота процессора, чем остальные его навороты. Поэтому с подобными задачами лучше справится система на Pentium IV 3.5 ГГц, чем система на Core i9 2.8 ГГц --- Сообщения объединены, 27 дек 2017, Оригинальное время сообщения: 27 дек 2017 --- Прямо обленённым себя почувствовал, т.к. застрял на i5 прошлого поколения. Правда "добрые языки" утверждают, что эта i5 помощнее иных последних i7, но льстят наверное.)
Оффтоп (Move your mouse to the spoiler area to reveal the content) Прошлого – это какого, 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 --- Оффтоп (Move your mouse to the spoiler area to reveal the content) Я иногда думаю, а как бы развивалась наука, появись компьютеры во времена Гаусса или маркиза де Лапласа. А ведь по историческим меркам они жили совсем недавно. В Америке ещё живы внуки (именно внуки, не правнуки или праправнуки) 10-го президента (Джон Тайлер), родившегося в 1790 году. А Гаусс родился 30 апреля 1777 г
Кстати, или не кстати, но в той программке которую я выложил выше, если все сделать точно по учебнику, тоже требуются сотни тысяч итераций на макетах, и миллионы на реальных данных. Но, достаточно учесть, что функции направляющих косинусов, в одном случае всегда равны 0, а в другом 1, и количество итераций сразу сокращается до десятков, и только в самых тяжелых случаях, когда половина данных ошибочны, количество итераций может перевалить за сотню, но никогда не достигает двух сотен. Предполагаю, что для обсуждаемой гравиметрической программы, существуют аналогичные решения. И не стоит гнаться за количеством процессоров, а стоит поискать подобные закономерности в гравиметрии, ну и перечитать вычислительную математику.
