» Расчетные программы Lira, SCAD, Stark, Profet, MicroFE, etc.

Pendolf

Цитата:

А кто эту "Радугу" разрабатывает? В смысле, какая-то контора или отдельные энтуазисты?

Контора с наемными энтузиастами

Цитата:

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

Ну придется считать схему каркаса отдельно и задавать нагрузки, либо перемещения. Хотя этот переход и есть самая большая проблема ведь влияние основания при расчете каркаса не будет учитываться в данном случае.

Ulys


Цитата:

Не по делу, просто интересно: про сломанный Stark кто-нибудь слышал?
У меня-то академическая стоит с ключом,а так говорят его до сих пор никто не сломал...

Да, мне по ушам также ездили до прошлого года, пока в Москву не приехал.

Stroodder

Цитата:

Ну придется считать схему каркаса отдельно и задавать нагрузки, либо перемещения. Хотя этот переход и есть самая большая проблема ведь влияние основания при расчете каркаса не будет учитываться в данном случае

Расчет каркаса по прочности (подбор арматуры в плитах, колоннах/стенах и т.п.) и какие-то продвинутые расчеты, связанные связанные с его основанием (ну там крены всякие и т.п.) подчас возможно сделать только независимо друг от друга...
Да и есть ли смысл перегонять усилия/перемещения туда-сюда? И как соотносить результаты упругого и упругопластического расчета?
Расчет каркаса совместно с основнием в том же STARK'е можно сделать на объемных элементах - для армирования конструкций думаю более чем достаточно...
А если здание шибко высотное, осадки и крены совсем не помешало бы посчитать в какой-нить программе с нелинейными моделями грунта...
Впрочем, есть и сложные случаи, те же комбинированные плитно-свайные фундаменты - тут уж так просто их в старке не смоделируешь

Pendolf

Цитата:

асчет каркаса совместно с основнием в том же STARK'е можно сделать на объемных элементах - для армирования конструкций думаю более чем достаточно...

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

P.S. Интересно на чем считали ТЦ "Охотный ряд"

Stroodder

Цитата:

Интересно на чем считали ТЦ "Охотный ряд"

А его проектировали (или "научно сопровождали") не НИИОСП им. Герсеванова? Последние могут использовать как какие-то собственные программки, так и тот же Plaxis (или другие "грунтовые" расчетные программы: ZSoil, FLAC).

Народ влезу не в тему может есть у кого СП 52-101-2003 "Бетонные и железобетонные конструкции без предварительного напряжения арматуры"
Позарез нужно

Если Радуга дополнится оболочечными КЭ,то ей цены не будет!
Когда ожидается такая версия?

v2

Цитата:

Если Радуга дополнится оболочечными КЭ,то ей цены не будет!
Когда ожидается такая версия?

Вопрос к разработчикам.

Так не у кого новых правил нет?

Тогда С Новым Годом Форумчане, правда с наступающим!



Добавлено
В догонку - Кто считал полностью плиты в Мономахе - результатам можно верить?
Особенно интересны результаты в отнощении поперечной арматуры - кто что думает?

Плиты не считал,а вот в колоннах армирование сильно завышено в Мономахе (р.3).

Имеет ли смысл ставить RAID 0 для ускорения МКЭ-расчетов или это блажь ?

Да,кстати,с Новым Годом!

v2

Цитата:

Плиты не считал,а вот в колоннах армирование сильно завышено в Мономахе (р.3).

а в Starke занижено...

Ха в колоннах оно не сильно завышенно, а обалденно завышено
в Мономахе 3,0 может в четвертом что-то изменилось?

Армирование в колоннах надо считать по СНиП (благо это там есть)ручками по усилиям из МКЭ-прог (ИМХО,но уверенное).
А вот Мономах же "конструирующая" прога...там подбор арматуры д.б. подостовернее..

По поводу RAID 0 мнение кто-то имеет???

Ручками хорошо когда у тебя несколько типов колонн,
а у меня гораздо больше.
По полводу RAID 0 не знаю.

concreteb30
А зачем ручками? Арбат на это есть! Пытливые умы могут проверить и вручную, уверяю все сойдется
v2
А как быть если я в сейсмике 32 формы колебаний задам (что совсем не много, кто считал тот знает)??? Я же ОДНУ колонну буду дня три считать.

Да,Арбат или ОМ СНИП ЖБ или свое в Ексель-Маткад.

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

Да , с сейсмикой туго,вспоминаю,лет 5 назад делал, выбирал сочетания вручную,благо здание было небольшое. Думаю ,нужно приспособить Ексель-Маткад для выборки РСУ по усилиям ... Слышу как ругаетесь,господа, но иначе нужно на 300 % доверять проге, а если нет ... как в Мономахе - наоборот?
ИМХо, АРМИРОВАНИЕ В КОЛОННАХ ПОДБИРАТЬ ПО УСИЛИЯМ самостоятельно !

v2

Цитата:

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

Но, думаю, что сначала надо разобраться ЧТО, ЗАЧЕМ и КАК проверять...
В принципе, не исключаю, что программа может просто врать (ошибки и/или недоделки в коде/алгоритме, идиоты разработчики и т.п.) "в запас" или нет, но, не думаю, что это имеет место быть в массовом порядке
Так что доверять/не доверять каждый решает сам для себя. Хотя, как говорится, доверяй - но проверяй


Цитата:

АРМИРОВАНИЕ В КОЛОННАХ ПОДБИРАТЬ ПО УСИЛИЯМ самостоятельно!

А почему ты считаешь, что прога может правильно определить усилия, а вот армирование - не в состоянии? И зачем тогда она вообще нам нужна, да еще за такие бабки?

Другое дело, что в разных программах армирование ж/б сечений реализовано по-разному и, как следствие, будут отличия... Опять-таки, одна прога не учитывает кручение и трещины, другая - учитывает, но не по СНиПу
Такая проблема действительно есть...
В идеале, правильнее всего, задавать в сечении дискретное расположение стержней с фактической привязкой (как оно будет в реальности), да еще с учетом нелинейности (деформационная модель - в новом СП). Такую прогу, наверное, стоило бы написать в довесок к известным программным комплексом, опять-таки надо разобраться с импортом результатов (РСУ) из различных пакетов...
Еще туманный вопрос с учетом поперечного изгиба, расчетной длиной и т.д.

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


Цитата:

Имеет ли смысл ставить RAID 0 для ускорения МКЭ-расчетов или это блажь ?

А что ты хочешь ускорить? Если разложение матриц (основное занятие проги в процессе решения) - то лучше нарасти оперативку (эффект будет при условии если сейчас ее не хватает для твоих задач), RAID тут погоды не сделает...
Если же хочешь ускорить чтение/запись данных и результатов на диск (по-моему это не так критично) - может быть, но тогда уж лучше сразу ставить парочку Raptor'ов на 10000 об/мин, иначе, думаю, ты можешь просто не почувствовать качественных изменений

Мнение о том,что проверять усилия в колоннах и по ним подбирать армирование сложилось после ошибок по 2 сооружениям в СКАДе ,в одном случае дали готовые результаты - армирование,считал очень опытный человек, ситуации были критическими,неприятными. В СТАРке ,уже позже,имея этот опыт,даже не пытался получать армирование в колоннах.
Усилия в колоннах возможно проверить либо по упрощенной схеме или вручную,т.е. они легко (относительно армирования) проверяемы.Если получать в качестве рез-та армирование - нужно проверять и усилия и армирование все равно.
Поэтому больше не хочу теоретизировать,свое мнение высказал,попытался предостеречь от своих ошибок .
Готов поменять мнение,если аргументы будут практическими, переубеди

RAIDом хочу ускорить работу с графикой в СТАРКе, кажется,там идет обмен с винтом?
В СКАДе ускорять вроде и нечего

v2

Цитата:

Мнение о том,что проверять усилия в колоннах и по ним подбирать армирование сложилось после ошибок по 2 сооружениям в СКАДе

Давай конкретнее, какого плана ошибки: неправильные усилия в колоннах (и, соответственно, неверное армирование) или усилия правильные, но бред с армированием?
В первом случае надо проверять РС, во втором - только пересчитать армирование...


Цитата:

RAIDом хочу ускорить работу с графикой в СТАРКе, кажется, там идет обмен с винтом?

Винт нагружается только в процессе открытия нового файла и/или подгрузки результатов (в бОльшей степени). А в обработке графики задействуется практически только процессор+память, так что тут RAID бесполезен... Лучше "камень" погорячее поставь
А у СТАРКа графика сама по себе тормозная, да еще и нестабильная

1.Неправильное армирование при правильных усилиях.
2.При перерисовке схемы как при выводе рез-тов в СТАРК ,так и при ее создании винт слышно шуршит, почему и хочу ускорить

v2
Pendolf
Все дело в память+камень господа. На новой машине, которую я из-за расчетов впрочем и наворотил работа с графикой стала намного приятней(ну видеокарта тоже не последнюю роль играет) А вот время расчета, особенно НЕИМОВЕРНО долгий расчет армирования и выборки РСУ зависит по моему мнению от кривого составления/обработки матрицы. Вся фишка ИМХО в том что алгоритм расчета у той же Лиры ускорен не за счет упрощений, а за счет улучшения алгоритма счета или, говоря другим языком, посредством кратчайшего пути оптимизации матрицы значений. Так что думаю никакие прибамбасы кроме как увеличения мощности не помогут. ИМХО: главное много быстрой памяти. Работал на трех версиях старка и везде одно и то же

P.S. Интересно когда 64-х разрядные расчетки появятся?

Stroodder
Время "счета" задачи (статический, динамический расчет и т.д.) определяется, главным образом, скоростью разложения матрицы (жесткости, масс и т.п.) расчетной модели...
В этом плане есть всякие оптимизированные методики, реализованные в решателях новых версий ЛИРЫ, СКАДА, СТАРКа...
Быстродействие их примерно на одном уровне.

С РСУ вопрос в другом...
В принципе, это просто перебор всех допустимых комбинаций усилий от разных нагружений. В СТАРКЕ это делается довольно медленно (видимо, на основе простого перебора), в ЛИРЕ - быстро (очевидно, что не "просто перебор" ), но, учтите, что к ЛИРЕ есть нарекания в этой части...
Так что наиболее тормозные конструктивные расчеты (РСУ, арматура) в СТАРКе особо-то никак не ускоришь, можно конечно камешек погорячее, но радикально это ничего не изменит


Цитата:

ИМХО: главное много быстрой памяти

Не скажи, не всегда...
Надо смотреть, сколько программа "отъедает" свободной памяти при критической загрузке и сколько остается, и если свободной памяти и так полно, то дальнейшее наращивание ОЗУ-шки ничего не даст.
Быстрота памяти штука, бесспорно, полезная... Еще двухканальность помогает


Цитата:

P.S. Интересно когда 64-х разрядные расчетки появятся?

Дык есть они давно...
Например, тот же ANSYS

Когда появятся такие программы в нашем отечестве - не знаю, боюсь что уже не на нашем веку

Pendolf

Цитата:

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

А я разве не так написал ?


Цитата:

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

Логически да, однако имею две идентичные машины на работе, на моей памяти добавили и время ~30% меньше уходит.

А как по поводу долгого расчета армирования в старке - алгоритм-то простой в линейной постановке????

Stroodder

Цитата:

Логически да, однако имею две идентичные машины на работе, на моей памяти добавили и время ~30% меньше уходит

Тут может примешиваться много факторов - я и говорю, что прямой зависимости нет


Цитата:

А как по поводу долгого расчета армирования в старке - алгоритм-то простой в линейной постановке????

Насколько там простой алгоритм сказать сложно... Впрочем, не думаю, что для общего случая косо-внецентренно-сжато-изгибаемого элемента алгоритм прямо таки уж очень простой (даже без учета нелинейностей)
Опять же, надо прогнать все сечения колонн (обычно их 3..5 на элемент) на все РСУ...

Но вот почему СТАРК ТАК медленно считает арматуру?
Может просто он один считает честно (по ВСЕМ РСУ), а все остальные халтурят?

Pendolf

Цитата:

Но вот почему СТАРК ТАК медленно считает арматуру?
Может просто он один считает честно (по ВСЕМ РСУ), а все остальные халтурят?

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

Цитата:

Но вот почему СТАРК ТАК медленно считает арматуру?
Может просто он один считает честно (по ВСЕМ РСУ), а все остальные халтурят?

Проблема с алгоритмом для РСУ, согласен с Stroodder
По вопросу Конвертор STARK ES<-> ЛИРА от Еврософта.
Делал запрос в Еврософт и вот выдержки:
1. proFEt&STARK ES 7.2/3.1+ содержит конвертор StarLi для обмена данными в форматах FEA (ПК Stark_ES) и LIR (ПК ЛИРА), обновление с версии proFEt&STARK ES 7.2/3.1 -150$.
2. Обмен данными между ПК STARK и ПК ЛИРА осуществляется с помощью специального переходного файла в формате XML и имеющего расширение SLI.
Переходной SLI-файл формируется на основе согласованного шаблона. Передаются следующие данные: координаты узлов, элементы (стержень, оболочка, объемное тело), связи/краевые условия, материалы/жесткости, узловые нагрузки, массы в узлах, осадка колонны, элементные нагрузки, элементные шарниры( только в стержнях ), объединение перемещений узлов. Конвертор StarLi осуществляет:
чтение конечно-элементных данных файла ПК STARK ( FEA-файл ), преобразование данных и запись в переходной SLI-файл; чтение данных SLI-файла, их преобразование и запись в FEA-файл ПК STARK.

А кто-нибудь уже имел дело с MicroFE 2004? Насколько это реально "основательно улучшенная" инкарнация ProFEt&Stark? Исправлены хоть какие-нибудь глюки, стабильно переходящие из версии в версию?
Короче, стоит ли оно дополнительной тыщи Ушастых Енотов?

Pendolf
Что есь баксы на этом форуме?

Pendolf

Цитата:

А кто-нибудь уже имел дело с MicroFE 2004? Насколько это реально "основательно улучшенная" инкарнация ProFEt&Stark? Исправлены хоть какие-нибудь глюки, стабильно переходящие из версии в версию?

Я слегка пробовал, стоит только на работе, много было глюков, т к сырая версия еще, Техсофт торопился с выпуском, думаю теперь уже подправили.
Развитие может быть у Техсофта, поэтому на фирме сделали ставку на него. Просто у Еврософта теперь некому заниматься развитием модуля Stark (все разработчики ушли в Техсофт), а Profet совсем старый и не обновляется.

Stroodder
УЕ (Ушастые Еноты) = баксы

Slavik01


Цитата:

Я слегка пробовал, стоит только на работе, много было глюков, т к сырая версия еще, Техсофт торопился с выпуском, думаю теперь уже подправили

Слышал, что вроде переделали графику (в лучшую ли сторону? ), может теперь хоть пошустрее и не вываливается при каждом неудачном телодвижении?


Цитата:

Развитие может быть у Техсофта, поэтому на фирме сделали ставку на него. Просто у Еврософта теперь некому заниматься развитием модуля Stark (все разработчики ушли в Техсофт), а Profet совсем старый и не обновляется

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