Стоит ли приобретать расчетную программу Пруск? Может кто подскажет?

[Дмитрий]

Да, вот купили недавно... Практически не используем - по мне пользоваться этим невозможно, ну разве кроме может быть тех, кто это все придумал...
Такого дебильного ввода я более нигде не наблюдал... :shock: Некоторые задачки довВести до логического завершения не хватает терпения, какие-то данные уже забиты, какие-то не обязательно вводить и т.д.
Чессно слово
[ATTACH]1098549596.jpg[/ATTACH]

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

[Дмитрий]

Не подумайте, что имею я что-то против сей проги и ее разработчиков, просто мне она не нравится по следующим причинам:
1. Нечеловечий ввод данный (см. выше).
2. И еще вот что: она заточена под очень узкие, слишком классические случаи. В моей практике очень редко встречаются квадратно-прямоугольные плиты, а если попадется внецентренно-нагруженный фундамент, так он еще и со смещенной от центра колонной/стеной. Так что пока всякие Пруски - в сад, EXEL - форева! 8)

Как я понял, Пруск не годится в каких-то случаях. А какая программа годится для всех случаев?

[dermoon]

Сообщение от Гость Как я понял, Пруск не годится в каких-то случаях. А какая программа годится для всех случаев?

Чаще всего одной "универсальной" прогой не обойтись, потребуется несколько наиболее подходящих.

[Дмитрий]

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

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

Если бы голову можно было бы заменить программой, то сначала исчезли бы "опытные пользователи-инженеры", а вслед за ними и мы грешные - программисты.

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

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

>>>>Уж лучше бы сделали возможность пользовательского программирования (по типу тех же буржуев) - ИМХО это более гибкий и продвинутый инструмент, чем всякие аппендиксы

Про буржуев: Старк - это русифицированная и улучшенная версия "старого" немецкого MicroFe, ПРУСК - сильно урезанная немецкая BauStatik, СПиН - расширенный немецкий Pfificus, все эти (немецкие) программы разрабатывались совместно немецкими и российскими программистами и в Германии это лучшие продукты в своей области. "Дебильный" ввод ПРУСКа (т.е. BauStatik) несколько лет назад был очень высоко оценен "опытными пользователями-инженерами" (немецкими) на крупнейшей международной компьютерной выставке CeBIT в Ганновере.
А пользовательское программирование... "догнать Савранского - это утопия" (с) "Покровские ворота". Если пользователь может писать алгоритмы расчетов, то это пользователь не SCADов-Лир-ПРУСКов и пр., а Delphi, Visual C++, ну на худой конец какого нить Basic.

Похоже, живем по пословице: "Что немцу - здорово, то русскому - смерть".

[Дмитрий]

Разработчик

Если бы голову можно было бы заменить программой, то сначала исчезли бы "опытные пользователи-инженеры", а вслед за ними и мы грешные - программисты.

Истину глаголите...
Слава Богу, ни те, ни другие исчезать как вид пока не собираются
Программы для инженеров пишут программеры, а инженеры пытаются на них реально проектировать и этим противоположностям, увы, не достигнуть гармонии и всеобщего удовлетворения

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

Развиваются они может и самостоятельно, но приобретаются, как правило, в довесок. Причем, часто под впечатлением рассказов разработчиков, о том как классно посчитать усилия в основной программе, а "произвести расчет и конструирование" в ПРУСК. Вот я о чем
Насчет раскладки арматуры и узлов рам - абсолютно с Вами согласен, но основная программа прочностного анализа должна уверенно давать базовые результаты, как
1. площадь арматуры или стальной профиль
2. трещины и деформации
для той схемы расчетной схемы, которую задает пользователь.
"Довески" никоим образом не должны служить заплатками на основную прогу, в коем качестве они иногда неофициально позиционируются. К примеру, есть разговоры типа: что армирование колонн надо считать в ПРУСКе, потому что, к примеру, в STARK ES:
1. не учитывается кручение для колонн
2. вроде бы не производится проверка трещиностойкости для 3D-балок
3. в ряде случаев нельзя задать оптимальную схему армирования или посчитать поперечную арматуру и т.п.
Так что судите сами где кончается истина и начинается заблуждение... 8)

Дебильный" ввод ПРУСКа (т.е. BauStatik) несколько лет назад был очень высоко оценен "опытными пользователями-инженерами" (немецкими) на крупнейшей международной компьютерной выставке CeBIT в Ганновере.

Увы, выставки-презентации-пьянки с демонстрацией решения специально отобранных "лучших зерен" и работа с реальным маразмом некоторых не вполне психически здоровых архитекторов - две большие разницы, как говорят в Одессе
Ну ладно, не буду больше призывать "Убить Дебилла", сформулирую претензии чисто конкретно 8) :
1. объем ввода данных в ПРУСК сильно раздут и слабо структурирован
2. слабая логическая связь между расчетной схемой и переменными параметрами
3. Отсутствует порядок в умолчаниях и вводимых данных
4. Трудно понять, что еще нужно ввести, почему неактивна кнопка счета?
6. Все это еще и сдобрено парочкой-троечкой глюков

То что в этой проге действительно круто (для сателлита-калькуллятора), так это ее стоимость: $700 (без НДС) :wink:

Если пользователь может писать алгоритмы расчетов, то это пользователь не SCADов-Лир-ПРУСКов

Да, если пользователь умеет писать на "Delphi, Visual C++, ну на худой конец какого нить Basic", то это - не наш пользователь
"Наши люди в булочную на такси не ездят!" - позиция понятна :wink:
Тут уж позвольте с Вами не согласиться: возьмите пользовательское программирование в AutoCAD, Word, EXEL. Масса людей пишут по-маленьку для себя и других (причем безвозмездно) и отнюдь не от переизбытка свободного времени...

ЗЫ. Блин, целый трактат получился

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

>>>>Программы для инженеров пишут программеры, а инженеры пытаются на них реально проектировать и этим противоположностям, увы, не достигнуть гармонии и всеобщего удовлетворения

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

>>>>Развиваются они может и самостоятельно, но приобретаются, как правило, в довесок. Причем, часто под впечатлением рассказов разработчиков, о том как классно посчитать усилия в основной программе, а "произвести расчет и конструирование" в ПРУСК.

Поверьте, эту технологию придумали не разработчики, а как раз "опытные пользователи-инженеры". Повторюсь, изначально продукты развивались отдельно, КЭ, расчеты элементов, чертилки. И прдавались раздельно, а потом пользователи пожелали скидывать результаты из одной системы в другую, так и возникла связка MicroFe->BauStatik->VarKon, ну и ее российский аналог.

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

Ну тут прямое противоречие в пожеланиях. Если не делать раскладки арматуры, как можно посчитать трещины и прогибы?
А профиль наверно все эти СКАДЫ-Лиры-MikroFE подбирают, точно знаю только про последнюю.

>>>>Довески" никоим образом не должны служить заплатками на основную прогу, в коем качестве они иногда неофициально позиционируются. К примеру, есть разговоры типа: что армирование колонн надо считать в ПРУСКе, потому что, к примеру, в STARK ES:
1. не учитывается кручение для колонн
2. вроде бы не производится проверка трещиностойкости для 3D-балок
3. в ряде случаев нельзя задать оптимальную схему армирования или посчитать поперечную арматуру и т.п.

А BauStatik (ПРУСК) и не есть "довесок". Правильно посчитать арматуру той же колонны может только эта программа, поскольку по СНиПу расчет принципиально нелинейный. Это кстати к унижительному "сателлит-калькуллятор". А что как позиционировать-рекламировать... не специалист, спорить не могу

>>>>1. объем ввода данных в ПРУСК сильно раздут и слабо структурирован

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

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

Это Ваше ИМХО. Возможно вы просто ее не видите. Конкретные пункты можем пояснить.

>>>>3. Отсутствует порядок в умолчаниях и вводимых данных

Опять неконкретно, что есть "порядок" и его отсутствие

>>>>4. Трудно понять, что еще нужно ввести, почему неактивна кнопка счета?

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

>>>>6. Все это еще и сдобрено парочкой-троечкой глюков

Спасибо за лестный отзыв. Нам до Microsoft далеко, они глюки десятками считают.


>>>>Тут уж позвольте с Вами не согласиться: возьмите пользовательское программирование в AutoCAD, Word, EXEL. Масса людей пишут по-маленьку для себя и других (причем безвозмездно) и отнюдь не от переизбытка свободного времени

Не надо передергивать. Во-первых ни одна из этих программ не занимается серьезными расчетами. Представить себе, что пользователь будет править на свой вкус наш, хотя бы даже алгоритм поиска положения нейтральной линии, могу только в кошмарном сне. а примитивные операции помножить-сложить, перенести данные и т.п. в BauStatik (ПРУСК) есть. И во вторых, >90% пользователей Word даже не подозревают о возможности программирования в нем а половина оставшихся пишет вирусы. И уверен, что подавляющее большинство пользователей двух других систем предпочитает получать (за деньги или "безвоздмездно") готовые таблицы или лиспы, а не заморачиваться с программированием и отладкой. Что касается "безвоздмезности", то я тоже многое делаю "безвоздмездно" (вот с Вами тут дискутирую), но зарплату получаю, как раз за разработку программ.

Впрочем, возможно я недопонимаю Вашей идеи "пользовательского программирования" в расчетных системах. Если она продумана и есть конкретные пожелания (ну вот в такой-то ситуации хотел бы сделать то-то и то-то), а не просто "сделайте мне красиво", то шлите на мыло [email protected]. Может мы совместно родим что-нить новое-оригинальное и все ахнут, и будет достигнута "гармония и всеобщее удовлетворение". (Смайлики не люблю)

На свой вопрос ответа я так и не получил.
Вопрос повис в воздухе.
Ухожу с форума, как говорится, несолоно хлебавши.

[Perezz!!]

На свой вопрос ответа я так и не получил

Странный человек. Тут люди костьми ложаться, а он не видит ни че. :P

[Дмитрий]

Разработчик

Давно зарекся участвовать в дискуссиях на форумах и конфах, пустое это...

Я принимаю сколь-нибудь заметное участие практически только в этом форуме...

пользователи пожелали скидывать результаты из одной системы в другую, так и возникла связка MicroFe->BauStatik->VarKon, ну и ее российский аналог.

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

Опять же пользователи все разные, каждому нужно свое,

Хотел показать начальству положительные отзывы, но их пока нет

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

Нет, конечно нельзя что-то взять и просто выкинуть... Мне кажется, надо сделать так, чтобы количество полей ввода не разрасталось "под ногами" как снежный ком (при большом объеме ввода), где приходится уже "искать концы". Мне как-то больше нравятся закладки-галочки-флажки, хотя может это просто дело привычки...
С ПРУСКом уж так получилось: помучались и бросили... С Вашей подачи осмотрел повнимательнее - признаю, некоторые вопросы отпали.
Сама прога, может не так уж и плоха (как мне показалось на первый взгляд), в конечном счете должно быть разнообразие и альтернатива выбора...

Ну тут прямое противоречие в пожеланиях. Если не делать раскладки арматуры, как можно посчитать трещины и прогибы?

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

А BauStatik (ПРУСК) и не есть "довесок". Правильно посчитать арматуру той же колонны может только эта программа, поскольку по СНиПу расчет принципиально нелинейный. Это кстати к унижительному "сателлит-калькуллятор"

Да че там (по СНиП) уж такого сильно "нелинейного"? Поправка на геометрическую нелинейность - учет прогиба?

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

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

Ну нет, я не предлагаю чтобы все кому не лень изменяли исходный код программы... Такие действия элементарно противоречат типовому лицензионному соглашению: ну там про "декомпиляцию, дизассемблирование" и прочую лабуду...
А вот как-то добавлять собственные функции - думаю, что это хорошо. Например, макрос, которым можно было бы посчитать ж/б сечение с жесткой арматурой (в основе - доступ к результатам расчета РСУ), или макросы, реализующие альтернативный ввод геометрии модели для каких-то специфических задач (в основе - стандартные операции ввода геометрии). По-моему, открытая архитектура программы это безусловный плюс. Из расчетных программ - к примеру тот же ANSYS (множество макросов, десяток генераторов сеток сторонних разработчиков). Думаю, что есть повод для размышлений.
Хотя у разработчиков тут могут быть свои резоны, типа гоните бабки - персонально вам сделаем :wink: .
Извините, я очень кратко, так сказать, тезисно :wink:

По последнему ответу Дмитрия сделаю несколько замечаний.

О трещинах: В формулу (144) СНиПа для ширины раскрытия трещин входит диаметр арматурных стержней. Значит, расчет по раскрытию трещин надо проводить после конструирования. Если при действии нормативных нагрузок ширина раскрытия трещин превышает предельно допустимое значение, то надо определить арматуру, требуемую для ограничения ширины раскрытия трещин.

Значит, нужна программа, которая умеет это делать.

О колонне: Критическая сила для ж/б колонны рассчитывается по формуле (58) СНиПа. Жесткость колонны оказывается в несколько раз меньше Eb*I (это легко проверить по формуле (58)). Она определяется с учетом неупругих свойств материалов и наличия трещин (см. пункт 3.25 СНиПа). Так что надо учитывать не только геометрическую нелинейность, но и физическую. Увеличение расчетного момента путем умножения на коэффициент eta (см. формулу (19) СНиПа) - это учет геометрической нелинейности. Определение критической силы по формуле (58) СНиПа - это учет физической нелинейности. Введение коэффициента eta и приближенной формулы (58) (кстати говоря, использующей результаты испытаний ж/б колонн <см. Труды НИИ ЖБ>) позволяет провести расчет колонны "вручную". Замечу, что разработчики СНиПа обязаны были придумывать упрощенные подходы для того, чтобы можно было провести "ручной" расчет. Они не могли при разработке нормативных документов предлагать такие расчеты, которые невозможно провести без использования компьютера и соответствующих программных средств.
Теперь положение дел изменилось и в новом СНиПе излагаются методы расчета, ориентированные на применение вычислительной техники. Хотя и сохранена возможность "ручных" расчетов. Поэтому в новом СНиПе наряду с методами, основанными на применении диаграмм деформирования бетона и стали и требующими применения вычислительных средств, сохранены приближенные подходы. В тексте Свода правил для их изложения применяется следующий оборот: "Допускается проводить расчет...".

Значит, нужна программа для расчета колонны с учетом геометрической и физической нелинейностей.

О фундаментной плите: Введение коэффициента постели - это прием, позволяющий "избавиться" от грунта и провести расчет фундаментной плиты без определения деформации грунта. В действительности фундаментная плита деформируется совместно с грунтом. Изгибающие моменты в плите и осадка фундамента должны определяться одновременно (т.е. в одной задаче). После того, как решена эта контактная задача, можно вычислить по найденному реактивному давлению грунта 'p' и найденной осадке 'w' коэффициент постели как k=p/w. Коэффициент 'k' является величиной, переменной по площади плиты. Хотя 'k' во внутренних областях плиты изменяется незначительно, его категорически (!) нельзя принимать постоянным по всей плите. Ошибки в определении осадки и изгибающих моментов в плите могут оказаться недопустимо большими. Замечу, что при учете физической нелинейности изгибающие моменты в плите заметно меньше тех, которые определены в рамках линейной задачи. С точки зрения обеспечения прочности фундамента отмеченное обстоятельство имеет очень большое положительное значение.
Решение задачи о совместной деформации плиты и грунта при помощи КЭ-программы вполне резонно. Однако при включении грунта в расчетную схему КЭ-программы придется вводить объемные элементы в пределах заранее неизвестной пространственной области (размер области, которую надо покрыть конечными элементами, можно определить только при помощи итераций). Кроме того, непосредственно под подошвой в сравнительно узкой зоне напряжение 'sigma z' очень быстро убывает при удалении от подошвы (как 1/z*z). Следовательно, в этой зоне нужна мелкая сетка. Кроме того, для учета многослойности грунта (т.е. при кусочно переменном модуле деформации E) придется вводить еще и внутренние границы слоев. Так что трудностей при применении КЭ-программы в этой задаче больше, чем достаточно. Много ли найдется пользователей, который смогут получить приемлемые по точности результаты?

Значит, для расчета фундаментной плиты нужна отдельная программа, в которой корректно решается контактная задача.

Номер формулы, который отобразился в тексте неправильно, равен пятидесяти восьми.

[Дмитрий]

Гость
По поводу нелинейностей ж/б и СНиП: как правило, разработчики ПО для расчета ж/б ограничиваются реализацией тех методик расчета, которые освещены СНиПом. Разработка внешних программ для уточненного расчета с нелинейностями, учетом фактического расположения арматуры и т.п., в которые надо экспортировать результаты (со всеми сопряженными трудностями и ограничениями) мне кажется нецелесообразной. На мой взгляд, лучше встраивать их в в среду пострпроцессора. Возможно, это потребует какой-то оптимизации архитектуры программы, но это будет ей только на пользу. И не надо говорить о "перегрузке и так тяжелой программы КЭ-анализа", во всех ведущих расчетных комплексах прослеживается эта архитектура: препроцессор - решатель - постпроцессор.

Решение задачи о совместной деформации плиты и грунта при помощи КЭ-программы вполне резонно.

Абсолютно согласен.

Значит, для расчета фундаментной плиты нужна отдельная программа, в которой корректно решается контактная задача.

Или процедура в теле основной программы. Но во всяком случае не так, как это сделано в ПРУСКе.

Насчет объемных элементов "упругого грунта":
1. Есть трудности и такого плана: сетка фундаментной плиты должна быть достаточно мелкой, а элементы массива основания могут быть более крупными (особенно в глубоких слоях). Пока функции построения геометрии модели не могут дать такого оптимального разбиения (с переходом крупности 3Д-элементов). Количество объемных КЭ под плитой получается очень большим, а такие задачи - трудно решаемыми с точки зрения аппаратных ресурсов...
2. Отпор грунта в краевых областях плиты получается преувеличенным , соответственно на краях плиты "вылазит" большая поперечная арматура (которой по логике работы конструкции там быть не должно), образуются точки с сильной концентрацией продольного армирования.
В среднем объемные элементы существенно завышают арматуру в плите по сравнению с различными ипостасиями упругих оснований.

О колонне: На мои замечания по вопросу о колонне Дмитрий прислал ответ, в котором утверждает, что для колонн может проводиться самое большее некий "уточненный расчет с нелинейностями". Конечно, в русском языке много оттенков, но "расчет с нелинейностями" - это нелинейный расчет.
В старом СНиПе проведение нелинейных расчетов никак не регламентировалось. В новом СНиПе содержится основа для нелинейного расчета: диаграммы деформирования материалов. Поскольку новый СНиП только что опубликован, а соответствующий ему Свод правил пока не опубликован, сошлюсь на статью разработчиков СНиПа Звездова А.И.,Залесова А.С.,Мухамедиева Т.А.,Чистякова Е.А (Бетон и железобетон,№2,2002).
В конце статьи читаем:"В общем случае влияние продольного изгиба учитывают расчетом железобетонной конструктивной системы по деформированной схеме, определяя деформации железобетонных элементов с учетом их неупругой работы и наличия трещин".

Нелинейный расчет колонны по новому СНиПу реализован, в частности, в программе ООО Техсофт.

О фундаментной плите: Общие рассуждения о решении задачи о совместном деформировании плиты и грунта при помощи КЭ-программы значат мало. Естественная моя реакция такая:"Попробуйте решить!".
А вот программа из ПРУСКа такую задачу решает. И не возникает никакая "большая поперечная арматура" на краях плиты (на свободных краях плиты поперечная сила равна нулю и, следовательно, поперечная арматура по расчету не требуется), и не возникает никакая "сильная концентрация продольной арматуры". А критиковать программу, даже не проведя расчет по ней, неправильно.

Желание проектировщиков иметь программы, написанных как реализация принципа "2 в 1" (или "n в 1") понятно. Но есть ли в настоящее время такие программы? Пока нет (ни в России, ни на Украине). Получается, что существующие программы критикуются не по причине неверных результатов их работы, а из-за того, что они не удовлетворяют принципу "2 в 1".

Э-эх, чего это меня так проняло?

О фендаментных плите и балке (ленточный). Какой бы из используемых ныне методов ни применялся для решения задачи об их совместной с грунтом работе, разбиение ли полупространства на КЭ или то, как это сделано в Статике/ПРУСКе в любом случае решается задача теории упругости, разнятся лишь методы. Решение задачи теории упругости в местах, где есть углы, обращенные внутрь области (в нашем случае это нижний край плиты) содержит особенности, т.е. напряжения стремятся к бесконечности. Попробуйте подробить сетку и увидите, что получится. В реальной конструкции естественно никаких бесконечностей нет, просто вблизи края плиты или балки образуются зоны пластической деформации грунта. Учесть этот факт принципиально возможно, надо только подождать, пока Intel шагнет еще на один порядок. Пока же придется мирится с тем, что любая программа будет давать завышенную арматуру. Мало того, обычно увеличение толщины плиты, приводит к увеличению требуемой арматуры, что соответствует логике расчета, но кажется нелогичным для реальной конструкции.

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

[Дмитрий]

Разработчик, Гость

О трещинах: В формулу (144) СНиПа для ширины раскрытия трещин входит диаметр арматурных стержней. Значит, расчет по раскрытию трещин надо проводить после конструирования.

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

В старом СНиПе проведение нелинейных расчетов никак не регламентировалось. В новом СНиПе содержится основа для нелинейного расчета: диаграммы деформирования материалов.

Как так не регламентировалось? Пожалуйста:

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

и вот
1.31. Расчет плоскостных конструкций (типа балок-стенок, плит перекрытий) и массивных конст¬рукций по предельным состояниям первой и второй групп следует производить по напряжениям (усилиям), деформациям и перемещениям, вычисляемым с учетом физической нелинейности, анизотропии, а в необходимых случаях — ползучести, накопления повреждений (в длительных процессах) и геометрической нелинейности (в основном для тонкостенных конструкций).
Другое дело, не объяснялось как это все делать...
Впрочем, с выходом нового СНиПа принципиально вроде ничего не изменилось. А эти СП 52-101-2003 еще никто здесь в глаза не видел...

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

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

Учесть этот факт принципиально возможно, надо только подождать, пока Intel шагнет еще на один порядок

Вы, вероятно, имеете ввиду то, что считать большие модели с объемными элементами итерационно (т.е. десятки и сотни раз повторять обычный линейный расчет) современным компутерам пока не по зубам? А то простейшие модели грунта (например, Кулона-Мора) уже появляются даже в отечественных программах (та же Лира 9.2), хотя как это там реально выглядит (главным образом, в плане времени счета) пока не видел... В ансисах/настранах такие материалы есть уже давным-давно...
Хотя, я понимаю, что внедрение любых нелинейностей (геометрических, физичеких) для расчетов в масшабах всей модели сопряжено с целым букетом проблем. Например, уже нельзя так легко (пользуясь принципом суперпозиции) комбинировать расчетные сочетания усилий, как того требует СНиП. Т.е. должны просчитываться не отдельные нагружения, а определенные их комбинации, которых, в принципе может быть очень много (все возможные сочетания со своими коэффициентами).
Хотя различные модели упругого основания (3Д-элементы, винклер, пастернак) базируются на одном и том же, результаты получаются довольно разные :wink:

Что же касается встраивания конструктивных расчетов в постпроцессор ("2 в 1"), конечно это реально и несложно

Дык правильно, для чего же еще нужен построцессор в программе, ориентированной на расчеты железобетона и стали? Ну и что тут может быть плохого в разнообразии возможностей (2 в 1, 3 в 1 и т.д.)?