расчет баллона

[a_a_a+ 11]

Поймите вы наконец простое правило. Если перемещения кривые, то ЭНЕРГИЯ деформации кривая и весь расчет кривой. Это основное правило для практикующих расчетчиков.

Картинкой кривой расчет не прикроешь.

Практикующий расчётчик - это, по здравой логике тот, кто решает практические задачи. Или хотя бы просто задачи.

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

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

...

А энергия - это (в линейной статике) функция производных перемещений и упругих констант.

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

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

Тот же COSMOSWorks в алгоритмах адаптивной сетки использует для оценки сходимости (помимо полной энергии) и плотность энергии в элементах. Пользователь, кстати говоря, может управлять "важностью" этих критериев.

"Полная энергия" - это своего рода "средняя температура по больнице" или "средняя зарплата в конторе". Конструкции разваливаются не "в целом". Это только домики из песка так разрушаются. Да и то, когда песок сухой!

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

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

И еще раз взываю к "практикам" расчета: задачи в студию! Ссылки на модели даны.

А простой резиновый шарик прогнал с "мягкой пружиной". Считает как прямым,

так и итерационным методом; итерационным - в 4 раза быстрее (железо старое, одно ядро).

Ну с резиновым (в смысле из резины) шариком Вы, уж, поосторожнее!

Вот это совсем, однако, непростой (при расчете МКЭ) объект для "простого" инженера!

[Борман 2 391]

И еще раз взываю к "практикам" расчета: задачи в студию! Ссылки на модели даны.

Нельзя ни поиметь IGES ?

PS. А что требуется посчитать ? Требуется предложить метод крепления уравновешенной конструкции ?

[a_a_a+ 11]

Нельзя ни поиметь IGES ?

PS. А что требуется посчитать ? Требуется предложить метод крепления уравновешенной конструкции ?

Идет дискуссия (пустая, по сути) на тему, можно ли в принципе считать незакрепленные уравновешенные объекты? А если можно, то нужно ли?

IGES постараюсь выложить в понедельник.

[Fedor 1 616]

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

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

[Fedor 1 616]

Нормальная картинка, только не раскрашенная. А я был победителем на Инвеком -92 по САПР и что? Бывали времена, а сейчас моменты

[a_a_a+ 11]

При какую новизну вы говорите? Какие “фишки” обсуждаете?

Пример. Чистое кручение пластины. Задача решена и прямым и итерационным методом в 1988 году.

Такая картинка устроит?

Эта - устраивает. Для 1988 года круто. Да и сейчас можно народ подразнить :)

А как насчет задачи с несимметричным телом под давлением?

[Fedor 1 616]

или

подойдут?

Правда это 2000, но было и в конце восьмидесятых подобное в DOS

[nokal 2]

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

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

[a_a_a+ 11]

Вы скиньте .STEP файл. И дайте пояснения по нагрузке. Если нагрузка уравновешена, то я не вижу проблем. Форма тела может быть любой.

<noindex>http://files.mail.ru/G6NKJ4</noindex> - iges

<noindex>http://files.mail.ru/EUYYSK</noindex> - step

Нагрузка - давление в полости.

Модель чуток поменял относительно опубликованной, а то старая была такой "кривой", что iges и step обратно не восстанавливались без ошибок.

Только вопрос-то дискуссии (если его кто его уже успел забыть по ходу обсуждения "смежных" тем) состоял в том, можно ли рассчитывать в статике незакрепленные (или частично незакрепленные) объекты, подвергнутые действию уравновешенных нагрузок (по крайней мере, в "незакрепленных" направлениях). "Консенсус", вроде как, найден :)

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

Что-то как-то сомнительно :(

Если ракета летит с ускорением вдоль оси бака, то никакой симметрии относительно плоскости ортогональной этой самой оси нет!

Здесь нужно подключать другие "фишки" COSMOSWorks или голову. Можно всё вместе.

[a_a_a+ 11]

Хитрую модель вы придумали. На GPU время расчета 0.7 сек.

Ну это, подозреваю, для линейных элементов :)

Core2Quad 3ГГц примерно то же дает.

А картинку напряжений/деформаций посмотреть?

[a_a_a+ 11]

Время расчета для линейных элементов. Картинка напряжений.

ОК!

[a_a_a+ 11]

А прямым методом, сколько времени идет расчет? В модели примерно 32 000 степеней свободы. Надеюсь 8 Гб оперативки хватит?

А оперативки, конечно, хватит, если хватит денег ее купить :)

На фоне других программ - я не стал их снимать (там два Солидвёркса - один с Фловёрксом, другой с Космосом, еще туча всякой фигни), а также Виста Алтимэйт, затраты памяти на собственно решатель с его данными, копеечные.

Что касается сравнения прямых решателей с итерационными, то не всё так просто в жизни, типа итерационный есть во много раз меньше памяти. Да, как правило, это так. Но для нелинейных (в тч контактных) задач прямой метод (в COSMOSWorks, по крайней мере), дает более быстроее решение. А память кушает всего раза в два-три (максимум) больше.

Кроме того, если использовать не чистые "ленточные", а профильные или "блочно-профильные" схемы хранения матрицы жесткости, то можно вполне добиться вполне сопоставимых затрат памяти.

Кроме того, личная практика показывает (я в своё время руководствовался опусом, не помню точно названия - типа Численные методы решения больших разреженных систем линейных уравнений - А. Джордж, Дж. Лю, изд-во Мир, год эдак 1985 - с тех пор у нас ничего лучше не появилось), можно придумать блочную схему с упорядоченным взаимодействием с диском. И без проблем все решать в ограниченном объеме оперативки.

При этом (по моим воспоминаниям о тех алгоритмах) распараллелить их было бы очень несложно.

[a_a_a+ 11]

Я правильно понял, что 55 362 степени свободы ПРЯМЫМ методом решены за 10 сек.

Это полное время решения задачи.

Собственно решение СЛУ прямым методом заняло около 7 сек.

[a_a_a+ 11]

Если элементы сгенерировать с промежуточными узлами. Что в этом случае скажет прямой метод?

Прямой метод сказал, что памяти для собственно решателя нужно 2,3 Гб, но многоядерность благополучно продолжает поддерживаться. А время решения СЛУ составило порядка 1.5 мин.

[a_a_a+ 11]

Вы уверены, что это прямой метод решает так быстро?

В программе написано, что прямой :)

Здесь еще и компьютер нехилый - quad 3ГГц

[a_a_a+ 11]

Собственно решатель работает порядка 5 секунд. Затраты памяти копеечные.

Решатель распараллеливается (по крайней мере, задействует ядра ) порядка на 50%.

Надо для объективности сказать (и это, кстати, фигурирует в “официальных” тестах), что, например, для контактных задач степень “распараллеливания” итерационного решателя падает больше, чем прямого.

И еще. Вот, например, в COSMOSFloWorks пользователь может в явном виде указывать, какие процессоры для какой задачи использовать (заодно можно косвенно оценить эффективность распараллеливания). Ну и кому это надо?

Как показывает практика, Windows спокойно разбирается в том, как загрузить процессоры. И не надо мешать ей работать. Можно благополучно запустить пару решателей Works и пару решателей FloWorks. Если процессоров/ядер много (пробовал до 4), то они в сумме загружаются на 100%.

При этом никто не мешает работать в Ворде и Интернете. Даже приоритеты не надо менять.

Но все это только до тех пор, пока процессы помещаются в оперативной памяти! Иначе компьютер намертво встает.

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

[a_a_a+ 11]

Если решать прямым методом и оптимизировать профиль, то процесс оптимизации примерно 8 мин. Матрица занимает 20 Гб памяти. Время решения 10 часов. Как можно ускорить решатель в 600 раз в 7 раз уменьшить размер матрицы?

Какие будут соображения?

А кто его знает, что они там делают. Им, думаю, зарплату не зря платят.

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

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

В предудыщих версиях в протокол выводилась фраза типа "ширина ленты"...

Сейчас этого нет.

[Fedor 1 616]

"Когда в свое время я его оптимизировал, то делал это по графам не в терминах степеней свободы, а в терминах узлов!

" - правильная и на мой взгляд идея. Когда то тоже так делал. На 286-7 достаточно шустро все получалось, не хуже чем на ЕС .

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

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

[a_a_a+ 11]

Оптимизация оптимизирована. (Получилось как масло масляное). Большое количество узлов и большая связанность матрицы. Поэтому такое время.

У меня такой вопрос. Почему вы не посчитали кубик с делением 40х40х40? Ведь данный кубик существенно меньше по размерности.

И еще. Вы проверяли данный алгоритм на ОЧЕНЬ плохо обусловленных матрицах?

А зачем мне кубик, нужно было подобрать задачу, чтобы продемонстрировать/выяснить возможность расчета "подвижных" объектов в статике.

COSMOSWorks, понятное дело, не даёт информации об обусловленности.

Частенько возникают задачи, про которые уже писал. Типа есть деталюхи, соединенные штифтами, имеющими возможность крутиться. Из-за погрешности сеточной геометрии (или бог знает чего еще - есть различные типы контакта и варианты их реализации, которые, между прочим, меняются от версии к версии) возникают на поверхности контакта неуравновешенные контактные силы, порождающие неуравновешенный же крутящий момент (сеточная поверхность-то некруглая!). По жизни "посредник" стабилизируется трением, локальной пластической деформацией, собственным несовершенством формы и еще бог, опять-таки знает чем. Но задачи с трением очень долго (иногда) считаются, а влияние трения на НДC не всегда значительное. Поэтому на первом этапе "доверяюсь" фишкам Космоса (тем самым "податливым пружинам"), а если они "не держат", то сам придумываю псевдожесткости (средствами того же Космоса).

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

[a_a_a+ 11]

Как вы проверяете точность проведенного расчета? Прямым методом и итерационным.

Скоростные характеристики вы показали. Теперь нужно показать с какой точностью вы считаете.

Ну это совсем, уж, интимный вопрос

На людях про такое не говорят

Тема отдельной дискуссии. Чуток, кстати, я про критерий полной энергии написал.