[Разработчик]

Принесли тут фундаментную плиту, стал тестировать и вспомнил пост Дмитрия от 2 ноября 2004

Я говорил, что по формуле СУММА(0.8*SIGMAz/E) нельзя рассчитать осадку произвольной точки фундамента (плитного, столбчатого или ленточного - бэз разницы) как единого целого, а можно только его центра (о чем говорит и СНиП). При этом я не исключаю возможности разбиения фундаментной плиты на n площадок и определения осадки в их центрах, причем обязательно с учетом их взаимного влияния, т.к. это не будет противоречить СНиПу и теоретическим основам данного метода. Эту процедуру можно зациклить и вычислять коэффициент постели под плитой итерационным методом. При этом среднюю осадку (= осадка в средней точке) фундаментной плиты можно определить способом послойного суммирования без лишних ухищрений (как то разбиение на площадки). ЭТО НЕ ПРОТИВОРЕЧИТ СНИП - значит правильно.

Подобный способ описан еще в "Руководстве по проектированию плитных фундаментов" (1984 года), если надо - могу "намылить".

Есть сомнения в справедливости такого подхода, кстати в "Руководстве" ничего такого не предлагается. Можно было бы, конечно, обсудить по мылу, но, поскольку методика изложена публично в профессиональном форуме, могут найтись те, кто последует за гуру и, возможно, совершат ошибку. Вы настаиваете на справедливости такого подхода (рассмотрения плитного фундамента как системы столбчатых) при расчете осадки?

[Дмитрий]

Разработчик

Есть сомнения в справедливости такого подхода, кстати в "Руководстве" ничего такого не предлагается

Какого рода сомнения и несчет чего именно?

Там (в Руководстве) предлагается такой способ:
на контур плиты наносится прямоугольная сетка qf и характеристики основания, нагрузки, осадки и т.п. сводятся к узлам этой сети (вычисляются в них). Осадка каждого узла определяется по формуле метода послойного суммирования...

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

Впрочем, я, кажется, понимаю от чего Вы предостерегаете - столбчатый фундамент чисто в практическом смысле - это подушка (плита), несущая нагрузку от колонны и среднее давление под ним можно определить вполне однозначно как p=F/(a x b), чего, разумеется нельзя проделать для фрагмента фундаментной плиты под колонну, ибо в последнем случае давление определяется не просто как нагрузка/площадь, а исходя из более сложных соображений...

В общем, думаю, возникло простое недопонимание инженера и программиста (ведь Вы же программист?)

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

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

Как правило, все ограничиваются либо равномерным коэффициентом жесткости, либо картинками из "КРОССа", хотя в последнем случае в определении КП не учитывается изгиб плиты и перераспределение давлений...

Мне же как-то больше нравятся объемные элементы...
Досадно, что от этого задача сильно разбухает и подчас посчитать ее уже неподсилу даже неслабой машинке...
В связи с этим, в свою очередь, можно вопрос (извините, что так сразу - просто давненько Вы не заглядывали ): прямые методы разложения матрицы жесткости в старке/микрофии вполне на уровне,
но вот, как показывает практика, в больших задачах они сравнительно малоэффективны (большие затраты памяти, малая скорость)...
Вроде в таких случаях рулят итерационные решатели (PCG и т.п.) или как?
/Вспомнил в связи с недавно всплывшей темой про стык плита-колонна. Там я приводил картинку, обсчитанную в Cosmos Works, где было около 100 000 объемных КЭ и посчиталось все это за ~2 мин, причем и установленные 2 Гб ОЗУ не особо пригодились
С другой стороны, задачи подобной размерности в том же старке (да и не только в нем) посчитать практически невозможно...

[Разработчик]

В общем, думаю, возникло простое недопонимание инженера и программиста (ведь Вы же программист?)

Программист - это временный способ зарабатывания денег, а вообще то я "Ну типа прочнист".
В старом (77г.) "Руководстве", что у меня такого примера (с плитой) еще нет, скачал 84-го, посмотрел. ХитрО это они придумали для неоднородного в плане основания. Я то полагал, что в каждом узле этой qf сетки Вы собираетесь прикладывать нагрузку от соответствующей колонны, потому и засомневался - это неправильно. Но там (в "Руководстве") во всех узлах прикладывается среднее давление и тогда, по существу, получается своеобразный способ осреднения податливости неоднородного в плане основания. На большее этот подход, применительно к плите не годится, т.к. не учитывает ее жесткости, от которой зависит распределение осадок по площади. Но среднее значение осадки при нагрузках, близких к равномерному распределению позволяет вычислять достаточно хорошо.

прямые методы разложения матрицы жесткости в старке/микрофии вполне на уровне, но вот, как показывает практика, в больших задачах они сравнительно малоэффективны (большие затраты памяти, малая скорость)... Вроде в таких случаях рулят итерационные решатели (PCG и т.п.) или как?

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

Там я приводил картинку, обсчитанную в Cosmos Works, где было около 100 000 объемных КЭ и посчиталось все это за ~2 мин, причем и установленные 2 Гб ОЗУ не особо пригодились С другой стороны, задачи подобной размерности в том же старке (да и не только в нем) посчитать практически невозможно...

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

[Дмитрий]

Сообщение от Разработчик Я то полагал, что в каждом узле этой qf сетки Вы собираетесь прикладывать нагрузку от соответствующей колонны, потому и засомневался - это неправильно

Ну, надо полагать, этот вопрос мы решили

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

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

Сообщение от Разработчик С начала 90-х годов я понял, что быстродействие - это аппаратная проблема. Пока программист бьется над повышением быстродействия алгоритма на десятки процентов, электронщики берут порядок. Когда я был молод и делал КЭ программу для СМ4, пришлось решать систему именно итерационным методом - память жала (128К оперативки и четыре жестких диска по 1Мб). Так что я сам такие методы люблю. Но наши спецы по решателям проанализировали (есть ведь много публикаций на эту тему) и выбрали то, что наиболее эффективно, ну там и сами что-то доработали, есть у нас сильные ребята

ИМХО, проблема быстродействия комплексная...
Посмотрел кое-какие материалы в инете (досадно, что по МКЭ на русском языке почти ноль, у буржуев - пожалуйста, вплоть до исходников программ), вроде как прямые методы, даже самые хорошие, практически упираюся в 500 000 DOF (кстати, вспомнилась фраза с одного из семинаров: "а зачем вам большие задачи? Мы вот "Воробьевы горы" целиком посчитали с 15 000!" ). Дальше уже целесообразно применять итерационные решатели, тот же Preconditioned Conjugate Gradient или более продвинутые (вроде у скадовцев что-то такое есть в заначке - смотрите, обставят ).
Во всяком случае, серьезные буржуйские расчетки давно имеют в арсенале как прямые, так и итерационные решатели.

Сообщение от Разработчик McroFe2004 без проблем рубит лимон неизвестных

Возможно, но какими усилиями и ресурсами?
За 2-3 минуты задачку в 100 000 элементов (около того же миллиона DOF) опять-таки врядли прожует

[Разработчик]

Дальше уже целесообразно применять итерационные решатели, тот же Preconditioned Conjugate Gradient или более продвинутые (вроде у скадовцев что-то такое есть в заначке - смотрите, обставят ). Во всяком случае, серьезные буржуйские расчетки давно имеют в арсенале как прямые, так и итерационные решатели.

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

За 2-3 минуты задачку в 100 000 элементов (около того же миллиона DOF) опять-таки врядли прожует

2-3 или 7-8, не принципиально. Принципиально - считать правильно, т.е. использовать те элементы, которые надо, правильно строить расчетные схемы, автоматизировать некоторые итерационные процессы (не пропускать через пользователя), да мало ли еще вопросов, куда более важных, связанных с механикой, конструированием и пр. Было время, решатель стал тормозом в реализации этих задач - его улучшили и снова взялись за дело. Когда и если возникнут проблемы - улучшим еще раз.

[Дмитрий]

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

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

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

[Разработчик]

Просто я пару раз пытался соорудить такие модели в СТАРКе (сами по себе здания были большие 20-25 эт., да еше основание), но это скорее напоминало мазохизм . То памяти не хватало, то диска

Ну было, было... Наши сами ругались, когда приходилось большие проекты загружать (мы ведь тоже расчетами немного занимаемся). Потому и переделали все на новых идеях, теперь журчит весело и ненапряжно в MicroFE2004/2005, а СТАРК - отработанный материал. В нем некоторые проблемы принципиально невозможно было решить, почему - не скажу, стыдно, причина банальная и чисто российская.