Паралельное вычисление в Cosmos Simulаtion 2010

[skyline1604 0]

Вообщем проблема следующая: при расчете Cosmos Simulаtion 2010 на четырехъядерном компьютере используется лишь одно ядро

в Cosmos Flo Simulation..эту проблему решили начиная с 2009 версии...

Может поделитесь опытом возможно ли организовать параллельное вычисление...

Сам ща пытаюсь с MPICH танцевать, но помоему бестолку

[a_a_a+ 11]

В COSMOSWorks пользователь не может управлять числом задействованных ядер/процессоров. Чему суждено быть, тому суждено.

Все здорово завист от используемого решателя : прямой/итерационный и типа анализа.

Есть такая табличка (здесь она транслировалась в сточки)...

Первый процент - прямой решатель, второй - итерационный.

Мораль: в статических и нелинейных задачах прямой решатель распараллеливается лучше. В частотах и устойыивости - никак. Зато в этих задачах лучше итерационный.

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

==============================

Precision T7400 with Quad Core Intel Xeon X5472 @ 3.0 GHz, 16 GB RAM.

Study Type

% Improvement in Time to Solve

DOF

Model Used/Notes

Direct Sparse

FFEPlus

Static (Test 1)

58%

13%

373437

Simple part, one load and restraint

Static (Test 2)

74%

22%

66057

Assembly with bolt connectors and contacts

Static (Test 3)

71%

22%

66057

Same as Test 2 but with large displacement enabled

Frequency

0%

25%

48855

Frequency analysis of a shaft, 20 frequencies

Buckling

0%

14%

122940

3 plates-surfaces model, 10 modes

Thermal (Test 1)

81%

0%

15345

Computer chip example, steady state

Thermal (Test 2)

82%

0%

15345

Same as above model but transient thermal

Nonlinear (Test 1)

58%

0%

48360

Elasto-plastic nonlinear static analysis, single part, no contacts

Nonlinear (Test 2)

62%

0%

48360

Same as above but nonlinear dynamic with base excitation

===================================

Ну и кому охота "improve English", то...

Notes

When looking at CPU usage in Task Manager, 100% indicates that all four CPUs are being used at maximum capacity. 25% indicates that one CPU is being used at full capacity.

In general, the Iterative solver (FFEPlus) did not show usage beyond 60% which could imply full usage of two CPUs and partial usage of a third.

Direct Sparse showed the greatest improvement in performance during the matrix decomposition stage, where for most testing done the total CPU usage was 99%.

Even for solver stages or study types which use only one core, there is still a minor benefit to having more than one CPU since it makes it possible to allocate an entire core to the solver while leaving background applications and system processes to use their own separate cores.

Nonlinear test models showed usage of more than one CPU only for certain stages of the Direct Sparse solver – during contact iterations for test model, total CPU usage stayed below 25%.

Multistep analysis such as the nonlinear one can have significant differences in multi-core performance between models depending on geometry, setup, number of contacts, etc.

[a_a_a+ 11]

Давно хотел ответить. Но как-то не было времени.

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

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

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

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

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

А вопрос-то в чём? Что COSMOS не может распараллелить процесс? Он это делает!

И это, как учили классики, объективно. То есть, не зависит от чьей-то воли и сознания.

Пишите в SolidWorks Corp., типа ваша программа опровергает законы математики, и следовательно, должна быть запрещена!

[a_a_a+ 11]

К сожалению или счастью, такими фундаментальными знаниями разработчики COSMOSWorks не обладают.

Наверное, именно благодаря этому они ухитрлись распараллелить прямой метод.

Лузеры, короче говоря.

[a_a_a+ 11]

А я не знал, что господин Алямовский разрабатывал COSMOSWorks.

Конечно, прямые методы распараллеливаются, но только гораздо хуже итерационных методов. Вы все перепутали. И эффективность распараллеливания существенно ниже.

Тов. Алямовский не разрабатывал COSMOSWorks, но алгоритмы и программы для решения СЛУ большой (в этом, на самом деле, секрет того, почему прямые алгоритмы распараллеливаются лучше, чем итерационные!) размерности создавал вполне реальные. Честно говоря, вопросами собственных значений вплотную не занимался (человеческий разум ограничен - нельзя, по моей логике, хорошо разбираться в "ИСПЕ", COSMOSWorks, ANSYS..., а также "теории МКЭ", к которой, кстати говоря, вопросы параллельных вычислений имеют весьма косвенное отношение.).

Может быть, конечно, если заниматься умозрительными рассуждениями, она (эффективность распараллеливания) ниже в прямом методе решения, чем в итерационном.

Но реальность такова, что если провести расчеты в существующией программе (в данном случае COSMOSWorks), то окажется, что прямой метод распараллелен (УЖЕ) лучше, чем итерационный.

Может быть, в продукте под названием "ИСПА", алгоритмы другие. Как говорится, "результаты в студию". Публикуйте тестовые задачи, решенные посредством того, что называется "ИСПА". Они будут воспроизведены в SW Simulation (в девичестве COSMOSWorks).

А пока не будем огорчать разработчиков информацией о том, что то, что ими сделано (и, что ценно, работает), противоречит суждениям тов. "ИСПА". А то, не дай бог, они доверятся лицам, "знающим теорию МКЭ", и ликвидируют это самое распараллеливание в надежде, что когда-то их уровень понимания "теории" позволит им распараллелить сначала итерационный алгоритм, а только потом - прямой.

И в заключение - мои соображения о том, почему, все-таки, распараллелен именно прямой алгортим. Как полагаю, чтобы распараллелить операции линейной алгебры - в конкретном случае это матричные произведения и суммы - нужно, чтобы не терялась скорость, иметь соответствующие строки-столбцы в оперативной памяти. В противном случае все время уйдет на взаимодействие с диском. Распараллеливание будет, а скорости - нет.

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

Накладными расходами на возможность работы в оперативной памяти являются в несколько раз (в COSMOSWorks, в зависимости от задачи, это 2 - 4 раза) большие затраты этой самой оперативной памяти при использовании прямых методов (здесь много зависит от схем хранения и пр.).

Итерационные же алгоритмы используют меньшую память, поскольку (по крайней мере, при решении СЛУ) не модифицируют (в линейной постановке) (насколько правильно помню!) сформированную матрицу жесткости системы, в частности, не заполняют нулевые ее члены. Поэтому, чтобы распараллелить этот процесс, нужно радикально увеличить потребную память (опертивную), тем самым увеличив (заодно) объем математических операций. Соответственно ликвидируются основные преимущества итерационных методов - малый (относительно) объем оперативной памяти и - это связанные сущности - меньший объем арифметических операций.

Грубо говоря, накладные расходы на реализацию распараллеливания сведут на нет его выгоду.

И в заключение. Еще раз и не только к этой теме.

Давайте вести позитивную дискуссию. Есть у Вас аргументированное мнение - публикуйте результаты. Я опубликовал. Нет результатов, помимо апелляций к "теории МКЭ", попытайтесь их добиться. Будет интересно.

[a_a_a+ 11]

Я много чего читал и много чего не заметил :)

Но, вот, что COSMOS распараллеливает прямой решатель заметил наверняка.

Также заметил, что итерационный распараллеливает хуже.

И это многие другие заметили.

Нам всем что теперь, отказаться от использования прямого решателя?

Или вернуться к версии 2007 года, когда распараллеливания не было?

Или дружно обратиться в SW Corp с просьбой не заниматься ерундой и вернуть старый однопотоковый решатель и сосредоточиться на модификации итерационного?

Есть у меня такое ощущение, что те, кто используют COSMOSWorks, просто займутся своей работой, благо программа им это более-менее удовлетворительно позволяет. В том числе благодаря эффективно распараллеленному алгоритму в прямом решателе.

[vl 327]

Есть у меня такое ощущение, что те, кто используют COSMOSWorks, просто займутся своей работой, благо программа им это более-менее удовлетворительно позволяет. В том числе благодаря эффективно распараллеленному алгоритму в прямом решателе.

Я бы сказал, благодаря неэффективно распараллеленному алгоритму в итерационном решателе.

Т.е. проблема в конкретной реализации в COSMOsе.

Потому как в остальном ISPA прав на все 100%.

Ну а уж что лучше реализовано в каком продукте - это другой вопрос

[_DS 45]

Если хочется гнать свою дурь на форум, то кто же запретит. Мне это не интересно.

Грубость в общении - не признак своего ума и знаний, а следствие своих комплексов. Ну это так, к слову.

[a_a_a+ 11]

Двумя голосами против одного установлено, что COSMOSWorks не распараллеливает прямой метод. Потому не распараллеливает, что просто не может этого сделать, согласно "теории МКЭ".

Посмотрите на картинки, г-да!

Это протокол монитора ресурсов Windows для первой попавшейся задачи в ходе счета прямым и итерационным методами. Обратите внимание, что итерационный метод также распараллелен! Учтите, что это контактная задача.

Здесь сумма загрузки ядер (это реально четырехядерный процессор) на некотором (значимом) интервале наблюдения больше 50%!

Мгновенная диагностика может, как на картинке с прямым методом давать меньший (или больший) результат!

Если не верите, что параллельно не было еще одного процесса (с целью обмануть аудиторию), то добро пожаловать ко мне на работу (со свидетелями), чтобы убедиться в соответствии картинок реальности.

Или, по-вашему, SW Corp в код вставила параллельный процесс, чтобы ввести всех в заблужение?

И в завершение.

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

То же относится и к г-ну Vl. Посредством хотя бы одного из уважаемых продуктов: LS-Dyna, Nastran, HyperWorks, Adams, Open CASCADE..., получите решение хоть одной задачи и опубликуйте протокол, где видно распараллеливание итерационным методом и - желательно - прямым.

И есть еще более конструктивное предложение. Берем кубик, разбитый на конечные элементы параболическими тетраэдрамии с числом неизвестных, допустим, 500000 и дружно публикуем протоколы работы процессоров на прямом и итерационном решателе в статической, для начала, задаче.

При этих условиях я согласен продолжать дискуссию.

Результаты в студию, г-да!

[a_a_a+ 11]

Не удержался...

Комментарии.

В прямом методе размерность взята чуток меньше, чем 500000 неизвестных - чтобы задача помещалась в оперативной памяти.

В итерационном - чуток больше, иначе считает слишком быстро - не удается снять протокол.

=================================

Мораль для просто свидетелей.

Многоядерные (в частности, четырехядерные) процессоры настоятельно рекомендуются для расчетов посредством SolidWorks Simulation.

Это утверждение справедливо и для Flow Simulation (в девичестве COSMOSFloWorks), но только начиная с версии 2009 года.

[a_a_a+ 11]

Кубик. Каждое ребро разбито на 80 элементов. Нижняя грань закреплена. На верхней грани приложен крутящий момент из 4 сил.

Степеней свободы – 1 574 640.

Попробуйте решить эту задачу прямым методом.

Для итерационного метода время решения:

1 ядро – 4 мин 32 сек

2 ядра – 3 мин 20 сек

4 ядра – 2 мин 02 сек

Приведено РЕАЛЬНОЕ время решения. Как видите, итерационный метод распараллеливается. Покажите на этой задаче, что прямой метод также эффективно распараллеливается.

Я, извиняюсь, плохо понимаю, что такое "крутящий момент из 4 сил"?

Думаю, что с точки зрения времени счета от нагрузки мало что будет зависеть, поэтому приложу крутящий момент так, как позволит COSMOSWorks (там есть много вариантов).

Подозреваю, что "ребро разбито на 80 элементов" в действительности звучит так: "на каждом ребре куба находится 80 ребер конечных элементов".

Прямым методом я эту задачу решить не могу, тк в оперативной памяти (у меня только 8 Гб) она не поместится, соответственно результат (если даже удастся его получить) будет не совсем показательным.

Картинку Вы не дали, но, в принципе, поверю.

И еще.

А какой порядок у конечных элементов? Линейные или параболические?

[vl 327]

Двумя голосами против одного установлено, что COSMOSWorks не распараллеливает прямой метод. Потому не распараллеливает, что просто не может этого сделать, согласно "теории МКЭ".

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

А вот о протоколах я скажу.

1. Я не сомневаюсь, что космос распараллелил задачу на 4 ядра, если вы это утверждаете.

2. А вот картинка, которая показана в качестве доказательства, ничего не доказывает. Даже если вы запустите задачу на одном ядре, Windows покажет вам загрузку всех 4-х, только 100% поделенное на 4. Здесь лучше поискать более корректный инструмент. Я посмотрю, что нибудь

Исправлено: вторые картинки впрочем как раз все показывают - занятость на 100% всех ядер. Т.е. этот вопрос снят.

То же относится и к г-ну Vl. Посредством хотя бы одного из уважаемых продуктов: LS-Dyna, Nastran, HyperWorks, Adams, Open CASCADE..., получите решение хоть одной задачи и опубликуйте протокол, где видно распараллеливание итерационным методом и - желательно - прямым.

Не могу. Из указанных продуктов это применимо лишь к LS-Dyna и Nastran. Но LS-Dyna под руками либо на кластере, либо на одноядерной машине. Nastranа параллельного у меня нет.

А самое главное - что это даст? Судя вот поэтому:

В итерационном - чуток больше, иначе считает слишком быстро - не удается снять протокол.

Итерационные методы лучше, или как?

[a_a_a+ 11]

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

А вот о протоколах я скажу.

1. Я не сомневаюсь, что космос распараллелил задачу на 4 ядра, если вы это утверждаете.

2. А вот картинка, которая показана в качестве доказательства, ничего не доказывает. Даже если вы запустите задачу на одном ядре, Windows покажет вам загрузку всех 4-х, только 100% поделенное на 4. Здесь лучше поискать более корректный инструмент. Я посмотрю, что нибудь

Не могу. Из указанных продуктов это применимо лишь к LS-Dyna и Nastran. Но LS-Dyna под руками либо на кластере, либо на одноядерной машине. Nastranа параллельного у меня нет.

А самое главное - что это даст? Судя вот поэтому:

Итерационные методы лучше, или как?

Понятно, что загрузку нужно считать как среднее от суммы процентов загрузки каждого ядра (на некотором этапе времени, само собой!

COSMOSWorks (Simulation) всегда параллельный и всегда под рукой!

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

Да, для кубика лучше итерационный.

Снять результаты для каждого ядра не в состоянии. Это тот случай, когда COSMOSWorks ограничивает действия пользователя. Но большинству такая функциональность (не использовать какие-то ядра/процессоры при их наличии) вряд ли понадобится. Пока никто на это не жаловался.

[a_a_a+ 11]

Это плохо, что вы не можете решить такую задачу. У меня есть реальная задача, которая прямым методом требует 100 Гб памяти. И решается на компьютере с 1 Гб памяти.

Обычные 8-ми узловые элементы. Я же написал общее количество степеней свободы.

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

Из того, что известно общее число степеней свободы конечно-элементной системы, не следует что они (она) образованы (а) "обычными 8-узловыми элементами". Что это, кстати такое согласно "теории МКЭ"?

Как же это я задачу не решил! А на картинках-то что? Обратите внимание, что времени потребовалось в два раза меньше, чем у Вас.

Мои предположения, кстати, высказанные ранее. Есть различные реализации, как прямых, так и итерационных методов (правильнее говоря, схемы хранения матриц). Так вот в COSMOSWorks итерационный решатель изначально (качественно!) релизован так, что его распараллеливание приведет к росту т.наз. накладных расходов. Поэтому, собственно, и результаты его распараллеливания достаточно скромные.

Здесь, извиняюсь, применима такая аналогия. Есть два двигателя - изначально экономичный и не очень. Какой больше шансов усовершенствовать (распараллелить)?

Ну нельзя в COSMOSWorks "отключить" ядра. Это кому-то из практикующих! инженеров надо?

Где, кстати, Ваши картинки, а то всё пока слова и слова...

И насчёт крутящего момента "из четырех сил" поподробнее, пожалуйста...

Что-то я в "теории МКЭ" такой сущности не встречал. Книжки, наверное, невнимательно читал...

Можно понизить планку. Решите прямым методом кубик с делением стороны на 40. На одном ядре и на 4. И приведите реальное время решения. Тогда можно оценить эффективность параллельности.

"Решите прямым методом кубик с делением стороны на 40"

Вы, хоть, сами понимаете, что пишите?

[a_a_a+ 11]

...ребро разбито на 80 элементов

Я просто не понимаю смысла Вашей фразы.

Кто-то еще понял?

И еще. Прошу опубликовать протоколы (скриншоты) Ваших рачетов. В противном случае дискуссия не имеет смысла.

Словам, ничем не подкрепленным, верить нельзя!