Нет, уравнение Дарси в оператор столкновений не добавляется. Пористая среда--это пространство, частично непроницаемое для жидкости, со сложной структурой, типа такой (или структура типа губки). На границе непроницаемой части используется обычно no-slip boundary condition.
Цилиндрическая трубка длиной 10 000 шариков, высотой и шириной (диаметром, то бишь) 30 шариков. Каждый шарик дискретизируется разрешением 30 точек на диаметр (т.е. 30х30х30 на шарик). Итого 2.4 * 10^11 точек всего, порядка 10^11 жидких узлов.
Заодно вам должно стать понятно, почему для таких моделирований не критична интегрированная среда и bells and whistles типа классных графичков из коробки. Потому что workflow такой:
1. сгенерировать на суперкомпьютере упаковку шариков (т.е. поставить в очередь, подождать пока дойдет очередь, пройдет расчет)
2. провести на суперкомпьютере моделирование LBM (поставить в очередь, подождать пока дойдет очередь, пройдет расчет)
3. рассчитать на суперкомпьютере коэффициенты диффузии, гидродинамической дисперсии (поставить в очередь, подождать пока дойдет очередь, пройдет расчет). Это как бы postprocessing, но он занимает едва ли не больше времени, чем CFD.
Чтоб был понятен масштаб. Для моделирований мы (коллега в основном, не я) пользуемся вот этим суперкомпьютером. 7 место в Top 500, если что. Моделирование может требовать всех мощностей суперкомпа.
10 лет назад в нашей группе купили какой-то CFD солвер, но он параллелился нелинейно, и выходил на асимптоту на 50 процессорах. После этого написали свой код.
Я чуть нижеописал систему, в которой finite volume method не сработал. Ansys, думаю, не сработает так же по тем же причинам (написано, что их солвер--finite element method).
Ах, да, простите за английские названия методов. Но надо признать, что вся «движуха» в науке и технологии--на английском языке. Мне кажется, такие вещи лучше оставлять на английском для согласованности (хоть и «метод конечных элементов» уже устоявшееся название).
К сожалению, я никогда раньше не слышал о методе МакКормака (потому что по образованию радиофизик). Поэтому буду пользоваться косвенным способом: гугл по запросу «maccormack method» выдает 90 и 100 тысяч результатов (на двух компьютерах). По запросу «lattice boltzmann method» выдает 1 530 000 результатов. Притом что метод МакКормака был опубликован в 1969 году. Из чего можно сделать вывод что он, скорее всего, просто не работает--уж не знаю, почему (точность, неустойчивость, малая область стабильности).
В моей научной группе (это в Германии, сначала она была в одном из Институтов Макса Планка) используют LBM для моделирования потока в случайных упаковках твердых шариков, типа таких, только часто с внешними стенками и с бОльшим на порядок числом частиц. Это надо для моделирования HPLC columns (собственно, это и есть трубки с шариками).
У нас есть коллаборация с этой научной группой. Они пытались использовать finite volume method для тех же целей (вроде бы, Open FOAM). У них были проблемы уже с генерацией mesh (особенно там, где шарики касаются стенок)--это решили тем, что между шариками и стенками оставляют зазор. Потом--с точностью моделирования, в том числе из-за зазора. Насколько я знаю, они так и не заставили finite volume method работать в этой системе.
Ух ты, я не знал про El'Beem, спасибо. Но я сознательно написал «коммерческие», поскольку только появление таких продуктов на рынке, мне кажется, предполагает достаточную зрелость, надежность, инфраструктуру, обход большинства «подводных камней», доверие и т.п. А в принципе, да, первые сообщения на форуме palabos в районе 2008 года, а в моей научной группе им стали пользоваться в 2003, и уже в 2000 метод неплохо работал. Но все равно, по меркам CFD, мне кажется, он довольно новый.
Кроме того, эта «библиотечка» (или библиотечки--тут я не уверен, какие вы имеете в виду) обычно включают многие постпроцессоры и препроцессоры (типа расчет числа Нуссельта, потока энтальпии--если вы об этом).
Если вы имеете в виду какие-то другие постпроцессоры и препроцессоры, то это скорее нарушает unix-way, потому что каждый должен заниматься своим делом. Эти пакеты обычно принимают стандартные форматы файлов на входе (геометрии), могут писать стандартные форматы на выходе (поле скоростей, плотности, тензоры давлений и т.п.). Дальше вы можете делать с ними, что хотите--отправить в другую специализированную программу, в визуализатор, или написать свой постпроцессор.
Если вы думаете, что Open FOAM из CAE Linux справится с любой задачей моделирования, то вы ошибаетесь. Так же, как, думаю, и Ansys.
Ну и, опять же, ничто не мешает включить Palabos в CAE Linux, но я не уверен, что это (первоочередная) задача разработчиков Palabos.
Я так понимаю, вам просто нужно моделировать поведение 3D модели в потоке воздуха? Ведь аэродинамическая труба--это устройство для моделирования явлений, протекающих в меньшем масштабе, но с тем же числом Рейнольдса. Если вы уменьшаете машинку в 5 раз, то, если увеличить скорость ветра в 5 раз, число Рейнольдса не изменится--формула 24 в статье. При том же числе Рейнольдса явления будут протекать одинаково. То есть задача--просто моделирование потока воздуха, текущего мимо модели, то есть стандартная задача гидродинамики.
Если у вас есть 3D модель, ее нужно дискретизировать равномерной сеткой и дать на вход программе моделирования в понятном ей формате. Многие продукты поддерживают программную генерацию геометрии, или автоматический импорт из популярных форматов (например, если у вас есть триангуляризованная поверхность модели). Вот пример моделирования в сложной геометрии. Palabos еще поддерживает возможность не совсем равномерной сетки.
Чтоб создать поток вокруг модели, необходимо указать либо силу, которая действует на толщу воздуха и обеспечивает поток, либо давление в плоскостях до и после модели (по направлению потока).
LBM в формулировке статьи, действительно, сможет моделировать только ламинарный поток несжимаемой жидкости. Но есть его улучшения с включением турбулентных явлений: например, вот, вот и вот. Вот есть даже компания (стартап в ETH Zurich), которая предлагает улучшение в LBM--entropic LBM, которое, как они утверждают, способно воспроизводить турбулентность. Но я никогда не занимался этой областью; может быть, они приукрашивают.
Вы правы. Но это, тем не менее, объясняет, почему локально по времени может быть выгодно публиковаться в неудобных журналах. Переход должен быть согласованным и масштабным. А насчет arxiv--лично я не сильно доверяю статьям оттуда, которые не дублируются в том же PhysRevE или PhysRevLett. Думаю, так многие делают.
Обычно в каждой узкой отрасли есть исторически сложившийся топовый журнал. Притом не обязательно с лучшим импакт фактором (и тем более условиями публикации или временем рецензирования) из всех журналов для общей отрасли. Поэтому вы будете стараться публиковать там--так больше людей заметят, прочитают, поверят вашей статье.
Переход на другие журналы разрушает систему авторитета и репутации, которая объективна очень важна в науке.
По коду: лучше не пользоваться транслитом, писать английские слова вместо shponka. Ваш большой if-else про диаметр вала можно заменить таблицей (массив Nx6, где N--число вариантов; каждая его строчка--d_min, d_max, b, h, t1, t2). За что отвечает каждый столбец, написать в комменте. Потом вы сможете пройтись в цикле по всем рядам, определить подходящий ряд или вывести ошибку. Объявление массива можно вынести куда-нибудь.
В одной функции не должно быть больше 20-50 строк (зависит от проекта, человека, монитора и т.п.). В одном файле--не более 200-400 строк. В общем, советую МакКоннела, там все это подробнее объяснено.
Делюсь своим опытом в Soft Matter и опытом коллег для ваших журналов: часто рецензентов выбирают из списка цитируемой литературы (у меня, насколько я понял, один рецензент был точно не из моих предложений). Кроме того, далеко не всегда рецензенты соглашаются рецензировать статью, и список предложений быстро истощается.
Как правильно заметили выше, хабр --уже самоорганизующаяся система с оценками постам (специальная форма peer review) и репутацией. Осталось только добавить peer review, как в журналах--когда как минимум 2 члена сообщества читают статью перед публикацией :-)
Но важно вот еще что: на хабре не публикуют результаты исследований. В лучшем случае описывают свои новые технологии. Мне кажется, что по вероятности ошибок отрасли расположены в следующем порядке (по убыванию вероятности): исследования в естественных науках, технологии на основе естественных наук (промышленная химия, медицина, самолетостроение), исследования в computer science, технологии на основе computer science (software engineering).
Поэтому нет смысла рецензировать статьи о фреймворках (их и не рецензируют). Поэтому же в CS доклад на конференции котируют как статью. А вот в физике плазмы или хроматографии peer review должен быть обязательно.
А зачем вам студенты? Вам нужны: ученые из той же отрасли, ученые из смежных отраслей, инженеры, внедряющие или применяющие ваши разработки, грантодатели. Основная причина публикации в таких журналах--они обеспечивают peer review и не пропускают плохих статей, обладают авторитетом. Никто не будет читать статьи из интернета, потому что им не доверяют, потому что там могут быть ошибки. Конечно, каждый читатель может сам поискать ошибки, но он может быть не экспертом или не иметь времени на это.
Еще раз, самое важное--в новых исследованиях очень велика вероятность ошибок (и еще иногда обмана). Поэтому нужен peer review, система репутации и авторитета журналов.
Вы очень правильно говорите насчет важности рецензий. Но: 1. Рецензенты оплаты не получают 2. (мелочь) они обычно знают, кто автор статьи. (я делаю диссер в германии, знаю, о чем говорю--правда, может, вне моей области не так, но это маловероятно).
Самое важное в научных журналах--это peer review. Притом не просто просмотреть и поставить плюсик (или минусик), а внимательно прочитать, проверить все формулки, поискать противоречия, пробелы в изложении, предложить улучшения и т.п. Кроме того, у журналов есть специализация, репутация, рейтинг, авторитет. Я согласен, что сайты могут их заменить, но все эти механизмы там тоже должны присутствовать, иначе вместо научных статей там будет куча булшита, а ля чертежи фильтров Петрика. За примером далеко ходить не надо--на хабре достаточно псевдонаучных статей, особенно по биологии. Например, вот.
Не позволяют retained rights, которые у каждого издательства и даже журнала свои. Например, Royal Society of Chemistry разрешает выкладывать на arxiv только препринт статьи (версию до того, как началось peer review), зато разрешает выкладывать на личный сайт даже журнальную версию. American Physical Society, кажется, разрешает выкладывать на arxiv только post-print (версию после рецензирования, но еще не отформатированную журнальными верстальщиками). Кто-то вообще ничего не разрешает. И т.п. Есть специальный сайт, где можно быстро получить обзор прав, получаемых автором на публикацию в данном журнале.
Заодно вам должно стать понятно, почему для таких моделирований не критична интегрированная среда и bells and whistles типа классных графичков из коробки. Потому что workflow такой:
1. сгенерировать на суперкомпьютере упаковку шариков (т.е. поставить в очередь, подождать пока дойдет очередь, пройдет расчет)
2. провести на суперкомпьютере моделирование LBM (поставить в очередь, подождать пока дойдет очередь, пройдет расчет)
3. рассчитать на суперкомпьютере коэффициенты диффузии, гидродинамической дисперсии (поставить в очередь, подождать пока дойдет очередь, пройдет расчет). Это как бы postprocessing, но он занимает едва ли не больше времени, чем CFD.
10 лет назад в нашей группе купили какой-то CFD солвер, но он параллелился нелинейно, и выходил на асимптоту на 50 процессорах. После этого написали свой код.
В моей научной группе (это в Германии, сначала она была в одном из Институтов Макса Планка) используют LBM для моделирования потока в случайных упаковках твердых шариков, типа таких, только часто с внешними стенками и с бОльшим на порядок числом частиц. Это надо для моделирования HPLC columns (собственно, это и есть трубки с шариками).
У нас есть коллаборация с этой научной группой. Они пытались использовать finite volume method для тех же целей (вроде бы, Open FOAM). У них были проблемы уже с генерацией mesh (особенно там, где шарики касаются стенок)--это решили тем, что между шариками и стенками оставляют зазор. Потом--с точностью моделирования, в том числе из-за зазора. Насколько я знаю, они так и не заставили finite volume method работать в этой системе.
Кроме того, эта «библиотечка» (или библиотечки--тут я не уверен, какие вы имеете в виду) обычно включают многие постпроцессоры и препроцессоры (типа расчет числа Нуссельта, потока энтальпии--если вы об этом).
Если вы имеете в виду какие-то другие постпроцессоры и препроцессоры, то это скорее нарушает unix-way, потому что каждый должен заниматься своим делом. Эти пакеты обычно принимают стандартные форматы файлов на входе (геометрии), могут писать стандартные форматы на выходе (поле скоростей, плотности, тензоры давлений и т.п.). Дальше вы можете делать с ними, что хотите--отправить в другую специализированную программу, в визуализатор, или написать свой постпроцессор.
Если вы думаете, что Open FOAM из CAE Linux справится с любой задачей моделирования, то вы ошибаетесь. Так же, как, думаю, и Ansys.
Ну и, опять же, ничто не мешает включить Palabos в CAE Linux, но я не уверен, что это (первоочередная) задача разработчиков Palabos.
Если у вас есть 3D модель, ее нужно дискретизировать равномерной сеткой и дать на вход программе моделирования в понятном ей формате. Многие продукты поддерживают программную генерацию геометрии, или автоматический импорт из популярных форматов (например, если у вас есть триангуляризованная поверхность модели). Вот пример моделирования в сложной геометрии. Palabos еще поддерживает возможность не совсем равномерной сетки.
Чтоб создать поток вокруг модели, необходимо указать либо силу, которая действует на толщу воздуха и обеспечивает поток, либо давление в плоскостях до и после модели (по направлению потока).
Переход на другие журналы разрушает систему авторитета и репутации, которая объективна очень важна в науке.
По коду: лучше не пользоваться транслитом, писать английские слова вместо shponka. Ваш большой if-else про диаметр вала можно заменить таблицей (массив Nx6, где N--число вариантов; каждая его строчка--d_min, d_max, b, h, t1, t2). За что отвечает каждый столбец, написать в комменте. Потом вы сможете пройтись в цикле по всем рядам, определить подходящий ряд или вывести ошибку. Объявление массива можно вынести куда-нибудь.
В одной функции не должно быть больше 20-50 строк (зависит от проекта, человека, монитора и т.п.). В одном файле--не более 200-400 строк. В общем, советую МакКоннела, там все это подробнее объяснено.
Но важно вот еще что: на хабре не публикуют результаты исследований. В лучшем случае описывают свои новые технологии. Мне кажется, что по вероятности ошибок отрасли расположены в следующем порядке (по убыванию вероятности): исследования в естественных науках, технологии на основе естественных наук (промышленная химия, медицина, самолетостроение), исследования в computer science, технологии на основе computer science (software engineering).
Поэтому нет смысла рецензировать статьи о фреймворках (их и не рецензируют). Поэтому же в CS доклад на конференции котируют как статью. А вот в физике плазмы или хроматографии peer review должен быть обязательно.
Еще раз, самое важное--в новых исследованиях очень велика вероятность ошибок (и еще иногда обмана). Поэтому нужен peer review, система репутации и авторитета журналов.