Логика в том, что все эти конструкции работают в линейной зоне. А считать вы можете в любой постановке... Особенно те конструкции и детали, которые летают. Или вы то же будете доказывать, что то что летает при полете работает в области пластики?:=) И как меняются свойства материала после такого полета?:=)

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

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

Жуть какая :) Но меня не интересует что прописано у вас. Я ответил что должно быть прописано.

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

@Бестолковый Немного тупиковый путь в обозначениях. Знаете почему? Напишите мне пожалуйста, какой шифр будет у одной и той же детали, которая будет входить и в субСБ, и одновременно, в субсубСБ? Классификатор ЕСКД не зря придумали. Люди не любят его использовать т.к. уходит много времени для определения шифра ДСЕ, но я считаю его использование правильным путем в применении обозначений. Вариант решения написал Вам в личку, если не против могу выложить и сюда.

да, примерно так   она создаёт монолитное твёрдое тело, а не сетку.

Потому что весь софт в Логосе написан и отлажен для этого супер-пупер компьютера.  Реальный расчетчик не будет считать пластику. И уж тем более не будет денег платить за аренду. И отдавать свои модели дяде.  Все что ползает, летает, ныряет и ... все надежные конструкции работают в линейной зоне. А вы на своей кафедре можете считать и в глубокой пластике. А как иначе диссертации защищать? :=) Должна же быть какая-то актуальность и новизна...

А какого рода режимы?

Очень сильно зависит от версии Teamcenter и от организации хранения иконок. Начиная с версии 9 иконки можно хранить непосредственно в БД. Можно, но не обязательно :) Например у нас тщательно перетаскиваются костыли от версии к версии ещё с 90-х годов, Поэтому и почти все иконки хранятся только в плагинах к RichClient.