Анимация результата расчета

[dmiantosha 11]

Сто Мб файл, это не реально. Это как надо замельчить с сеткой то, чтобы такое получить? Не ну конечно нет предела глупостей. Тем более в файл результата можно записывать не все подряд, а только те величины, которые интересует, для аимации чаще всего скорость. Наверника скорость хранится как переменая Real, ее размер 4 байта. Координаты узла доаустим пусть тоже храниться в 4 байтах. Тогда для записи одного узла потребуеться 8 байт. В килобайт можно записать тогда 128 узлов, в Мегабайт 131072 узлов, в 100 Мб = 13107200 - это 13 милионов узлов. в таком виде файл кончено не хранят, его сжимают, т.о 100Мб (я думаю) - это примерно 20-30 миллионов узлов, чтобы такое посчитать мне придеться год ждать или 2.

Я считал струю, и делал анимацию. Так как картина очень бурно развиваеться, то 20 шагов мне было мало, на анимации я получал провалы и бред.

Изменено 10 февраля 2007 пользователем dmiantosha

[Dick 0]

Так я и говорю в зависимости от задачи. Я струи не считаю, поэтому 5-15 файлов для моих задач достаточно, а для анимации в нестационаре бывает необходима не только скорость, а если еще и сетка 3-6 млн. элементов.

[Tako 0]

Это очень просто исправить.

При заказе Трансиент результатов закажите не все результаты, а десяток необходимых для построения величин. Можно еще и сжатие файлов поставить. И получите вы 100 файлов по 20 килобайт.

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

[dmiantosha 11]

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

[Tako 0]

Я свою фразу адресовывал для Dick.

dmiantosha, я Ваши два последних сообщения вообще не понял, хотя несколько раз перечитал. То ли Вы считаете, что 100мб это много, то ли - мало.

Сообщу факт из личного опыта. У меня есть задача, на 1,5 милиона, трансиент результаты которой весят 136мб каждый. И результатов мне нужно было далеко не 15 шагов. В итоге результаты занимали под 20 гигов. Причем задача решилась не с первого расчета.

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

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

Столкнувшись с такой задачей, я сейчас заказываю результаты выборочно.

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

Изменено 13 февраля 2007 пользователем Tako

[dmiantosha 11]

Я говорил, что 100 Мб это очень много, смотри, если 1.5 миллиона узов весили 13Мб, то 100 Мб будет примерно весить 12-13 млн узлов (как я, примерно и подсчитывал ранее), такую сетку помоему не посчитать на локалке или это придеться делать очень долго. Также я говорил, что 15 шагов для многих задач мало. В общем, я с вами полнотстью согласен.

Сколько времени у вас читаеться один шаг с сеткой в 1.5 миллиона? По-моему доложно быть очень долго. У меня 3.2 Гц 1Гб ОП, задача внешнего обтекания с 70 тыс. узов считаеться оклоло получаса. (ну это конечно весь расчет, не один шаг).

[Tako 0]

Я говорил, что 100 Мб это очень много, смотри, если 1.5 миллиона узов весили 13Мб, то 100 Мб будет примерно весить 12-13 млн узлов (как я, примерно и подсчитывал ранее), такую сетку помоему не посчитать на локалке или это придеться делать очень долго. Также я говорил, что 15 шагов для многих задач мало. В общем, я с вами полнотстью согласен.

Я сказал 136 Мб, а не 13

Сколько времени у вас читаеться один шаг с сеткой в 1.5 миллиона? По-моему доложно быть очень долго. У меня 3.2 Гц 1Гб ОП, задача внешнего обтекания с 70 тыс. узов считаеться оклоло получаса. (ну это конечно весь расчет, не один шаг).

Разве полчаса это долго? Эта задача считалась несколько дней.

[Miki 3]

какие 100 мб ? из 12 млн узлов ?

вы думаете там только скорости что ли записываются ?

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

на 2 Гб машине без особых проблем делается препроцессинг для сеток под 15-20 млн элементов.

постпроцессор тоже прекрасно работает с такими файлами результатов.

вы же одновременно не грузите все величины в модели. ве зависит лишь от количества объектов визуализации.

на моей практике я не имел никаких проблем с моделями до 15-20 млн ни в пре, ни в пост-процессоре.

решается все конечно на другой машине.

примерная прикидка использования памяти 1,5 млн гекс или 2-2,5 млн тетр на 2 Гб.

[dmiantosha 11]

Ок, я все понел. Счет в несколько дней - это сильно Надеюсь мне не придется встречатсья с таким.

[Druzhinin_S_L 0]

Miki, а почему Вы все "меряете" элементами? Ведь в CFX контрольный объем формируется вокруг узла и состоит как бы из кусочков элементов, содержащих этот узел, и законы сохранения записываются именно для этого контрольного объема. Поэтому ресурсоёмкость задачи (при прочих равных) напрямую зависит именно от числа узлов (nodes), а не от числа элементов сетки (elements). Поправьте меня (как говорит В.В.Путин), если я не прав.

[Tako 0]

Druzhinin_S_L, Вы не правы.

CFX считает по собственной сетке, которая построена основываясь на узлах, которые не совпадают с узлами КЭ сетки, а находятся в центре конечных элементов. Таким образов, на размерность задачи влияет количество элементов, а не узлов.

Для подтверждения цитата из хэлпа:

The ANSYS CFX-Solver calculates the solution to your CFD problem using Finite Volume elements, which are NOT the same as mesh elements. Each node in the mesh is at the centre of a finite volume element. Additional information on how the Finite Volume elements are used in the solution process is available.

[Druzhinin_S_L 0]

Странно... В ниже приведённой выдержке из Хелпа ясно написано, каким образом "вокруг" УЗЛА строится КОНТРОЛЬНЫЙ ОБЪЁМ:

____________________________________________________________

Discretisation of the Governing Equations

This approach involves discretising the spatial domain into finite control

volumes using a mesh. The governing equations are integrated over

each control volume, such that the relevant quantity (mass,

momentum, energy etc.) is conserved in a discrete sense for each

control volume.

The figure below shows a typical mesh with unit depth (so that it is

two-dimensional), on which one surface of the finite volume is

represented by the shaded area.

***(дожна быть прикреплена картинка. если нет, то посмотрите сами в хелпе в SolverTheory.pdf почти в самом начале Figure 3 Finite Volume Surface)***

It is clear that each node is surrounded by a set of surfaces which

comprise the finite volume. All the solution variables and fluid

properties are stored at the element nodes.

____________________________________________________________

Значения всех параметров хранятся в УЗЛАХ - то есть в ЦЕНТРАХ этих построенных "вокруг" них контрольных объёмов, а значит и размерность задачи зависит от кол-ва узлов.

!!!(прикрепите, пожалуйста, эту картинку кто может. там всё очень наглядно показано)!!!

PS: Кстати, именно об этом и Ваша цитата.

Изменено 14 февраля 2007 пользователем Druzhinin_S_L

[Tako 0]

Druzhinin_S_L, прошу прощения и у Вас и у тех, кого может быть сбил с толку.

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

А я до этого думал по другому. Хорошо что Вы подняли этот вопрос.

Тогда вопрос к размышлению.

Представим себе Гексагональную сетку. Я ее разбиваю на тетры. Количество элементов увеличилось в 6 раз. А количество местоположение узлов не изменилось.

Так что для CFX эти сетки будут одинаково считаться?

[Druzhinin_S_L 0]

Ничего страшного, никого Вы пока с толку не сбили. Даже Miki - гуру CFD - тоже пока безнадёжно заблуждается в этом вопросе (это для меня очень удивительно). Вопросик давно пора серьёзно обкашлять со всеми заинтересованными людьми.

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

Для CFX это конечно разные будут сетки. Хотя число уравнений не изменится, и время решения системы не возрастёт в разы, НО(!) для узлов изменится так называемый параметр Connectivity Number - то есть число элементов (elements, не путать с контрольным объёмом!), стыкующихся в данно узле. (на него, кстати, есть рекомендуемые ограничения в зависимости от типа элемента). Таким образом, постоенный вокруг узла контрольный объем будет состоять из большего числа подобъёмов ( в его постоении проучаствует большеее кол-во элементов) со всеми вытекающими последствиями для интегрирования. Грубо говоря, будет поточнее и подольше.

Тут другой ещё есть момент. Для любителей "прогнать" одну и ту же сетку на разных солверах. Fluent, например, использует в качестве контольных объемов именно элементы сетки (и ресурсоёмкость зависит от кол-ва элементов), а CFX делает так, как мы с вами уже разобрались (ресурсоёмкость ~ числу узлов, которых, кстати, всегда в разы (!!!) меньше). Таким образом, подобное сравнение изначально некорректно - сетки-то на самом деле разные.

ИМХО: При всей гибкости и разнообразности возможностей Fluent-а, реализация именно численных методов и дискретизация в CFX сделана на порядок грамотнее. Ну, после объединения под крышей Ansys-а они там сами разберутся.

Изменено 15 февраля 2007 пользователем Druzhinin_S_L

[Druzhinin_S_L 0]

Miki обиделся? Извини.