[X-DeViL]

Предлагаю обсудить положительные и отрицательные стороны этих программ...

Посты "SCAD/LIRA рулит" прошу не стирать ^^

Тема навеяна темой на IXBT Intel vs AMD ^^

[Rotfeder]

b]maestro[/b]
Спокойно. МКЭ- вообще не идеал. Там полно своих минусов. Тем не менее стыковка в общем узле КЭ с разным количеством степеней свободы в узле- это традиционная проблема МКЭ. В данном случае надо вводить абсолютно жесткое тело. ТАкой подход будет реализован в 9.4.

А может лучше просто не использовать элементы с разным числом степеней свободы в одном проекте? сделать в узле оболочки не 5 степеней свободы, а шесть, как это сделано в MicroFe - тогда стержни с оболочками прекрасно состыкуются.

Что МикроФе, что ЛИра считаю усилия в ЦТ КЭ. А там- можешь пересчитывать, можешь нет. Но надежных алгоритмов пересчета нет.

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

Теперь о многопроцессорности в МикроФе- просветите, плз...
Все просто - схема разбивается на подконструкции (если я не ошибаюсь, в Лире их называют суперэлементами). Кажадя подконструкция может быть рассчитана независимо от других (за исключением исключением интерфейсных узлов - узлов стыка разных подконструкций). Так вот на многопроцессорных машинах MicroFe считает эти подконструкции паралельно. Это было сделано уже довольно давно - года 4 назад, а может и больше.

[maestro]

Rotfeder

А может лучше просто не использовать элементы с разным числом степеней свободы в одном проекте? сделать в узле оболочки не 5 степеней свободы, а шесть, как это сделано в MicroFe - тогда стержни с оболочками прекрасно состыкуются.

Это невозможно теоретически. НЕкоторые КЭ не могут обладать некотрым степенями свободы. НАпример оболочка не может канонически воспринимать изгиб в своей плоскости. Ввиду неизвестности размера всей стены, например. КЭ об этом просто "не знает". Аналогично, только хуже- объемники. У них только 3 степени свободы в узле. Это- теория. Поэтому- КЭ с разным кол-вом степеней свободы в узле в одной схеме- будут. Будут и грабли, с этим свзянные.

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

Все правильно. Но, насколько я знаю, в МикроФе, как во всех современных прогах реализован МКЭ в форме перемещений. А там в узлах вычисляются перемещения, а усилия- в ЦТ КЭ по его жесткостным характеристикам и разницам перемещений узлов. Поэтому (пусть меня поправят) но речь идет именно о пересчетах. И вообще- при этом куча проблем. НАпример- а как отличать обычные узлы, в которых можно интерполировать от точек с сингулярными разрывами? Лира когда-то так считала, но это уже пройденные для них вещи.

Все просто - схема разбивается на подконструкции (если я не ошибаюсь, в Лире их называют суперэлементами). Кажадя подконструкция может быть рассчитана независимо от других (за исключением исключением интерфейсных узлов - узлов стыка разных подконструкций). Так вот на многопроцессорных машинах MicroFe считает эти подконструкции паралельно. Это было сделано уже довольно давно - года 4 назад, а может и больше.

Кто бьет на подконструкции? Ты или сама программа?

[p_sh]

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

Сообщение от SCAD справка Режим Вычисление усилий в дополнительных сечениях используется в тех случаях, когда необходимо знать значение усилий в промежуточных точках по длине стержня или в узлах пластинчатых элементов (напомним, что по умолчанию усилия вычисляются в начале, конце и середине стержня и центре пластины). Значения усилий в промежуточных сечениях необходимы, например, если предполагается выполнять подбор арматуры. В окне следует активизировать опции, определяющие вид элементов (стержни или пластины), и назначить параметры: для стержней - количество сечений (общее, включая сечения в начале и конце стержня), для пластин и объемных элементов - вид выдаваемой информации.

и неточности в справке к скаду.

[Rotfeder]

maestro

Это невозможно теоретически. НЕкоторые КЭ не могут обладать некотрым степенями свободы.
Теория - она не стоит на месте, она продвигается вперед
Все, что вам сказали, стоит иногда подвергать сомнениям. Почитайте, например, книжку - Ф. М. Свойский. Граничные условия для конечных элементов со вращательными степенями свободы. СПб 2005 г.
Есть еще много чего, но эта книжка на русском языке, и написана более-менее доступно, с примерами расчета и т.п.

Аналогично, только хуже- объемники. У них только 3 степени свободы в узле. Это- теория.
Это не теория - это традиция. Опять же почитайте вышеупомянуютую книжку.

Но, насколько я знаю, в МикроФе, как во всех современных прогах реализован МКЭ в форме перемещений. А там в узлах вычисляются перемещения, а усилия- в ЦТ КЭ по его жесткостным характеристикам и разницам перемещений узлов. Поэтому (пусть меня поправят) но речь идет именно о пересчетах.
Опять же вы ошибаетесь.
Основной конечный элемент для MicroFe - это элемент, основанный на гибридном методе. Я читал в руководстве к Лире, что "гибридный метод не получил распространения". Это не так.

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

Понимаете, maestro, многие ваши утверждения об мкэ или спорны или не верны. Вы ссылаетесь на мифическую теорию, а теория говорит совсем о другом. Боюсь, что все это слишком сложно, чтобы объяснять в форуме - почитайте книжки - не руководства к программам.

Кто бьет на подконструкции? Ты или сама программа?
Сама программа. Хотя человек в этом тоже может поучаствовать при желании.

[Дмитрий]

Сообщение от Rotfeder Так вот на многопроцессорных машинах MicroFe считает эти подконструкции паралельно. Это было сделано уже довольно давно - года 4 назад, а может и больше.

Все же складывается такое субъективное впечатление, что параллельный счет в MicroFe в существующем виде не слишком-то уж эффективен...
По крайней мере, у меня на двухядерном Athlon'е с частотой 2 ГГц на сравнительно большой задачке выигрыш по общему времени счета составил всего ~25% (при сравнении с разбиением на 4 подконструкции и без разбиения).
Зато тут есть грабли такого плана: на двухъядерных/двухпроцессорных машинах расчет задачи с подконструциями идет только в два трида, и памяти все это дело жрет больше, чем однопоточный счет. Представим ситуацию, что посчитать без подконструкций не получается (не хватает памяти), однако с подконструкциями в таком случае получается только хуже...
Пример из жизни: хотел просчитать большую задачку (требует около 850 Мб оперативки) с подконструкциями и без, и сравнить время. В результате - без подконструкций посчиталось, с подконструкциями (делал разбиение до 8 подконструкций) - "недостаточно памяти": требует около 950 Мб оперативки, пишет что недоступно (а прикол еще и в том, что всего на машине 2 Гб ОЗУ, причем в тот момент свободно около 1,7 Гб).

ЗЫ. Кстати, заметил такой глюк: если в fea модели есть слоистое основание, то после его удаления при последующем счете модели (без основания) возникает ошибка генерации этого самого основания, т.е. полного удаления его не происходит. Приходится удалять его "остатки" из fea-файла ручками...

[SV]

К вышесказанному хочу добавить, что это действительно серьезная проблема.
При попытке сделать расчет 3-х сблокированных секций 14-6-14 этажей на слоистом основании, для анализа их взаимного влияния
на деформации, расчет не пошел по той же причине.
Пришлось идти на некоторые ухищрения- защемлять надземную часть выкинув фундамент, считать посекционно, затем передавать узловые нагрузки на фундаменты 3-х секций и проводить расчет. Однако данный прием далек от реальной работы системы, т.к. надземная часть и соответственно нагрузки от нее считались без учета тех самых деформаций основания.
Различные варианты разбиения на подконструкции ни к чему хорошему не привели.
:?: :?: :?:

[Rotfeder]

Дмитрий
Вы конечно же правы. Многопроцессорный расчет, вообще, имеет тот недостаток, что между запущенными нитями (тредами) расчета начинается борьба за ресурсы - за память, за доступ к диску. Поэтому достичь двухкратного ускорения счета за счет добавления второго процессора никогда не удается.
По крайней мере, у меня на двухядерном Athlon'е с частотой 2 ГГц на сравнительно большой задачке выигрыш по общему времени счета составил всего ~25% (при сравнении с разбиением на 4 подконструкции и без разбиения).

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

Сейчас основная проблема - это недостаток оперативки. Не важно, что на машине ее может стоять и 4 и 8 Гб - важно то, что из-за 32-разрядной архитектуры Windows процессу (процесс - это запущенный exe-шник, который может делить вычислений по нескольким нитям) доступно в теории 2Гб памяти, а на самом деле меньше - в эти 2 Гб входят и сам код программы и системные dll и т.д.
Опять же, память желательно иметь большим непрерывным куском - а для этого приходится извращаться.
Так что если для каждой подконструкции нужно много памяти, то вдвоем они могут и не влезть (пусть даже по отдельности каждая влезает).

Для поставляемой сейчас версии программы - доступный лимит оперативки около 1 Гб (зависит от конкретной машины и операционки). Рабочий вариант - тот который пойдет в новую версию - может использовать 1,5 Гб - больше из 32-разрядной системы выжать не удасться.
С другой стороны есть другие варианты решения проблем и с опреативкой и с многопроцессорными расчетами, про которые пока не буду рассказывать.


ЗЫ. Кстати, заметил такой глюк: ...
Честно говоря я не в курсе, а вы писали к нам что-нибудь по этому поводу? Обычно мы пытаемся исправлять ошибки в программе. Для Ing2005 обновления можно скачивать с нашего сайта - мы их выкладываем раз 1-2 месяца.

[Дмитрий]

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

Ну, о двухкратном ускорении никто пока и не мечтает, но 50-70%, кажется, вполне реально. :wink: Ведь расчетная МКЭ программа по сути ничем не лучше каких-нибудь Photoshop'ов & 3D Studio, где из многопоточности сумели выжать что-то существенное.
Кстати, реализованный подход к параллельности вычислений (с подконструкциями), наверное, не единственно возможный?

Сообщение от Rotfeder Для поставляемой сейчас версии программы - доступный лимит оперативки около 1 Гб (зависит от конкретной машины и операционки).

Да, я примерно так и предполагал.

Сообщение от Rotfeder Честно говоря я не в курсе, а вы писали к нам что-нибудь по этому поводу? Обычно мы пытаемся исправлять ошибки в программе.

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

После подтирания в fea-файле секции, содержащей данные про основания, и последующего открытия/сохранения файла - все ОК.

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

Про обновления знаем, регулярно скачиваем - спасибо.

[Rotfeder]

Сообщение от Дмитрий Ну, о двухкратном ускорении никто пока и не мечтает, но 50-70%, кажется, вполне реально.

Я уже точно не помню, так как сам этим не занимался, но по-моему получалось 70-80% выигрыша в скорости счета, но все это при достаточном запасе оперативки.

Сообщение от Дмитрий Кстати, реализованный подход к параллельности вычислений (с подконструкциями), наверное, не единственно возможный?

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

[Дмитрий]

Сообщение от Rotfeder Я уже точно не помню, так как сам этим не занимался, но по-моему получалось 70-80% выигрыша в скорости счета, но все это при достаточном запасе оперативки.

70-80% - это цифры для решателя stark/microfe ???
При моем "блиц-тестировании" на предельно больших задачах (для данной программы) я получил до 30% выигрыша, на небольших задачах (требующих ~100 Мб оперативки) выигрыша вообще не наблюдалось...

[Rotfeder]

Дмитрий
Прошу прощения, был не прав - все забыл. Сейчас спросил у коллег - все так, как вы сказали.
Нормальный выигрыш в скорости был только на отдельных этапах решения задачи. А суммарный выигрыш небольшой. С другой стороны 30% - это лучше чем ничего

[Brazda]

СКАД ВеСТ - пакет прикладных программ Лира 3.2 нагрузки и воздействия. Одна и та же задача - ветровая нагрузка на ж/б столб. В СКАДе выдаёт значения в т/м, в Лире в тс/м2. Если методика расчёта одна и таже, то почему разница? Непонятно как считает СКАД, если в формуле Wо=0,038т/м2 (III ветровой район) и безразмерные коэффициенты, то почему на выходе размерность т/м?

[Tony_Chu]

Сообщение от Brazda СКАД ВеСТ - пакет прикладных программ Лира 3.2 нагрузки и воздействия. Одна и та же задача - ветровая нагрузка на ж/б столб. В СКАДе выдаёт значения в т/м, в Лире в тс/м2. Если методика расчёта одна и таже, то почему разница? Непонятно как считает СКАД, если в формуле Wо=0,038т/м2 (III ветровой район) и безразмерные коэффициенты, то почему на выходе размерность т/м?

У меня скад выдает в т/м2

[Brazda]

СКАД в смысле ВеСТ? так значения отличаются существенно

[крокодил]

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

[Fellini]

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

Будем ждать пока отучишься и появится толк.

[Vavan Metallist]

Сообщение от Brazda СКАД в смысле ВеСТ? так значения отличаются существенно

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

[Sid Barret]

Сообщение от Vavan Metallist Я заметил, что ППП лировский в расчетах ветра на круглые элементы бачину выдает. ВеСТ правильнее считает. Утверждаю так потому, что сделал себе калькулятор в екзеле и с вестом сходится очень хорошо. ППП завышает раза в 2, а то и больше. По моему что то у них с единицами.

у меня вообще дела плохи, я иногда уже и екселю не всегда доверяю..

[Brazda]

Vavan Metallist, а про размерность что скажете?

[Vitkov]

Сообщение от Rotfeder Почитайте, например, книжку - Ф. М. Свойский. Граничные условия для конечных элементов со вращательными степенями свободы. СПб 2005 г. Есть еще много чего, но эта книжка на русском языке, и написана более-менее доступно, с примерами расчета и т.п.

Уважаемый Rotfeder! Будьте так любезны, дайте почитать эту книжку. Может завалялся электронный вариант. Спасибо.