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

[Rotfeder]

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

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

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

1)Про большинство программ, думаю, это спорный вопрос.

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

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

4) исторически, сначала предпочитали выводить значения усилий в центре элементов - так было удобнее анализировать результаты, т.к. графики не было, или она была плохая. Потом, перешли к узловому выводу - он позволяет более качественно строить изолинии и изополя.
Лира - программа с большим хвостом - в ней вывод в центре элемента.
У MicroFe - хвост по-меньше - там вывод по узлам.
Собственно говоря, во всем есть свои плюсы и минусы.
Имея усилия в центре элемента, можно отчасти избавится от сингулярностей решения. С другой стороны, нельзя проконтролировать правильность решения. Если вы получили большие усилия на свободном крае плиты - это повод задуматься о правильности расчетной схемы и возможно исправить ошибку. При выводе усилий в центре элемента программа вам такого шанса не дает, а эти большие усилия на краю никуда не денуться - они есть, только вы их не видите. И решение в центре элемента тоже искаженное.

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

[Дмитрий]

Rotfeder

Как я понимаю, речь идет об арматуре

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

1)Про большинство программ, думаю, это спорный вопрос

ЛИРА, СКАД, РОБОТ. С узловым выводом, кроме STARK/MICROFE так сразу и не вспомню (подскажите, если знаете)...

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

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

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

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

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

А Вы за ее попсовость?

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

Понятно, что проблем и так куча (а кому сейчас легко?)...
Просто, думаю, есть вещи фундаментального характера (чтоб их потом переделать - придется, вероятно, перетрясти очень многое), а есть косметического. В общем, тут надо смотреть, думать...

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

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

Анализ обсуждений на этом форуме отчетливо показывает, что проектировщики редко высказывают запросы на разработку новых программных средств или на модификацию существующих. Чаще они пытаются отыскать подходящие программы из числа имеющихся. И эдесь дело не в стоимости разработки или модификации, а дело в менталитете. Я думаю, что программа ViCADo2005 найдет много пользователей, как, например, когда-то нашла их программа Arcon.

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

[Rotfeder]

Сообщение от Дмитрий С настраиваемым вариантом долго возиться для достижения приемлимого результата,

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

ЛИРА, СКАД, РОБОТ. С узловым выводом, кроме STARK/MICROFE так сразу и не вспомню (подскажите, если знаете)...

У скада ноги растут из лиры, так что в данном случае - это не отдельная программа.
А как насчет всяких там стадов, ансисов, настранов и т.п.?
Я не такой уж спец по интерфейсу КЭ-программ -

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

А зачем? Если вести речь только об усилиях, то значения усилий в узлах более информативны.
По предыдущему нашему разговору вопрос не в том, в каких точках считать усилия, а в том, какие брать усилия для армирования.

А чем это у вас элементы ВЫСОКОточные? :wink: Количество узлов ведь то же... Или функции формы используются иные, чем в элементах ЛИРЫ (вроде это обычный полином, степень которого определяется числом узлов КЭ)?

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

Когда говорят о точности элемента, то имеют ввиду две вещи
1) сравнивают точность решения разными элементами для одной задачи с одним и тем же шагом сетки. Чье решение ближе к точному - тот элемент лучше.
2) Сходимость задачи к точному решению при измельчении сетки.
Есть некие стандартные тестовые задачи, на которых проверяется сходимость.
В общем, когда-то проводились сравнительные тесты, по результатам которых мы выглядили лучше. Они даже были вывешены на еврософтовском сайте, только сейчас я их там почему-то не нашел. А к себе мы их пока не успели повесить.

Можно считать по запросу в расчетном ядре и использовать для армирования либо то, либо другое, но это излишнее усложнение программы А Вы за ее попсовость?

Я за бритву Оккама и неумножение сущностей. Чем сложнее программа, тем сложнее избежать ошибок. Это не лень разработчика, а суровая правда жизни

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

[Дмитрий]

golov

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

Опять же, выпуск компьютерного "железа" и т.п. За всем этим прежде всего стоит стремление производителя к банальному вытягиванию из потребителя дополнительных денег, и, как следствие, конкурентная борьба, мода и т.д. В позиционировании тех же мобильников упор давно уже деляется не на их прямую функциональность, а на всевозможные аппендиксы и приблуды, или на ощущение обладателем оного изделия некоей автоматической коррекции своего социального статуса :wink:

Анализ обсуждений на этом форуме отчетливо показывает, что проектировщики редко высказывают запросы на разработку новых программных средств или на модификацию существующих

А их часто спрашивают? К тому же, сами знаете, что подавляющее большинство проектировщиков у нас сидят на САПРе, купленном за 100 р. на рынке... Какие (и к кому?) в этом случае могут быть вопросы и претензии?

Я думаю, что программа ViCADo2005 найдет много пользователей, как, например, когда-то нашла их программа Arcon

ARCON ориентирован, насколько я знаю, на архитекторов-дизайнеров. Традиционно уж так сложилось, что конструкторы (а раскладка арматуры и т.п. - их скорбный удел ) у нас работают в основном с AutoCAD (что необходимо и, в принципе, достаточно) и всякие архитектурно-рисовальные проги "не под АКАД" (равно как и всякие ихние трехмерные модели зданий) им совершенно чужды. Удачных опытов автоматизации проектирования (тех же ж/б конструкций) на основе "скрещивания" архитектурно-рисовальной 3D-модели здания с конструктивом в "одном флаконе" я не знаю (разве что слышал что-то неопределенное про AllPlan).

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

[Дмитрий]

Rotfeder

А чего возиться? Один раз настроил, как нравится и забыл.

Возится надо в процессе настройки палитры. Да, настройки запоминаются (версия у меня 3.1), но ведь "случаи-то бывают разные": удаление/переустановка программы, эпизодическая работа на другой машине и т.п.
И мое недовольство обращено в адрес единственной стандартной палитры заливки. Убогая она у Вас какая-то, невнятная, больше похожая на детский акварельный рисунок, чем на графическое представление результатов
Для сравнения (и на суд посетителей, не являющихся юзерами СТАРКА) привожу варианты стандартной заливки в разных расчетных программах, реализующих МКЭ: Stark ES, Robot Millenium, PLAXIS 3D Tunnel. Правда, в поледнем случае палитра не красно-синяя, а спектральная (за наличие которой в Stark/MicroFE я также ратую)...
To be continued...
[ATTACH]1102071681.gif[/ATTACH]

[Дмитрий]

Rotfeder

А как насчет всяких там стадов, ансисов, настранов и т.п.? Я не такой уж спец по интерфейсу КЭ-программ

Насколько я знаю, в ансисах/настранах есть возможность посмотреть как узловые, так и элементные результаты.

Цитата: Так почему бы не считать усилия в точках, не принадлежащих ни узлам, ни центру КЭ. А зачем? Если вести речь только об усилиях, то значения усилий в узлах более информативны

Насчет информативности: а чем значения в, скажем, 3 или 4 внутренних точках менее информативны, чем значения в таком же количестве узлов элемента?

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

На самом деле это вопросы тесно взаимосвязаны...
Мы пришли к выводу, что проблемы с армированием у Stark'а имеют двойственную природу:
- с одной стороны, несовершенство алгоритма вычисления площади армирования ж/б сечения (неадаптированность к работе с результатами анализа по МКЭ);
- с другой стороны, раз уж мы используем МКЭ, неизбежно сталкиваемся с последствиями разной степени тяжести, проявляющиеся в искажении усилий, вызванными идеализацией и дискретизацией расчетной схемы (неучет реальных размеров сопряжений и опирания конструкций и т.п.) или самой внутренней математикой элементов (это дело совсем темное).
Первой "дырке" мы обязаны "хроническим" занижением прочности ж/б плит в расчете по наклонным сечениям - тут понятно, где искать "корень зла"...
Со вторым лицом "двуликого ануса" ситуация, надо полагать, посложнее будет... Понять, где действительно сильно напряженный участок плиты/стены, а где гипотетический "всплеск" чего-то там - без стаканА не всегда получится
В общем, такие вопросы подчас оперативно можно решить только в меру личной безответственности, положив в каком-то месте арматуры меньше, чем требуется оной по расчету
Поскольку умозрительно определить причину "всплеска" арматуры в каком-то узле простому и так затюканому заказчиками-экспертами пользователю довольно проблематично, я и предлагаю такой механизм: вычислять усилия не в самих узлах (где решение может быть неустойчиво), а в нескольких внутренних точках элемента, удаленных от узлов, скажем, на 1/3 или 1/4 расстояния от данного узла до центра элемента. Усилия в таком случае будут вычисляться не в "точечной опоре", а уже на некотором расстоянии, что может заметно смягчить подобные вредные эффекты МКЭ. И информативность результатов от этого нисколько не утратится.
Также это помогло бы кардинально решить проблему со скачками поперечных сил на опорах (где вместо +/-Qmax получается Q=0 и приходится делать с каждой стороны разные KNFL) без всяких плясок с бубнами
Есть, на мой взгляд, и другое возможное приложение реализации stress points - учет реальных размеров сечений элементов в узлах сопряжения (об этом сейчас тоже много говорят). Т.е. если положение stress points в элементе сделать произвольным, то, в принципе, с их помощью можно вычислять усилия (скажем, в плитах перекрытий) в месте опирания не по центру, а по грани стены...
В общем, думается, что все это весьма перспективно...
Жаль, что вот сделать полноценное сравнение того и другого непросто... Неузловое вычисление усилий, насколько я знаю, реализовано пока только в семействе программ PLAXIS.

Я за бритву Оккама и неумножение сущностей. Чем сложнее программа, тем сложнее избежать ошибок. Это не лень разработчика, а суровая правда жизни

Есть такой нехитрый маркетинговый прием, особенно часто сталкиваешься с которым при общении с продавцами магазинов бытовой и компьютерной техники - покупатель спрашивает продавца о чем-то таком, чего у них нет или они просто не в курсе, "менеджер" тотчас делает умное лицо и авторитетно заявляет: "ЭТОГО у нас не было, нет и не будет!", потом объясняет что ЭТО де полный отстой, говно, которое "на самом деле" и даром никому не нужно, ну и т.д., после чего спокойно, без суеты, объясняет покупателю, ЧТО ему действительно необходимо (рассказывает "правду жизни" и т.п.) и впаривает уже то, что у них есть...
К чему это я? А-а, так выпьем же за то, чтобы самим не уподобляться таким "менеджерам"!
To be continued...

[Дмитрий]

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

В ходе тестирования проверялось соответствие рассчитанных параметров НДС плиты принятой гипотезе ее одноосного
напряженного состояния и выясним точность решения.
Учитывая критику предыдущих результатов, в данной модели:
1. увеличена точность дискретизации: по ширине плиты 5 КЭ.
2. опоры смоделированы закреплением перемещений по осям Z, X, Y.
3. для модели STARK ES созданы KNFL по пролетам (для передачи скачков поперечной силы, иначе в одних и тех же узлах значения будут осреднены Q+(-Q)=0)

Модель рассчитана в программах:
1. STARK ES (использовался 4-узловой четырехугольный "гибридный" КЭ оболочки, усилия определяются в 4-х узлах)
2. PLAXIS 3D Tunnel (использовался 8-узловой четырехугольный КЭ плиты (теории плит Миндлина), усилия определяются в 4-х stress points, не совпадающих с узлами КЭ)

На рис. результаты расчета в Plaxis и Stark ES
[ATTACH]1102104526.gif[/ATTACH]

[Дмитрий]

2-я картинка
[ATTACH]1102104795.gif[/ATTACH]

[Дмитрий]

Для Stark'а провожу также эпюру усилий по ширине сечения.
Для Plaxis'а усилия по ширине плиты практически не изменяются (подтверждая принятую гипотезу одноосного НДС)
[ATTACH]1102105193.gif[/ATTACH]

[Дмитрий]

Итак, некоторые выводы:
1. Результаты Plaxis'а практически повторяют "балочные" как по форме (по ширине сечения усилия не изменяются), так и по содержанию:
Mmax=103.56 кНм/м (балочное Mmax = 104.9 кНм)
Qmax/min = +/- 97.49 кН/м (балочное Qmax/min = +/- 97.5 кН)
Причем это "голые" результаты, без всякого интегрирования и осреднения...
2. У Stark'а ошибка вычисления (количественная и, особенно, качественная - по равномерности НДС) заметна:
Mmax=92.47 кНм/м (-12%)
Qmax/min = +/- 141.23 кН/м (+45%)
Ошибка приведена для локальных значений, а не осредненных по сечению, т.к. расхождение с принятой гипотезой также считаем ошибкой /поскольку в конструировании используем также в основном локальные значения/
3. "Паразитный" момент My~20 кНм численно по обеим программам практически совпадает (кроме характера эпюры по ширине, у плаксиса он также равномерен). "Паразитные" поперечные силы по рез-там плаксиса ->0, для СТАРКа +/- 78.5 кН/м, достигая максимумов на краях сечения.

Чем объясняется столь высокая точность решения PLAXIS? Возможно, пресловутыми 8-узловыми элементами (хотя в Robot'е они тоже есть, но звезд с неба он в данном случае тоже не хватал), возможно, просто более продвинутой технологией вычисления усилий...
Со STARK, к сожалению, не все так идеально :cry:
Где же обещанные "высокоточные" гибридные сорта конечных элементов?
Конечно, если все проинтегрировать, осреднить по сечению, картина устаканится, в реальных пространственных моделях ведь же не влезешь со своим видением "устройства мира"
Что за усилия вычисляются в узлах сложных моделей, сказать уже и не берусь, но с простейшей плитой-балкой имеем погрешность для Q почти 50% и солидный довесок блох-"паразитов"...
Так что предмет для разговора все же есть :wink:

[Дмитрий]

До кучи приведу результаты ЛИРЫ:
Mx,max = 81.9 кНм/м (-22%)
Qx,max= 82.6 кН/м (-15%)

Ошибка также приличная (причем не в запас, а в "минус"), но она чисто по значениям, т.к. по "качеству" картина усилий вполне равномерна, "паразиты" незначительны.

На картинке изополя, эпюры по разрезу вдоль и поперек (на средней опоре).
[ATTACH]1102154198.gif[/ATTACH]

[Дмитрий]

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

Просчитал все ту же плиту-балку со всеми тремя типами элементов. Самые худшие результаты (особенно по Q) дают как раз гибридные КЭ. Результаты "КЭ метода перемещений" наиболее приемлимые:
Mmax = 109.8 (+4.7%)
Qmax = 108.9 (+12%)

ЗЫ. А настроенная мною палитра в СТАРКе после переключение на стандартную почему-то слетела
[ATTACH]1102156594.gif[/ATTACH]

[Дмитрий]

В продолжении темы о том, насколько правдоподобны "узловые" усилия, приведу другую задачку: ячейка плоского перекрытия (6х6), опирающаяся на колонну 0,4х0,4 м.
Сравним наиболее расхожий вариант моделирования такого узла (просто стержень+плита) с, на мой взгляд, наиболее точным, где колонна смоделирована призматическим телом из объемных КЭ.
В "обычном" варианте шаг сетки 0,5х0,5 м, в "точном" - 0,1х0,1 в зоне стыка (участой 2х2 м), остальные 0,2х0,2 м.
Нагрузка на плиту (толщиной 20 см) 1 т/м2 + собств. вес, краевые условия плиты - "плавающая заделка".
По результатам Stark:
1. Момент в узле сопряжения Мх = 145,9 кНм, армирование AsX=31.85 см2/м - для простого примыкания стержня
2. Для уточненного варианта Мх=78,82 кНм/м, AsX=16.4 см2/м
Причем, измельчение сетки для 1-го варианта только усугубляет ситуацию, так что получается парадокс: увеличение точности сетки приводит к росту ошибки в узле опирания...
[ATTACH]1102272094.gif[/ATTACH]

[Дмитрий]

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

Приведу для сравнения результаты с этими моделями.

1. С жестким телом.
Как видно по картинке, усилия внутри области сечения колонны сильно искажаются-"проваливаются" до нуля, резко выправляясь уже во внешней области. Неаккуратно (картина НДС мало соответствует "истинной)", но более-менее точно: 109/12.
[ATTACH]1102272760.gif[/ATTACH]

[Дмитрий]

Вариант с CL-PL.
Эффект вообще сомнителен...
Та же ассимптотичность моментов, значения приближаются к "общеузловому".

ЗЫ. В общем, похоже, тут сначало все-таки надо разобраться с адекватностью усилий в узлах пластин на опорах, потому что такие вещи ("скачкИ" в 2 и более раз) как-то "сгладить" при постпроцессорной обработке будет проблематично
[ATTACH]1102273427.gif[/ATTACH]

[Николай Баглаев]

Дмитрий

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

При решении задачи с абсолютно твердым телом нужно специально определять KNFL для сечения колонны.

При использовании CLPL моменты сглаживаются, кроме того, при измельчении сетки пик не растет.

[Дмитрий]

Николай Баглаев

Задача правильнее всего решается с объемными элементами - это действительно так. Но в объемных элементах нельзя подобрать армирование (по крайней мере в нашей программе )

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

При решении задачи с абсолютно твердым телом нужно специально определять KNFL для сечения колонны

Это придется делать вручную? К тому же, количество KNFL ограничено где-то 1290...

При использовании CLPL моменты сглаживаются, кроме того, при измельчении сетки пик не растет

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

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

Может и мне написать парочку review для вашего сайта?

[Rotfeder]

Сообщение от Дмитрий Итак, некоторые выводы: 1. Результаты Plaxis'а практически повторяют "балочные" как по форме (по ширине сечения усилия не изменяются), так и по содержанию: Mmax=103.56 кНм/м (балочное Mmax = 104.9 кНм) Qmax/min = +/- 97.49 кН/м (балочное Qmax/min = +/- 97.5 кН) Причем это "голые" результаты, без всякого интегрирования и осреднения... 2. У Stark'а ошибка вычисления (количественная и, особенно, качественная - по равномерности НДС) заметна: Mmax=92.47 кНм/м (-12%) Qmax/min = +/- 141.23 кН/м (+45%) ... Чем объясняется столь высокая точность решения PLAXIS? Возможно, пресловутыми 8-узловыми элементами (хотя в Robot'е они тоже есть, но звезд с неба он в данном случае тоже не хватал), возможно, просто более продвинутой технологией вычисления усилий... Со STARK, к сожалению, не все так идеально :cry: Где же обещанные "высокоточные" гибридные сорта конечных элементов?

Дмитрий. Вернувшись после выходных и почитав ваши послания был поражен тем, с какой подробностью вы проработали вопрос о сведении решения задачи из области теории плит к балочной постановке. Прилагаю картинку, полученную в MicroFe 2004 (в Старке тоже можете получить что-то подобное. Лень было возиться с мелкими сетками, тем более, что реузультат и так близок к идеальному (с вашей точки зрения). Qx вдоль разреза меняется в пределах -95 ...-96 кН/м при точном 97,5. Тут сетка - только 4 элемента по сеччению, так что простим программе 1,5 кН, недостающих до балочного решения.
Секрет прост - надо положить коэффициент Пуассона равным нулю. Все эффекты, которые привносит теория плит уходят - остается практически чисто балочное решение, которое вы по какому-то недоразуменю считаете точным.
[ATTACH]1102329344.gif[/ATTACH]