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

[a_schelyaev 366]

А в FV разве нельзя создать пользовательскую систему координат?

Именно для подвижного тела нет. Там реализовано задание вращения используя только глобальную систему координат. До создания функционала с пользовательскими СК зашло в тупик по субъективной причине.

А потом другие дела навалились.

Так что ждемс.

[fluent3000 0]

Такое ощущение, что шнек никак не воздействует на жидкость. Зазор есть, но не настолько большой чтобы вся вода успевала через него просачиваться. 1-2мм при диаметре шнека 120мм. Толщина перьев шнека 2мм (шнек довольно низко полигональный).

Вот видео

Здесь 137000 ячеек. Считалось 1,5 - 2 суток. Core2Duo/2.6 GHz/2,8Гб

Потом считал с меньшим кол-вом ячеек. Увеличивал скорость вращения шнека. Шероховатость стенок и шнека. Включил Модель Зазора. Результат аналогичный. Шнека как будто нет (хотя воду вроде как и раскачивает). Но картинка в целом точно неестественная.

Когда увеличил плотность (2000кг/м3) и вязкость (0.2) программа вообще аварийно вырубается (с предложением винды отправить отчет об ошибке).

Еще в какие-то моменты при грубом расчете (20 -30 тыс. расчетных ячеек) видно, что вода не брезгует проходить и сквозь стенки шнека.

В чем могут быть проблемы. Куда копать?

[a_schelyaev 366]

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

Поэтому, придется адаптировать.

А второй вариант это через скользящую границу.

[Lex TD 8]

Впрочем, подобная эффективность и не снилась helicoide..

Быть того не может, ведь на шнеке не построишь вечный двигатель

[kristeen 355]

Быть того не может, ведь на шнеке не построишь вечный двигатель

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

[fluent3000 0]

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

Поэтому, придется адаптировать.

А второй вариант это через скользящую границу.

Использую адаптацию параллелепипедом в области шнека. Очень мелкие сетки получаются тогда (>700тыс.). Даже нет возможности проверить дает ли это какие-то результаты. В домашних условиях такое не посчитать.

Под скользящей границей имеется ввиду скользящая сетка?

Это 3 рабочих объема один из которых вращается, а на торцах этого вращающегося цилиндра задана скользящая стенка?

При этом можно получить аналогичные результаты и это будет работать при грубых сетках? И крутящий момент шнека можно будет узнать? Кстати так и не нашел как узнать крутящий момент на шнеке.

Изменено 20 января 2013 пользователем fluent3000

[Bonusfrag 104]

Очень мелкие сетки получаются тогда (>700тыс.).

Вам надо для вращающегося тела сделать отдельное ГУ типа "Стенка". Отличаться от другого ГУ "Стенка" оно будет включенной адаптацией по поверхности, к которой применяется ГУ.

Или модификатор надо для самого этого подвижного тела делать с адаптацией по границе тела.

(не знаю, какой вариант доступен во 2й версии)

Т.е. адаптировать надо не по объему, а по поверхности!

Но всё-равно эту задачу лучше смотреть в 3 версии, где есть x64 решатель, не ограничивающий использование памяти.

Для моего домашнего ПК с 8 гиг памяти предел наступает при ~ 2млн ячеек. Данные не помещаются в памяти и солвер начинает гонять данные с памяти на диск и обратно. Это сильно тормозит счет, но иногда на небольшое время приходится использовать.

[fluent3000 0]

Думал при включении адаптации по ГУ, адаптация происходит только на стадии генерации сетки. Тело-то движется, а адаптация по ГУ происходить на каждой итерации не будет.

Но сейчас проверил и впрямь происходит. Вы правы. Сейчас буду пробовать таким макаром.

Еще вопрос. Насколько степень полигональности подвижного тела и рабочего объема, влияет на скорость вычислений?

Изменено 20 января 2013 пользователем fluent3000

[Bonusfrag 104]

Еще вопрос. Насколько степень полигональности подвижного тела и рабочего объема, влияет на скорость вычислений?

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

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

[HFL 34]

Для моего домашнего ПК с 8 гиг памяти предел наступает при ~ 2млн ячеек.

Интересная информация (если она соответствует действительности). Это примерно в 4 раза больше чем потребляет решатель CFX. Интересно - это решатель столько съел или постпроцессор ему помог

[fluent3000 0]

С адаптации по ГУ получилось добиться 230000 расч. ячеек. Но за ночь посчитал только 155 итераций и 0.003сек.

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

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

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

Изменено 21 января 2013 пользователем fluent3000

[a_schelyaev 366]

Интересная информация (если она соответствует действительности). Это примерно в 4 раза больше чем потребляет решатель CFX. Интересно - это решатель столько съел или постпроцессор ему помог

Решатель.

Судя по всему, по настройкам решалки у нас аналог Double Precision в CFX.

А если включить 128битную нашу решалку, то памяти еще больше скушается.

B еще одно интересное наблюдение - глобального сравнения не проводили, но периодически клиенты утверждают, что они получаем аналогичное ему решение на сетке в 3-4 раза меньшей по объему в FV.

[Bonusfrag 104]

(если она соответствует действительности)

В эти 8 гиг входит также ОС + немножко всякой требухи, свойственной домашнему ПК,

т.е. реально где-то 6,5 Гиг это 2 млн ячеек.

постпроцессор редко кушает много, но я его всегда выгружаю.

[HFL 34]

6,5 Гиг это 2 млн ячеек.

Это много даже если используется 128-битная арифметика вместо стандартной

[Bonusfrag 104]

Это много даже если используется 128-битная арифметика вместо стандартной

Это пиковое значение за один шаг. В среднем за шаг память занята значительно меньше (раза в 2...).

Что там происходит в этот пиковый момент - хз.

Точнее, не совсем хз - это некое конкретное уравнение.

Т.е. запас для оптимизации есть.

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

вот из мануала:

Рекомендация по выбору объема оперативной памяти:

Для оценки потребной оперативной памяти, можно воспользоваться соотношением: 200-300 тысяч ячеек ~ 1

ГБ (в зависимости от разрядности Солвера и сложности задачи).

Наилучшая масштабируемость* достигается, когда на ядро приходится 50 – 100 тысяч ячеек.

а память не особо дорогая (десктопная), и воткнуть её можно 64 гига на 6 ядер (на 2011 платформе).

Но нафига...? Вот при этих 2 млн ячеек на 4х ядрах нестационарная задача считается сильно ощутимое время.

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

[HFL 34]

Наилучшая масштабируемость* достигается, когда на ядро приходится 50 – 100 тысяч ячеек.

Смешная фраза наилучшая масштабируемость это когда ваша задача влезла целиком в кэш процессора

Различают <noindex>2 типа</noindex> <noindex>масштабируемости </noindex>- weak scalability и strong scalability.

Обычно масштабируемость выражают через кривую эффективности которая имеет вот <noindex>такой</noindex> вид. Где там может быть оптимум ?

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

[a_schelyaev 366]

Это много даже если используется 128-битная арифметика вместо стандартной

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

2. Обуславливатель и итерционная схема предполагает затраты по памяти в обмен на способность продавливать решение иам, где старичок Ланцож ножками дергается в конвульсиях.

3. Больше придумать ничего не могу.

:)

Смешная фраза наилучшая масштабируемость это когда ваша задача влезла целиком в кэш процессора

Нижний порог получился строго из преобладания доли обменов над вычислениями.

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

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

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

[Bonusfrag 104]

вот <noindex>такой</noindex> вид.

что там означают три кривых / подписи к ним ?

А про эффективность отвечу так: вплоть до того, что задача на N ядрах может решаться медленнее, чем на M (где N>M).

Но это редкость. есть другой момент - есть X задач и M ядер, и надо раздать ядра так, чтоб время решения было наименьшим.

И вот на основе таких кривых и указанных рекомендаций этот вопрос как-то можно решить.

Но я сразу скажу - этот момент знаю плохо, более чем на 4х ядрах не работал и работа в многопроцессорном варианте не предвидится.

PS у FV тоже какая-то такая кривая есть:

оформление графика удручающее ))

[HFL 34]

Нижний порог получился строго из преобладания доли обменов над вычислениями.

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

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

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

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

[HFL 34]

что там означают три кривых / подписи к ним ?

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

А про эффективность отвечу так: вплоть до того, что задача на N ядрах может решаться медленнее, чем на M (где N>M).

Но это редкость. есть другой момент - есть X задач и M ядер, и надо раздать ядра так, чтоб время решения было наименьшим.

И вот на основе таких кривых и указанных рекомендаций этот вопрос как-то можно решить.

Но я сразу скажу - этот момент знаю плохо, более чем на 4х ядрах не работал и работа в многопроцессорном варианте не предвидится.

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

Например при переходе от 100 к 200 ядер общее время решения задачи уменьшается на 5%

добавляете еще 100 - уменьшается еще на 1% ну и так далее

FV тоже какая-то такая кривая есть:

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