Как смоделировать такое? Есть ли пример?

[a_schelyaev 371]

О - логарифмическая шкала

Ну, это жуткий боян, которому лет пять.

Я вообще не уверен, что это режим с нитями.

У вас обмены блокирующие ?

Это когда без прохождения обмена расчет стоит?

Если так, то да для MPI.

Для нитей зависит от графа зависимостей, т.е. от постановки задачи.

Если вместо числа ядер по оси x отложить стоимость лицензии на данное число ядер, эффект будет еще более впечатляющим

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

Реально обладать значительным количеством параллельных опций не всем по карману.

До сих пор порядка 100 ядер является средним значением ядер у клиента.

Поэтому, о какой масштабируемости мы тут говорим?

:)

[HFL 34]

Ну, это жуткий боян, которому лет пять.

Я вообще не уверен, что это режим с нитями.

А смесь TBB и MPI масштабируется лучше чистого MPI ?

С вероятность в 80% используются блокирующие вызовы

До сих пор порядка 100 ядер является средним значением ядер у клиента.

Это размер очереди или число физических ядер у клиента ?

[a_schelyaev 371]

А смесь TBB и MPI масштабируется лучше чистого MPI ?

С TBB выше вероятность получить неблокирующие вызовы, чем с MPI.

Соответственно, больше шансов получить 100% загрузки ЦП.

Это размер очереди или число физических ядер у клиента ?

Ядер.

:)

[HFL 34]

С TBB выше вероятность получить неблокирующие вызовы, чем с MPI.

Соответственно, больше шансов получить 100% загрузки ЦП.

Совершенно верно. Это игра в статистику. Именно поэтому у вас оптимальный размер одного домена на ядро порядка 50к узлов расчётной сетки. Но чем больше задействовано ядер тем больше будет блокировок.

Это ещё как то работает на итерационных решателях. На прямых решателях и тем более на явных сжимаемых решателях вы упрётесь в блокировки практически сходу. Фишка блокирующих вызовов в том, что у вас в один момент времени между доменами может происходить только одна передача данных. Остальные либо ждут на блокировках либо "в пути" к точке блокировки. Чем длиннее этот "путь" (а в итерационном решателе на относительно крупном подомене этот "путь" достаточно длинный) тем меньше вероятность встать на блокировку. ТВВ просто удлиняют этот путь и заодно уменьшают число точек блокировки (не одна блокировка на ядро а одна на узел)

С неблокирующими вызовами MPI свои фишки (неявное выделение памяти, скрытые блокировки на wait()) но в общем и целом там масштабируемость выше на порядок.

[kristeen 355]

kristeen, а сколько по времени считалась ваша задача и на какой машине (ОС/проц/память/частота памяти)?

Мне тут говорили, что Fluent решает всё без упрощений и тоже будет долго. А CFX так же? Можно ли в CFX считать быстро в первом приближении, пока все настраиваешь, а потом уже более менее детально просчитать за пару суток такую задачу?

Думаю, и CFX и Fluent будут считать примерно с одной скоростью. На счет первого приближения -- обычно так и делают, если задача сложная, запускают на грубой сетке, с одинарной точностью итп чтобы посмотреть, запуститься-то хоть вообще.

Считал в CFХ.

Сетка очень грубая, оччень.

Global Statistics :

Global Number of Nodes							   =		8092

	 Global Number of Elements					   =		7655

		 Total Number of Tetrahedrons			   =		 665

		 Total Number of Prisms					   =		  59

		 Total Number of Hexahedrons			   =		5806

		 Total Number of Pyramids					=		1125

4 секунды симуляции с шагом 0,01 сек считались 1 час 17 минут на i7 2840, на одном ядре, т.к. при такой размерности выигрыш от параллельного расчета нулевой. Памяти брало очень мало.. ~4 было занято, из них 1,5 -- системой. На создание анимации почти столько же ушло)

Опишите, для чего Вам нужен расчет. Если Вам нужно узнать требуемый момент на шнеке, с учетом того, что точно известны свойства жидкости, то это можно. Но если определять, когда шнек перестанет крутиться... Я бы использовал аналитические расчеты, а CFD -- для верификации.

ps Еще посмотрите на XFlow CFD. Доступен, где всегда. Туториал там же в топике. <noindex>Видео на ютубе</noindex>. Движение тел задается оччень просто (по сравнению с CFX, FlowVision не пробовал). Считает довольно быстро)

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

[a_schelyaev 371]

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

Погоняю на обеих схемах явной и неявной.

Но то, что с внедрением TBB загрузка всех ядер выросла до 100 в 90% случаев это медицинский факт.

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

Еще посмотрите на XFlow CFD.

Не советую даже время на это тратить.

[HFL 34]

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

Погоняю на обеих схемах явной и неявной.

Но то, что с внедрением TBB загрузка всех ядер выросла до 100 в 90% случаев это медицинский факт.

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

Проще собрать статистику под профайлером. Загрузка процессора особо ни о чём не скажет. Те же самые барьеры в MPI (в отличае от барьеров в OpenMP или TBB) при ожидании загружают процессор сильнее любой решалки. Динамическая балансировка имеет смысл когда у вас идёт значительное перестроение сетки (при условии что время на переразбивку домена существенно меньше собственно времени решения).

[a_schelyaev 371]

Динамическая балансировка имеет смысл когда у вас идёт значительное перестроение сетки (при условии что время на переразбивку домена существенно меньше собственно времени решения).

Сетка обычно разом меняется во время адаптации и в таких случая делается глобальная перетряска.

В остальных случаях изменения сетки незначительны.

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

Вот нашел из старой презентации, размер задачи не помню. Объяснял на пальцах аудитории для чего нужен параллелизм и как понять какой код как в деньгах получится:

[fluent3000 0]

4 секунды симуляции с шагом 0,01 сек считались 1 час 17 минут на i7 2840, на одном ядре, т.к. при такой размерности выигрыш от параллельного расчета нулевой. Памяти брало очень мало.. ~4 было занято, из них 1,5 -- системой. На создание анимации почти столько же ушло)

i7-2840? Какой-то непопулярный процессор. И похоже официально не выпускался. Судя по всему у Вас он стоит на каком-нибудь ThinkPad... W520?

Мне лишь удалось найти тесты i7-2820 и сравниться с ним. Ваш мощнее в 2-3 раза моего.

Опишите, для чего Вам нужен расчет. Если Вам нужно узнать требуемый момент на шнеке, с учетом того, что точно известны свойства жидкости, то это можно. Но если определять, когда шнек перестанет крутиться... Я бы использовал аналитические расчеты, а CFD -- для верификации.

Момента на шнеке будет достаточно. То когда он остановится зависит уже от мощности двигателя.

А вот точные свойства жидкости не известны. Более того, это суспензия. Было бы, конечно, круто если в CFX можно было сделать расчет для многофазной суспензии. Но если нет, то ничего страшного.

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

Т.е. меня даже устроит жидкость грубоэквивалентная моей суспензии.

ps Еще посмотрите на XFlow CFD.

Не советую даже время на это тратить.

Похоже Вы опасаетесь этого конкурента. :) Обязательно посмотрю. Точнее уже качаю :) Изменено 22 января 2013 пользователем fluent3000

[HFL 34]

а CFD -- для верификации.

Ох не дай вам бог попасть под горячую руку моего шефа с таким заявлением

Вот нашел из старой презентации, размер задачи не помню. Объяснял на пальцах аудитории для чего нужен параллелизм и как понять какой код как в деньгах получится:

Не совсем очевидный график. По оси У это затраты на ядро ?

Из чего они складываются :?

[kristeen 355]

i7-2840?...Мне лишь удалось найти тесты i7-2820 и сравниться с ним.

Извините, оплашал. i7-2820QM. Хотя суть не меняется..

Ох не дай вам бог попасть под горячую руку моего шефа с таким заявлением

Ну, эксперимент по-умолчанию над всем рулит) Если только вы не из Virgin Racing..

[HFL 34]

Если только вы не из Virgin Racing..

Это уже читали ? <noindex>http://www.engineeringexchange.com/profile...-races-with-cfd</noindex>

[a_schelyaev 371]

Похоже Вы опасаетесь этого конкурента. :) Обязательно посмотрю. Точнее уже качаю :)

Лучше CFX смотрите, а не это.

Из чего они складываются :?

Цена за лицензию.

За железо затраты линейны.

[HFL 34]

Цена за лицензию.

За железо затраты линейны.

У вас одна лицензия на 16 ядер или это из соображения 16 ядер на узел ?

Я прикинул стоимость только железа в моём случае (а оно весьма дорогое по сравнению с "обычным")

Получилось чуть меньше 3 руб/час на 1 ядро (если разделить на год). Обычно железо меняют раз в 3 года,

лицензию на ПО - раз в год. Когда клиент покупает "аппаратно-програмный комплекс" затраты на железо и софт обычно идут в соотношении 50:50. Так что 150 руб/час это просто космическая цена

[Bonusfrag 104]

3 руб/час на 1 ядро

лицензия (при 16 ядрах) будет примерно 4 руб/час на 1 ядро.

[Гость ISPA]

Получилось чуть меньше 3 руб/час на 1 ядро (если разделить на год). Обычно железо меняют раз в 3 года,

лицензию на ПО - раз в год.

Есть ли смысл обновлять лицензию на ПО раз в год, если железо не изменилось.

И железо по разному меняется. Если не появилось новых машинных команд, то и ПО в таком случае обновлять не нужно.

[Bonusfrag 104]

Есть ли смысл обновлять лицензию на ПО раз в год, если железо не изменилось.

так лицензия же годовая )

абонентская плата, однако)

в новых версиях вводится новый функционал - часто нужный и полезный.

бессрочная* стоит дороже годовой.

[Гость ISPA]

так лицензия же годовая )

Тогда надо говорить не об обновлении, а о продлении лицензии.

Покупать серьезный расчетный софт только на один год. И осваивать его.

Это не серьезно.

[a_schelyaev 371]

Это не серьезно.

Это финансовая реальность. В рамках венчурных проектов этап поиска облика изделия может длиться только один год. После этого проект могут закрыть по разным причинам.

В такой ситуации тратить деньги за бессрочку бессмысленно.

К тому же руководство не всегда доверяет тратам денег на какие-то "цветные картинки" (практически дословно со слов одного гендира одного предприятия). Поэтому сперва годовая, а там посмотрим.

Благо у нас есть схема перехода с годовой на бессрочную.

[Гость ISPA]

Это финансовая реальность.

Да это понятно.

Просто речь шла про многоядерность, про узлы кластера.

Про обновление железа под серьезный софт.

Вот я и спросил про обновление софта под старое железо.